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

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

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

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

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

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

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

Чтобы использовать его, вы применяете другой подход в своем wp-config.php, который нормальный, комментируя четыре (4), определяет DB_NAME, DB_USER, DB_PASSWORD и DB_HOST и вместо этого регистрация по умолчанию для веб-хостов, а затем регистрация информации о каждом самом веб-хосте. Вот как может выглядеть этот сегмент wp-config.php (обратите внимание, что первый раздел - это незавершенный код, закомментированный, а также обратите внимание, что я установил файл моих хостов на моем локальном компьютере с немаршрутизируемым .dev, чтобы сделать повседневную разработку проще. На Mac VirtualHostX делает это ветерок):

.dev

Надеюсь, это (в основном) объяснение. Я попытался сделать код таким же чистым, как я мог, но, к сожалению, он требует этих двух критических // ** 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'); строк до и после блока регистрационного кода веб-хостинга, поскольку для меня не было возможности « hook "Вызывается WordPress до require_once().

Как только вы обновили свой wp-config.php, вы можете просто использовать ярлык URL wp-config.php, чтобы перейти на экран администратора так:

  

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

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

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

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

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

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

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

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

Мне хотелось что-то подобное, когда несколько месяцев назад я перешел на WP, поэтому написал довольно простой сценарий оболочки, который использует rsync и mysqldump поверх ssh:

http://snarfed.org/sync_wordpress

Это не сложный или основанный на Интернете, но я доволен этим.

WP Engine - это новая услуга, предлагающая «One-Click Staging»:

  

WPEngine имеет эксклюзивную функцию, называемую «staging». Вот как это работает: прежде чем вы вносите страшные изменения в свой блог, нажмите кнопку «snapshot». Мы делаем полную копию вашего блога и настраиваем его в отдельной безопасной зоне. Вы можете играть с чем угодно; ничего не живут. Только когда вы готовы сделать это вживую, вы касаетесь своего основного сайта.

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

Плагин дубликатов: Вот плагин, над которым я работал. В настоящее время он находится в стадии бета-тестирования, но он выполняет работу для большинства сайтов. Сейчас он нацелен на более мелкие установки WordPress. http://wordpress.org/extend/plugins/duplicator/

Ресурсы Дополнительные ресурсы для плагина можно найти здесь: http://lifeinthegrid.com/duplicator/

Сообщество: Сообщите нам о ваших успехах или о любых проблемах, с которыми вы могли столкнуться! В целях более простого управления различными потоками, пожалуйста, размещайте сообщения на форумах плагинов WordPress.org. Пожалуйста, не публикуйте данные регистрации из плагина на онлайн-форумах. Данные регистрации могут быть отправлены на наш сайт поддержки.

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

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

Это выглядит многообещающим. Мы работаем над некоторыми сценариями, чтобы обрабатывать перенос некоторых данных, например, wp-options, изменение путей в db, копирование по медиа.

Проблема заключается в том, что живой сайт продолжает расти, а другой находится в разработке. Один сайт, на котором мы работаем, имеет 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 в кучу: https://github.com/jplew/SyncDB

  

SyncDB - это сценарий развертывания bash, предназначенный для того, чтобы вывести скуку из синхронизации   локальные и удаленные версии сайта Wordpress. Это позволяет разработчикам, работающим в   локальная среда (например, MAMP), чтобы быстро «нажимать» или «тянуть» изменения на или из   их производственный сервер с помощью одной команды терминала.

Этот скрипт хорошо работает с WP-Skeleton Марка Джаквита и использует mysqldump, git и rsync для синхронизации всей вашей базы данных сайта , код и медиа - в два простых шага:

./syncdb
git push hub master

Я использовал http://wordpress.org/plugins/сор-клон-на-в.ч.-академии /. Он работает красиво!

Всего 3 шага:

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

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

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

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

WP Перенастройка DB Pro /WP Sync DB

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

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

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

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

1. Установите /активируйте плагин на локальном хосте и производственной среде
2. Настройте перенос push с вашего сервера localhost /development на ваше производство.
3. Заполните правила для передачи таблиц и определите правила поиска и замены для выполнения
4. Вот и все!

Поиск базы данных и amp; Замените базы данных WordPress на InterconnectIT

https://interconnectit.com/products/search- и заменить-на-WordPress-баз данных /

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

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

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

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

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

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

Другое платежное решение: рамка темы Xtreme One выпущенная версия 1.2 с Xtreme Backup , который позволяет "экспортировать или импортировать настройки ваших Childthemes, Layouts или Widgets со всеми их настройками /контентом в виде XML-файла. "

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

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

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

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

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

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

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

Другим полезным инструментом для обработки миграций серверов для сайтов является WordPress CLI, в этой статье представлен хороший обзор того, что он может сделать, но в частности раздел «Поиск и замена» полезен для поиска всех ссылок на старый /dev site url:

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

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

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

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

Позвольте мне отдать одного из моих фаворитов: -)

// 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'); для live также может делать добро, наконец, как указано выше: WP_HOME и WP_SITEURL для соответствующих локальный /фактический URL.

Это почти все, ничего не осталось выше классического WordPress «Вот и все, прекратите редактирование!» line ...

192.168. позволяет вам выполнять локальные тесты (например, с прокладок или телефонов) в локальной сети)

$ GLOBALS ['is_local'] может пригодиться и в разработке вашей темы для дополнительного вывода отладки и т. д.

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

1. Из всех рассмотренных здесь идей - самым простым является WP_HOME и WP_SITEURL параметры
2. Затем я использую их для установки двух совпадающих URL-адресов wp_options, которые распространяются, когда плагины /темы игнорируют эти
3. Это дает мне 100% уверенность в том, что меняется в моей базе данных.
4. Это также работает кросс-платформенный (все эти сценарии bash не очень хорошо воспроизводятся в Windows)
5. Легко понять, что делает плагин
6. Нет конфигурации за пределами двух констант - выполните mysqldump и импорт mysql в вашу локальную базу данных, и плагин увидит, что константа и таблица отличаются и обновляют их, чтобы они соответствовали
7. Текстовый поиск и замена
8. Нет возможности издеваться над вашей базой данных - я использую объект базы данных WordPress для выполнения двух обновлений и не более
9. Он отлично играет с такими вещами, как скелет WordPress , где вы можете иметь все, что находится в управлении версиями и установить локальная конфигурация
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 и перейдите к настройкам и сохраните постоянную ссылку.

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

Я пробовал разные типы плагинов, и все они имеют много проблем.

Поэтому я предпочитаю этот простой перенос вручную, который, как мне кажется, легче.