Как переместить существующую папку wp-content WordPress вместе с базой данных на новый сервер и новый домен?
Запускаю WP 3.5.1 на стеке LEMP (на Linode)...
У меня есть папка wp-content для сайта на WP вместе с полной резервной копией базы данных. URL сайта был примерно таким:
test.example.com
Я хочу запустить сайт на своем сервере по адресу:
test.mydomain.com
И после завершения работ и применения изменений DNS, чтобы сайт работал по URL:
myclientsdomain.com
Какой предпочтительный (и желательно самый простой) способ обработки таких перемещений серверов и изменений доменов? Мне нужен пошаговый ответ, который учитывает все описанные выше ситуации как для файлов, так и для базы данных.

В Кодексе WordPress есть довольно хорошее пошаговое руководство по переносу WordPress. Я следую ему при смене доменов.
Перенос файлов довольно прост. Основная сложность заключается в жёстко прописанных ссылках в базе данных. Однако поиск и замена с учётом сериализованных данных позволит обработать все необходимые изменения в базе данных. Раньше я использовал плагин Velvet Blues, но скрипт Search and Replace действительно на высшем уровне.

Я регулярно использую замечательный плагин Duplicator для выполнения этой процедуры.
http://wordpress.org/extend/plugins/duplicator/
Плагин полностью поддерживается, и здесь доступны отличные FAQ:
http://lifeinthegrid.com/labs/duplicator/
Плагин создаст резервную копию в формате .zip, включающую как базу данных, так и файлы, а также установочный файл .php, который нужно поместить в новую корневую директорию. Вам просто нужно ввести данные новой базы данных, и плагин сделает всё остальное.
Это, пожалуй, мой любимый плагин для WordPress на сегодняшний день.
Если вам понадобится помощь в процессе, просто дайте мне знать.

Я постоянно использую этот плагин для сайтов клиентов. Я могу сделать точную копию их WordPress, установить её на мой dev-сервер, внести изменения, а затем скопировать всё обратно на их сервер при необходимости.

Вам нужно будет учесть несколько моментов (ответы на них будут дальше), я рекомендую следующие шаги:
Создайте резервные копии файлов и базы данных
Это само собой разумеется. Вы будете выполнять множество манипуляций с данными, поэтому убедитесь, что оригинал в безопасности.
Перенос файлов
Самый быстрый способ — использовать хостинг, на котором можно импортировать каталоги с другого сервера. Это можно сделать, указав данные FTP и целевую директорию.
Поскольку серверы обычно имеют гораздо более быстрое интернет-соединение, чем у пользователей, это предпочтительный способ передачи данных. Вы также можете использовать командную строку для выполнения этих команд вручную.
Более медленный вариант — создать ZIP-архив, скачать его, загрузить на новый сервер и распаковать. Если у вас нет возможности сделать это, выберите долгий путь — скачайте все файлы и загрузите их заново. А пока файлы переносятся — можно выпить кофе :)
Перенос базы данных
Опять же, многие хостинг-провайдеры позволяют импортировать существующую базу данных в новую, даже с другого сервера (конечно, ваш старый сервер должен разрешать внешние подключения).
Если это возможно — отлично, но вы также можете экспортировать/импортировать базу данных вручную.
Настройка нового (под)домена на новую директорию
На новом сервере убедитесь, что файлы расположены так же, как на старом, и укажите поддомен на ту же директорию, что и раньше (обычно это корень WordPress).
Редактирование wp-config.php
Сохраните новый wp-config.php
. Вам нужно только изменить данные для подключения к базе данных.
Загрузите новый URL
WordPress должен быть уже настроен, но он все еще использует старые SiteURL и AdminURL, поэтому войти в админку не получится.
Измените эти значения в таблице options
вашей новой базы данных. Ищите параметры siteurl
и home
. Укажите там ваш новый домен.
Проверьте вход и сайт
Теперь все должно работать: вы можете войти, редактировать, писать и использовать сайт. Единственная проблема может заключаться в том, что в ваших записях по-прежнему указаны старые URL для изображений и вложений.
Если ваши записи содержат старый URL или вы не уверены, проверьте таблицу posts
в базе данных.
Вы можете сделать это, выполнив поиск по базе данных напрямую или используя скрипт, например Serial Search and Replace. Если вы найдете старый URL, его придется заменить вручную или автоматически. Я предпочитаю автоматическую замену с последующей проверкой на ошибки.
Проверьте другие таблицы
Также убедитесь, что другие таблицы не содержат старый URL. Это может быть сложнее заменить, но это необходимо для полного переноса сайта.
Обновите постоянные ссылки
Просто для уверенности сохраните настройки постоянных ссылок еще раз, чтобы они пересоздались.
Проверьте сайт
Пожалуйста, не забудьте ТЩАТЕЛЬНО проверить сайт после переноса. Проверьте все функции, особенно AJAX-элементы, контактные формы, карты и т. д., так как они чаще ломаются, чем обычные PHP/HTML.
Время для пива :)
На что обратить внимание!
Как всегда, ничто, созданное вручную, перенесенное вручную и отредактированное автоматически, не является безошибочным. Вот несколько распространенных ловушек, в которые легко попасть, но их также легко избежать.
- Плохо написанные плагины (сохраняют URL сайта вместо относительного пути и используют функции WordPress для получения полного URL. Также могут быть проблемы с AjaxURL.)
- Проблемы с кодировкой (Убедитесь, что на обоих серверах и в базах данных используется одинаковая кодировка!!! Обычно, если вы используете рекомендуемую UTF-8, проблем не будет)
- Сериализованные данные (Это самая большая проблема, с которой вы можете столкнуться. Если вы используете плагин вроде Tablepress, где вся таблица хранится в сериализованном массиве, она сломается при автоматической замене. Если у вас есть такие данные, ищите функцию экспорта/импорта в этом плагине и используйте ее как дополнительный шаг. Если такой функции нет — придется делать вручную)
- Настройки сервера (Может случиться так, что сайт не запустится на новом сервере из-за стандартных настроек. Убедитесь, что ресурсов достаточно!)
- Жестко прописанные URL в теме (хотя этого быть не должно, такое происходит слишком часто и ломает изображения и ссылки, как только старый сайт становится недоступен)
- Проблемы с кешированием (Не используйте те же файлы кеша, что и на старом сервере. Лучше отключить кеширование перед экспортом сайта, а также очистить весь кеш)
- Предположение, что все работает после повторного изменения настроек (всегда проверяйте все заново)
- Настройки в плагинах и теме (старые email-адреса и т. д.)
Вот и все. Это выглядит как много работы, но на самом деле большая часть выполняется автоматически. Вам просто нужно подумать обо всем, что МОЖЕТ пойти не так, и проверить, так ли это :)
Удачи!

