Читання та розуміння журналів помилок WordPress, частина 1

Оскільки ми продовжуємо розглядати, що означає бути незалежним розробником WordPress, необхідні інструменти та різноманітні стратегії, які можуть покращити наш набір навичок, я розповідав про різні константи, плагіни та інструменти, які нам допоможуть.

Якщо ви просто випадково натрапили на цю публікацію, то я рекомендую ознайомитися з моїм довідником щодо нативних інструментів налагодження WordPress, а також з рештою публікацій із серії .

Зрештою, я вважаю важливим, щоб ми всі працювали на одній основі – або на чомусь тісно пов’язаному – коли розглядаємо цю інформацію.

Зрештою, використання такого інструменту, як Xdebug, є незамінним, але ми повинні працювати над цим (для тих, кому цікаво, я написав короткий посібник про це трохи більше року тому).

А поки що почнемо з основ. У попередньому дописі я залишив таке твердження:

У наступній публікації ми почнемо дивитися на те, що необхідно для вивчення журналу помилок, який генерує WordPress, і як зрозуміти інформацію, яку ми бачимо.

І саме це я хочу розглянути сьогодні, тому що це дасть вам щось практичне, над чим можна працювати.

Розуміння журналів помилок WordPress, частина 1

Перш ніж заглиблюватися в це питання, я хочу відповісти на одне запитання, яке поставив учасник сайту.

А саме мене запитали:

Коли ми подивимося на об’єктно-орієнтовані принципи?

Хоча я трохи розповідав про це в попередніх серіях, я працюю над тим, щоб детальніше розглянути це пізніше в цій серії.

З огляду на це, давайте почнемо переглядати журнали помилок.

Налаштування ваших констант

Якщо ви не налаштували константи у своєму файлі wp-config.php, я рекомендую зробити це зараз, оскільки це дасть вам найбільший рівень деталізації під час вивчення будь-яких проблем, які можуть виникнути.

Якщо ви ще не наздогнали, обов’язково прочитайте цю публікацію (а якщо так, переконайтеся, що у вашому файлі конфігурації визначено наступні константи ):

<?php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );
@ini_set( 'display_errors', 1 );
define( 'SCRIPT_DEBUG', true );
define( 'SAVEQUERIES', true );

Коли вони встановлені, у вас є все необхідне, щоб не лише бачити інформацію на екрані, але й у журналі налагодження, який створюватиме WordPress.

Де колода?

Залежно від природи вашого оточення це може змінюватися; однак у більшості випадків ви знайдете debug.log у каталозі wp-content над каталогами plugins, themes і uploads.

Як ви можете бачити з попереднього перегляду знімка екрана вище, мій файл налагодження містить багато вмісту. У наступному розділі ми розглянемо це більш детально, а також розглянемо, як це зрозуміти. Проте тим часом перевірте, чи цей файл взагалі існує. Якщо він існує, тоді сміливо перегляньте вміст файлу. Ви можете розуміти або не розуміти багато чого з того, що відбувається, але вміст у файлі означає, що щось у темі чи плагіні викликає різні попередження PHP, сповіщення та помилки, які WordPress виловлює та скидає до файлу журналу.

Що взагалі означає файл журналу?

Це не обов’язково означає, що щось зламано, але це вказує на те, що щось не працює належним чином, не виявляється належним чином і не обробляється на програмному рівні, або просто робить щось, чого робити не повинно.

Це не повинно виглядати так (але може!).

Як розробники, ми повинні прагнути переконатися, що наш код не генерує нічого, що може бути записане в журнал помилок.

Одна справа – робити це в процесі розробки, оскільки ми можемо отримати уявлення про те, що ми робимо та як працює WordPress. Але інша справа, коли ми випускаємо на виробництві такі речі.

Читання журналу помилок

Очевидно, читати журнал помилок не просто відкривати його. У багатьох складається перше враження, що це може бути купа жаргону. Я теж це розумію. Але коли ви розумієте, що це вам показує, це набагато легше зрозуміти.

