Руководство по миграции WordPress-сайта

  • Tutorial


Каждый веб-разработчик регулярно сталкивается с задачей миграции. Сюда входят и развёртывание (deploy) локальной версии на удалённом сервере, и перенос работающего сайта с одного сервера на другой. Некоторые печатные издания для программистов называются «Cookbook» – что буквально значит «книга рецептов». Рецептов множество, какой из них лучший — дело вкуса. В этом материале автор расскажет о том, какую технологию переноса типичного сайта на WordPress он считает оптимальной, и почему.

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

Резервное копирование данных


С технической точки зрения нам предстоит сделать копии двух составляющих сайта:
  • Файловой системы
  • Базы данных

Каждый веб-разработчик должен заботиться о сохранности данных веб-сайта. Поэтому, как правило, после того как рабочая версия развёрнута на удалённом сервере, разработчик сайта настраивает резервное копирование данных или «бэкап» (от англ. «backup copy», резервная копия).

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

В чём главная цель разработчика при переносе сайта с одного сервера на другой? Ничего не потерять. То есть на новом месте сайт должен быть полностью идентичен тому же сайту на старом.

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

Самый простой путь — обратиться ко всем редакторам сайта с просьбой не вносить изменения в содержимое сайта на время переноса (допустим, на ближайшие полчаса). Если, например, вы ведёте блог на WordPress, то договариваться с кем-либо нет необходимости.

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

Режим обслуживания


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

Как принудительно перевести в него сайт?

Для этого необходимо в корне сайта создать файл под названием .maintenance и разместить в нём следующий PHP-код:

<?php $upgrading = time();


Результат:


В принципе, этого будет достаточно для того, чтобы никто (кроме администратора сервера) не смог пользоваться сайтом.

Однако, если вы хотите сделать страницу более привлекательной, можете создать в папке wp-content файл maintenance.php, который будет загружаться вместо исходного текста. В нём вы можете сверстать какую угодно картинку для поджидающего окончания работ пользователя.

Также можно порекомендовать специальный плагин, которые можно использовать в тех же целях:


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

Резервная копия базы данных


Способов создания резервной копии базы данных WordPress существует несколько:
  • При помощи плагинов WP-DB-BackupWP Database Backup и прочих.
  • При помощи браузерной утилиты phpMyAdmin
  • При помощи консоли сервера
  • При помощи панели хостинга

С целью экономии места в посте не буду рассказывать про первые два способа, они достаточно тривиальны.

Если у вас есть доступ к консоли сервера, и вы умеете пользоваться терминалом — это заметно ускорит работу.

Прежде всего потому, что создании резервной копии выполняется одной единственной командой:

mysqldump -u[пользователь] -p[пароль] [имя_базы_данных] > [имя_файла_резервной_копии].sql


По-хорошему будет заархивировать дамп базы на ходу:

mysqldump -u[пользователь] -p[пароль] [имя_базы_данных] | gzip >[имя_файла_резервной_копии].sql.gz


Текстовые файлы, коим является дамп базы, архивируются наилучшим образом. Размер архива может быть значительно ниже размера дампа базы. Это важно при переносе, т.к. 100Мб перенести куда быстрее, чем 1Гб, например.

Некоторые хостинг-компании предоставляют возможность архивирования данных сайта через панель управления услугами:

После чего на почту приходит заархивированная копия базы данных и сайта.

Однако, далеко не каждый хостинг предоставляет подобные возможности клиентам, поэтому если данный вариант присутствует — удобнее всего пользоваться им.

Резервная копия файлов


Файловая система WordPress обычно выглядит следующим образом (без поддиректорий и их содержимого):
├── index.php
├── license.txt
├── readme.html
├── wp-activate.php
├── wp-admin
├── wp-blog-header.php
├── wp-comments-post.php
├── wp-config-sample.php
├── wp-config.php
├── wp-content
├── wp-cron.php
├── wp-includes
├── wp-links-opml.php
├── wp-load.php
├── wp-login.php
├── wp-mail.php
├── wp-settings.php
├── wp-signup.php
├── wp-trackback.php
└── xmlrpc.php


В принципе, больше всего нас интересуют папка wp-content и конфигурационный файл wp-config.php.

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

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

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

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

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

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


Восстановление данных


Итак, архив файлов сайта и дамп базы данных перенесены на новый сервер.

Воссоздание файловой структуры


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



Чтобы восстановить исходную структуру и не напортачить с папками, необходимо руководствоваться следующим правилом:

Распаковывать архив необходимо там же, где он был создан.

