Перед изменениями сделайте резервную копию файлов и базы. Откройте wp-config.php и добавьте настройки перед строкой /* That's all, stop editing! */:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Так ошибки будут записываться в лог, но не показываться посетителям.
После включения повторите проблемное действие: откройте страницу, сохраните запись или запустите нужную форму. Затем проверьте файл wp-content/debug.log. Ищите строки с PHP Fatal error, PHP Warning, названием плагина, темы или конкретным файлом. Важны не только последние строки, но и время появления ошибки.
Проверяйте конфликт по порядку: отключите подозрительный плагин, смените тему на стандартную и повторите действие на копии сайта. Если ошибка исчезла, включайте компоненты по одному. Не исправляйте лог удалением строк: он только показывает симптом и место сбоя. После диагностики отключите отладку или верните WP_DEBUG в false, а старый лог очистите.
Лог — это карта поиска, а не готовое решение: сначала зафиксируйте действие, которое вызывает ошибку, затем найдите компонент и проверьте гипотезу на тестовой копии. Так отладка не превращается в риск для рабочего сайта.
Обновления WordPress без поломок
@wp_safe_updates_ww
Режим WP_DEBUG: как включить логирование и найти причину падения сайта
Этот пост опубликован в Telegram-канале Обновления WordPress без поломок. Подписаться можно по ссылке: @wp_safe_updates_ww.