Как переехать с WordPress 6.4 и найти настоящую причину сбоя

Если после переноса WordPress показывает белый экран или не подключается к базе, не начинайте с увеличения лимитов MySQL. Сначала сверьте имя базы, пользователя, пароль и адрес сервера в wp-config.php, затем сопоставьте ошибку с журналами PHP и MySQL. Покажу порядок диагностики и объясню, когда действительно виноват плагин.

До копирования: зафиксируйте рабочее состояние

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

Одинаковые симптомы не означают одинаковую причину. Белая страница бывает следствием фатальной ошибки PHP, сбоя темы или плагина; сообщение о подключении к базе указывает на проблему связи с MySQL, но не доказывает повреждение таблиц. Поэтому я фиксирую точный текст ошибки, время появления и действие, после которого она возникла. «После переезда» — это время, а не диагноз.

Если перенос выполняется с изменением домена, отдельно отмечаю старый и новый адрес. В базе WordPress могут храниться URL, а некоторые плагины записывают их в сериализованные данные. Простая глобальная замена строкой в SQL способна повредить такие данные; документация WordPress рекомендует применять средства, учитывающие этот формат. Если домен тот же, менять адреса в базе автоматически не требуется. Перед любым преобразованием делаю ещё одну копию дампа и проверяю результат на тестовом экземпляре. Отдельно пригодится резервное копирование WordPress с проверкой восстановления.

• Сохранить файлы и дамп базы отдельно
• Записать версии PHP, WordPress, темы и плагинов
• Зафиксировать домен и текущие параметры подключения
• Проверить, что резервную копию можно восстановить

Новый сервер: сначала база и доступ

На целевом хостинге нужна база данных, куда импортируется дамп, и пользователь, которому разрешён доступ к этой базе. Общие этапы переезда разобраны в материале про перенос сайта на другой хостинг. Конкретный адрес MySQL задаёт хостинг: это может быть localhost, имя отдельного сервера или иной адрес из панели. Утверждение «MySQL обязан принимать соединения только с локального IP» не универсально и может просто отрезать WordPress от базы на отдельном сервере. Я беру hostname, имя базы и правила доступа из конфигурации площадки, а не угадываю их.

Проверяю, что импорт завершился без ошибок, таблицы появились, а пользователь базы имеет необходимые приложению права. Если используется удалённое подключение, администратор площадки должен подтвердить доступ с веб-сервера и правила фильтрации. Открывать MySQL всему интернету ради проверки — плохая диагностика и плохая настройка. Нужен доступ только с тех узлов, которым он необходим.

Файлы сайта копирую целиком, включая скрытые файлы и каталоги, если они нужны конфигурации веб-сервера. Но .htaccess сам по себе не заставляет WordPress «читать старые директории» и не объясняет ошибку соединения с базой. Его правила могут влиять на маршрутизацию запросов в Apache; на другой конфигурации веб-сервера они вообще не применяются. Поэтому при 404 и проблемах постоянных ссылок проверяю правила веб-сервера, а при ошибке подключения исследую параметры MySQL. Не смешиваю эти ветки только потому, что они всплыли в один день.

Для тестового запуска лучше временно направить домен на новую площадку через локальную запись или другой контролируемый способ, не меняя сразу публичные DNS-записи. Проверяю главную страницу, одну запись, медиафайл и вход в админку. Такой короткий прогон обнаруживает очевидные проблемы до переключения пользователей. Смысл теста — проверить полный путь от веб-сервера до контента, а не только увидеть страницу входа.

• Создать базу на целевой площадке
• Импортировать дамп и проверить таблицы
• Взять параметры доступа у хостинг-провайдера
• Сверить файлы и отдельно проверить маршрутизацию

wp-config.php: проверьте четыре значения

Если имя базы или пользователя изменилось, обновите соответствующие значения в wp-config.php. Для подключения важны имя базы, имя пользователя, пароль и адрес базы данных. Эти параметры должны совпадать с тем, что создано на новом сервере. Порт указывают только тогда, когда площадка действительно сообщает отдельный порт и формат адреса; добавлять его «на всякий случай» незачем. Сначала сверяю значения посимвольно, включая регистр там, где он важен, затем проверяю, не обрезан ли пароль при копировании.

