v4.2.7
Моё время занято на 60%
Обращайтесь — пока другой клиент не занял остаток!
Забронировать консультацию
Сайт упал после обновления WordPress — восстановление за 24 часа
После автоматического обновления WordPress — критическая ошибка, белый экран. Полное восстановление с резервной копии, анализ конфликта плагинов, отладка.
Проблема
Клиент самостоятельно обновил WordPress до версии 6.4.2, после чего сайт перестал открываться. На всех страницах — «белый экран смерти» (WSOD), административная панель также недоступна. Хостинг — cPanel, сайт на WordPress с 15+ активными плагинами.
Вот как выглядел экран для посетителя и администратора:
Пустая страница без исходного кода. HTTP 200, но тело ответа пустое.
🔧 Инструменты для решения
Резервное копирование
Полный бэкап от предыдущего дня (файлы + БД) в cPanel (Backup / JetBackup). Последняя рабочая версия.
PHP Debug
Активация WP_DEBUG и WP_DEBUG_LOG в wp-config.php для сбора критических ошибок.
MySQL
Ручной ремонт таблиц через phpMyAdmin (cPanel) — Repair table для wp_options, wp_posts.
cPanel
Доступ к файловому менеджеру, управлению БД, логам ошибок и откату через резервные копии.
⏳ Восстановление: шаг за шагом
-
1
Диагностика через cPanel — включил WP_DEBUG в wp-config.php (через файловый менеджер). Сразу получил логи с конкретными ошибками (см. выше). Выяснил, что проблема в плагинах и таблице options.
-
2
Откат к резервной копии — через cPanel (раздел Backups) восстановил файлы предыдущего дня и базу данных. Сайт снова открылся, но старая версия WP — временное решение.
-
3
Локализация конфликта — на staging-копии (создал поддомен) обновил WP до актуальной версии, но плагины отключил. Сайт работал. Поочерёдное включение выявило виновников:
old-plugin/custom-functions.phpиoutdated/class.api.php. -
4
Ремонт MySQL — через phpMyAdmin выполнил CHECK TABLE и REPAIR TABLE для проблемных таблиц. Ошибка повреждения устранена.
-
5
Обновление/замена плагинов — устаревшие плагины удалил, нашёл современные аналоги. Обновил остальные.
-
6
Повторное обновление WordPress — через админку (после деактивации проблемных плагинов) — успешно. Сайт работает на последней версии.
Почему не получилось просто обновить? Три плагина использовали устаревшие функции WordPress, удалённые в новой версии. Также одна из таблиц БД оказалась повреждена во время автоматического апдейта (сбой питания на сервере). Резервная копия + лог ошибок позволили точно определить цели.
— Выдержка из технического отчёта
📌 Типовые ошибки WordPress после обновления
| Ошибка / симптом | Вероятная причина | Решение |
|---|---|---|
Parse error: syntax error, unexpected ... |
Плагин/тема используют PHP-код, несовместимый с новой версией PHP (напр. PHP 8.0 → 8.2). | Отключить проблемный плагин через Файловый менеджер (переименовать папку), обновить или заменить. |
Call to undefined function |
Плагин вызывает функцию, которая удалена в новой версии WP. | Деактивация через БД (изменить active_plugins в wp_options), затем обновление. |
| Белый экран (ничего не выводится) | Фатальная ошибка PHP, но вывод отключён. Не хватает памяти (memory limit). | Включить WP_DEBUG, увеличить memory limit в wp-config.php или .htaccess. |
| Ошибка подключения к БД / "Error establishing a database connection" | Неправильные данные в wp-config.php после обновления, либо краш таблиц MySQL. | Проверить креденшелы в cPanel, восстановить БД из бэкапа или починить таблицы через phpMyAdmin. |
💾 Ключевой вывод: резервное копирование — воздух
Если бы не ежедневная резервная копия в cPanel (внешнее хранилище), восстановление заняло бы минимум 2-3 дня. Благодаря бэкапу удалось за час вернуть сайт онлайн, а затем уже в спокойном режиме разобраться с конфликтами на тестовой копии.