Запись

Ошибки WordPress: полное руководство по поиску и исправлению

Подробный гайд по диагностике ошибок WordPress: включение режима отладки WP_DEBUG, работа с debug.log, использование Query Monitor, исправление критических PHP-ошибок и оптимизация медленных SQL-запросов.

ошибка WordPress

Ошибки WordPress - самая частая причина простоев сайтов на CMS: от белого экрана после установки плагина до критических PHP-фаталов и медленных SQL-запросов, из-за которых сайт не грузится. В этом руководстве разберём полный цикл диагностики: как включить режим отладки WP_DEBUG, где читать логи, как использовать Query Monitor и как исправить самые распространённые ошибки. Инструкция подходит для WordPress 6.x и новее.

Классификация ошибок WordPress

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

Тип ошибки Как проявляется Где искать причину
PHP Fatal Error Белый экран, сообщение «Критическая ошибка» debug.log, error_log хостинга
Warning / Notice Видны на странице, но сайт работает debug.log, Query Monitor
Медленные SQL-запросы Сайт долго грузится, TTFB > 1 сек Query Monitor, Slow Query Log
HTTP 500 Ошибка сервера на всём сайте .htaccess, error_log сервера
WSOD (белый экран) Пустая страница без сообщения debug.log, memory_limit
Database Error «Error establishing a database connection» wp-config.php, MySQL
Важно: в продакшене нельзя оставлять отображение ошибок включённым. Они попадают в индекс и раскрывают структуру сервера. Диагностика проводится только через логирование в файл.

Как включить отладку в WordPress: WP_DEBUG

Главный инструмент диагностики - встроенный режим отладки WordPress. Он контролируется тремя константами в wp-config.php.

1Откройте wp-config.php

Файл находится в корневой директории сайта. Подключитесь по FTP, SFTP или через файловый менеджер хостинга.

2Добавьте константы отладки

Найдите строку /* That's all, stop editing! */ и вставьте перед ней следующий блок:

// Включаем режим отладки
define( ‘WP_DEBUG’, true );// Записываем ошибки в файл debug.log
define( ‘WP_DEBUG_LOG’, true );
// Скрываем ошибки на сайте (для продакшена)
define( ‘WP_DEBUG_DISPLAY’, false );
@ini_set( ‘display_errors’, 0 );
// Логируем устаревшие функции и стили
define( ‘WP_DEBUG_LOG’, true );
define( ‘SCRIPT_DEBUG’, true );
define( ‘SAVEQUERIES’, true );

3Расшифровка каждой константы

Константа Назначение Когда использовать
WP_DEBUG Главный переключатель отладки Всегда включается первой
WP_DEBUG_LOG Пишет ошибки в wp-content/debug.log Обязательно для продакшена
WP_DEBUG_DISPLAY Показывает ошибки на экране Только для локальной разработки
SCRIPT_DEBUG Загружает несжатые версии скриптов WP При отладке JS/CSS ядра
SAVEQUERIES Сохраняет все SQL-запросы в массиве Для анализа медленных запросов
Ошибка: никогда не включайте WP_DEBUG_DISPLAY на боевом сайте. Посетители увидят стек-трейс с путями к файлам, и это станет уязвимостью для злоумышленников.

Где искать логи ошибок WordPress

После включения отладки ошибки пишутся в несколько мест. Каждое полезно для своего типа задач.

Лог WordPress: debug.log

Расположение: /wp-content/debug.log

Содержит PHP Fatal, Warning, Notice и Deprecated. Это основной источник информации о сбоях плагинов и тем.

Лог веб-сервера: error_log

Расположение зависит от хостинга:

  • Apache: /var/log/apache2/error.log или /home/user/logs/error_log
  • Nginx: /var/log/nginx/error.log
  • Панель ISPmanager: раздел «Журналы → error_log»
  • cPanel: раздел «Метрики → Журнал ошибок»

Лог PHP-FPM

Полезен, когда PHP-процесс падает до того, как WordPress успел записать ошибку. Обычно находится в /var/log/php-fpm/error.log.

Лог MySQL