Распространённая ловушка — исправить только три параметра и оставить старое значение DB_HOST. На общем хостинге база может быть доступна под отдельным hostname, и localhost там неверен. Обратная ситуация тоже бывает: новый сервер ждёт локальное соединение, а в конфиг перенесли старый адрес. WordPress называет имя базы, пользователя, пароль и хост среди первых значений, которые стоит проверить при сообщении об ошибке подключения. Это куда полезнее, чем немедленно переписывать конфигурацию MySQL.

Префикс таблиц, заданный в $table_prefix, — отдельная настройка. Он должен соответствовать именам таблиц установленного сайта, например таблица настроек должна начинаться с тем же префиксом. Если он не совпадает, WordPress может не найти ожидаемые таблицы или показать другую ошибку; сам по себе этот факт не подтверждает, что TCP-соединение с MySQL отсутствует. При обычном переносе префикс не меняют. Если его менять сознательно, это уже отдельная миграция схемы с резервной копией и проверкой зависимых данных, а не косметическая правка после переезда.

Не добавляю в рабочий wp-config.php случайные строки, не меняю кавычки вслепую и не публикую файл с паролем в заявке поддержки. Если синтаксис PHP повреждён, PHP-журнал обычно даст более прямую зацепку, чем экран браузера. Доступ к конфигурации ограничиваю, а секреты передаю только через согласованный защищённый канал. Иногда у человека действительно опечатка. Это исправляется точным сравнением, а не заклинанием «переустановить WordPress».

Когда кэш-плагин действительно причастен

Кэш-плагин не превращает автоматически рабочую базу в повреждённую. Он может участвовать в проблеме, если его код несовместим с версией PHP или WordPress, если остались настройки внешнего кэша либо если плагин создаёт чрезмерную нагрузку. Но это гипотезы, которые проверяются по журналам и воспроизводимости. Если страница сообщает, что не удалось установить соединение, проверка плагинов полезна как способ изоляции возможной причины, а не как доказательство, что виноват кэш.

Сначала сохраняю резервную копию, затем отключаю плагины контролируемо и сравниваю результат на тестовой копии или в согласованное окно. Если после отключения ошибка исчезает, возвращаю плагины по одному и фиксирую, после какого именно шага симптом повторяется. Для белого экрана такой метод диагностики рекомендует документация WordPress: отключить плагины и включать их последовательно. Одновременно выключать кэш, менять PHP, править базу и обновлять ядро — значит уничтожить возможность понять причину.

В условном сценарии сети «Тополь-Строй» сайт на WordPress 6.4 после копирования открыл страницу ошибки. Сначала выяснилось, что DB_HOST остался от исходной площадки; после исправления подключения сайт загрузился, но административная часть выдавала PHP-ошибку при включённом плагине. Мы разделили два сбоя: соединение исправили настройкой, а конфликт плагина подтвердили отключением и повторной активацией на тестовой копии. Я не приписываю этому сценарию измеренные часы простоя, экономию или конкретное имя плагина: этих данных здесь нет. Вывод проще и полезнее — за одним переездом могут скрываться две независимые неисправности.

Версия WordPress 6.4 в заголовке описывает исходную установку статьи, а не обещает универсальную совместимость всех расширений. Перед включением проверяю документацию каждого плагина для установленной версии ядра и PHP. Обновления сначала применяю на копии, где проверяю основные сценарии сайта. Если расширение давно не поддерживается или конфликт воспроизводится, ищу замену либо оставляю его отключённым до решения владельца сайта. Не обновляю всё подряд на боевом сервере в надежде, что случайность будет благосклонна.

У кэширования есть ещё один источник ложных выводов: HTML может продолжать отдаваться из файлового или внешнего кэша, хотя динамическая часть уже сломана. И наоборот, очистка кэша может убрать устаревшую страницу ошибки, не исправив первичную причину. Поэтому после восстановления я очищаю только тот слой кэша, который использует сайт, и проверяю результат новым запросом. «Очистить всё» — не универсальный ремонтный инструмент, а операция с конкретной целью.

