Проблемы переезда сайта на WordPress на другой хостинг

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

Wikimedia_Foundation_Servers-8055_35

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

Самый простой способ переноса сайта WordPress на другой хостинг гласит: сделай бэкап файлов и базы, скопируй на другой хостинг, восстанови бэкапы, поменяй настройки доступа к базе WordPress. Всё выглядит быстро и красиво — казалось бы, какие могут возникнуть проблемы?

У меня их было несколько и все — с базой данных. Хотя это и не было очевидно в одном из случаев.

Проблема 1. Бэкап не восстанавливается

Бэкап у меня не хотел восстанавливаться по множеству причин. Я пробовал делать архив как через панель PhpMyAdmin, так и через консоль по SSH, и восстанавливать также разными способами — не помогало. То размер ключа не такой, то тип ключа не такой, то символьные поля не того типа.

Одна из множества подобных проблем
Одна из множества подобных проблем

Вероятное, но не спасшее меня решение: поменять в бэкапе базы (если он в текстовом виде — в общем случае там будут SQL-запросы, для тех, кто знает SQL — простые как стихи Пушкина) длины ключей с varchar(255) на varchar(128). После исправления возникли другие ошибки. Их мы с приятелем тоже поправили, и всё-таки восстановили бэкап на новой базе, однако лучше бы мы этого не делали, т.к. всё равно возникла вторая проблема, и ниже я опишу решение, как избавиться от обеих проблем сразу.

Проблема 2. При добавлении записи не отображается визуальный редактор WordPress

Вообще, эта ерунда может быть симптомом очень множества разных проблем. У кого-то просто на собственного пользователя редактор оказался отключён, кого-то спасает обновление файлов WordPress на хостинге. Вариантов много, но если вы видите такое:

Нажимаем «Добавить запись» и видим вот такое — верный признак отсутствия AUTO_INCREMENT
Нажимаем «Добавить запись» и видим вот такое — верный признак отсутствия AUTO_INCREMENT

Ключевая фраза: «Вы редактируете страницу, на которой отображаются свежие записи».

Это 99,99% симптом проблемы с автоинкрементом таблиц. Точнее, с его отсутствием. Описание этой проблемы я нашёл в единственном месте в интернете, вот тут. Там же подробнее описаны симптомы и метод лечения, если у вас такое уже давно, но вы никак не нашли способа решения.

Наглядно вся суть проблемы (на примере таблицы wp_options)
Наглядно — вся суть проблемы (на примере таблицы wp_options)

Кратко: ключевые поля таблиц при переносе теряют свойство AUTO_INCREMENT, которое для них жизненно необходимо. В итоге при попытке вордпресса что-то записать в таблицу создаётся запись с нулевым ключом, и запись не происходит. Это можно изменить постфактум и вручную — удалить из таблиц записи с нулевым ключом и в редакторе структуры в PhpMyAdmin поставить галочку «A_I» в свойствах поля. (Да, A_I — это именно AUTO_INCREMENT, а не All Inclusive). Главное не забыть сделать это для каждой таблицы.  Но во избежание появления любых ошибок (в том числе, первой проблемы) у меня есть немного более простое решение (хотя в тексте оно выглядит сложным).

Вручную можно просто поставить эту галочку
Вручную можно просто поставить эту галочку

Решение обеих описанных выше проблем (позволяющее их полностью избежать), по шагам:

Шаг 1. Бэкап

Перво-наперво, делаем полный бэкап нашего старого сайта. Кстати, можно даже на время его закрыть, если у вас ожидаются какие-то обновления контента (я не закрывал, т.к. комментарии у меня Disqus, новые статьи я на время переноса не планировал, да и вообще переносил в воскресенье и довольно быстро).

Файловую систему архивируем полностью. Лучше сделать архив на самом сайте — через контрольную панель (если ваш хостер это позволяет) либо через консоль по SSH, например, так:

tar czf site-home-folder.tar.gz site-home-folder
Экспортируем только данные
Экспортируем только данные

Базу данных экспортируем через PhpMyAdmin, но только ДАННЫЕ. То есть, структуру не экспортируем. На всякий случай можно поставить совместимость с MSSQL, но можно и не ставить.

Тут кто-то скажет, что для верности лучше использовать бэкап через SSH и команду mysqldump. Нет, не лучше. В данном конкретном случае никаких преимуществ это не даст. Но если вам лично проще через SSH, чем через PhpMyAdmin — пожалуйста.

Шаг 2. Установка «пустышки» на новый хостинг