Нет необходимости использовать какие-либо плагины, скрипты или даже знание SQL. Достаточно простого блокнота для миграции. Вам нужно загрузить все файлы WordPress на новый сервер и просто изменить в файле wp-config.php (в основной папке WordPress) 3 значения: define('DB_NAME', 'ваше_новое_имя_базы_данных'); define('DB_USER', 'ваше_имя_пользователя_базы_данных'); define('DB_PASSWORD', 'ваш_пароль_базы_данных');
Далее, если вы используете клиент MySQL, например phpMyAdmin на текущем сервере, вам нужно экспортировать базу данных в файл, затем открыть your_db_dump.sql в блокноте, найти и заменить все вхождения test.example.com на test.mydomain.com, после чего импортировать этот дамп в новую базу данных (которую вы указали в wp-config.php). Это всё.

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

Я не могу согласиться с вами. Я переносил множество установок WordPress этим методом, и он всегда работал. В базе данных почти все замены делаются с guid записей. Лишь несколько замен выполняются в wp_options (например, siteurl, home). Я могу согласиться, что некоторые данные сериализованы, но это не относится к URL нашего домена. Правильно спроектированные виджеты используют bloginfo('url'), а не прямой URL, поэтому нам не нужно беспокоиться о сериализованных данных.

Да, если вы планируете заранее или просто вам повезло, это может сработать, поэтому я и сказал 99% ;), но вопрос был общим. И это основано на моем личном опыте.

Значит, у нас разный опыт ;) Я бы сказал, что этот метод БУДЕТ работать в 99% случаев. Возможно, я ошибаюсь, потому что работаю с WP всего несколько лет, но я не встречал никаких проблем при переносе, даже с включенными плагинами и виджетами.

Думаю, это зависит от того, что используется на сайте. Мой негативный опыт был с простыми сайтами... Дело в том, что, как отметил @helgatheviking, есть бесплатный инструмент, который выполняет поиск и замену с учетом сериализации, так что нет необходимости рисковать, даже если вы на 99% уверены в успехе.

да, это будет работать в 99% случаев, но зачем направлять даже 1% неправильно? ваш ответ должен содержать оговорку, что это может повредить некоторые данные. В идеальном мире все плагины написаны безупречно, но лично я сталкивался с этим — мы живем не в идеальном мире.

Я согласен, что мы живём не в идеальном мире, и всегда есть шанс на неудачу. Вы оба правы. Он спросил о самом прямом способе миграции, и я думаю, что это он. И он будет работать в большинстве случаев. С 1% риска провала я могу рискнуть, если это должен быть самый простой способ. Это моё предложение по решению этой проблемы. Если можно, не могли бы вы прислать мне ссылки на плагины или виджеты, которые могут создать проблемы при таком способе миграции? Пока я не встречал таких.