• Сохранить копию перед отключением расширений
• Проверить сайт без плагинов
• Возвращать плагины по одному
• Сверить совместимость с версиями WordPress и PHP

Диагностика по сообщению и журналам

При сообщении Error Establishing a Database Connection начинаю с четырёх значений в конфиге, затем проверяю состояние базы и доступ пользователя на стороне хостинга. Если параметры верны, прошу администратора базы посмотреть журналы и доступность сервиса в момент ошибки. Причинами могут быть и недоступность сервера, и исчерпание ограничений площадки; повреждение таблиц — лишь одна из возможных отдельных проблем. Нельзя заключить по одной надписи, что база повреждена, и тем более сразу запускать ремонт.

При белом экране без сообщения сначала ищу PHP-журнал веб-сервера и записи в системном журнале хостинга. На тестовой копии можно временно включить WP_DEBUG и WP_DEBUG_LOG, а WP_DEBUG_DISPLAY отключить, чтобы ошибки не показывались посетителям. WordPress пишет диагностический журнал обычно в wp-content/debug.log, если каталог доступен для записи. После проверки режим отладки нужно выключить и оценить доступность самого журнала: диагностические файлы могут содержать чувствительные пути и детали работы сайта.

Ошибка MySQL server has gone away не означает автоматически, что надо увеличить пакет и перезапустить службу. В руководстве MySQL перечислены разные причины: тайм-аут, потеря сетевого соединения, слишком большой запрос или пакет, а также другие ситуации. Увеличение max_allowed_packet имеет смысл, когда подтверждена проблема с размером запроса; при сетевом сбое, неверном hostname или остановленной базе оно ничего не исправит. Сначала смотрю серверный журнал и параметры подключения, затем выбираю действие по конкретной причине. Импорт дампа повторяю лишь после диагностики и проверки, что повторный импорт не испортит текущее состояние.

Таблицы проверяю только при признаках именно табличной ошибки и после создания свежей копии. Инструмент зависит от движка, типа таблиц, прав на хостинге и способа администрирования. Поэтому универсальную команду «проверить и починить всё» я здесь не даю: она была бы выдуманной для части установок. Если восстановление из дампа безопаснее ремонта, сравниваю время и полноту резервной копии и согласую откат. Важно сохранить исходную базу нетронутой до тех пор, пока сайт не прошёл проверку.

• Сохранить точный текст ошибки и время
• Сверить конфиг и доступность базы
• Сопоставить PHP- и MySQL-журналы
• Исправлять только подтверждённую причину

Проверка перед переключением сайта

До переключения публичного адреса я прохожу короткий список сценариев. Для смены домена полезен аудит перед миграцией: главная страница, несколько типов записей, поиск или форма, загрузка медиа, вход и основные действия в админке. Проверяю ссылки, постоянные адреса, отправку форм и то, что сайт читает свежие данные из новой базы. Если меняли домен, дополнительно проверяю URL и редиректы. Это не попытка доказать, что проверена каждая функция; это способ поймать поломки, которые остановят обычную работу сразу после переезда.

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

Резервное копирование после переезда должно охватывать и файлы, и базу на новой площадке. Я проверяю расписание, место хранения копий и то, можно ли восстановить их без исходного сервера. Мониторинг доступности базы полезен, но он не заменяет резервную копию и не объясняет причину каждого сбоя. Если после переключения обнаружилась проблема, заранее сохранённая старая копия и зафиксированные параметры дают путь к откату, а не коллекцию догадок.

Условный кейс заканчивается только после повторной проверки: публичная часть и админка доступны, тестовые записи и изображения читаются, журналы не показывают повторяющуюся ошибку, резервная копия нового состояния создана. При подтверждённом конфликте плагин остаётся выключенным до проверки обновления или замены. Это нормальный результат переноса. Требовать, чтобы любое расширение любой версии работало на любой площадке, — не план, а лотерея с интерфейсом настроек.

• Проверить публичные страницы и админку
• Проверить формы, медиа и ссылки
• Включать компоненты по одному с проверкой
• Создать и проверить новую резервную копию

Частые вопросы