Как: легко перенести установку WordPress из разработки в производство?
Я занимаюсь разработкой одной коробки и использую вторую для производства. Прямо сейчас я просто сбрасываю базу данных и затем выполняю поиск замены для изменений URL; затем скопируйте файлы и импортируйте новый SQL.
Есть ли лучшие способы сделать это?
@ Insanity5902 : Развертывание сайта WordPress из одного ящика в другое было PITA с самого первого дня, когда я начал работать с WordPress. (По правде говоря, это была PITA с Drupal в течение 2 лет, прежде чем я начал работать с WordPress, поэтому проблема, конечно, не только в WordPress.)
Меня беспокоило, что каждый раз, когда мне нужно было переместить сайт, мне приходилось тратить так много раз дублированных усилий, и это мешало мне развертывать тестирование так часто, как я бы этого хотел. Так, около 4-6 месяцев назад я начал работать над плагином для решения проблемы миграции веб-хостинга и я упомянул свои идеи на форуме WP Tavern .
Ну что ж, перенесемся на сегодняшний день, и у меня все получилось, и я удобно его называю "WP Migrate Webhosts." Несмотря на то, что плагин все еще очень бета (возможно, даже альфа), учитывая ваш вопрос, я думаю, что я готов позволить людям начать бить по нему.
Предполагаемый вариант использования:
- сначала разработчик обрабатывает загрузку всех измененных тем и файлов плагинов через FTP,
- затем полностью загружает базу данных разработки MySQL на тестовый сервер и, наконец,
- then запускает плагин для переноса любых ссылок из предыдущего домена в новый. (Мой плагин not пытается решить проблему слияния новых полей базы данных или таблиц с оперативными данными; THAT - это гораздо более серьезная проблема, которую я не знаю, как ее решить. )
Вы можете скачать плагин с моего веб-сайта и разархивировать его в каталог плагинов (если вы не знаете, как это сделать, тогда этот плагин не для вас, потому что для этого нужен кто-то, кто знает, что они делают. ) Я буду держать этот плагин в сети, пока не опубликую его на WordPress.org, после чего вы должны искать его там.
Чтобы использовать его, вы применяете другой подход в вашем wp-config.php, который обычно закомментирует четыре (4) определения DB_NAME, DB_USER, DB_PASSWORD и DB_Host и вместо регистрация значения по умолчанию для веб-хостов, а затем регистрирует информацию о каждом веб-хосте. , Вот как может выглядеть этот сегмент wp-config.php (обратите внимание, что в первом разделе приведен закомментированный ненужный код, а также обратите внимание, что я установил свой файл hosts на локальном компьютере с не маршрутизируемыми доменами верхнего уровня .dev для ежедневной разработки). На Mac VirtualHostX это легко):
// ** MySQL settings - You can get this info from your web Host ** //
/** The name of the database for WordPress */
//define('DB_NAME', 'wp30');
/** MySQL database username */
//define('DB_USER', 'wp30_anon');
/** MySQL database password */
//define('DB_PASSWORD', '12345');
/** MySQL hostname */
//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' => '', // '' if WordPress is installed in the root
));
register_webhost('dev',array(
'name' => 'Example Local Development',
'Host' => '127.0.0.1:3306',
'domain' => 'example.dev',
'rootdir' => '/Users/mikeschinkel/Sites/example/trunk',
));
register_webhost('test',array(
'name' => 'Example Test Server',
'rootdir' => '/home/example/public_html/test',
'domain' => 'test.example.com',
));
register_webhost('stage',array(
'name' => 'Example Staging Server',
'rootdir' => '/home/example/public_html/stage',
'domain' => 'stage.example.com',
));
register_webhost('live',array(
'name' => 'Example Live Site',
'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() до и после блока регистрационного кода веб-хоста, поскольку у меня не было возможности "hook" WordPress до того, как wp-config.php будет называется.
После того как вы обновили свой wp-config.php, вы можете просто использовать ярлык URL wp-migrate-webhosts, чтобы перейти на экран администратора следующим образом:
Вышеприведенное приведёт вас к экрану администрирования, подобному следующему, который содержит довольно много текста описания и позволяет переносить ИЗ любой из других доменов веб-хоста одним щелчком мыши после выбора доменов для переноса. from (NOTE: этот пример показывает переход DOWN с тестовых/stage/live серверов на локальную разработку, но будьте уверены, что он может мигрировать TO любой домен, в котором он находится. Это также означает, что плагин отлично подойдет для создания существующего живого сайта и быстрой работы локальной среды разработки! ):
Если неясно, "миграция" в этом контексте означает обновить все ссылки в текущей базе данных, чтобы соответствовать текущему определенному веб-хосту (а "current" равно сниффинг) проверяя $_SERVER['SERVER_NAME'].)
Что хорошо в плагине, так это то, что он реализует некоторые базовые миграции, но любой может подключить его и выполнить свои собственные миграции . Например, если вы добавите плагин галереи, который хранит полные пути к изображениям в базе данных, вы можете подключить действие migrate_webhosts, которому будет передан веб-хост "from" и "to" webhost каждый в виде массива метаданных, и вам будет позволено выполнять все, что вам нужно делать в базе данных, используя SQL или любые применимые функции WordPress API для выполнения миграции. Да, любой из нас мог бы сделать это без плагина, но без плагина я обнаружил, что написание всего необходимого кода было больше усилий, чем оно того стоило. С плагином проще написать эти крошечные зацепки и покончить с этим.
Вы также можете обнаружить, что мои миграции потерпели неудачу в случаях Edge, которые я не тестировал, и, возможно, вы можете помочь мне улучшить плагин? Любой, кто захочет, может написать мне по электронной почте через мой аккаунт Gmail (мой псевдоним "mikeschinkel").
Кроме того, плагин был разработан для приема пользовательских метаданных веб-хостинга в дополнение к тем, которые он распознает как database, user, password, Host, domain и т.д. Прекрасным примером может быть googlemaps_apikey, где вы можете хранить различные ключи API для каждого домена что плагин вашей карты Google должен работать правильно (кто из вас, кто использовал плагин карт Google, не развернул приложение на действующем сервере и забыл изменить код на правильный ключ API? :) С помощью этого плагина, элемента googlemaps_apikey в вашем массиве register_webhost () и небольшого настраиваемого хука migrate_webhosts вы можете эффективно устранить это как проблему!
Ну вот и все. Я запускаю этот плагин здесь, на бирже ответов WordPress, потому что вопрос @ Insanity5902 вызвал его. Дайте мне знать, если это полезно, здесь, если необходимо, или по электронной почте, если нет.
Постскриптум Если вы решите использовать это, помните, что это альфа/бета, и это означает, что он изменится, поэтому будьте готовы к небольшим операциям, если вы хотите использовать его сейчас, а затем используйте выпущенную версию, как только она будет побита многими руками.
P.P.S. Каковы мои цели с этим? Мне нравится видеть, как это переносится в ядро WordPress, чтобы у всех был к нему доступ. Но прежде чем это можно будет даже рассмотреть, многие люди должны быть заинтересованы в его использовании, чтобы убедиться, что он действительно решает больше проблем, чем он может создать. Так что, если вам понравилась идея, во что бы то ни стало, используйте ее и помогите мне набрать обороты для возможного включения в ядро WordPress.
Когда это возможно, я устанавливаю WP_HOME и WP_SITEURL в wp-config.php. Это, в сочетании с дампом и импортом базы данных, является самым простым из всех известных мне решений.
http://codex.wordpress.org/Changing_The_Site_URL#Edit_wp-config.php
Мой любимый хак; добавьте настройку в свой /etc/hosts, чтобы рабочий домен указывал на вашу коробку разработки, прямо на вашем компьютере. Для развертывания в производство вы rsync все файлы и нажмите базу данных снова.
Риски этой стратегии очевидны; вы можете спутать свою среду разработки с производственной средой.
Это все еще легко исправить, хотя.
Я хотел что-то подобное, когда несколько месяцев назад перешел на WP, поэтому я написал довольно простой сценарий Shell, который использует rsync и mysqldump поверх ssh:
http://snarfed.org/sync_wordpress
Он не сложный и не веб-ориентированный, но я доволен этим.
WP Engine это новая служба, которая предлагает "Постановка в один клик":
WPEngine имеет эксклюзивную функцию под названием "подготовка". Вот как это работает. Прежде чем вносить страшные изменения в свой блог, нажмите кнопку "снимок". Мы делаем полную копию вашего блога и размещаем его в отдельном безопасном месте. Вы можете играть с чем угодно; ничего не живое Только когда вы готовы сделать это вживую, вы затрагиваете свой основной сайт.
Похоже, очень простой способ быстро перейти от разработки к производству, особенно с уже живым сайтом.
Плагин Duplicator: Вот плагин, над которым я работал. В настоящее время он находится в бета-версии, но он выполняет работу для большинства сайтов. Прямо сейчас это нацелено на меньшие установки WordPress. http://wordpress.org/extend/plugins/duplicator/
Ресурсы: Дополнительные ресурсы для плагина можно найти здесь: http://lifeinthegrid.com/duplicator/
Сообщество: Пожалуйста, дайте нам знать о ваших успехах или любых проблемах, с которыми вы можете столкнуться! Чтобы упростить управление различными темами, пожалуйста, публикуйте сообщения на форумах плагинов WordPress.org. Пожалуйста, не публикуйте какие-либо данные регистрации из плагина на онлайн-форумах. Данные регистрации могут быть отправлены на наш сайт поддержки.
Вы можете взглянуть на продукт от iThemes, который называется BackUpBuddy . Я использовал его только дважды, каждый раз, когда случалось одно или два препятствия, но в целом это выглядит многообещающе.
Это выглядит многообещающе. Мы работаем над некоторыми сценариями для переноса некоторых данных, например, wp-options, изменения путей в БД, копирования на носитель.
У меня проблема в том, что живой сайт продолжает расти, а другой находится в разработке. Один сайт, над которым мы работаем, имеет 20 сообщений в день и более 3000 комментариев в день. Это слишком много данных для перемещения через phpmyadmin или через командную строку. Кроме того, перемещение данных всегда вызывает проблемы с UTF по некоторым причинам.
Кроме того, теперь, когда похоже, что пункты меню хранятся в БД, у меня есть еще кое-что для решения.
Я проверяю весь свой код в SVN и внедряю код через FTP с сервера (Beanstalk). Это не делает изменения в БД для меня, хотя или активировать новые плагины.
Сейчас я планирую создать файл манифеста во время разработки, чтобы внести все изменения в работающий сайт.
Например, файл будет иметь удобочитаемые строки
Он будет включать плагины для активации, wp-опции для перемещения, изображения для перемещения, страницы для перемещения. Затем мой плагин обнаружит файл манифеста и внесет все изменения в промежуточный сайт.
После того как я проверил это и был уверен, что получил все, я мог быть уверен, что это сработает на производстве.
Этот плагин все еще только идея, но у меня есть некоторый код, написанный для него.
Кроме того, если вы хотите внести изменения только в URL в вашей БД, вы можете использовать следующий SQL.
просто замените $old$ на старый домен и $new$ на новый
update wp_postmeta set meta_value = replace(meta_value, '$old$' , '$new$') ;
update wp_posts set post_content = replace(post_content, '$old$' , '$new$') ;
update wp_options set option_value = replace(option_value, '$old$' , '$new$') ;
Я лично решаю эту проблему с моим проектом на Github, который называется Autopress . У меня пока нет идеального решения, но я все ближе, особенно с плагином wpstage от людей wpengine.
Два проекта Google Summer of Code, имеющие одинаковую цель:
- Автоматическая миграция (GSoC 2010)
- WordPress Move ( предложение ) (GSoC 2011)
Начиная с 2017 года, я нашел два лучших способа справиться с переносом базы данных WordPress из разработки в производство.
WP Migrate DB Pro/WP Синхронизировать БД
https://wordpress.org/plugins/wp-migrate-db/
Эти плагины WordPress позволяют загружать, извлекать и синхронизировать таблицы базы данных между установками WordPress. Это намного лучше, чем поиск/замена по многим причинам, потому что:
- Экспортирует вашу базу данных как дамп данных MySQL (так же, как phpMyAdmin)
- Находит и заменяет URL-адреса и пути к файлам
- Обрабатывает сериализованные данные
- Позволяет сохранить его на свой компьютер в виде файла SQL
Я фанат того, что мне платят за работу, которую я выполняю, поэтому я рекомендую вам поддержать мистера Брэда Туеснарда и купить лицензионную копию настоящей вещи. WP Синхронизация БД является копией, и в результате она всегда отстает в поддержке. С этим плагином процесс очень прост:
- Установите/активируйте плагин на вашем локальном хосте и в производственной среде
- Сконфигурируйте Push-передачу с вашего локального хоста/сервера разработки на ваш продукт
- Укажите правила для таблиц, которые нужно перенести, и определите правила поиска и замены для выполнения.
- Это оно!
Поиск в базе данных и замена баз данных WordPress на InterconnectIT
https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
Этот бесплатный инструмент не является плагином, но устанавливается в корневой каталог вашей производственной установки WordPress. Это не так хорошо, как WP Мигрировать DB Pro, потому что для этого требуется несколько ручных шагов, но, тем не менее, это отличный вариант, который постоянно работает. При использовании этого подхода процесс выглядит так:
- Сделайте резервную копию вашей локальной базы данных, это абсолютно необходимо, так как мы скоро ее повторно импортируем
- Добавьте скрипт в папку в корневом каталоге вашей установки
- Запустите поиск и замену в вашей базе данных
- Экспортируйте свою базу данных и сохраните ее для своей производственной среды
- Повторно импортируйте резервную копию с шага № 1, чтобы восстановить локальный хост
- Подключитесь к своей производственной базе данных и сделайте резервную копию (как всегда, прежде чем делать это)
- Импортируйте сделанный нами экспорт ПОСЛЕ запуска процедуры поиска/замены из шага № 4
Вы можете использовать более быстрый подход, но он включает в себя время простоя вашей производственной площадки, что, на мой взгляд, недопустимо. Вот почему мы называем это производством, верно?
Несмотря на то, что здесь нет недостатка в хороших решениях, я решил добавить свой сценарий bash deploy в кучу: https://github.com/jplew/SyncDB
SyncDB - это скрипт развертывания bash, предназначенный для снятия утомительной синхронизации локальной и удаленной версий сайта Wordpress. Это позволяет разработчикам, работающим в локальной среде (например, MAMP), быстро "выдвигать" или "извлекать" изменения на или с их производственного сервера с помощью одной команды терминала.
Этот сценарий хорошо работает с WP-Skeleton Марка Якита и использует mysqldump, git и rsync для синхронизации всего сайта - базы данных, кода и мультимедиа - в два простых шага:
./syncdb
git Push hub master
Я использую http://wordpress.org/plugins/wp-clone-by-wp-academy/ . Работает красиво!
Всего 3 шага:
- Установите плагин на обоих сайтах.
- Используйте плагин для создания резервной копии на старом сайте.
- Возьмите резервный URL, который он вам дает, и вставьте его на страницу плагина на новом сайте, нажмите "Перейти", и ваша миграция будет завершена всего за несколько секунд!
Он автоматически настраивает все URL-адреса - включая сериализованные замены строк - поэтому нет риска потери конфигураций виджетов и т.д.
Единственные проблемы, с которыми я столкнулся, связаны с некоторыми веб-сайтами с большими базами данных (~ 300 МБ), что приводило к превышению времени ожидания выполнения скрипта PHP при импорте резервной копии сайта.
Я использую команду экспорта Subversion для установки файлов WordPress (http://core.svn.wordpress.org/tags//), а также всех плагинов в хранилище (http://plugins.svn.wordpress.org//tags //), затем просто заархивируйте тему и пользовательские плагины и установите их как обычно. После того, как все это работает и работает без содержимого, я экспортирую тестовую базу данных и выполняю поиск/замену для URL и пути к файлу (хранится для носителя) и импортирую в пустую базу данных, а затем просто переключаю информацию базы данных в wp-config .php. Обычно у меня уходит около 10 - 20 минут.
Обычно я захожу в phpMyadmin, загружаю базу данных и редактирую содержимое wp_options> siteurl и wp_options> home для ожидаемого домена. Если вам необходимо обновить URL-адреса в содержимом ваших сообщений и страниц, вы можете выполнить поиск/замену URL-адреса и пути медиа/загрузки в файле .SQL перед загрузкой. Это быстрая работа.
Я уже давно пользуюсь плагином backupbuddy. Это позволяет создавать резервную копию базы данных и всех файлов, загружать ее в виде Zip или отправлять напрямую на другой сервер через FTP. Он также находит и заменяет URL-адрес. Обычно мне требуется около 5 минут, чтобы пройти весь процесс. А поскольку все файлы заархивированы, процесс загрузки/выгрузки происходит намного быстрее. И нет, я не работаю на них, но этот плагин действительно сделал весь этот процесс намного проще.
Еще одно платное решение: каркас темы Xtreme One выпущенная версия 1.2 с Xtreme Backup , которая позволяет "экспортировать или импортировать настройки ваших дочерних тем, макетов или виджетов со всеми их настройками/контентом в виде XML-файл. "
так как я запускаю свои сайты в IIS (я также запускаю asp.net, поэтому мне нужны окна) я использую WebPI из Msft для установки нового экземпляра, затем копирую шаблон и использую импорт/экспорт для передачи данные.
Это не идеально, но все это занимает меньше часа.
Очевидно, было бы хорошо иметь решение в один клик, но это то, что я нашел для меня самым простым.
RAMP - это новый плагин для развертывания контента от Crowd Favorite, и он выглядит очень привлекательно. Это 250 долларов, поэтому я еще не пробовал. Может быть, просто окупить себя за сэкономленное время, поэтому я обдумываю это.
Большим преимуществом, которое он имеет по сравнению с большинством других упомянутых методов, является то, что он может интеллектуально объединять записи, комментарии и т.д. Это не просто импорт mysqldump, это больше похоже на управление исходным кодом для базы данных. Например, при развертывании публикации также будут развернуты теги для этой записи, если они еще не существуют в рабочей среде.
Коллега нашел это. Интересная концепция, хотя она не работает на разных серверах. Я все еще исследую это, но похоже, что это могло бы отлично работать для инсценировки
Возможно, этого не было, когда вы задавали вопрос, но я уже пару месяцев пользуюсь сервисом Blogvault, и он сделал это без нареканий. Я, вероятно, сделал более 50 миграций (пересечение доменов, поддоменов и веб-хостов), не проблема и не занимает много времени.
Это платная услуга (за домен/месяц), но не так много.
Это самый простой способ: https://themes.artbees.net/docs/website-migration/
Это займет всего два клика. Один на экспорт, другой на импорт.
Это возможно с помощью плагина All in one WP Migration. Выше ссылка показывает, как его использовать.
Еще одним полезным инструментом для обработки миграций серверов для сайтов является интерфейс командной строки WordPress. В этой статье представлен хороший обзор того, что он может делать, но в частности раздел "Поиск и замена" полезен для поиска всех ссылок на старый/dev-сайт. :
Позвольте мне отдать один из моих любимых :-)
// proven local<->live codefork (covers local network testing, i.e. from mobile devices):
$GLOBALS['is_local'] =
in_array( $_SERVER['REMOTE_ADDR'], array("127.0.0.1","::1")) || // simple localhost (IPv4 IPv6)
$_SERVER['HTTP_Host'] == 'local.workblog' || // call by local name (adjust)
substr($_SERVER["REMOTE_ADDR"],0,8) == '192.168.'; // (mobile) device in local network
$table_prefix = NULL; // ensure scope
if ( $GLOBALS['is_local'] ) // LOCAL fork ------------------------
{
....
}
else // STAGE/LIVE fork -------------------
{
... а потом ты работаешь оттуда. DB_NAME, DB_USER ... table_prefix. Лично я включаю ALTERNATE_WP_CRON на локальном (чтобы избежать некоторые раздражающие предупреждения ), WP_DEBUG на обоих (если вы не разработчик) или только на живых (если вы есть), другая ini_set('display_errors', '0'); для живых также может сделать хорошо, наконец, как уже упоминалось выше: WP_HOME и WP_SITEURL для соответствующего локального/фактического URL.
Это почти все, ничего не осталось выше классического WordPress "Все, прекрати редактировать!" строка ...
192.168. часть позволяет вам провести локальное тестирование (например, с планшетов или телефонов) в вашей локальной сети)
$ GLOBALS ['is_local'] также может пригодиться в разработке вашей темы для некоторых дополнительных выводов отладки и т. Д ...
Поработав некоторое время над этим ответом, я создал свой собственный небольшой плагин - Pitta Migration . Причины:
- Из всех опробованных здесь идей - самые простые варианты
WP_HOMEиWP_SITEURL - Затем я использую их для установки двух совпадающих URL-адресов
wp_options- которые покрывают, когда плагины/темы игнорируют эти - Это дает мне 100% уверенность в том, что меняется в моей базе данных
- Это также работает кроссплатформенно (все эти скрипты bash не очень хорошо работают в Windows)
- Легко понять, что делает плагин
- Конфигурации, кроме двух констант, нет - выполните импорт mysqldump и mysql в вашу локальную базу данных, и плагин увидит, что константа и таблица различаются, и обновит их для соответствия
- Нет текстового поиска и замены
- Нет шансов утомить вашу базу данных - я использую объект базы данных WordPress для двух обновлений и ничего более
- Он хорошо играет с такими вещами, как WordPress Skeleton где вы можете иметь все в управлении исходным кодом и установить локальную конфигурацию
- Я поместил его в каталог плагинов WordPress и на Github , чтобы он был бесплатным, полностью открытым исходным кодом, его было легко раскошелиться и легко установить
- После установки вы можете забыть об этом, и он должен "просто работать" - он дает вам небольшое уведомление о том, что база данных была изменена
- Должен работать с любым процессом резервного копирования/FTP/восстановления
Если вы пытаетесь добиться непрерывной синхронизации, я предлагаю использовать rsync вместе с пользовательским заданием cron для перезаписи любых URL-адресов или данных, специфичных для сайта.
На мой взгляд, самый простой способ, которым я следую, - это перенос вручную. Просто скопируйте папку wp-content и файл wp-config.php на новый хост. Экспортируйте базу данных со старого хоста и импортируйте ее в новую базу данных нового хоста.
В новой базе данных хоста перейдите в таблицу wp-option и там измените URL сайта и URL блога на новый адрес хоста со старого хоста. как из http: // localhost/wp to http://example.com
Теперь в файле wp-config просто измените информацию базы данных и пользователя на новую информацию о хосте.
Теперь войдите в новый wp-admin, зайдите в настройки и сохраните постоянную ссылку.
Вы сделали. Я думаю, что это просто без использования каких-либо плагинов.
Я пробовал различные виды плагинов, и у всех них есть много видов проблем ..
Поэтому я предпочитаю эту простую ручную передачу, которая, как мне кажется, проще.