Як і у випадку з багатьма іншими речами, пов'язаними з розробкою WordPress, найкращий спосіб розібратися в константі WP_DEBUG_LOG - це знайти її в коді ядра WordPress.
Важлива ділянка коду знаходиться в файлі wp-includes / load.php:
Якщо ви встановите WP_DEBUG в true, задасте WP_DEBUG_DISPLAY в false і WP_DEBUG_LOG в true, то в такому випадку всі помилки будуть виводитися в файлі debug.log у вашій папці wp-content; в PHP інформація про помилки буде відсутній.
Щоб задати ці константи, ви повинні додати наступні рядки в свій wp-config.php:
Але навіщо це робиться?
1. Щоб приховати помилки
Чи подобається вам бачити помилки в веб-браузері? Ви дійсно впевнені, що вам виводиться абсолютно все? Що з приводу блоків div, прихованих за допомогою CSS? Що з приводу AJAX-запитів?
Інтерфейс - не найнадійніше місце, щоб відловлювати помилки. Лог-файл PHP показує абсолютно все.
2. Щоб відловити всі помилки.
Може бути, ви любите використовувати такі плагіни, як Debug Bar або Query Monitor, для вилову помилок, і вам їх цілком вистачає. Я не звинувачую вас в цьому. Ці плагіни дійсно круті.
Однак я виявив, що вони пропускають деякі помилки. Я підозрюю, що це викликано їх натурою - адже вони є плагінами, і перед ними можуть завантажуватися інші плагіни. Звичайно, ви можете змінити порядок завантаження, щоб вони завантажувалися на самому початку, однак як бути щодо помилок в мультісайтового плагинах і в самому ядрі WordPress? Крім того, як я виявив, помилки з Strict Standards не враховуються цими плагінами.
Ці плагіни ідеально підходять для різних речей, проте у випадку з виловом всіх PHP-помилок на них покладатися не варто. PHP сам по собі - це надійне джерело звітів про помилки, і саме такий звіт ви знайдете в debug.log.
3. Щоб прибрати помилки сторонніх плагінів.
Все це прекрасно, якщо ваш код видає помилки. Ви можете їх виправити.
Але як бути зі сторонніми плагінами, які ви активували? Як бути, якщо вони видають попередження і повідомлення всюди у вашому інтерфейсі? А оскільки ви включили звіти WP_DEBUG, ви отримуєте повідомлення, попередження, невідповідність стандартам і т.д. Перебір. Це може заважати і зробити практично неможливою роботу з певними активованими плагінами.
У минулому я просто б деактивував такі плагіни. Чи не найкраще рішення. Крім того, як бути, якщо ви не можете працювати без цих плагінів? Раніше я просто відключав WP_DEBUG. Ганебно, я знаю.
На даному етапі я буду просто вважати, що переграв вас. Ви вже додали константи вище в wp-config.php і підключили debug.log. Тепер ви можете відстежувати і фільтрувати debug.log.
Відстеження і фільтрація debug.log
Крім відстеження debug.log на помилки, вам, природно, знадобиться прибрати з нього весь шум, створений сторонніми плагінами. Інакше ваші «правильні» помилки можуть потонути в цьому шумі.
Безумовно, деякі люди використовують додаток Console в OS X для зчитування лог-файлу, яке має свою фільтрацію зайвого шуму від сторонніх плагінів. Звучить цікаво, хоча сам я це не пробував. Я вирішив піти обхідним шляхом.
Я написав PHP-скрипт. Він просто відстежує лог-файл на зміни і видає повідомлення про помилки. Він може також фільтрувати всі Xdebug блоки, грунтуючись на регулярних виразах, що дозволить вам ігнорувати попередження і повідомлення з боку сторонніх плагінів.
Один debug.log для всіх сайтів
Раніше я використовував окремі логи debug.log для всіх сайтів, які у мене є в середовищі розробки. Коли я переключався на інший сайт, щоб працювати з ним, мені потрібно було також відстежувати вже інший лог-файл. Чи не найкраще рішення.
Тепер у мене для всіх сайтів заданий один лот. Зробив я це за допомогою простого плагіна. Я додав наступний код в wp-content / mu-plugins / custom-debug-log-path.php для кожного сайту:
Тепер мені достатньо було стежити за одним балкою для всіх своїх розроблюваних сайтів.
Такий підхід працює просто чудово. Звичайно, є ще багато поліпшень, які можна зробити, проте мені цілком вистачило такого звіту про помилки.
Чи використовуєте ви схожий звіт про помилки? Які поліпшення ви можете запропонувати?