Перенос WordPress на другой хостинг, домен или денвер. Перенос WordPress на другой хостинг: особенности, порядок действий

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

Навигация по странице:

Вы наверно знаете, что если просто взять и направить новый домен на сайт, то админка и отдельные части сайта будут открываться со старого домена + будут глючить меню постоянно перекидывая не туда куда вам нужно. Есть 2 пути решения этой проблемы, исправить дамп базы данных или воспользоваться волшебными строчками кода для файла wp-config.php WordPress:

define("WP_HOME", "http://новыйдомен.ru");
define("WP_SITEURL", "http://новыйдомен.ru");

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

Этот код полностью решает проблему с перебрасыванием с нового домена на старый и заставляет грузится админку вордпресс с нового адреса, но к сожалению ему не под силу изменить все ссылки внутри постов, страниц, таксономий, виджетов и так далее. По сути этот код пхп подменяет домен который прописан у ваших настройках, перенос wordpress на другой домен при этом не выполняется:и можно банально изменить домен в настройках, чтоб не дописывать код в wp-config.php.

Но сегодня не об этом, нам нужно сделать полную замену старого домена на новый.

Для переноса wordpress на другой домен нам потребуются вот такие инструменты:

Название Описание Ссылка
(первый клик сгенерировать ссылку,
второй открыть в новой вкладке)
FileZilla - бесплатный FTP клиент ФТП клиент для работы с файлами и каталогами на вашем хостинге.
Adminer Php файл для скачивания базы mySQL. Можно воспользоваться встроенным phpMyAdmin на вашем хостинге, если он конечно есть, но я опишу универсальный вариант с использованием этого файла.
Notepad++ Стильный и удобный редактор файлов. На голову выше штатного текстового редактора в виндовс.

Смена домена wordpress

Для смены домена в WordPress нам нужно скачать дамп базы данных. Сделать это можно с помощью пхп файла Adminer или воспользовавшись панелью хостинга phpMyAdmin.

Пошаговая инструкция по смене домена в Вордпресс:

1) скачиваем Adminer по ссылке выше и заливаем его через фтп к себе на хостинг. Для этого нам нужен ФТП клиент FileZilla, а также фтп доступ к вашему хостингу. Запускаем фтп клиент FileZilla и вводим наши фтп данные как показано на скриншоте:

2) в правой колонке у нас файлы с сервера, а в левой файлы нашего ПК. В левой колонке нужно найти папку где лежит adminer-4.2.2.php (кстати у вас может быть немного другое имя), а в правой нужно найти директорию где лежит наш сайт, там будут обязательно файлы "wp-config.php", "index.php", директории "wp-content", "wp-admin", "wp-includes" и залить админнер на сервер.

3) Открываем браузер и набираем там вашсайт.ком/adminer-4.2.2.php (заменить под свой вариант) должна открыться страница вот такого плана:4) Если вы знаете эти данные что просит админнер то вводим их, если нет то открываем файл wp-config.php, он в корне вашего сайта и берем нужные данные доступа к базе, как показано на рисунке:

5) вводим данные в форму входа и нажимаем войти, у нас должно появится окно вот такого плана:


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

7) можно скачать базу целиком и потом мудохаться с заменой юрл, а можно разбить ее на 2 части и избежать проблем. В первую часть базы мы включаем все таблицы кроме "wp_comments" и "wp_posts" внимательно смотрите на скин ниже:


и нажимаем экспорт. Сохраняем файл, обязательно обозначаем что это первая часть, например добавляем в имя цифру 1:Теперь делаем вторую часть для этого в том же экспорте нужно поставить чербоксы только возле таблиц "wp_comments" и "wp_posts", смотрите скин:
и опять нажимаем экспорт только к имени добавляем число 2:

8) Открываем первую часть базы в Notepad++, который уже должен быть инсталлирован на наш ПК:и нажимаем сочетание клавиш Ctrl+f, в этом окне пишем свой домен в окно поиска и нажимаем Enter:
продолжаем поиск до того момента пока мы не найдем данные вот такого плана:

"siteurl", "http://сайт"

""home", "http://сайт"

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

9) Открываем вторую часть в Notepad++ и делаем немного другую вещь. Опять нажимаем Ctrl+f но в поиске переходим во вторую вкладку "Replace" и заполняем как у меня на скине:

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

10) Возвращаемся к нашему админнеру, переходим во вкладку импорт и заливаем сначала первую часть дампа потом вторую по очереди:

11) После успешной заливки обеих частей дампа в базу, ваш сайт сменил доменное имя, и если вы до этого направили ДНС нового домена на ваш хостинг, то сайт откроется с нового доменного имени, смена домена wordpress - прошла успешно, перенос wordpress на другой домен - выполнен.

12) Заходим в админку, первая вкладка настроек "общее" (вашсайт/wp-admin/options-general.php) смотрим правильный ли у нас домен указан в обеих полях и нажимаем сохранить изменения при этом изменений мы никаких не делали. Все, теперь ваш сайт будет работать с нового домена.