Что я делаю:
Создаю новую базу данных на принимающем хосте. Импортирую SQL-файл. Выполняю следующие SQL-запросы в новой базе данных:
UPDATE wp_options SET option_value = replace(option_value, 'test.example.com', 'test.mydomain.com') WHERE option_name = 'home' OR option_name = 'siteurl'; UPDATE wp_postmeta SET meta_value = replace(meta_value, 'test.example.com', 'test.mydomain.com') WHERE meta_key = '_menu_item_url'; UPDATE wp_posts SET guid = replace(guid, 'test.example.com','test.mydomain.com'); UPDATE wp_posts SET post_content = replace(post_content, 'test.example.com', 'test.mydomain.com');
Загружаю файлы WordPress на принимающий сервер.
- Загружаю папку wp-content, перезаписывая стандартные файлы WordPress.
- Настраиваю файл wp-config.php как обычно, используя имя базы данных, пользователя и пароль из созданной базы данных.
- Перехожу в админ-панель и вручную изменяю все упоминания test.example.com в виджетах (их нельзя изменить через SQL-запрос, так как они сериализованы в базе данных).
- Когда придет время переключиться на myclientsdomain.com, выполняю указанные выше SQL-запросы и исправления виджетов снова.
В зависимости от темы и плагинов, вам может потребоваться внести дополнительные изменения в базу данных или админ-панель. Их придется обнаруживать самостоятельно и исправлять по мере нахождения.
Предупреждаю, что этот метод не идеален, и перенос WordPress между доменами может быть сложным. Еще один вариант, который я видел — добавить следующее в файл wp-config:
define('WP_HOME','http://'. $_SERVER['SERVER_NAME']);
define('WP_SITEURL','http://'. $_SERVER['SERVER_NAME']);
Это поможет сайту работать на любом текущем домене, но вам все равно придется иметь дело с жестко прописанными URL в контенте, настройках и меню. Я сам не тестировал этот метод и не знаю, нужно ли удалять соответствующие опции из базы данных, чтобы он работал.
Обновление: Стоило догадаться, что существует плагин для обработки базы данных http://wordpress.org/extend/plugins/wp-migrate-db/

Я настоятельно рекомендую НЕ выполнять предложенные выше команды обновления SQL. Таблица options в частности может содержать много сериализованных данных — простой поиск/замена в сериализованных данных повредит эти данные.

Я предлагаю полностью удалить эту часть вашего ответа и, более того, предостеречь от ручных методов поиска/замены, таких как этот или использование команды 'sed'.

Я не делаю простой поиск/замену. Я ограничиваю команды изменением полей, которые НЕ содержат сериализованные данные, и даже упоминаю, что не следует использовать такие команды для изменения информации, хранящейся в виджетах, поскольку эти данные действительно сериализованы.
Что касается таблицы options, я специально использую условие WHERE "WHERE option_name = 'home' OR option_name = 'siteurl';", чтобы избежать изменения сериализованных данных.

Теперь я вижу, что пропустил условие WHERE при первом прочтении. Извините за это. Однако вам не нужно изменять значения home и siteurl в таблице options, именно для этого и существуют WP_HOME/WP_SITEURL. Использование этих определений переопределяет значения из таблицы options, а добавление дополнительного определения WP_RELOCATE заставляет первые два перезаписывать настройки в таблице options.

Также я почти уверен, что не следует изменять guid в таблице post. Они предназначены не для URL, а как уникальные идентификаторы. Примечание: проверил - для вложений есть случай, когда нужно изменить guid, но это не относится к простой смене домена.

Обратите внимание, что использование WP_HOME и WP_SITEURL было отделено от остальной части моего ответа, и я также указал: "Я сам это не тестировал и не знаю, нужно ли удалять соответствующие опции из базы данных для их работы". Я признал, что не слишком хорошо знаком с этой темой, но что это отличается от работы с базой данных.
GUID - это не просто уникальные ID, и их изменение не всегда необходимо, но и не вредно.

Это нормально, я просто предоставлял более релевантную информацию об этих двух вариантах, не пытаясь раздувать спор. Что касается GUID, они действительно могут навредить. GUID являются глобально уникальными идентификаторами. "Глобально" в данном случае означает во всём мире, поэтому они включают информацию о домене. Так что любая внешняя система, взаимодействующая с вашей (например, RSS-агрегатор), потеряет связь со всем вашим контентом.

По теме - http://codex.wordpress.org/Changing_The_Site_URL#Important_GUID_Note

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

"Для того чтобы поле GUID было 'глобально' уникальным, общепринятой практикой является использование URL или его представления. Таким образом, если вы владеете доменом example.com, то только вы используете example.com, и поэтому он уникален для вас и вашего сайта." <- Это может быть нарушено, если GUID содержит домен разработки (например, если рабочая область агрегируется внешними источниками). Внезапно появляются две записи с одинаковым GUID. Лучше включать в него рабочий домен, чтобы соблюдать это правило, ИМХО.

В предыдущем ответе было это, но вот пошагово с некоторыми дополнительными пояснениями:
- Не устанавливайте WordPress заново
- Перекачайте через FTP всю оригинальную директорию WP в новую директорию (см. ниже, если чего-то не хватает)
- Импортируйте SQL через phpMyAdmin в панели управления вашего сервера.
- Загрузите файл searchreplacedb.php через FTP в директорию, где находится WordPress.
- Запустите searchreplacedb.php через браузер (после этого удалите файл!!!).
Возьмите перерыв и выставьте клиенту счет на $75!
(searchreplacedb.php доступен БЕСПЛАТНО по адресу: interconnectit.com/products/search-and-replace-for-wordpress-databases ... там же есть инструкции).
Если у вас есть только папка с содержимым WordPress, у вас другая проблема. Вам нужно получить остальные файлы установки WordPress ТОЧНО ТАКОЙ ЖЕ ВЕРСИИ. Поищите в базе данных, если не знаете, какая версия WP используется. Старые версии легко найти в интернете. Разместите все файлы в правильных местах, как было раньше, используя FTP для настройки новых папок, если хотите, чтобы сайт выглядел так же, как раньше. Не заходите на сайт после загрузки базы данных и файлов WP, если чего-то не хватает, иначе сайт переключится на стандартную тему или отключит плагины. Я терял настройки плагинов и приходилось делать все заново, так что думайте и действуйте не спеша.
Если у вас уже есть подпапка или дополнение, или новый сайт будет нуждаться в этом, планируйте заранее. Не просто заменяйте URL, не учитывая необходимость новой папки или её отсутствие. Возможно, вам придется сначала запустить searchreplacedb для 'папка/url', а потом уже для 'url', и т.д. Иначе вы можете испортить настройки, превратив 'дополнение' в 'корневой сайт с установкой в подпапке' или что-то подобное!
Если новая структура совпадает со старой, и у вас есть вся директория WordPress, вы можете сделать это проще и быстрее, чем читать этот пост! Разместите программу в той же директории, куда вы загрузили WordPress, для лучшего результата, как указано в инструкциях, так как там есть автоконфигурация.
Если у вас нет доступа к FTP, панели управления или SQL, вам действительно нужен лучший хостинг, иначе вам может не повезти.
Попробуйте поиск и замену, рекомендованные в других постах, и если вам повезет, у вас старая версия WP, и она соответствует нужным параметрам, это сработает; но это мучительный способ играть в русскую рулетку с вашим сайтом.
Также никогда не редактируйте данные в Блокноте, если не уверены, что там нет строк длиннее, чем он может принять. Вот отличная ошибка, на поиск которой вы можете потратить недели! Если вам нужно посмотреть, только смотрите, не сохраняйте. Вам стоит забыть о существовании Блокнота и использовать Notepad++, но ручное редактирование сериализованных данных в текстовом редакторе так же плохо, как попытка сделать поиск и замену в phpMyAdmin; не делайте этого.
Вы можете поискать "sql serialized data". Короткий ответ: поиск и замена испортят сериализованные данные в SQL. Базы данных WordPress содержат сериализованные данные... особенно в последних версиях.
Я делал это слишком много раз, с переменным успехом, и бился головой об стену, пока наконец не разобрался как следует. Теперь это прогулка в парке.

Я перенёс множество сайтов с одного сервера/домена на другой таким способом, и обычно всё, что вам нужно — это резервная копия и папка wp-content, которая у вас уже есть. Вот метод, которому я следую:
- Установите WordPress на новый сайт. Вы можете использовать любой удобный вам способ — некоторые хостинги предлагают установку в один клик, в противном случае просто выполните установку предпочитаемым методом.
- Замените папку wp-content на ту, которую вы сохранили. Это гарантирует, что все ваши плагины, загруженные файлы и т.д. будут соответствовать старому серверу.
- Замените базу данных на сохранённую копию. Обычно я делаю это через phpMyAdmin, используя функцию "Импорт". Важно помнить: если ваша резервная копия не включает операторы DROP, вам сначала нужно удалить все таблицы в базе данных.
- Если вы меняете доменное имя, вам нужно открыть таблицу wp_options в phpMyAdmin и обновить опцию "site_url". Есть ещё одна опция "home", которую можно обновить, но это необязательно, так как её можно изменить в админке WordPress после того, как сайт заработает.
Готово!
Этого должно быть достаточно, чтобы ваш сайт заработал. После запуска рекомендуется проверить специфичные настройки плагинов и тем, которые могут ссылаться на старый сайт, а также пересоздать постоянные ссылки (пермалинки).
