Лог ошибок php wordpress

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

Где хранится лог ошибок ВордПресс и как его посмотреть

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

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

Фактический журнал логов хранится в файле с именем debug.log в каталоге содержимого вашего сайта wp-content на сервере хостинг-провайдера. Как посмотреть логи? Один из способов просмотра и очистки журнала – прямой доступ к этому файлу. Скачайте файл с помощью файлового менеджера и откройте его любым текстовым редактором. Можно воспользоваться плагинами, которые упрощают работу с логами.

Можно ли удалять логи? Файл с отладочной информацией и уведомлениями об ошибках со временем может разрастись до внушительных размеров. Поэтому, если ваш сайт работает нормально, то старые логи можно удалить, чтобы освободить рабочее пространство.

Как включить/выключить логирование

Чтобы включить создание лог-журнала для сайта на WordPress, понадобится внести изменения в системный файл wp-config.php, который расположен на сервере хостинга.

1. Запустите файловый менеджер и подключитесь к удаленному серверу со своей учетной записью, который вам предоставил хостинг-провайдер.
2. Перейдите в корневой каталог, где установлен ваш сайт.
3. Сделайте резервную копию файла wp-config.php, чтобы восстановить систему после завершения отладки.

Откройте файл wp-config.php на удаленном сервере, вставьте или отредактируйте строки, которые управляют созданием логов:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );


Большинство сайтов на WordPress уже имеют запись для константы WP_DEBUG, установленную в значение false, поэтому вам нужно изменить это значение на true. Строка с WP_DEBUG_LOG может отсутствовать, поэтому придется ее добавить, эта команда активирует создание журнала логов для сайта. Константа WP_DEBUG_DISPLAY, установленная в значение false, поможет скрыть запись логов от посетителей сайта. Убедитесь, что каждая константа определена в файле только один раз.

Лог действий в WordPress

После того как запись логов включена, перейдите в папку содержимого сайта на WordPress. Обычно она называется wp-content, если вы не переименовали ее ранее. Откройте файл журнала debug.log, перейдите в конец и найдите строки с метками времени, соответствующими вашим недавним действиям над сайтом.

Каждый раз, когда возникает предупреждение или ошибка в работе сайта, WordPress генерирует уведомление, которое записывается в журнал логов с отметкой времени в формате UTC. По этим причинам на работающем сайте рекомендуется оставить WP_DEBUG включенным. Устраните выявленные проблемы, при необходимости восстановите оригинальный файл wp-config.php.

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

Плагины для логирования действий

Разработано несколько специальных плагинов, позволяющих просмотреть журнал логов напрямую из админки WordPress. Вы можете установить их прямо в админпанели в разделе «Плагины»

Activity Log – популярный плагин с большим количеством активных установок. Позволяет записать хронологию действий пользователей, их вход в админку и выход. Будут зафиксированы последние действия со страницами и записями, удаление и установка тем и плагинов.

WP Security Audit Log – плагин для мониторинга действий пользователей в админке сайта. Можно использовать для ведения лог-журнала электронного магазина WooCommerce и отслеживать изменение состояния продукта. Плагин создает предупреждение о безопасности, когда в системе создается новый пользователь, и позволяет отследить подозрительную активность, прежде чем это станет проблемой безопасности.

WP Log Viewer – плагин создает виджет панели администратора и позволяет включить/отключить запись лога одним щелчком мыши, при этом не требуется вручную редактировать файл wp-config.php. Можно выполнить фильтрацию ошибок, очистить журнал, сортировать записи по дате или провести поиск ошибок по времени. Пользовательские ошибки обозначаются разными цветами.

Error Log Monitor – этот плагин добавляет виджет, который видим только для администраторов. Он отображает последние сообщения из журнала логов, а также умеет отправлять уведомления по электронной почте о новых возникших ошибках. Частота уведомлений и количество отображаемых записей в журнале настраивается. Плагин оптимизирован для работы с очень большими лог-файлами.

iPipe – надёжный хостинг-провайдер с опытом работы более 15 лет.

Мы предлагаем:

• Виртуальные серверы с NVMe SSD дисками от 299 руб/мес
• Безлимитный хостинг на SSD дисках от 142 руб/мес
• Выделенные серверы в наличии и под заказ
• Регистрацию доменов в более 350 зонах

No one likes to see errors on their website. Not only do they look bad to visitors and potential customers, but they also indicate that something’s wrong. But they’re, unfortunately, an inevitable part of running a site. The good news is that following a few best practices and being proactive can dramatically reduce the number of errors you experience. 

One way to monitor potential site issues — or troubleshoot existing ones — is to keep and review an error log. Let’s dive into this a bit more.

What is error logging and why is it important?

Error logging is the process of tracking and monitoring issues that occur on a website. This is usually done with a record of simple text files that live on your web server and are updated whenever an error occurs. Error logs are used to identify the number of problems that occur, provide details about each one, and show when it took place.

How to enable error logging

To enable error logging on your WordPress site, you’ll need sFTP access, available with WordPress.com plugin-enabled plans. This allows you to edit your website files remotely. In this case, you’ll be working with the wp-config.php file, which holds the basic configuration settings for your website.

A word of warning: you should only use sFTP and edit your wp-config.php file if you feel comfortable doing so. Mistakes can cause catastrophic errors on your website. If you don’t have experience changing these types of files, you may want to hire a developer or reach out to WordPress.com support for help.

1. Connect to your website via sFTP

You’ll need to start by enabling sFTP on your site. Go to My Site(s) → Settings → Hosting Configuration and click the Enable SFTP button.

Then, you’ll see your sFTP login details: URL, Port Number, Username, and Password. You’ll need to input these into FTP software, like FileZilla, to access your site. Follow these detailed instructions to connect to your WordPress.com website.

2. Find and download your wp-config.php file

Navigate to your wp-config.php file. This sits in the root directory of your file structure, alongside folders such as wp-content. Download this file, so you have a backup copy on hand.

3. Edit the wp-config.php file

Edit your wp-config.php file using a text editor such as Notepad.

Look for define( ‘WP_DEBUG’, false ); and replace this text with the following:

define( ‘WP_DEBUG’, true );

if ( WP_DEBUG ) {

        @error_reporting( E_ALL );

        @ini_set( ‘log_errors’, true );

        @ini_set( ‘log_errors_max_len’, ‘0’ );

        define( ‘WP_DEBUG_LOG’, true );

        define( ‘WP_DEBUG_DISPLAY’, false );

        define( ‘CONCATENATE_SCRIPTS’, false );

        define( ‘SAVEQUERIES’, true );

}

You’ve now successfully enabled error logging. You should only have this feature turned on while troubleshooting. Otherwise, it can leave your site more vulnerable to hacking attempts. To disable logging, simply delete the code you just added and restore the following:

define( ‘WP_DEBUG’, false );

How to view the error log manually

Once the log is enabled, you’ll need to load your website to trigger any error codes. Those codes are stored in a file called debug.log, which you can access via sFTP by following the same steps as above. 

You can find the debug.log file inside of the wp-content folder. If there are errors, the file will appear. However, if there aren’t any errors, then you won’t see it at all — congratulations!

Once you find the file, download it to your computer to view the full log, using a text editing software like Notepad. It will look something like this:

This file will provide valuable information that will point you, or your developer, to the source of your problem. 

How to view the error log using a plugin 

Using a plugin to find your error log can be an easier and faster method, depending on your level of experience. In the WordPress dashboard, click on Plugins → Add New. Search for “Error Log Monitor” and click Install → Activate.

This plugin installs a widget on your WordPress dashboard that allows you to access your error log. If you haven’t enabled error logging correctly, the widget will display instructions on how to do so. However, you should ignore these instructions, as they’re incorrect for a WordPress.com installation. Instead, use the ones listed above.

If you can’t see the dashboard widget, click on the Screen options tab at the top of the WordPress dashboard and ensure that “PHP error log” is checked.

How to find the plugin or theme that’s causing an error

Error logs are not inherently easy to read, but they do give insightful information into the cause of an error.

Typically, each line in your error log will display a message, alongside the date and time it happened and the file in which the error occurred. It also lists the line number where the error is located. For example:

Apr 20, 15:08:59

Notice: Undefined index: fg2 in /wordpress/themes/pub/varia/functions.php on line 166

Let’s break this down. First of all, there’s the date and time of the error: April 20, 15:08:59. This helps you determine if this was a one-off glitch or a recurring issue.

Then, you can see the type of error that’s been logged. Here are a few common types of error you may see here:

• Notice. These are more warnings than errors, as they don’t actually stop your website code from executing. While you should still address a notice, your site will most likely still function, although potentially not as designed.
• Parse error. This is typically the result of a mistake in the syntax of the underlying PHP code of the website (often in a theme or plugin). Parse errors include things like missing semicolons, parentheses, and other similar mistakes. A parse error will stop executing code when it hits the problem, so your site may look visibly broken or not function as intended.
• Fatal error. This is often caused by undefined functions or classes, like a typo or poor coding practice. You can avoid it by using high-quality code, along with functions such as class_exists or function_exists.

In this case, the error is a notice.

Next, we see the error itself. In the example above the error is “undefined index.” This is followed by the specific location of the problem. In the above example, the error is occurring with the functions.php file of the Varia theme.

How to fix errors

Now that you can see your errors, it’s time to troubleshoot. Here’s a few things you can try:

• If you’re a developer and the error is in your custom code, go to the line number in the log entry and work to debug.
• If the error is within a theme or plugin, start by checking for any available updates. Keeping your plugins and themes up to date is critical for avoiding bugs and maintaining website security. Once you’ve applied any updates, re-check the error log to see if there are any new entries. If the error still exists, reach out to the plugin author or consider switching to an alternative. 
• The error may also be caused by a conflict between two plugins. Try using the WordPress troubleshooting mode to fix this problem.
• If the problem occurred immediately after installing or updating a plugin, deactivate it to see if the error persists. If it doesn’t, the plugin is the likely cause and you may want to find an alternative. If the error occured after a core update, you may need to manually deactivate plugins to find the source.

Troubleshooting with the WordPress error log

WordPress, like any software, may occasionally run into problems. It may seem confusing to find and fix those problems, but the error log can be a huge help! It enables you to learn valuable information that can help you troubleshoot and solve site errors in a timely manner.

To avoid errors, always use well-maintained plugins and themes, and keep on top of updates. Need more help? If you have a WordPress plugin-enabled plan, you benefit from world-class Happiness Engineers that can provide guidance.

Disclosure: Our content is reader-supported. This means if you click on some of our links, then we may earn a commission. See how WPBeginner is funded, why it matters, and how you can support us.

Editorial Staff at WPBeginner is a team of WordPress experts led by Syed Balkhi with over 16 years of experience building WordPress websites. We have been creating WordPress tutorials since 2009, and WPBeginner has become the largest free WordPress resource site in the industry.

The following are some techniques I use nearly every day for debugging WordPress and WooCommerce, and can be used for plugin or theme development equally.

Echoing or printing to the screen will only get you so far when debugging, especially in a complex framework like WordPress; to really understand the code flow, and to trace and fix issues, you need to be able to log messages to a file. For this WordPress makes use of the PHP core error_log() function, which allows you to “send an error message somewhere.” Using it is quite simple:

error_log( "Hello World!" );

Put this into a script, request the page and we will have logged a message “somewhere”, but where? By default when running under Apache and called with no additional arguments, error_log() will send the message to your apache error log file. For me this is found at /var/log/apache2/error_log, for you this may be somewhere else, and is specified by your apache conf file. My Apache conf is found at /etc/apache2/httpd.conf, again yours could be elsewhere on your system depending on how you installed Apache. Logging to the apache error log is a good first step, however a lot of stuff that we don’t necessarily care about also gets logged there, and it doesn’t always work well with newlines in your debug statements; thankfully WordPress provides a solution with a set of debugging constants.

Debugging with WP_DEBUG

The first and most important constant is WP_DEBUG. Enable this within your wp-config.php file to report all PHP notices to your log file, and allow the use of the other debugging constants:

define( 'WP_DEBUG', true );

WordPress recommends “that plugin and theme developers use WP_DEBUG in their development environments”, which is indeed good advice, but unfortunately not followed by all developers, which means that your log file can become inundated with notices from misbehaving 3rd party plugins and themes, making it all but impossible to watch for notices from your own plugin development. You don’t have many options here:

• You can take the time to fix the notices in the offending code (which is nice until you update and get the notice-ridden code all over again)
• You can deactivate the plugin if you don’t really need it (not always an option)
• Or you can disable notice reporting (useful if you just want to be able to log debug statements without losing them among notices you don’t care about). Unfortunately this makes it difficult to stay on top of notices from your own plugin development and can make you part of the problem! Still, it’s the best option at times, see my debug helper plugin for a simple way to do this.

A Better Log File With WP_DEBUG_LOG

Enabling the WP_DEBUG_LOG constant, in the same manner as the WP_DEBUG above improves our debugging experience by sending notices and messages to wp-content/debug.log. Another benefit is being able to use the print_r(), var_dump() and other handy multiline debugging functions. WP_DEBUG must be enabled for this constant to have any effect:

define( 'WP_DEBUG',     true );
define( 'WP_DEBUG_LOG', true );

Watch the log file like any other for convenience while developing:

$ tail -f wp-content/debug.log

Remember: One thing to keep in mind with this configuration enabled is that there will be some spots in the WordPress code that are executed prior to the log file being set, so depending on how deeply you’re debugging into core files, you may need to watch the apache error log (or other location, as always depending on your php.ini) for some of your messages. It doesn’t come up often, but if you’re deep into core territory and start missing statements that you know should be logged, check your apache error log, or other default destination before you accuse the computer of cheating.

In Your Face Debugging With WP_DEBUG_DISPLAY

Enabling the WP_DEBUG_DISPLAY constant will cause notices/errors to be displayed right on the page when they occur. When you have all outstanding notices fixed and are developing a plugin or theme this is a great constant to have enabled as it doesn’t require watching your log file. Granted it won’t catch all notices all the time so you will still need to be aware of your log file, but this is a great way to keep yourself honest.

Script Debugging with SCRIPT_DEBUG

By default WordPress will use minified CSS/JavaScript files, which is great for site performance, but not so great for finding and fixing issues with them. Sure you could learn to read minified JavaScript, or you could use yet another handy constant: SCRIPT_DEBUG, which will cause the un-minified scripts to be loaded instead.

Query Debugging With SAVEQUERIES

WordPress is obviously heavily dependent on the database, and this is an area that can be difficult at times to get visibility into. One solution is to enable the SAVEQUERIES constant, which will save all queries to the queries member of the db object along with their execution time, and the stack of functions that called them. I find this one to be of limited benefit just due to the sheer number of database queries in the typical WordPress page load, and I prefer to error_log() the particular query that I’m actually interested in, but it certainly can be useful:

global $wpdb;

error_log( print_r( $wpdb->queries, true ) );

// try and narrow down a particular query:
foreach ( $wpdb->queries as $query ) {
  if ( strpos( $query[2], 'WP_Query->get_posts' ) !== false ) error_log( print_r( $query, true ) );
}

A Plugin to Help with Debuggin’

One of the first plugins I wrote for myself is a small debug helper plugin unimaginatively called WP Debug Helper. This can disable notice reporting for those times when you just can’t deal (this functionality commented-out by default), and adds two functions that I find useful additions to my debugging toolbox:

wp_debug_backtrace()

Convenience function for printing a stack trace

wp_var_dump()

Convenience function for calling the core var_dump() function

Feel free to download it, use it, add to it; let me know in the comments if you have suggestions for any other helpful functions to add.

Putting it all Together

To put it all together and wrap things up, here are some example logging patterns I find myself using over and over:

Configure wp-config.php:

/**
 * For developers: WordPress debugging mode.
 *
 * Change this to true to enable the display of notices during development.
 * It is strongly recommended that plugin and theme developers use WP_DEBUG
 * in their development environments.
 */
define( 'WP_DEBUG',        true );
define( 'WP_DEBUG_LOG',    true );
define( 'WP_DEBUG_DISPLAY',true );
define( 'SCRIPT_DEBUG',    true );
define( 'SAVEQUERIES',     true );

Watch the Log File:

$ tail -f wp-content/debug.log

Example log statement:

error_log( "Hello World!" );

Example logging print_r:

error_log( print_r( $foo, true ) );

Get the classname of an unknown object:

error_log( get_class( $obj ) );

Example logging a stacktrace (if my WP Debug Helper plugin is installed and active):

error_log( wp_debug_backtrace() );

Example var dumping a variable (if my WP Debug Helper plugin is installed and active):

error_log( wp_var_dump( $foo ) );

Dump all defined constants (note that this will be quite extensive within WordPress):

error_log( print_r( get_defined_constants(), true ) );

Dump all available globals (note that this will be quite extensive within WordPress):

error_log( print_r( $GLOBALS, true ) );

// or maybe:
foreach( $GLOBALS as $key => $value ) {
  if ( ! in_array( $key,array( '_wp_using_ext_object_cache', 'wpdb', 'registered' ) ) )
    error_log( $key . " => " . print_r( $value, true ) );
}

Dump queries:

global $wpdb;

error_log( print_r( $wpdb->queries, true ) );

Have any other tips or patterns you find yourself using again and again? Let us know in the comments below. Happy Debugging!