Нужен для диагностики медленных запросов. Включается через my.cnf или из MySQL-клиента.

Совет: если вы работаете с клиентским сайтом и не можете открыть файл через FTP, используйте плагин Error Log Monitor или WP Log Viewer - они показывают debug.log прямо в админке WordPress.

Что делать, если debug.log не создаётся

  1. Проверьте права доступа на папку wp-content - должно быть 755.
  2. Создайте пустой файл debug.log вручную через FTP и задайте права 644.
  3. Убедитесь, что на хостинге достаточно дискового пространства.
  4. Проверьте в панели хостинга, не отключена ли запись логов администратором сервера.

Query Monitor: главный плагин диагностики

Query Monitor - бесплатный плагин, который показывает все запросы к базе данных, хуки, PHP-ошибки, HTTP-запросы и кэш в админ-баре WordPress. Это must-have для любого разработчика.

Установка и активация

  1. Перейдите в Плагины → Добавить новый.
  2. Введите Query Monitor, автор John Blackbourn.
  3. Установите и активируйте.
  4. В верхней панели админ-бара появится новая ссылка.
Рекомендация по безопасности: Query Monitor раскрывает чувствительные данные. Настройте отображение только для администраторов: Настройки → Query Monitor → Capabilities - оставьте галочку только у manage_options.

Что можно увидеть в Query Monitor

Раздел Что показывает Зачем смотреть
Queries Все SQL-запросы страницы Найти медленные запросы и N+1 проблемы
PHP Errors Fatal, Warning, Notice, Deprecated Локализовать проблемный плагин или тему
HTTP API Calls Внешние запросы к API Найти тормозящие интеграции
Scripts & Styles Подключённые JS и CSS Оптимизировать загрузку фронта
Template Какой шаблон отрендерил страницу Понять, какой файл нужно править
Blocks Использованные Gutenberg-блоки Диагностика блочных тем
Conditionals Текущие условные теги WP Отладка логики шаблонов
Object Cache Статистика Redis / Memcached Проверка эффективности кэша

Как найти медленный запрос в Query Monitor

  1. Откройте проблемную страницу сайта в режиме администратора.
  2. Кликните на пункт Query Monitor в админ-баре.
  3. Перейдите во вкладку Queries.
  4. Отсортируйте по столбцу Time (время выполнения).
  5. Запросы, которые занимают больше 100 мс, выделены красным.
  6. Кликните на медленный запрос - увидите трассировку: какой файл и функция его вызвали.
Результат: вместо того чтобы гадать, почему сайт тормозит, вы точно видите, что запрос wp_postmeta к таблице с 2 миллионами записей выполняется 1.8 секунды, и вызывается из single.php:47.

10 самых частых PHP ошибок WordPress и их исправление

1Allowed memory size exhausted

Сообщение: Allowed memory size of 134217728 bytes exhausted

Причина: PHP-скрипт превысил лимит памяти.

Исправление: увеличьте лимит в wp-config.php:

define( ‘WP_MEMORY_LIMIT’, ‘256M’ );
define( ‘WP_MAX_MEMORY_LIMIT’, ‘512M’ );

Если не помогло - увеличьте memory_limit в php.ini до 512M или попросите хостинг-провайдера.

2Maximum execution time exceeded

Сообщение: Maximum execution time of 30 seconds exceeded

Причина: скрипт выполняется дольше отведённого времени.

Исправление: в wp-config.php:

@ini_set( ‘max_execution_time’, 300 );

Если ошибка возникает при импорте или обновлении плагинов - это нормально, после завершения верните значение в 30 секунд.

3Call to undefined function

Сообщение: Fatal error: Call to undefined function some_function()

Причина: плагин или тема обращаются к функции, которая не загружена.

Исправление:

  1. Определите в debug.log, какой плагин вызывает ошибку.
  2. Отключите этот плагин через FTP, переименовав его папку в /wp-content/plugins/.
  3. Обновите плагин до последней версии или найдите альтернативу.

4Cannot redeclare function

Сообщение: Fatal error: Cannot redeclare some_function()

Причина: функция объявлена дважды - часто при копировании functions.php в дочернюю тему.

Исправление: оборачивайте функции в проверку:

if ( ! function_exists( ‘my_custom_function’ ) ) {
function my_custom_function() {
// ваш код
}
}

5Критическая ошибка WordPress (Critical Error)

Сообщение: «На сайте возникла критическая ошибка. Проверьте email для инструкций»

Причина: PHP Fatal Error в теме или плагине. С WordPress 5.2+ включён режим восстановления.

Исправление:

  1. Проверьте почту администратора - WordPress пришлёт письмо со ссылкой на режим восстановления.
  2. Воспользуйтесь ссылкой, войдите в админку.
  3. Отключите проблемный плагин или тему.
  4. Исправьте код в debug.log.
Совет: если письмо не пришло (например, отключён wp_mail), откройте сайт в режиме инкогнито. На экране будет сообщение «Произошла критическая ошибка», и в debug.log вы увидите точную причину.

6Белый экран смерти (WSOD)

Проявление: пустая белая страница без текста.

Причины: переполнение памяти, конфликт плагинов, сломанный functions.php.

Пошаговое исправление:

  1. Включите WP_DEBUG и WP_DEBUG_LOG в wp-config.php.
  2. Если сайт не открывается вообще - загрузите wp-config.php по FTP.
  3. Переименуйте папку plugins в plugins_old - отключит все плагины.
  4. Откройте сайт. Если заработал - включайте плагины по одному.
  5. Если не помогло - переименуйте папку активной темы в /wp-content/themes/. WordPress переключится на стандартную тему.

7Error establishing a database connection

Сообщение: белая страница с этим текстом.

Причина: неверные данные в wp-config.php или упавший MySQL.

Исправление:

  1. Проверьте константы: DB_NAME, DB_USER, DB_PASSWORD, DB_HOST.
  2. Убедитесь, что MySQL запущен: sudo systemctl status mysql.
  3. Проверьте, что пользователь БД имеет права на эту базу.
  4. Попробуйте подключиться через phpMyAdmin с теми же данными.

8Parse error: syntax error

Сообщение: Parse error: syntax error, unexpected ...

Причина: опечатка в PHP-коде - забытая скобка, точка с запятой, кавычки.

Исправление:

  1. Посмотрите в debug.log строку и столбец, где ошибка.
  2. Откройте файл через FTP и исправьте синтаксис.
  3. Перед сохранением прогоните код через онлайн-валидатор PHP.

9Deprecated: Function … is deprecated

Сообщение: Deprecated: Function create_function() is deprecated

Причина: плагин или тема используют устаревшие PHP-функции.

Исправление: это предупреждение, не ошибка. Обновите плагин до свежей версии. Если обновления нет - сообщите разработчику или найдите альтернативу.

10WP_Error: объект не существует

Сообщение: Object of class WP_Error could not be converted to string

Причина: код пытается вывести объект WP_Error как строку.

Исправление: перед использованием всегда проверяйте:

$response = wp_remote_get( $url );
if ( is_wp_error( $response ) ) {
// Обработка ошибки
return $response->get_error_message();
}
// Использование ответа
echo $response[‘body’];

Медленные SQL-запросы: диагностика и оптимизация

Медленные запросы - главная причина тормозов WordPress. На больших сайтах (от 100 000 записей) это проявляется особенно сильно.

Признаки медленных SQL-запросов

  • Время до первого байта (TTFB) превышает 1 секунду.
  • В Query Monitor отдельные запросы занимают > 100 мс.
  • Высокая нагрузка на CPU сервера при низкой посещаемости.
  • Админка WordPress тормозит сильнее фронта.

Топ-5 причин медленных запросов в WordPress

Причина Как проявляется Решение
Запросы без индексов SELECT * FROM wp_postmeta WHERE meta_value = ... Добавить составной индекс на (meta_key, meta_value)
Проблема N+1 Плагин делает запрос для каждой записи отдельно Переписать на WP_Query с meta_query
SELECT * вместо нужных полей Тяжелые запросы с большим результатом Запрашивать только нужные столбцы
LIMIT с большим offset Пагинация на последней странице зависает Использовать keyset-пагинацию
JOIN больших таблиц wp_posts JOIN wp_postmeta на миллионах записей Денормализация или кэширование

