Italiano
Español
RomânăКак перенести WordPress с сервера разработки на рабочий сервер?
Я выполняю разработку на одном сервере, а для продакшена использую второй. Сейчас я просто делаю дамп базы данных, затем выполняю поиск и замену URL-адресов, после чего копирую файлы и импортирую новый SQL.
Существуют ли лучшие способы сделать это?
@Insanity5902: Развертывание сайта WordPress с одного сервера на другой всегда было головной болью с самого начала моей работы с WordPress. (Честно говоря, это было проблемой и с Drupal в течение 2 лет до того, как я начал работать с WordPress, так что проблема явно не исключительно в WordPress.)
Меня раздражало, что каждый раз при переносе сайта приходилось тратить столько усилий, часто дублируя одни и те же действия, и это мешало мне развертывать тестовые среды так часто, как хотелось бы. Поэтому около 4-6 месяцев назад я начал работать над плагином для решения проблемы миграции между хостингами и упомянул свои идеи на форуме WP Tavern.
И вот сегодня я практически завершил работу над ним и временно назвал его "WP Migrate Webhosts". Хотя плагин всё ещё находится в стадии бета-тестирования (возможно, даже альфа), учитывая ваш вопрос, я думаю, что готов позволить людям начать его тестировать.
Предполагаемый сценарий использования:
- Сначала разработчик загружает все измененные файлы темы и плагинов через FTP,
- затем полностью переносит базу данных MySQL на тестовый сервер,
- и только после этого запускает плагин для миграции всех ссылок со старого домена на новый. (Мой плагин не решает проблему слияния новых полей или таблиц БД с актуальными данными; ЭТО гораздо более сложная задача, которую я пока не знаю, как решить.)
Вы можете скачать плагин с моего сайта и распаковать его в папку с плагинами (если вы не знаете, как это сделать, то этот плагин не для вас, так как он требует некоторого опыта работы). Я оставлю его доступным до релиза на WordPress.org, после чего его нужно будет искать там.
Для использования потребуется изменить подход в файле wp-config.php: закомментировать четыре (4) стандартные директивы DB_NAME, DB_USER, DB_PASSWORD и DB_HOST, а вместо них зарегистрировать настройки по умолчанию для хостингов и информацию о каждом из них. Вот как может выглядеть соответствующий раздел wp-config.php (обратите внимание, что первая часть — это закомментированный ненужный код, а также на то, что я использую локальные домены .dev для удобства разработки. На Mac VirtualHostX значительно упрощает этот процесс):
// ** Настройки MySQL - можно получить у хостинг-провайдера ** //
/** Имя базы данных для WordPress */
//define('DB_NAME', 'wp30');
/** Имя пользователя MySQL */
//define('DB_USER', 'wp30_anon');
/** Пароль к базе данных MySQL */
//define('DB_PASSWORD', '12345');
/** Хост MySQL */
//define('DB_HOST', '127.0.0.1:3306');
require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/wp-webhosts.php');
register_webhost_defaults(array(
'database' => 'example_db',
'user' => 'example_user',
'password' => '12345',
'host' => 'localhost',
'sitepath' => '', // '' если WordPress установлен в корень
));
register_webhost('dev',array(
'name' => 'Локальная разработка Example',
'host' => '127.0.0.1:3306',
'domain' => 'example.dev',
'rootdir' => '/Users/mikeschinkel/Sites/example/trunk',
));
register_webhost('test',array(
'name' => 'Тестовый сервер Example',
'rootdir' => '/home/example/public_html/test',
'domain' => 'test.example.com',
));
register_webhost('stage',array(
'name' => 'Стейдж-сервер Example',
'rootdir' => '/home/example/public_html/stage',
'domain' => 'stage.example.com',
));
register_webhost('live',array(
'name' => 'Продакшн Example',
'rootdir' => '/home/example/public_html/',
'password' => '%asd59kar12*fr',
'domain' => 'www.example.com',
));
require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/set-webhost.php');
Надеюсь, это в основном понятно. Я постарался сделать код максимально чистым, но, к сожалению, пришлось добавить две загадочные строки require_once() до и после блока регистрации хостингов, так как невозможно "перехватить" WordPress до вызова wp-config.php.
После обновления wp-config.php можно просто использовать URL-адрес wp-migrate-webhosts для перехода на экран администрирования:
Это приведет вас к админ-панели, где будет много пояснительного текста, и вы сможете мигрировать С любого другого домена в один клик после выбора исходного домена (ПРИМЕЧАНИЕ: в примере показан переход С тестового/стейджа/продакшна на локальную разработку, но плагин может мигрировать НА любой домен, где он находится. Это также означает, что плагин отлично подойдет для быстрого развертывания локальной среды разработки на основе существующего продакшн-сайта!):
Если это неочевидно, "миграция" в данном контексте означает обновление всех ссылок в текущей базе данных в соответствии с настройками текущего хостинга (а "текущий" определяется через $_SERVER['SERVER_NAME']).
Круто то, что плагин реализует базовые миграции, но любой может добавить свои собственные обработчики. Например, если у вас есть плагин галереи, который хранит полные пути к изображениям в БД, вы можете подключиться к действию migrate_webhosts, которое получит метаданные исходного и целевого хостингов, и выполнить необходимые SQL-запросы или использовать API WordPress для миграции. Да, это можно сделать и без плагина, но без него писать весь код с нуля было слишком трудоемко. С плагином же достаточно написать небольшие хуки и забыть о проблеме.
Возможно, в некоторых случаях мои миграции не сработают — я мог что-то упустить. Может, вы поможете улучшить плагин? Все желающие могут написать мне на Gmail (мой алиас — "mikeschinkel").
Кроме того, плагин поддерживает пользовательские метаданные хостингов помимо стандартных, таких как database, user, password, host, domain и т. д. Например, можно добавить googlemaps_apikey для хранения разных API-ключей Google Maps для каждого домена (кто из вас, работая с плагинами Google Maps, не забывал поменять API-ключ при переносе на продакшн? Ну признайтесь! :) С этим плагином, элементом googlemaps_apikey в массиве register_webhost() и небольшим хуком на migrate_webhosts эта проблема исчезнет!
Вот, собственно, и всё. Я публикую этот плагин здесь, на WordPress Answers Exchange, потому что вопрос @Insanity5902 стал для меня триггером. Дайте знать, если он окажется полезным — здесь или по почте.
P.S. Если решите использовать, помните: это альфа/бета, и возможны изменения. Будьте готовы к небольшим правкам, если начнёте сейчас, а потом перейдёте на релизную версию.
P.P.S. Какие у меня цели? Я бы хотел, чтобы этот функционал попал в ядро WordPress, чтобы он стал доступен всем. Но для этого нужно, чтобы множество людей протестировали его и подтвердили, что он решает больше проблем, чем создаёт. Так что если идея вам нравится — пользуйтесь и помогите набрать критическую массу для возможного включения в WordPress!
Отличные решения, но у меня есть пара вопросов: 1) Нужно ли еще определять WP_SITEURL для доступа в админку? 2) Этот инструмент отображается только для администраторов? (не уверен, отображается ли раздел инструментов для не-админов)
Ryan Gibbons
Привет @Insanity5902:
1) Нет необходимости устанавливать WP_SITEURL, плагин делает это за вас. Фактически вы устанавливаете его, когда "регистрируете" "домен" и "путь к сайту" для веб-хоста. В обычной работе WordPress WP_SITEURL должен быть установлен либо в коде, либо в базе данных, чтобы гарантировать, что никто не подделает URL и не совершит вредоносных действий из-за неожиданного значения в $_SERVER['SERVER_NAME']. Плагин WP Migrate Websites устанавливает WP_SITEURL косвенно на основе $_SERVER['SERVER_NAME'], но он сделает это ТОЛЬКО если текущий домен совпадает с одним из доменов, которые вы определили в файле wp-config.php, и никак иначе.
MikeSchinkel
2.) Упомянутый мной URL-ярлык фактически выполняет перенаправление в админ-консоль, поэтому он доступен только для пользователей, вошедших в админку. Пока у меня нет специальных проверок только для администраторов. Я никогда раньше не добавлял возможности в плагин, но мне нужно будет полностью изучить этот вопрос в ближайшие недели, поэтому могу поработать над этим в течение следующего месяца. Однако плагин не является разрушительным; он может переносить данные ТОЛЬКО на текущий домен, и процесс повторяем, поэтому даже если не-админ получит доступ, он не сможет нанести вред, по крайней мере я не могу представить такого сценария.
MikeSchinkel
@Mike: Можешь добавить его в репозиторий плагинов WordPress? Думаю, это поможет собрать дополнительную обратную связь и привлечь поддержку разработчиков.
hakre
@harke - Я планирую это сделать, когда плагин станет более зрелым. Сначала хочу, чтобы его протестировали 5-10 человек, чтобы убедиться в его надежности и проверить валидность сценариев использования, прежде чем публиковать его в системе рейтингов на форуме плагинов. Я считаю, что этот плагин может стать значимым, если правильно его развивать. Также я хочу полностью его задокументировать перед публикацией, и процесс документирования заставит меня проверить многие предположения, сделанные во время разработки.
MikeSchinkel
Когда может быть невозможно установить эти параметры? Это звучит немного проще, чем изменять данные в базе данных.
jfklein
@jfklein Я почти всегда работаю с WordPress Network, который несовместим с этими константами.
User
Делаю то же самое. К сожалению, не все темы поддерживают это. Например, 'Responsive Theme' из ThemeID. Поиск по дампу/всем таблицам 'http://localhost' (или любое другое локальное имя), особенно в wp_options, и выполнение поиска и замены часто неизбежны.
Frank N
@FranKee Я создал плагин https://wordpress.org/plugins/pitta-migration/, который использует константы для обновления таблицы wp_options, что должно охватить большинство тем и плагинов
icc97
@icc97: Отлично. Посмотрю. PS: Красивое изображение в заголовке, хорошо передает ситуацию.
Frank N
Да! Я так рад, что я не единственный, кто об этом подумал! Любая разница между dev и prod — это плохо. Полное устранение этой разницы гораздо лучше, чем попытки обойти ее. И эта настройка не требует никаких усилий. При необходимости можно даже проводить тестирование на виртуальной машине с измененным файлом hosts.
Alexander Bird
Мне очень нравится этот метод, но как вы обрабатываете перенос базы данных между средами (push/pull)?
Joel Peltonen
Что касается риска перепутать dev и prod, я использую плагин для Chrome, который отображает IP-адрес веб-страницы. Вы сразу поймете, что работаете локально, когда увидите 127.0.0.1
kosinix
Это действительно очень удобная опция, которая отлично подойдет многим! Конечно, она не работает с встроенными URL и не помогает тем, кто разрабатывает локально и использует IDE с отладчиком. Но если WPEngine сможет создать механизм, объединяющий локальное развертывание, тогда это будет действительно что-то стоящее (Technosailor, ты слышишь?)
MikeSchinkel
Согласен, это было бы отличным дополнением.
Travis Northcutt
Функция snapshot копирует данные только из production в staging, но не наоборот. Это отлично подходит для тестирования изменений, но не поможет при развертывании в production.
sam
@sam на самом деле, они недавно начали внедрять возможность копирования из staging в production. http://wpengine.com/2013/04/user-portal-v2-and-staging-to-production/
Travis Northcutt
Просто заметка, мой sql-запрос может повредить ваши сериализованные данные.
s:14:blogs.prod.com имеет закодированную длину 14. После выполнения кода, теперь у нас
s:14:dev.prod.com
что является повреждёнными данными. Должно быть
s:12:dev.prod.com
используйте с осторожностью.
Andrew
Только что проверил ваш скрипт. Отлично. Если я правильно понял, он устанавливает чистый WP на сервер. Вопрос в том, как мигрировать с разработки на продакшен. Может ли он помочь с этим?
Sruly
Это он? http://github.com/vluther/Autopress Советую добавлять ссылки в ваши ответы, чтобы люди могли сразу перейти по ним!
artlung
@Mike Lee: Да, вы можете голосовать за комментарии. Смотрите, я проголосовал за комментарий artlung. Ищите стрелку вверх при наведении слева от комментария.
MikeSchinkel
Я работаю над способом держать всё под контролем версий и затем разворачивать изменения из разработки в продакшен. У меня уже получилось сделать это без проблем для нескольких сайтов, но остаются некоторые детали, которые нужно доработать.
Vid Luther
Не уверен, что это то, что нужно, но у WP Engine есть плагин для миграции сайтов между хостингами. Он называется Snapshot (Прямая ссылка).
joelhaus
Похоже, ни один из этих проектов так и не был запущен?
icc97
Вы можете использовать WordPress Skeleton wp-config.php, который устанавливает константу WP_LOCAL_DEV для достижения аналогичного результата
icc97
RAMP предназначен для развертывания контента, в отличие от развертывания кода, но я согласен, выглядит превосходно. Теперь у них есть демонстрация RAMP, где можно опробовать функционал.
Emyr Thomas
Вопрос был о развертывании контента, а не кода, и я начал свой ответ со слов "RAMP — это новый плагин для развертывания контента..."
Ian Dunn
Четыре месяца назад я не смог заставить этот плагин работать... И до сих пор он версии 0.1 на code.google
brasofilo