Например, если вы сжимали сайт при помощи консольного архиватора из корня сайта zip -r "full-backup.zip" *, то и распаковывать на новом сервере его необходимо также в корне сайта unzip full-backup.zip.

Обратите внимание, что невидимые файлы, коим является .htaccess не всегда архивируются вместе с остальными. Поэтому, если на вашем новом сайте не работают «красивые адреса», первым делом проверьте, перенесли ли вы .htaccess в корень сайта.

Не забудьте удалить архив с файловой структурой сайта с сервера, чтобы его не могли скачать посторонние.

Воссоздание базы данных


Прежде чем восстанавливать базу данных, необходимо убедиться, что на новом сервере уже создана соответствующая новая база данных.

Если же её ещё нет, то создать новую базы данных можно разными способами:
  • Через веб-интерфейс при помощи утилиты phpMyAdmin
  • Через панель управления хостингом
  • Через консоль сервера следующей командой:
    mysql -u[имя_пользователя] -p;
    # после ввода пароля  вы войдете в режим командной строки MySQL
    mysql: CREATE DATABASE [имя_базы_данных] CHARACTER SET utf8 COLLATE utf8_general_ci; CHARACTER SET utf8 COLLATE utf8_general_ci; CHARACTER SET utf8 COLLATE utf8_general_ci;
    GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER ON[имя_базы_данных] .* TO [имя_пользователя]@localhost IDENTIFIED BY '[пароль]';
    

В результате мы должны иметь на руках:
  • Имя базы данных
  • Имя пользователя
  • Пароль

В некоторых случаях, когда база данных находится на другом сервере, нам необходимо ещё знать адрес хоста (обычно — localhost,  если на той же машине).

Используя эти данные мы должны импортировать наш дамп базы данных.

Опять-таки, сделать это мы можем теми же средствами.

В phpMyAdmin выбираем базу данных, вкладку «Импорт», выбираем файл дампа и отправляем форму запроса.



Если вы работаете через консоль, используйте команду mysql -u[имя_пользователя] -p[пароль] [имя_базы_данных] < [дамп_базы_данных].sql.

В случае, если дамп базы данных был заархивинован: gunzip < [дамп_базы_данных].sql.gz |mysql -u[имя_пользователя] -p[пароль] [имя_базы_данных].

Не забудьте удалить дамп базы данных с сервера или перенести его в безопасное место, в случае, если он там был.

Настройка файла конфигурации


Теперь необходимо открыть в редакторе файл wp-config.php и установить соответствующие настройки для соединения с новой базой данных:



Не забудьте удалить файл .maintenance из корневой папки сайта.

Остаётся только проверить работоспособность сайта!

Заключение


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

Вероятно, более опытные веб-разработчики захотят поделиться с коллегами собственными наработками по теме.

Что же, для этого и созданы комментарии. Поэтому любые советы, дополнения и просто обмен опытом категорически приветствуются.

P.S. Важное дополнение в комментарии от nik_vr:
При переносе с localhost'а на реальный сервер нельзя забывать про адрес сайта. Смена домена с одновременным переносом по вашей инструкции сделает сайт абсолютно неработоспособным. По-этому в инструкцию стоит добавить ещё один шаг (актуальный при смене домена, в т.ч. — при переносе с локального сервера на боевой). Для примера будем считать, что сайд переносится с домена mysite.local на домен mysite.ru.

В сохранённом дампе базы данных WordPress ищем все вхождения mysite.local и заменяем на mysite.ru. Можно это сделать в любом нормальном текстовом редакторе (например, Notepad++). После замены аккуратно сохраняем БД, не забывая о кодировке (в случае с более или менее современными версиями WordPress нужна кодировка UTF-8 без BOM).


После импорта базы данных можно выполнить следующую MySQL-команду:

UPDATE wp_options SET option_value = 'http://mysite.ru' WHERE option_value = 'http://mysite.local';
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 51
  • +2
    При переносе с localhost'а на реальный сервер нельзя забывать про адрес сайта. Смена домена с одновременным переносом по вашей инструкции сделает сайт абсолютно неработоспособным. По-этому в инструкцию стоит добавить ещё один шаг (актуальный при смене домена, в т.ч. — при переносе с локального сервера на боевой). Для примера будем считать, что сайд переносится с домена mysite.local на домен mysite.ru.

    В сохранённом дампе базы данных WordPress ищем все вхождения mysite.local и заменяем на mysite.ru. Можно это сделать в любом нормальном текстовом редакторе (например, Notepad++). После замены аккуратно сохраняем БД, не забывая о кодировке (в случае с более или менее современными версиями WordPress нужна кодировка UTF-8 без BOM).
    • 0
      Большое спасибо. Подзабыл об этом, т.к. обычно на локалхосте разрабатываю под таким же доменом, как потом выкладываю в сеть.

      Добавлю комментарий к топику, с вашего позволения.
      • 0
        Также после импорта базы данных можно выполнить следующую MySQL-команду:
        UPDATE wp_options SET option_value = 'http://mysite.ru' WHERE option_value = 'http://mysite.local';
        
        • 0
          или использовать плагин Root Relative URLs
          да меня тоже выбешивают абсолютные урлы в бд.
          • 0
            Немного смущает, что этот плагин уже полтора года не обновлялся. В какой-то момент он может начать некорректно отрабатывать на новых версиях WordPress. Но в целом относительные пути — это отличная вещь.
            • 0
              плагины с парой строчек кода берут пару функций из api времен версий 2.5
              там просто нечего обновлять) но он прожорливый, от того его лучше использовать на девелоперской версии.
              • 0
                API тоже иногда меняется :) Хотя legacy-кода там могло бы быть и поменьше. Насчёт прожорливости учту — чаще всего WordPress для клиентов приходится переносить на виртуальный сервер, с лимитом времени на скрипты бывают проблемы.
          • +1
            Можно проще сделать!
            В файле wp-config.php добавить строки:
            define('WP_HOME','http://example.com');
            define('WP_SITEURL','http://example.com');

            Тут больше способов, как сменить url сайта: codex.wordpress.org/Changing_The_Site_URL
          • +1
            В базе данных WP может быть сотня мест, где сохранились прямые ссылки. Изменить их путем sql-запроса или путем правки строк в SQL-дампе ни в коем случае нельзя (nik_vr дал плохой совет!), так как большинство из них сериализованные. Для таких случаев придумана вот эта утилита: interconnectit.com/products/search-and-replace-for-wordpress-databases/

            Её, впрочем, можно использовать и для других целей.
            • 0
              Спасибо. Добавлю в пост.
              • +1
                Ссылки, которые хранит сам WordPress у меня за 6 лет ни разу не было проблем (в плане замены). Не один десяток сайтов так перенёс. Возможно, могут быть проблемы с плагинами, которые хранят ссылки как-то нестандартно.
                Что касается сериализованных данных, то не вижу особых проблем — если всё делать аккуратно, ссылки в «наборах» прекрасно заменяются.
                Но за ссылку на утилиту — спасибо, интересная штука, надо будет попробовать.
                • 0
                  Не очень понял, что значит аккуратно делать? Вот есть у вас сериализованная строка:

                  s:17:"http://localhost/";
                  


                  Знаете, что будет, если вы её слепо замените на

                  s:17:"http://mysupersite.com/";
                  


                  Вы получите

                  PHP Notice:  unserialize(): Error at offset 23 of 31 bytes in - on line 3
                  


                  Или под аккуратно вы имеете ввиду менять еще и число символов руками? Ну тогда это это страшная вещь, я вам скажу :)
                  • 0
                    Работаю в хостинге и переношу до нескольких десятков сайтов в день. Ни разу не видел подобной проблемы. В большинстве случаев вопрос решается проходом sed по дампу базы. Иногда нужно чуть поправить конфиги.
                    • 0
                      То, что вы не встречали проблемы, еще не значит, что можно брать и менять строку на другую произвольной длины в сериализованном объекте или массиве, а с учетом того, что WP по умолчанию подавляет любые сообщения уровня Notice, то можно предполагать, что проблемы были, но вы о них недогадывались. Но чтобы не напрасно не спорить тут, просто накидайте небольшой кусочек PHP-кода и убедитесь сами в наличии проблемы.

                      sed'ом, думаю, можно конечно поменять и размер строки в сериализованном виде. Но выглядит это извращением.

                      p.s. Вордпресс по умолчанию подавляет любые сообщения уровня notice, поэтому даже если проблема есть вы её с большой вероятностью никогда не увидите, если не будете проверять на её наличие.
                    • 0
                      Аккуратно, это значит — проверить наличие сериализованных данных. Вот сейчас, например, я открыл БД последнего сайта, который переносил подобным образом и прошёлся поиском на предмет упоминаний домена. Домен ни разу не упоминается в сериализованных данных. Все вхождения — в обычных ключах. Для примера глянул БД одного сайта на Joomla — там кругом массивы и автозамена не покатит, конечно же.
                      В принципе, пару раз и руками доводилось менять данные в массивах. Но не домены, кстати. По-моему в стандартных таблицах WordPress домен хранится только в отдельных ключах. Возможно какие-то плагины хранят его и в массивах, но мне пока везёт :)
                • +1
                  Во время миграции, чтобы не лазить лишний раз в MySQL удобнее намного пользоваться вот этими двумя строками wp-config

                  define('WP_HOME','http://example.com');
                  define('WP_SITEURL','http://example.com');

                  codex.wordpress.org/Changing_The_Site_URL


                  Прямые ссылки, например на картинки, сейчас Wordpress сам не проставляет, разве что пользователь сам введет какие-то, которые будут вести на старый сайт. На этот случай удобнее пользоваться плагином для поиска и замены: wordpress.org/plugins/search-and-replace/

                  • 0
                    Буквально с месяц назад переносил сайт на WordPress 4.0 с локалхоста на сервер — ссылки на изображения в постах прямые были.
                    • 0
                      Тоже смотрю, что в визуальный редактор менеджер изображений вставляет абсолютные пути.
                      • 0
                        И не только в визуальный. Я plaintext-редактор использую — штатный загрузчик изображений и туда вставляет полные пути. Вот прямо сейчас проверил на свежем WordPress 4.1 — ничего не поменялось. В принципе, можно каждый раз ручками править, но оно кому-то надо? Не так уж часто с домена на домен приходится переносить.
                        • 0
                          Проще прогнать одних из указанных выше плагинов при переносе.
                  • 0
                    (del)
                    • 0
                      Wordpress — это одна из самых лояльных к миграции систем. Тут всё настолько просто, насколько это вообще можно представить — проще только CMS без БД. Здесь ведь даже никаких подготовительных действий не нужно совершать, по большому счету.

                      Лучше расскажите, как осуществлять миграцию в три-четыре действия таких CMS как MODx или, прости господи, Bitrix. Вот это действительно интересно.
                      • 0
                        Ну, для битрикса, справедливости ради, надо сказать, работает следующий способ:

                        1. Делаем резервную копию в папку сайта.
                        2. Скачиваем и заливаем архив резервной копии на нужный домен (или локально).
                        3. Скачиваем restore.php (ссылку на него можно найти при выполнении п.1) и закидываем рядом с архивом.
                        4. Запускаем site.tld/restore.php. Дождавшись распаковки сайта, вводим данные для доступа к БД.
                        6. Правим .htacсess, если нужно.

                        При грамотной работе с битриксом, в общем-то всё.

                      • 0
                        Дочитываю Wordpress Missing Manual и буду мигрировать с Joomla.

                        Почти все понял, но кое-что в WP мне хочется изменить, а пока не знаю как. Например, хочется Media Library, в которой я могу сам создавать папки в любом месте в любой момент и закачивать туда картинки.
                        • 0
                          Я вас огорчу, в Media Library вообще нет понятия папок. Но вы можете поискать готовое стороннее решение, или же написать своё :)
                          • 0
                            В принципе, насколько нужны папки при таком устройстве галлереи, как в WP?
                            • 0
                              WP Media L кидает по папкам, но там wp-content/images/year/month/

                              Можно, конечно, перенастроить корневую и убрать даты, но все равно не для всех удобно.
                            • 0
                              я знаю, что стандартными средствами не реализовать. буду искать готовое.

                              Php пока не знаю. Буду учить сразу после прочтения WP. Правильнее до, но у меня поддержка моей версии джумлы заканчивается + из-за проблем с хостингом сайт глючит сильно.
                        • +3
                          Зачем все эти сложности в 2014-2015 году? Давно создали полностью автоматизированный плагин для таких переездов: wordpress.org/plugins/duplicator/. На старом сервере заходите в плаг — создать архив.
                          Создается файл архива + installer.php. Переносите их на новый сервер, запускаете installer.php. Установщик спросит вас новые логины\пароли от базы данных. Все хардлинки заменит сам.
                          Сохраняется всё вплоть до расположения окон в админке.
                          В итоге всё вместе занимает 10 минут времени.
                          • 0
                            Вот именно за тем, что не все об этом знают. Спасибо за открытие, до того не слышал даже об этом плагине, хотя долгие годы работаю с WP.
                            • +1
                              Плагин по моему еще с первых версий вордпресса появился. Есть альтернативные с более красивым интерфейсом, но Duplicator мною лично опробован несколько десятков раз. Самый большой плюс — сохраняет абсолютно всё на своих местах.
                              Когда я только знакомился с ВП, переносил все руками. И обязательно была какая-то жопа — то настройки админки сбрасывались, то пермалинки умирали и т.п.
                              • 0
                                Ещё раз большое человеческое спасибо. Я всё по-старинке, да по-старинке делал… Так надёжнее. Но если можно применить инновации, почему бы и нет?
                                • +1
                                  Забыл одну ерунду…
                                  Плагин во время запаковки сайта может упереться в php_max_execution_time или в ограничение по оперативке. Простых сайтов это не касается, но вот если это интернет-магазин на WP+WooCommerce с 5000+ товаров — может долго тупить на запаковке картинок к товарам. Приходится картинки отдельно переносить иногда. Но это обычно касается очень больших и тяжелых сайтов.
                            • 0
                              Отлично сработало! Спасибо за совет.
                            • 0
                              А можете подсказать хороший форум по WP? Можно англоязычный.

                              Хочу до НГ перенести сайт, но чувствую, что сам на все 100% не сделаю. Надо еще и ссылки сохранить старые, как в Joomla. /category/ уже нашел как удалять через WordPress SEO by Yoast, но могут быть глюки из-за этого
                            • 0
                              А как называется ftp-менеджер на скрине «Воссоздание файловой структуры»?
                              • 0
                                Это не просто FTP, это редактор кода + FTP + SSH + MySQL + документация + ещё много чего:
                                panic.com/coda
                              • 0
                                Существует такая штука — wp-cli, интерфейс командной строки для WordPress. Там много разных полезных команд (я статью написал про него), в том числе для действий с базой данных, в том числе для поиска/замены в дампе с учётом сериализованных данных.
                                На wp-cli основан плагин WP Migrate DB Pro, который упрощает процесс переноса базы.
                                • 0
                                  До кучи ещё один плагин для сабжа плюс бекапов: Xcloner
                                  • 0
                                    Ну коли такая пьянка пошла, расскажу и я про свой процесс деплоя )
                                    1. Есть WP сайт на локалке.
                                    2. Есть ssh досптуп на сервак
                                    3. Есть phpmyadmin сервака

                                    Использую git, composer, плагин wp-migrate-db.

                                    На локалке делается git pull, после делается бэкап с помощью wp-migrate-db и сохраняется локально.

                                    После идем на сервак, заходим в папку с сайтом и пишем git pull. Если что-то доставлялось локально (плагины или темы или еще что), то пишем composer update. После идем в phpmyadmin сервака и импортиреум сделанный wp-migrate-db ранее файл.

                                    ВСЕ! Профит.
                                    • 0
                                      В сохранённом дампе базы данных WordPress ищем все вхождения mysite.local и заменяем на mysite.ru. Можно это сделать в любом нормальном текстовом редакторе (например, Notepad++)

                                      Так нельзя делать. Например, в опциях могут храниться сериализованные данные, и если вы ручками будете их править, то можете переломать всё к чертям. Используйте для этого WP-CLI либо Search-Replace-DB, а лучше ознакомьтесь с более правильным переносом
                                      • 0
                                        Так нельзя делать.

                                        Вообще-то я об этом написал еще 24 декабря 2014 в 21:31. Или вы просто решили ссылочкой на свой сайт поделиться?

                                        Search-Replace-DB

                                        И об этом я тоже писал.

                                        Почему бы вам вместо того, чтобы постить коммент для получения беклинка в теме, которой скоро год, не написать отдельный пост на Хабре? Пользы будет больше.
                                        • 0
                                          Или вы просто решили ссылочкой на свой сайт поделиться?

                                          Полезной ссылкой чего б и не поделиться?)

                                          Почему бы вам вместо того, чтобы постить коммент для получения беклинка в теме, которой скоро год, не написать отдельный пост на Хабре?

                                          А смысл? Всё, что надо, уже написано, а что появится нового, так статья будет дополняться
                                          • 0
                                            Смысл в том, что на хабре людей в разы больше, чем на вашем сайте. И нет гарантий, что ваш сайт вообще завтра будет еще существовать, а в будущем хабра я сомневаюсь гораздо меньше.
                                      • 0
                                        Не могу найти информацию толковую по правильному трансферу с хостинга WP. Судя по их докам, они не дают прямого доступа к базе и по FTP нельзя тоже. Есть только миграция контента через Импорт в админке, но там переносится именно контент, а всё остальное потом руками допиливать придётся. Не понятно даже как старый добрый бэкап сделать хотя бы.
                                        • 0
                                          поставьте плагин UpdraftPlus — Backup/Restore он копирует базы, файлы и все остальное на фтп или в облако
                                          • 0
                                            Вы уверены, что на wordpress.com это возможно? :)
                                            • 0
                                              Извините, пропустил про хостинг WP — не уверен, никогда там не хостился.

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