Как включить Slow Query Log в MySQL

# В my.cnf или my.ini
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

После перезапуска MySQL в лог попадут все запросы, выполняющиеся дольше 1 секунды, а также запросы без использования индексов.

Оптимизация запросов к wp_postmeta

Самая проблемная таблица в WordPress - wp_postmeta. Она содержит EAV-структуру и растёт очень быстро.

— Добавить индекс для ускорения запросов по мета-полям
ALTER TABLE wp_postmeta ADD INDEX meta_value_idx (meta_value(191));
ALTER TABLE wp_postmeta ADD INDEX meta_key_value_idx (meta_key, meta_value(191));
— Индекс для ускорения JOIN с wp_posts
ALTER TABLE wp_postmeta ADD INDEX post_id_meta_key_idx (post_id, meta_key);
Важно: перед добавлением индексов сделайте полный бэкап базы данных. Операция ALTER TABLE на большой таблице может занять несколько часов и заблокирует таблицу.

Как переписать медленный WP_Query

Пример плохого кода:

// ПЛОХО: N+1 запросов
$products = get_posts([ ‘post_type’ => ‘product’, ‘numberposts’ => 100 ]);
foreach ( $products as $product ) {
$price = get_post_meta( $product->ID, ‘_price’, true ); // отдельный запрос для каждого
}

Пример оптимизированного кода:

// ХОРОШО: один запрос с JOIN
global $wpdb;
$results = $wpdb->get_results(
«SELECT p.ID, p.post_title, pm.meta_value AS price
FROM {$wpdb->posts} p
INNER JOIN {$wpdb->postmeta} pm ON p.ID = pm.post_id
WHERE p.post_type = ‘product’
AND p.post_status = ‘publish’
AND pm.meta_key = ‘price’
LIMIT 100»
);

Кэширование запросов

Для часто используемых, но тяжёлых запросов используйте трансиенты:

function get_expensive_data() {
$cache_key = ‘expensive_data’ . get_current_user_id();
$data = get_transient( $cache_key );
12345678
}

Полезные плагины для диагностики ошибок WordPress

Query Monitor
Главный инструмент отладки: SQL, PHP, хуки, кэш
WP Crontrol
Управление cron-задачами, запуск вручную, диагностика
Error Log Monitor
Просмотр debug.log в админке без FTP
Debug Bar
Расширение Query Monitor для продвинутой диагностики
Плагин Назначение Когда использовать
Health Check Проверка сайта в режиме изоляции Когда конфликт плагинов, но не знаете какой
User Switching Быстрое переключение между пользователями Отладка проблем с ролями и правами
WP Mail SMTP Логирование писем Когда не приходят письма с сайта
Reroute Email Перенаправление писем на тестовый ящик На dev-окружении

Чек-лист: алгоритм диагностики любой ошибки

Последовательность действий

  • Включите WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY=false в wp-config.php
  • Воспроизведите ошибку на сайте
  • Откройте файл /wp-content/debug.log и найдите последние записи
  • Определите тип ошибки: PHP Fatal, Warning, SQL
  • Установите Query Monitor и проверьте ту же страницу
  • Для SQL-проблем включите Slow Query Log в MySQL
  • Определите виновника: плагин, тема, ядро WP или хостинг
  • Отключите проблемный элемент через FTP (переименование папки)
  • Обновите плагин/тему до последней версии
  • Если обновления нет - найдите альтернативу или напишите разработчику
  • После исправления выключите WP_DEBUG на продакшене
  • Проверьте сайт через 24 часа - ошибка не должна вернуться
Совет: заведите отдельный wp-config-local.php с включённой отладкой и подключайте его только на dev-сервере. Это избавит от случайного включения WP_DEBUG на боевом сайте.

FAQ: частые вопросы об ошибках WordPress

Ответы на популярные вопросы

Безопасно ли держать WP_DEBUG включённым постоянно?