Ставим на новый хостинг новый чистый WordPress, но той же версии, что у нас сайт. Та же версия нужна не то чтобы обязательно, но на всякий случай пусть будет так.

Создаём базу данных средствами хостера. Далее нам же нужно к своему сайту как-то обращаться, правильно? Можно прописать свой домен на новый IP в файл hosts (как это сделать на Windows, как это сделать на Mac) на своей локальной машине, на которой мы всем этим занимаемся. Если IP нашего нового сайта (IP должен предоставить хостинг) 80.145.112.40, а домен — mysite.ru, то пишем в hosts конкретно следующее:

80.145.112.40   mysite.ru

(Набираем IP, нажимаем Tab, набираем домен). Обновляем кэш на Mac (dscacheutil -flushcache) или перезапускаем Windows — всё, набрав в браузере mysite.ru мы попадаем на новый хостинг, а не на старый. Кстати, удобно, когда под рукой два компьютера — чтобы на одном вы видели старый сайт, на другом — новый. Главное, не перепутать.

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

Убеждаемся, что «пустышка» работает нормально. Можно попробовать создать пост и залить в него картинку. Работает? Ок, переходим дальше.

Шаг 3. Устраняем разницу в БД

Это чисто проверочный пункт, не факт, что он вам вообще нужен. Дело в том, что некоторые плагины для WordPress создают свои таблицы в базе данных. Поэтому просто откройте в PhpMyAdmin старую и новую базы — в разных окнах браузера. И таблица за таблицей сравните — какие таблицы отсутствуют в новой.

Отмеченные таблицы, например, в дистрибутив WordPress не входят
Отмеченные таблицы, например, в дистрибутив WordPress не входят

Нашли отсутствующие? Сделайте экспорт СТРУКТУРЫ конкретно этих таблиц из старой базы и прогоните получившийся SQL-скрипт на новой базе. Если вдруг будут ошибки, тогда возможно стоит попробовать всё-таки установить на WordPress все те плагины, что могут создавать свои таблицы (загуглите имя таблицы — должно помочь). Пусть плагин сам создаст эти таблицы в новой базе.

Шаг 4. Удаляем «пустышку»

Теперь нам нужно избавиться от «пустышки», но не полностью. От файлов WordPress можно оставить, разве что, wp-config.php — там прописаны параметры подключения к новой БД. Но ещё лучше переписать эти параметры в старый файл, который будем переносить, а этот новый — грохнуть. Мало ли что вы туда писали или плагин какой-нибудь писал, а вы забыли. Вот плагин WP-Cache, например, прописывает настройки в wp-config.php.

Очищаем таблицы перед импортом новых данных. От них нам нужна только корректная структура.
Очищаем таблицы перед импортом новых данных. От них нам нужна только корректная структура.

Базу данных нам нужно очистить — удалить всё содержимое таблиц, но оставить сами таблицы. Можно сделать это через PhpMyAdmin — заходим в структуру БД, жмём галочку «Check All», чтобы разом отметить все таблицы, и выбираем действие «Очистить таблицы».

На всякий случай ещё раз сравниваем структуру таблиц в PhpMyAdmin старой и новой базы.

Шаг 5. Копируем старый сайт на новый хостинг

Теперь заливаем архив с файлами WordPress на новый хостинг и разархивируем его. Можно, конечно, и через простой перенос файлов по FTP справиться, но лучше всё же через архив: это гораздо быстрее, не будет проблем со скрытыми файлами, меньше вероятность появления проблем с разницей прав доступа. Через SSH это можно сделать примерно такой командой:

tar xzf site-home-folder.tar.gz site-home-folder

Но, кстати, некоторые нормальные хостинги предоставляют адекватный файловый менеджер, можно распаковать прямо в нём.

Аналогично и с базой. Заходим в PhpMyAdmin нового хостинга и прогоняем SQL архива старой базы. Напомню, в этом архиве должны быть сведения только о наполнении таблиц, никаких процедур создания или удаления таблиц здесь быть не должно. Ну а сама новая база перед прогоном бэкапа должна быть пустой — таблицы созданы, а записей в них нет.

Всё. Проверяйте — должно работать. Теперь можно поменять в настройках домена NS-сервера (новый хостинг должен предоставить их список), удалить или закомментировать добавленную запись в файл hosts на локальной машине, и ждать, пока кэш DNS обновится глобально (мой провайдер, «Онлайм», обновлял этот кэш пол-дня, хотя остальные провайдеры справились гораздо быстрее).

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс