Как: легко перенести установку WordPress из разработки в производство?

Я занимаюсь разработкой одной коробки и использую вторую для производства. Прямо сейчас я просто сбрасываю базу данных и затем выполняю поиск замены для изменений URL; затем скопируйте файлы и импортируйте новый SQL.

Есть ли лучшие способы сделать это?

@ Insanity5902 : Развертывание сайта WordPress из одного ящика в другое было PITA с самого первого дня, когда я начал работать с WordPress. (По правде говоря, это была PITA с Drupal в течение 2 лет, прежде чем я начал работать с WordPress, поэтому проблема, конечно, не только в WordPress.)

Меня беспокоило, что каждый раз, когда мне нужно было переместить сайт, мне приходилось тратить так много раз дублированных усилий, и это мешало мне развертывать тестирование так часто, как я бы этого хотел. Так, около 4-6 месяцев назад я начал работать над плагином для решения проблемы миграции веб-хостинга, и я упомянул свои идеи на форуме WP Tavern .

Ну что ж, перенесемся на сегодняшний день, и у меня все получилось, и я удобно называть его « WP Migrate Webhosts ». Несмотря на то, что плагин все еще очень бета (возможно, даже альфа), учитывая ваш вопрос, я думаю, что я готов позволить людям начать бить по нему.

Предполагаемый вариант использования:

1. сначала разработчик обрабатывает загрузку всех измененных тем и файлов плагинов через FTP,
2. затем полностью загружает базу данных разработки MySQL на тестовый сервер и, наконец,
3. затем запускает плагин для переноса любых ссылок из предыдущего домена в новый. (Мой плагин никак не пытаться решить слияние новых полей базы данных или таблицы с реальными данными, ЧТО это гораздо большая проблема , что я не знаю , как решить.)

Вы можете скачать плагин с моего веб-сайта и разархивировать его в каталог плагинов (если вы не знаете, как это сделать, тогда этот плагин не для вас, потому что для этого нужен кто-то, кто знает, что они делают.) Я буду держите этот плагин в сети, пока я не опубликую его на 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()строк до и после блока кода регистрации веб-хоста, поскольку у меня не было возможности « перехватить » WordPress до wp-config.phpвызова.

После того, как вы обновили свой, wp-config.phpвы можете просто использовать ярлык URL, wp-migrate-webhostsчтобы перейти к экрану администратора следующим образом:

http://example.com/wp-migrate-webhosts

Вышеприведенное приведёт вас к экрану администрирования, подобному следующему, который содержит довольно много текста описания и позволяет вам мигрировать из любого другого домена веб-хоста одним щелчком мыши после выбора доменов для миграции ( ПРИМЕЧАНИЕ . В этом примере показано переход DOWN из тестируемых / этапа / живых серверов для местного развития , но будьте уверены , он может мигрировать в любой области , где это случается, находится. Это также означает , что модуль будет отлично подходит для принятия существующего живого сайта и быстро получить местную среду разработки рабочего! ):

Если не ясно, « миграция » в этом контексте означает обновить все ссылки в текущей базе данных, чтобы они соответствовали определенному в настоящее время веб-хосту (а « текущий » выявляется проверкой $_SERVER['SERVER_NAME'].)

Что хорошо в плагине, так это то, что он реализует некоторые базовые миграции, но любой может подключить его и выполнить свои собственные миграции . Например, если вы добавите плагин галереи, который хранит полные пути к изображениям в базе данных, вы можете подключить migrate_webhostsдействие, которое будет передаваться веб-хосту « from » и веб-хосту « to » каждый в виде массива метаданных, и вам будет разрешено выполнить все, что вам нужно сделать в базе данных, используя SQL или любые применимые функции WordPress API для выполнения миграции. Да, любой из нас мог бы сделать это без плагина, но без плагина я обнаружил, что написание всего необходимого кода было больше усилий, чем оно того стоило. С плагином проще написать эти крошечные зацепки и покончить с этим.

Вы также можете обнаружить, что мои миграции потерпели неудачу в крайних случаях, которые я не тестировал, и, возможно, вы можете помочь мне улучшить плагин? Любой, кто захочет, может написать мне по электронной почте через мой аккаунт Gmail (мой псевдоним «mikeschinkel»).

Кроме того , плагин был разработан , чтобы принять пользователем определения метаданных веб - хостов в дополнение к тем, что он признает , как database, user, password, host, и domainт.д. Прекрасный пример может быть , googlemaps_apikeyгде вы можете хранить различные ключи API для каждого домена , которому требуется плагин вашего Google Map в работать правильно (кто из вас, кто использовал плагин Google Maps, не развернул приложение на реальном сервере и забыл изменить код на правильный ключ API? Да ладно, честно ... :) С этим плагином, googlemaps_apikeyэлемент в вашем register_webhost () массив и небольшой пользовательский migrate_webhostsкрючок можно эффективно устранить , что как проблема!

Ну вот и все. Я запускаю этот плагин здесь, на бирже ответов WordPress, потому что вопрос @ Insanity5902 вызвал его. Дайте мне знать, если это полезно, здесь, если необходимо, или по электронной почте, если нет.

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

PPS Каковы мои цели с этим? Мне нравится видеть, как это переносится в ядро ​​WordPress, чтобы у всех был к нему доступ. Но прежде чем это можно будет даже рассмотреть, многие люди должны быть заинтересованы в его использовании, чтобы убедиться, что он действительно решает больше проблем, чем он может создать. Так что, если вам понравилась идея, во что бы то ни стало, используйте ее и помогите мне набрать обороты для возможного включения в ядро ​​WordPress.

По возможности я установил WP_HOMEи WP_SITEURLв wp-config.php. Это, в сочетании с дампом и импортом базы данных, является самым простым из всех известных мне решений.

http://codex.wordpress.org/Changing_The_Site_URL#Edit_wp-config.php

Мой любимый хак; добавьте настройку, чтобы /etc/hostsрабочий домен указывал на вашу коробку разработки, прямо на вашем компьютере. Чтобы развернуть в производство, вы синхронизируете все файлы и перемещаете базу данных.

Риски этой стратегии очевидны; вы можете спутать свою среду разработки с производственной средой.

Это все еще легко исправить, хотя.

Я хотел что-то похожее, когда перешел на WP несколько месяцев назад, поэтому я написал довольно простой скрипт оболочки, который использует 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 . Я использовал его только дважды, каждый раз, когда случалось одно или два препятствия, но в целом это выглядит многообещающе.

Я лично решаю эту проблему с моим проектом на Github, который называется Autopress . У меня пока нет идеального решения, но я все ближе, особенно с плагином wpstage от людей wpengine.

Это выглядит многообещающе. Мы работаем над некоторыми сценариями для переноса некоторых данных, например, 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$') ;

Два проекта Google Summer of Code, имеющие одинаковую цель:

• Автоматическая миграция (GSoC 2010)
• WordPress Move ( предложение ) (GSoC 2011)

Я использую команду экспорта 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 перед загрузкой. Это быстрая работа.

Несмотря на то, что здесь нет недостатка в хороших решениях, я решил добавить свой сценарий 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 шага:

1. Установите плагин на обоих сайтах.
2. Используйте плагин для создания резервной копии на старом сайте.
3. Возьмите резервный URL, который он вам дает, и вставьте его на страницу плагина на новом сайте, нажмите «Перейти», и ваша миграция будет завершена всего за несколько секунд!

Он автоматически настраивает все URL-адреса - включая сериализованные замены строк - поэтому нет риска потери конфигураций виджетов и т. Д.

Единственные проблемы, с которыми я столкнулся, связаны с некоторыми веб-сайтами с большими базами данных (~ 300 МБ), что приводило к превышению времени ожидания выполнения сценария PHP во время импорта резервной копии сайта.

Начиная с 2017 года, я нашел два лучших способа справиться с переносом базы данных WordPress из разработки в производство.

WP Migrate DB Pro / WP Sync DB

https://wordpress.org/plugins/wp-migrate-db/

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

• Экспортирует вашу базу данных как дамп данных MySQL (так же, как phpMyAdmin)
• Находит и заменяет URL-адреса и пути к файлам
• Обрабатывает сериализованные данные
• Позволяет сохранить его на свой компьютер в виде файла SQL

Я фанат того, что мне платят за работу, которую я выполняю, поэтому я рекомендую вам поддержать мистера Брэда Туеснарда и купить лицензионную копию настоящей вещи. WP Sync DB - это копия, и в результате она всегда отстает в поддержке. С этим плагином процесс очень прост:

1. Установите / активируйте плагин на вашем локальном хосте и в производственной среде
2. Настройте принудительную передачу с вашего локального хоста / сервера разработки на ваш продукт
3. Укажите правила для таблиц, которые нужно перенести, и определите правила поиска и замены для выполнения.
4. Это оно!

Поиск в базе данных и замена баз данных WordPress на InterconnectIT

https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

Этот бесплатный инструмент не является плагином, но устанавливается в корневой каталог вашей производственной установки WordPress. Это не так хорошо, как WP Migrate DB Pro, поскольку требует нескольких шагов вручную, но, тем не менее, это отличный вариант, который постоянно работает. При использовании этого подхода процесс выглядит так:

1. Сделайте резервную копию вашей локальной базы данных, это абсолютно необходимо, так как мы скоро ее повторно импортируем
2. Добавьте скрипт в папку в корневом каталоге вашей установки
3. Запустите поиск и замену в вашей базе данных
4. Экспортируйте свою базу данных и сохраните ее для своей производственной среды
5. Повторно импортируйте резервную копию с шага № 1, чтобы восстановить локальный хост
6. Подключитесь к своей производственной базе данных и сделайте резервную копию (как всегда, прежде чем делать это)
7. Импортируйте сделанный нами экспорт ПОСЛЕ запуска процедуры поиска / замены из шага № 4

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

так как я запускаю свои сайты в IIS (я также запускаю asp.net, поэтому мне нужны окна), я использую WebPI из Msft для установки нового экземпляра, затем копирую шаблон и использую импорт / экспорт для передачи данных.

Это не идеально, но все это занимает меньше часа.

Очевидно, было бы неплохо иметь решение в один клик, но это то, что я нашел для меня самым простым.

Еще одно платное решение: платформа тем Xtreme One выпустила версию 1.2 с Xtreme Backup, которая позволяет «экспортировать или импортировать настройки ваших дочерних тем, макетов или виджетов со всеми их настройками / содержимым в виде файла XML».

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

http://code.google.com/p/deploymint/

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

Это платная услуга (за домен / месяц), но не так много.

RAMP - это новый плагин для развертывания контента от Crowd Favorite, и он выглядит очень привлекательно. Это 250 долларов, поэтому я еще не пробовал. Может быть, просто окупить себя за сэкономленное время, поэтому я обдумываю это.

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

Позвольте мне отдать один из моих любимых :-)

// 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'] также может пригодиться в разработке вашей темы для некоторых дополнительных выводов отладки и т. Д ...

Я уже давно пользуюсь плагином backupbuddy. Это позволяет создавать резервную копию базы данных и всех файлов, загружать ее в виде zip или отправлять напрямую на другой сервер через FTP. Он также находит и заменяет URL-адрес. Обычно мне требуется около 5 минут, чтобы пройти весь процесс. А поскольку все файлы заархивированы, процесс загрузки / выгрузки происходит намного быстрее. И нет, я не работаю на них, но этот плагин действительно сделал весь этот процесс намного проще.

Еще одним полезным инструментом для обработки миграций серверов для сайтов является интерфейс командной строки WordPress. В этой статье представлен хороший обзор того, что он может делать, но в частности раздел «Поиск и замена» полезен для поиска всех ссылок на старый / dev сайт URL. :

Расширенное управление WordPress с WP-CLI

Это самый простой способ: https://themes.artbees.net/docs/website-migration/
Это займет всего два клика. Один на экспорт, другой на импорт.

Это возможно с помощью плагина All in one WP Migration. Выше ссылка показывает, как его использовать.

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

Поработав некоторое время над этим ответом, я создал свой собственный небольшой плагин - Pitta Migration . Причины:

1. Из всех идей пытались здесь - самое простое это WP_HOMEи WP_SITEURLварианты
2. Затем я использую их для установки двух совпадающих wp_optionsURL-адресов, которые охватывают, когда плагины / темы игнорируют эти
3. Это дает мне 100% уверенность в том, что меняется в моей базе данных
4. Это также работает кроссплатформенно (все эти скрипты bash не очень хорошо работают в Windows)
5. Легко понять, что делает плагин
6. Конфигурации, кроме двух констант, нет - выполните импорт mysqldump и mysql в вашу локальную базу данных, и плагин увидит, что константа и таблица различаются, и обновит их для соответствия
7. Нет текстового поиска и замены
8. Нет шансов утомить вашу базу данных - я использую объект базы данных WordPress для двух обновлений и ничего более
9. Он прекрасно работает с такими вещами, как WordPress Skeleton, где вы можете иметь все в управлении исходным кодом и установить локальную конфигурацию
10. Я поместил его в каталог плагинов WordPress и на Github, чтобы он был бесплатным, полностью открытым, легким для вас и прост в установке.
11. После установки вы можете забыть об этом, и он должен «просто работать» - он дает вам небольшое уведомление о том, что база данных была изменена
12. Должен работать с любым процессом резервного копирования / FTP / восстановления

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

В новой базе данных хоста перейдите в таблицу wp-option и там измените URL сайта и URL блога на Новый адрес хоста со старого хоста. как с http: // localhost / wp на http://example.com

Теперь в файле wp-config просто измените информацию базы данных и пользователя на новую информацию о хосте.

Теперь войдите в новый wp-admin, зайдите в настройки и сохраните постоянную ссылку.

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

Я пробовал различные виды плагинов, и у всех них есть много видов проблем ..

Поэтому я предпочитаю эту простую ручную передачу, которая, как мне кажется, проще.