На продакшене - нет. При неправильной настройке (WP_DEBUG_DISPLAY=true) ошибки будут видны посетителям и попадут в поисковую выдачу. Допускается держать только WP_DEBUG=true и WP_DEBUG_LOG=true, чтобы ошибки записывались в файл, но не отображались. Периодически проверяйте debug.log и удаляйте его после анализа - файл может вырасти до гигабайтов.

Что делать, если критическая ошибка появилась после обновления плагина?

WordPress 5.2+ пришлёт письмо администратору со ссылкой на режим восстановления. Перейдите по ней и отключите проблемный плагин. Если письма нет, подключитесь по FTP и переименуйте папку плагина в /wp-content/plugins/. После этого сайт заработает. Сообщите разработчику плагина об ошибке и приложите строки из debug.log.

Почему Query Monitor показывает много запросов, но сайт не тормозит?

WordPress на стандартной странице делает 50–150 SQL-запросов - это нормально. Обращайте внимание не на количество, а на время выполнения. Запросы до 10 мс выполняются мгновенно. Проблемой считаются запросы дольше 100 мс или отдельные запросы, занимающие более 50% общего времени загрузки страницы.

Можно ли смотреть debug.log без FTP?

Да, используйте плагины Error Log Monitor, WP Log Viewer или Log HTTP Requests. Они добавляют в админку страницу с содержимым лога. Но для безопасности ограничьте доступ к этим плагинам только администраторам и удаляйте их после решения проблемы.

Как найти плагин, вызывающий ошибку, если их установлено 30+?

Используйте бинарный поиск: отключите половину плагинов и проверьте сайт. Если ошибка исчезла - виноват один из отключённых. Если нет - проблема в оставшихся. За 5–6 шагов вы найдёте виновника быстрее, чем перебором. Плагин Health Check делает это автоматически в режиме изоляции, не затрагивая обычных посетителей.

Стоит ли использовать плагин для оптимизации SQL или делать руками?

Для 90% сайтов достаточно плагина кэширования (WP Rocket, LiteSpeed Cache, W3 Total Cache) и индексации основных таблиц. Ручная оптимизация запросов нужна на высоконагруженных проектах: интернет-магазинах с 100 000+ товаров, новостных порталах, SaaS-проектах. В этих случаях привлекайте backend-разработчика для написания кастомных запросов и настройки кэша.

Как понять, что проблема не в WordPress, а в хостинге?

Если debug.log пустой, Query Monitor не показывает медленных запросов, но сайт тормозит или падает - проблема на уровне сервера. Проверьте: загрузку CPU через htop, свободную память через free -h, дисковое пространство через df -h. На shared-хостинге соседние сайты могут потреблять все ресурсы - в этом случае поможет переход на VPS.

Итог

Диагностика ошибок WordPress строится на трёх китах: WP_DEBUG с записью в файл, Query Monitor для анализа запросов в админке и системных логах сервера для критических сбоев. 90% ошибок вызываются плагинами и темами, 9% - нехваткой ресурсов хостинга, 1% - багами ядра. Начните с включения отладки, найдите виновника через debug.log, откатите или обновите проблемный элемент - и сайт вернётся в строй за 15 минут.

Примеры выполненных работ

Устранение тормозов WordPress: оптимизация админки, WPML и исправление ошибок PHP

Админка WordPress открывалась до 21 секунды, менеджеры испытывали проблемы с редактированием записей. Нашёл избыточную нагрузку WPML и Toolset, устранил ошибки совместимости PHP и исправил шаблон туров. Подробный разбор диагностики и решения.

Доработка структуры каталога и навигации в OcStore 1.5.6.4

Переработана структура каталога интернет-магазина на OcStore 1.5.6.4: карточки товаров получили постоянные URL и стабильные хлебные крошки, старые адреса перенаправляются через 301 Redirect, а отдельные товары теперь можно выводить в плитках категорий вместе с подкатегориями.

Нужна помощь с похожей задачей?

Пришлите ссылку на сайт и кратко опишите задачу — я посмотрю и предложу следующий шаг.

Telegram@tekito_devWhatsAppMAX

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *