Перенос WordPress-сайта с сохранением настроек и URL’ов на новый сервер

О переносе сайтов от профи. Копирование и перенос файлов с сервера на сервер. Как это делают админы 🙂

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

Что такое FTP и зачем он нужен?

Базово олдскульные  вебмастера привыкли пользоваться протоколом FTP. Логично, File Transfer Protocol — протокол для передачи файлов, он ведь так и называется.  Этим довольно просто пользоваться, когда вы имеете небольшие сайты, с небольшим количеством файлов — несколько сотен, объемом до 1-2 Гб. Но и то, такая задача может превратиться в часы мучений в некоторых условиях.

Ибо если же вам нужно перенести хотя бы гигабайты данных, то вы неминуемо столкнетесь с проблемами, что обрывается соединение, файлы передаются очень медленно и долго. Это объясняется простым фактом, что протокол FTP был создан аж в 1971 году. То есть ему уже 50 лет.

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

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

Как работать с файлами на сервере Linux не имея доступа по FTP?

Те, кто немного попродвинутей и опытней в вебмастерском деле, они уже могут знать, что существует возможность передачи файлов через более безопасный и быстрый протокол SSH. Да-да, тот самый, который используется для управления серверами и предоставляет  возможность подключаться к серверу посредством консольного SSH-клиента такого как Putty.

Такие люди используют для работы с файлами утилиту WinSCP, являющуюся виндовым аналогом консольной утилиты scp.

Scp — нативная утилита в линуксах, которая позволяет копировать файлы по сети между серверами. Создана на основе стандартной утилиты копирования файлов — cp. Поэтому так и называется — S (secure) CP (copy).

А можно просто использовать любой FTP-клиент подключаясь SSH-пользователем на 22-порт. Можно даже рутом и тогда будете иметь доступ через Файлзиллу к любым файлам на сервере.

И такой вариант для работы с файлами всегда будет работать гораздо стабильнее, безопаснее и быстрее. А плюс к этому, не нужно даже настраивать FTP-службу на сервере.

Идем далее.

Быстрый перенос и копирование файлов с сервера на сервер

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

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

Так вот — рекомендую и вам пользоваться такими же способами от истинных ниндзя ? А их тоже не один.

Упаковка (архивация) файлов сайта на сервере и копирование с помощью SCP

Если сайт небольшой, то его можно упаковать в архив и отправить на другой сервер с помощью утилиты scp, такими командами:

tar zcf  ./site.tar.gz  #архивация. 

Её, разумеется, часто можно выполнить и через панель управления. Затем копируем (отправляем) с исходного сервера на целевой:

scp site.tar.gz  root@1.1.1.1:/root/

Здесь после указания имени пользователя и IP через двоеточие указываем путь, куда мы хотим положить на целевом сервере этот файл.

Будет  запрошен пароль от целевого сервера и файл улетит туда.

Затем его можно там распаковать:

tar zxf ./site.tar.gz

и дальше уже положить файлы куда вам надо на новом сервере.

Копировать можно вводя команды и на новом сервере, следующим образом:

scp root@2.2.2.2:/root/site.tar.gz  /var/www/

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

Копирование большого количества файлов и папок  с одного сервера на другой без архивации

Когда файлов немного и объем небольшой, нет смысла заморачиваться с упаковкой файлов. Можно скопировать всё и так, всю папку целиком со вложенной структурой. Для этого нужно использовать опцию -r ( от recursive). Можно использовать её вмести с опцией -v ( от verbose) которая позволит наблюдать подробно ход процесса копирования — какие файлы передаются по сети, видеть прогресс.

scp -rv /var/www/site.ru root@1.1.1.1:/var/www/

В итоге у вас на новом сервере будет создана папка /var/www/site.ru и туда перенесутся все файлы с текущего.

Можно исполнить это и с нового сервера, опять же «забрать» файлы со старого, нетрудно догадаться:

scp -rv root@2.2.2.2:/var/www/site.ru  /var/www

Результат будет точно таким же.

Однако, такой способ имеет некоторые недостатки.  Во-первых, при таком копировании могут не сохраниться или сбиться права доступа к файлам и папкам. Вернее даже не права доступа, а владельцы. И их потом нужно будет выставлять, менять на нужные командой chown.

Во-вторых, куда большим недостатком является то, что утилита scp будет перезаписывать все файлы, которые у вас уже есть на сервере. А часто бывает так, что какие-то файлы у нас на сервере уже лежат, и нам нужно обновить сайт. Такая задача часто возникает к примеру у разработчиков — они пишут сайт на одной машине, а потом «деплоят» — заливают новую версию поверх старой. Так вот утилита scp в таком случае работает неэффективно, ибо она пересылает и перезаписывает все файлы подряд.  А если файлов много и передача занимает часы? Обрывается связь, и нужно перезапускать этот процесс, ну и так далее.

А еще  даже при переносе с одного сервера на другой случается,  что связь рвется, и нужно опять же процесс перезапускать.

Так вот, есть ещё более удобная штука, которая решает и эти заморочки.  Это синхронизация.

Перенос файлов с одного сервера на другой синхронизацией утилитой rsync

Эта чудесная утилита умеет переносить файлы и в процессе делать сверку файлов в папке назначения на наличие и модификации.  И она точно так же умеет работать через протокол SSH. А также и внутри сервера.  Но что же значит «проверять файлы и папки на наличие и изменения»? Это значит, она не будет файлы перезаписывать, если они уже есть в папке назначения, а будет только доливать новые и изменившиеся файлы.

А еще, это значит что при обрыве процесса по каким угодно причинам — мы можем легко продолжить процесс переноса файлов ровнёхонько с того же места, где оно было прервано. То есть долить, а не перезалить всё заново. И это значительно увеличивает эффективность и скорость работы (вспомните о террабайтах данных).

Ну что-ж, теперь давайте посмотрим как это делается.

Для начала, её может понадобиться установить, хотя часто она и так уже есть на серверах. Если не окажется, то сделать так:

yum install -y rsync  #для Centos

apt install -y rsync  #для debian, ubuntu

Утилита должна стоять на обоих серверах, если её нет на целевом сервере, куда вы ею подключаетесь — то получите ошибку.  В случае если всё нормально, то понадобится ввести пароль указанного пользователя SSH.

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

rsync -avh /etc  /backup/

В этом случае будет создана папка /backup/etc и внутри будет все содержимое. Аналогично тому, как если бы вы воспользовались копированием

cp -r /etc/ /backup

Однако есть нюансы, которые важно понимать, при работе с утилитой rsync. Обратите внимание, в первой команде в пути исходной папки нет закрывающего слеша. А во второй он есть, и наоборот его нету у второй папки.

cp -r /etc /backup/

Такой вариант отработает точно так же.

Однако если исполнить

rsync -avh /etc/ /backup/

Это будет работать совсем иначе. В этом случае, содержимое папки /etc нальется прямо в папку /backup. Что конечно совершенно не подходит. Ибо там может лежать что-нибудь ещё., потом разбираться что где лежит.

Без указания слеша папка будет скопирована полностью вместе с содержимым.  Но ещё лучше сделать так:

rsync -avh /etc/  /backup/etc_backup_131019/

Это значит, что будет создана папка /backup/etc_backup_131019/ и в нее синхронизируется содержимое папки /etc/

Если вдруг мне понадобится потом все вернуть, я исполню так:

rsync -avh /backup/etc_backup_131019/  /etc/

И будут перезаписаны только те файлы, которые менялись. Кстати, о ключах -avh. Они позволяют видеть процесс копирования/синхронизации — весь список файлов. За это отвечает ключ -v (verbose). Ключ -h  отображает размер  файлов в human-readable формате — то есть не в байтах, как без него, а в мегабайтах, килобайтах, гигабайтах.  Если вам нет необходимости видеть подробности, ключи -vh можно не использовать, и копировать только с ключом -a.  Он означает archive — то есть полный перенос всего как есть, включая права и владельца. Помните, я ведь говорил, что утилита scp меняет владельца. А rsync нет. Причем, не изменится именно uid и gid пользователя, останется как есть.

Поэтому если вы переносите файлы, владельцы у которых на старом и новом серверах разные,  то права вероятно придется сменить с помощью chown на пользователя, актуального на новом сервере.

chown -R apache:apache /var/www/site.ru

Примерно так.

Но что-то я забежал вперед. Давайте теперь посмотрим как можно файлы переносить rsync’ом между серверами. Наверняка кто-то уже догадался, если внимательно читал всё что выше.

rsync -avh /var/www/site.ru/  root@1.1.1.1:/var/www/site.ru/

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

Если вы сделаете например так:

rsync -avh /var/www/site.ru  root@1.1.1.1:/var/www/site.ru/

В случае, если папка не существует на целевом сервере  — она будет создана, и всё будет нормально. Если же она уже существует, то синхронизации не произойдет. А будет создана папка /var/www/site.ru/site.ru и содержимое будет залито в неё. Это основной нюанс при работе с rsync.   Просто используйте полные пути и  слеши в конце всегда и вам будет легко с этим освоиться.

Аналогичным образом можно «вытянуть» содержимое со старого сервера, исполнив на новом:

rsync -a root@2.2.2.2:/var/www/site.ru/  /var/www/site.ru/

В общем, вкусив rsync, вы больше не сможете жить без него, и будете вспоминать FTP как страшный сон. Я гарантирую это.

Запуск переноса файлов в фоновом  режиме

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

Для этого можно освоить и пользовать утилиту screen. Которая позволяет вешать консоли в бэкграунде. То есть в виде фонового процесса. Это помогает тем, что связь с вашей локальной машины к серверу может быть нестабильной,  сессия держаться недолго, прерываться. Тогда даже десяток гигабайт у вас в процессе копирования может прерваться, что уж говорить о больших объемах. Если же вы запустили процесс внутри screen, тогда даже если вы отвалитесь от сервера, ваше копирование будет продолжаться на сервере и вы всегда сможете заново подключиться к серверу, вернуться в screen и продолжить за ним наблюдать, или делать вообще что угодно.

ставится точно так же, если отсутствует.

yum install screen  #для дебиан и убунты сообразите сами

Затем её запускаем

screen

И всё, у вас откроется как-бы терминал в терминале.  Можете там делать всё, о чем мы говорили ранее, и вообще что угодно любое другое.

Теперь, если ваш терминал на локальной машине отвалится от сервера, вы всегда можете подключиться заново, набрать

screen -r

И попадете туда, где вы запустили ваш процесс.

Можно и принудительно отключиться от screen, оставив процесс выполняться в фоне, а самому что-то продолжить дальше делать в основном терминале. Для этого надо нажать комбинацию клавиш ctrl+a, и затем D.   А вернуться потом обратно screen -r.

Еще есть куча вариантов и способов для этой тривиальной задачи, но в 95% случаев этого достаточно.

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

Как переносить сайты между серверами по FTP, если нету SSH?

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

А ещё, вот это вот всё очень помогает понимать как можно удобнее и быстрее бэкапить свои данные. Ибо утилита rsync позволяет не перегонять весь объем данных по сети, а экономно и быстро слить только новые и изменившиеся данные. Вообще, rsync имеет кучу всевозможных опций. Умеет копировать и так и сяк. Может попутно удалять файлы как с исходного места, так и чистить лишние на целевом и ещё много всякого. Это же может делать и lftp. Но с этим стоит быть очень аккуратным, во избежание потери данных.

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

Надеюсь, это чуточку облегчит кому-то жизнь и поможет стать существенно профессиональнее ?

А ещё, пользуясь случаем — я переношу сайты профессионально.  В любых мыслимых и немыслимых объемах и количествах.  Легко и быстро, решая любые проблемы, которые могут возникнуть в процессе переноса сайтов, файлов, баз данных (кстати, по их переносу тоже есть много нюансов)  и вообще всего чего угодно, что у вас крутится на Linux сервере. 

Стоимость этой услуги от 1000 руб, зависит от объема и количества сайтов, а также попутных работ — настроек, оптимизации, и прочего. Зависимость там конечно не прямая.   Обычно даже  самые сложные случаи  с сотнями сайтов и полным пакетом настройки и оптимизации оцениваются не более чем в 10к руб. 

Больше результатов…

<index>

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

Акция:

Мы перенесём Ваш сайт (выполним трансфер) на WordPress хостинг Hostenko бесплатно.

• Примерное время выполнения: 15-20 минут.
• Сложность: от начинающего до пользователя среднего уровня
• Что нам понадобится: хостинг с PHP (5.2+), MySQL Database и FTP-доступ
• Требуемое ПО: FTP-клиент, текстовый редактор, PHPMyAdmin

С чего начать: что надо знать перед началом работы

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

Есть различные подходы к структуризации компонетов WordPress, но в нашем случае достаточно будет следующего разделения компонентов на 2 основных группы:

• Файлы на вашем веб-сайте (php, css, html, javascript и др.)
• База данных (БД) (в ней хранится вся информация по файлам и работе с ними)

Файлы

Чтобы ваш WordPress работал, надо, чтобы Файлы формировали «облик» и структуру вашего сайта, а БД при этом контролировала всю работу Файлов. Все файлы в составе сайта написаны преимущественно с использованием языка программирования. В случае с нашим движком речь идет о PHP. Чтобы увидеть файлы, из которых состоит существующая установка WordPress, вам надо залогиниться на ваш хостинг или подключиться к вашему серверу по FTP. Создать FTP-подключение к вашему сайту вы можете при помощи специального ПО, например: WinSCP, Firebug или FileZilla. Необходимые настройки для подключения по FTP-протоколу вам должен предоставить ваш хостинг-провайдер. Для того, чтобы перенести файлы с одного сервера на другой, нужно просто переместить их так же, как вы перемещаете файлы на локальном диске, перетаскивая их на пиктограмму другого диска, папки или подраздела. Разница заключается лишь в том, что в данном случае эта операция выполняется при помощи FTP-клиента: специальной программы, которая подключена к серверу вашего хостинг-провайдера.

База данных (MySQL)

Если с файлами в рамках WordPress справиться можно достаточно легко, то вот управление и редактирование БД в вашем WP — дело далеко не простое. Для новичков поясню: вы не можете просто взять и переместить базу, перетащив ее «мышкой», как вы это делали с файлами и папками. У БД есть свой протокол, к которому она жестко привязана. Информация в рамках установленного WordPress хранится внутри отдельной БД MySQL. Ее предоставляет ваш хостер или провайдер серверов. Чтобы получить к ней доступ, необходимо подключаться, указывая пароль, логин пользователя и имя хоста. Вместо того, чтобы вникать в код и особенности языка программирования, на котором создана ваша БД, вам понадобится PHPMyAdmin: это надстройка, управляющая работой вашего сайта, которая еще известна как «Панель управления хостингом». PHPMyAdmin создает интерфейс, при помощи которого пользователь может работать с базой данных. Нам в процессе перемещения сайта понадобится всего несколько основных инструментов из этой Панели, а большую часть возможностей ее мы и вовсе проигнорируем (чтобы вы, копаясь в тонкостях и расширенных возможностях, ничего не «напортачили»).

Далее рассмотрим пример перемещения сайта на новый поддмен (поддмен носит имя «sandbox.devnot.es»).

Предупреждение новичкам

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

Видео-инструкция

Это видео послужит пошаговым руководством для осуществления всей требуемой процедуры (правда, всё равно почитайте текстовую инструкцию после просмотра видео, там есть некоторые нюансы, которые важно знать новичку в деле «миграции» сайтов). А пока выберите режим просмотра видео HD и разверните на весь экран, чтобы ничего не пропустить: наиболее важные шаги специально засняты с увеличением части страницы в момент редактирования или других операций с сайтом.

Примечание: на этапе, когда будете менять URL-адреса в БД, пользуйтесь инструментом группового редактирования адресов путем поиска и замены, а не стандартным текстовым редактором: это поможет избежать проблем. Найти его можно в свободном доступе на сайте InterconnectIT.

Шаг 1: Файловая система

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

• .htaccess
• index.php
• xmlrpc.php

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

• readme.html
• license
• favicon.ico (если этот файл у вас есть)

Не забудьте эти файлы; а все остальные, у которых в имени есть часть «wp», надо перенести в обязательном порядке по умолчанию. Вам понадобятся все три папки с файлами и их содержимое («wp-admin», «wp-content» и «wp-includes»), а также те файлы, о которых речь шла ранее. Полный перечень насчитывает 31 файл: Если вы переносите файлы в рамках одного и того же хоста или сервера, нет необходимости в локальном бэкапе: вы всегда можете за пару секунд перенести фалы обратно простым копированием.

• wp-admin/
• wp-content/
• wp-includes/
• .htaccess
• favicon.ico
• readme.html
• index.php
• license.txt
• wp-load.php
• wp-login.php
• wp-links-opml.php
• wp-config.php
• wp-feed.php
• wp-pass.php
• wp-blog-header.php
• wp-rss.php
• wp-atom.php
• wp-mail.php
• wp-config-sample.php
• wp-settings.php
• wp-activate.php
• wp-cron.php
• wp-comments-post.php
• wp-rss2.php
• wp-commentsrss2.php
• wp-register.php
• wp-app.php
• wp-signup.php
• wp-trackback.php
• wp-rdf.php
• xmlrpc.php

Теперь, когда мы знаем, какие именно файлы нам обязательно понадобятся, все их можно сохранить на локальном компьютере. У нас получится локальный бэкап на тот случай, если мы совсем запутаемся и «наломаем дров» с новой установкой и переносом. После того, как вы сохраните файлы на локальный диск, можете приступать к переносу файлов на новый сервер или к другому провайдеру хостинга. Не переживайте: уведомление о том, что возникла ошибка php, вам не придет; появится сообщение, что нельзя установить подключение к БД до тех пор, пока вы не завершите перемещение файлов.

Шаг 2: БД MySQL

Если вы не можете сразу отыскать имя пользователя и пароль, откройте файл «wp-config.php». В нём хранится ваше имя пользователя и пароль. Если вы переносите блог в рамках одного и того же сервера или хостинга, можете пропустить данный шаг.

Итак, перед вами — задача по смене сервера или хостинг-провайдера либо же вы просто переносите блог или сайт на новый адрес. Помимо переноса самих файлов, вам надо также перенести БД. В БД хранятся все пути взаимодействия с контентом и файлами на сайте. Вместо автоматического экспорта БД средствами WordPress, проведём все процедуры вручную: для эьлшл нам понадобится интерфейс PHPMyAdmin. У основных хостеров есть свои надстройки над этой панелью, такие как cpanel, plesk или другие варианты.

Зайдя в панель, переходим к выбору БД WordPress. Чтобы правильно выбрать БД, надо свериться с информацией из файла wp-config.php: в нем найдем пункт «DB_NAME» с именем нашей базы данных (В приведенном примере имя БД — «devnotes_wp»). Кликнем на этом имени и после открытия нового окна справа вверху вам надо нажать на кнопку «Export» («Экспорт»). Потом выбираете опцию «Save as file» («Сохранить как файл») и не забудьте снять сжатие, а затем нажать на «Go» («Начать»). Запустится процесс скачивания файла [DB_NAME].sql. Этот файл вам надо будет залить на новый сервер или хостинг.

Не архивируйте файл sql, поскольку его надо будет редактировать на следующем этапе работы (о котором речь пойдет далее).

Шаг 3: меняем адреса

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

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

Здесь для редактирования воспользуйтесь текстовым редактором с опцией поиска и замены определенного фрагмента. Для таких ОС, как Windows and Linux, подойдет бесплатный редактор NotePad++. Еще есть неплохая программа для этих целей под названием Sublime 2. Отыщите все фрагменты кода, содержащие прежний веб-адрес, и замените их на новый адрес. В процессе вставки и автозамены будьте внимательны, чтобы не вставить лишние символы в новые адреса (например, дублирование «слэшей»).

Примечание: простой поиск и замена выделенного фрагмента хорошо работает в большинстве случаев; однако сегодня в БД может храниться определенная часть ссылок и информации, которую так просто автозаменой не исправишь. Чтобы ничего там не «поломать», воспользуйтесь опцией поиска и замены с чувствительностью к регистру и сериям (в англоязычном интерфейсе — «serialize-data sensitive»), В частности, инструмент для такого поиска и замены можно скачать с сайта InterconnectIT.

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

Шаг 4: восстанавливаем БД

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

После перенесения и смены URL надо подключить БД так, чтобы она «опознавала» сайт на новом месте. Для этого вам надо залогиниться в новое местоположение сайта через PHPMyAdmin.

Зайдя на перенесенный сайт при помощи PHPMyAdmin, выберите новую БД, кликнув на ее названии слева, а затем нажав на «Импорт» справа. Убедитесь, что вы выполняете операции именно в таком порядке, чтобы на следующем шаге не получить сообщение об ошибке. Загрузите сохраненный ранее скачанный файл с расширением .sql. Если всё сделано верно, вы увидите подтверждение того, что ваша БД была загружена.

Шаг 5: возвращаем WordPress «к жизни»

Последним шагом в нашей процедуре перемещения сайта станет прописывание нового местоположения сайта на базе WordPress и подключение БД, чтобы нам не выдавалась ошибка подключения к БД: «Database Error». Если вы всё ещё видите данную ошибку, то самое время отредактировать содержимое файла wp-config.php. Там надо обновить настройки БД и указать новые, согласно внесенным изменениям в БД MySQL.

Вот что из этого вам надо отредактировать:

• DB_NAME — имя новой БД, созданной для WordPress
• DB_USER — имя пользователя, у которого есть права доступа к БД
• DB_PASSWORD — пароль для вышеуказанного пользователя
• DB_HOST — имя хоста для БД. Обычно здесь прописывают «localhost» (если только нет каких-то специфических настроек или требований со стороны самого провайдера).

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

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

Ура, вы всё сделали!

Да, именнно так: вы закончили. К этому моменту вы уже должны были перенести успешно свой блог или сайт на базе WordPress на новый сервер или хостинг. Все вышеперечисленные операции нужны для того, чтобы успешно перенести сайт на новый хостинг, новый домен или субдомен, либо сменить сервер в рамках одного и того же хостинг-провайдера.

Источник: Migrating WordPress Across Hosts, Servers And URLs

Смотрите также:

7 лучших WordPress плагинов для календаря и планирования вашего времениКак создавать страницы в WordPress с иерархией и шаблонамиУлучшаем SEO магазина на WooCommerce с помощью расширения от Yoast</index>Хостинг для wordpressSsl сертификат —> —>Используемые источники:

• https://vpsadm.ru/bystryi-perenos-saytov-sposobyi/
• https://hostenko.com/wpcafe/tutorials/perenos-wordpress-sayta-s-sohraneniem-nastroek-i-url-ov-na-novyiy-server/