Перенос wordpress на другой домен

Теоретически я уже рассказал как делать перенос wordpress на другой домен, точнее вот здесь (дальше я буду называть эту пошаговую инструкцию как "Инструкция 1") я рассказал как перенести ВП на другой хостинг, а в заголовке (дальше буду называть "Инструкция 2") я описал как делать смену домена Вордпрес. Осталось только структурировать все описанное.

И так, структурировання пошаговая инструкция :

1) Из "Инструкции 1" делаем все пункты от первого до пятого (1 - 5) включительно.

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

4) Эта инструкция подразумевает что вы уже привинтили новый домен к новому хостингу, этот процесс я описывать не буду. Подключаемся к новому хостингу, там у нас должна быть сделанная база и привинчен сам сайт (созданные папки куда заливать файлы по ФТП). Из "Инструкция 1" вам нужно сделать пункты с 13 по 15 включительно.

5) В "Инструкция 1" в п. 16 говорится что нужно залить 1 часть базы, у нас же 2 части, то есть мы заливаем по очереди первую и вторую часть базы данных.

6) На этом все, перенос wordpress на другой домен закончен и мы можем насладится его работой.

В этой инструкции я немного все упростил, не стал описывать все по новой, ведь перенос wordpress на другой домен и перенос сайта wordpress на другой хостинг - задачи довольно похожие. Вам главное понимать, что скачивать вам со старого хостинга нужно не 1 дамп цельный, а 1 дамп разбитый на 2 части. Ну и от сюда следует что вам нужно будет закачать на новый хостинг 2 части одного дампа базы. + в этих частях нужно знать как и где делать смену домена на новый. Мы сделали перенос wordpress на другой домен, если у вас что то не получилось вы можете обратиться ко мне и я вам помогу.

  • Tutorial

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

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

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

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

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

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

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

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

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

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

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

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

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

Результат:

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

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

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

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

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

Способов создания резервной копии базы данных WordPress существует несколько:
  • При помощи плагинов WP-DB-Backup , WP 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. Важное дополнение в комментарии от

При простом переносе файлов wordpress из одной директории в другую, сайт «ломается» — нарушается вёрстка, пропадают картинки. Данная инструкция поможет вам, если:

  • вам необходимо произвести перенос с одного домена на другой или с поддомена на основной домен;
  • вам необходимо произвести перенос с подкаталога ../domain.ru/wordpress в основной каталог ../domain.ru/ .

Перенос с одного домена на другой

В том числе, с поддомена sub.domain.ru на основной домен domain.ru .

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

  1. 1 Откройте корневой каталог исходного сайта. .
  2. 2 Выделите все файлы сайта и скопируйте их в корневую папку нового сайта.
  3. 3

    При необходимости создайте новую базу данных (БД) и импортируйте в неё дамп БД исходного сайта: , .

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

  4. 4

    После импорта необходимо скорректировать адрес сайта в базе данных. Для этого откройте базу данных нового сайта в phpmyadmin . Выберите необходимую базу и перейдите во вкладку SQL . По очереди выполните следующие SQL-запросы:

    • UPDATE wp_options SET option_value = REPLACE(option_value, "http://olddomain.ru", "http://newdomain.ru") WHERE option_name = "home" OR option_name = "siteurl";
    • UPDATE wp_posts SET guid = REPLACE(guid, "http://olddomain.ru","http://newdomain.ru");
    • UPDATE wp_posts SET post_content = REPLACE(post_content, "http://olddomain.ru", "http://newdomain.ru");

    Где olddomain.ru — прежнее название сайта, а newdomain.ru — новое название сайта. Если вы используете SSL-сертификат для сайта замените http на https .

    Важно: если у вас кириллический домен, название домена в SQL-запросах необходимо вводить в формате Punycode. Для перевода кириллического домена в формат Punycode, воспользуйтесь . Например, вам необходимо перенести сайт на кириллический домен новыйдомен.ru . Название этого домена в формате Punycode выглядит так: xn--b1aedoqcfcd1k.ru . В таком случае, вам необходимо вводить SQL-запрос (на примере 2 запроса): UPDATE wp_posts SET guid = REPLACE(guid, "http://olddomain.ru","http://xn--b1aedoqcfcd1k.

    Возникла ошибка

    Если вы наблюдаете подобную ошибку: 1146 — Table "u1234567_hid5.wp_options" doesn"t exist , проверьте, существует ли такая таблица wp_options .

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

  5. 5 Очистите папку wp-content/cache , если у вас настроено кэширование. Перед проверкой корректности отображения сайта очистите кэш браузера.
  • Tutorial

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

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

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

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

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

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

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

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

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

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

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

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

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

Результат:

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

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

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

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

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

Способов создания резервной копии базы данных WordPress существует несколько:
  • При помощи плагинов WP-DB-Backup , WP 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. Важное дополнение в комментарии от