Чтение и понимание журналов ошибок 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, мы займемся именно этим.

Что после этого?

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

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