Отже, давайте розглянемо дуже простий приклад. Це також не надуманий приклад. Фактично, це те, що походить від плагіна, над яким я працював. Журнал помилок містить таку інформацію :

[05-Jul-2018 19:43:53 UTC] PHP Fatal error:  Uncaught Error: Class 'EasyEmailExportAdminEmailExportSubmenu' not found in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php:37
#8 /U in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 37
[05-Jul-2018 19:44:03 UTC] PHP Warning:  include_once(./src/Admin/EmailExportSubmenu.php): failed to open stream: No such file or directory in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25
[05-Jul-2018 19:44:03 UTC] PHP Warning:  include_once(): Failed opening './src/Admin/EmailExportSubmenu.php' for inclusion (include_path='.:/usr/local/Cellar/php/7.2.5/share/php/pear') in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25

Зверніть увагу, що в наведеній вище суті є три рядки. Найкращий спосіб дій під час читання журналів помилок — почати знизу та просуватися вгору. Це пояснюється тим, що речі під час виконання працюють у стеку.

Короткий екскурс про стеки

Я не буду вдаватися в визначення цього терміну з інформатики, але код виконується і працює таким чином, що функції виникають і буквально в пам’яті комп’ютера накладаються одна на одну.

Таким чином, останнє, що потрібно запустити, завжди буде вгорі, а корінь, з якого він починається, знаходиться внизу. Оскільки ми пишемо код для вже існуючої програми, тобто WordPress; тоді наш код, імовірно, завжди буде вгорі.

Розуміння журналів помилок WordPress: це не такий стек

Ідея полягає в тому, що код почне виконуватися в WordPress і працюватиме так, як ми виконуємо. Коли є сповіщення, попередження чи помилка, зазвичай це щось у нашому коді (хоча WordPress не є винятком, це зазвичай так).

Отже, коли ви читаєте журнал помилок, ви, по суті, читаєте те, що називається трасуванням стека. У Вікіпедії, як за посиланням, є досить глибоке визначення теми, але, мабуть, найбільш актуальним для цієї публікації є наступне:

Програмісти зазвичай використовують трасування стека під час інтерактивного та постмортального [налагодження] (https://en.wikipedia.org/wiki/Debugging). Кінцеві користувачі можуть бачити трасування стека, що відображається як частина повідомлення про помилку, про яке користувач може повідомити програмісту.

Це джайв з тим, що я описав вище, правда? Але досить говорити про те, що таке трасування стека (це стане зрозумілішим, коли ми поглибимося в налагодження), давайте повернемося до читання файлу журналу в його поточному вигляді.

Назад до читання журналу

Включно з файлами

По-перше, давайте розглянемо нижню частину вищезазначеного. Він містить наступне:

[05-Jul-2018 19:44:03 UTC] PHP Warning: include_once(): Failed opening './src/Admin/EmailExportSubmenu.php' for inclusion (include_path='.:/usr/local/Cellar/php/7.2.5/share/php/pear') in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25

Це означає, що в рядку 25 мого файлу easy-email-export.php не вдалося відкрити файл для включення. Це означає, що в коді є оператор include_once, який посилається на ./src/Admin/EmailExportSubmenu.php, який він не може знайти.

Отже, найкращим способом дій було б знайти рядок 25 і визначити, чому він не знаходить файл. Можливо, це повний шлях до того, куди він дивиться. Ми миттєво торкнемося цього, коли будемо говорити про запис у журнал помилок.

Осмислення помилок

У наступному рядку (тобто рядку над тим, який ми щойно розглянули) міститься наступне:

[05-Jul-2018 19:44:03 UTC] PHP Warning: include_once(./src/Admin/EmailExportSubmenu.php): failed to open stream: No such file or directory in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25

Цей конкретний рядок лише трохи відрізняється, але він дає додаткове розуміння, і це міститься в пункті, який читає «Немає такого файлу чи каталогу». Це корисно, оскільки воно буквально говорить нам, що файл не існує.

Принаймні, його не існує там, де він дивиться. Отже, є дві можливості:

1. ми не створили файл, на який ми посилаємося,
2. ми вказуємо розташування файлу не в тому місці

Таким чином, перше, що нам потрібно буде перевірити, це чи існує файл у місці, яке ми намагаємося включити. Якщо ні, ми повинні створити файл.

Якщо файл існує, ми знаємо, що плагін намагається завантажити його з неправильного шляху. Тому нам може знадобитися переглянути наш автозавантажувач, наш шлях включення або спосіб отримання файлів. Оскільки, швидше за все, якщо файл існує, його намагаються завантажити з місця, де він не знаходиться.

Нерозпізнана помилка

У останньому рядку коду ви побачите щось на зразок цього:

[05-Jul-2018 19:43:53 UTC] PHP Fatal error: Uncaught Error: Class 'EasyEmailExportAdminEmailExportSubmenu' not found in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php:37
#8 /U in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 37

Це хороший приклад, по-перше, тому що він явно заявляє, що це неперехоплена помилка. Це означає, що якою б не була функціональність, щось видає помилку, і вона не виявляється.

• це може бути винятком,
• це може бути проблемою при спробі викликати функцію, якої не існує,
• це може працювати зі змінною, яка не визначена,
• і так далі.

Зрештою, існує маса проблем, які можуть виникнути. Хороша новина в цьому прикладі полягає в тому, що це практично те саме, що й вище: файл не знайдено.

За винятком того, що замість попередження PHP чітко повідомляє нам, що це фатальна помилка, і програма не може продовжувати виконання, доки цей рядок коду не буде вирішено. Перш ніж відкинути це як те саме, що й у попередньому розділі (бо, у певній манері кажучи, це так), нам потрібно визнати, що це явно вказано як фатальну помилку, тоді як у попередньому прикладі її розглядали як УВАГА.

Існують різні способи концептуалізації цього, але загалом я думаю про це так:

• Сповіщення повідомляє мені, що в коді щось не так, але воно не настільки погане, щоб призупинити виконання.
• Попередження трохи серйозніше, тому що воно означає, що щось може не працювати.
• Помилка прямо говорить: «Це не працює, і програма не може продовжити».

Тепер ми знаємо, що проблема, так би мовити, зупиняє шоу, і ми знаємо, в чому проблема. Простіше кажучи, файл, потрібний програмі для завершення її виконання, не знайдено, і тому програма припиняє роботу.

Це, звичайно, фатальна помилка.

Яке рішення?

Те, що я надаю як рішення моєї проблеми, не буде приписом щодо того, що буде працювати для вас. Для мене це був рядок у моїй конфігурації Composer, через який автозавантажувач Composer не міг знайти файл у належному місці (але це більше пов’язано з організацією файлів, простором імен тощо).

Для вас може бути щось інше.

• можливо, він шукає файл у неправильному каталозі,
• можливо, назва файлу відрізняється від зазначеної в коді,
• а може щось інше.

У будь-якому випадку, справа в тому, що потрібно пройти через файл журналу знизу вгору, щоб діагностувати проблему та відстежити, що робить PHP, WordPress і ваша робота, а потім діагностувати її звідти.

Запис до журналу помилок

У наступній публікації ми приділимо час, щоб побачити, як ми можемо писати в журнал помилок. Іноді читати файл добре, і просто переходити туди-сюди між тим, що ми бачимо, і вирішенням проблем – це добре.

Але як щодо випадку, коли ми хочемо щось викинути, щоб отримати уявлення про те, що бачить WordPress або PHP? Це теж корисно.

Тому в наступній частині цієї серії про розуміння журналів помилок WordPress ми зробимо саме це.

Що після цього?

Далі ми розглянемо, як використовувати деякі плагіни, описані раніше, для тестування коду, а також для профілювання нашого коду, щоб переконатися, що ми зробили все можливе, щоб гарантувати рівень якості.

Це не означає, що ми повністю закінчили процес налагодження, але ми точно на крок ближче, і ми готові писати код із ступенем якості, який не призведе до файлу, що представляє різні нюанси проблем ми були надто необережні, щоб виправити (не кажучи вже про розуміння).