Синхронизация локального контента с сайтами разработки / размещения

Я исхожу из фона Laravel, что означает, что я привык использовать миграции и поселки базы данных, чтобы поддерживать контент на сайтах dev / staging в синхронизации с моей локальной средой.

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

Развертывание самого кода не является проблемой, так как код хранится под контролем версий, и я могу создать webhook для автоматического развертывания кода.

Я читал о плагинах, таких как WP Migrate DB, но я не уверен, что это инструмент для работы.

Может ли кто-нибудь посоветовать лучший способ достичь этого?

Solutions Collecting From Web of "Синхронизация локального контента с сайтами разработки / размещения"

обзор

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

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

WordPress фактически сохраняет результирующие URL-адреса в базе данных.

Итак, предположим, что ваш локальный URL-адрес разработки: http://localhost/awesome . Ваши сообщения, хранящиеся в базе данных, также сохраняли ваш URL-адрес разработки (то есть http://localhost/awesome ) в каждом сообщении. URL-адрес также сохраняется в таблице wp_options . Поэтому, когда вы импортируете дамп локальной базы данных на сервер, вам нужно заменить существующий URL на URL-адрес сервера, чтобы ссылки на сообщения отображались.

Не очень элегантное решение:

Одним из решений, которые я лично использую, является поиск Replace DB с помощью interconnect / it .

Чтобы использовать скрипт, загрузите zip-файл снизу, извлеките папку под названием search-replace-db-master (при условии, что вы используете версию 3.1.0), переименовав ее в какой-то секрет по вашему выбору, загрузите его через FTP, SFTP или SCP в общедоступный каталог вашего веб-сервера, затем перейдите к этой папке в своем браузере. Сценарий автоматически попытается найти и заполнить поле базы данных, но вы должны убедиться, что данные верны и что для базы данных вы хотите выполнить операцию поиска / замены.

Типичная установка WP с этим скриптом будет иметь следующие папки:

  • / Ваш секретный-поиск-замена-папка
  • / WP-администратора
  • / WP-содержание
  • / WP-включает в себя

ПРИМЕЧАНИЕ . Пожалуйста, ознакомьтесь с установкой и использованием инструмента на своем веб-сайте и убедитесь, что детали верны при замене.

Как это работает?

Ваш:

URL-адрес разработки: http://localhost/awesome
URL-адрес Live Server: http://awesome.com

Вы указываете URL-адрес разработчика в Replace Textbox и URL-адрес реального сервера в « With Textbox . Убедитесь, что у вас есть резервная копия базы данных, затем нажмите кнопку « dry run или « live run чтобы выполнить действие.

Вывод

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

Там много решений, и один из них упоминается в вашем вопросе (например, WP Migrate DB ). Вам просто нужно выложить утомительный рабочий процесс разработки WordPress , так же как и CMS WordPress на протяжении всего своего существования, есть еще одно основное предостережение, которое позволяет нам хотеть освободиться.

WP Migrate DB действительно установленный профессиональный инструмент.

Существует также серверное приложение ServerPress и локальное приложение для хостинга Flywheel (ранее Pressmatic). Оба этих приложения для Windows и Mac создают настраиваемую локальную среду разработки, которая может использоваться совместно в сети или по сети, и помещается в промежуточные или живые сайты на (некоторых) хостах. Последняя особенность не очень зрелая в любом приложении, особенно в новом Local.

Наконец, есть VersionPress (в настоящее время Beta 4) – плагин и (в работе) размещенная служба.

Для нашего сайта мы написали скрипт Perl, который копирует базу данных, затем использует команды wp-cli для настройки определенных параметров, локальных для данного сайта. Сценарий также запускает командную строку UNIX для синхронизации каталогов загрузок.

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

Тем не менее, у нас также есть сайт для размещения контента для наших пользователей, и мы используем RAMP для переноса отдельных элементов контента (или их пакетов) с сайта промежуточного контента на сайт в реальном времени. Это приведет к возникновению всех зависимостей с заданной почтой / страницей, такими как вложения мультимедиа, термины таксономии, пользователи и т. Д. RAMP ориентирован на конечного пользователя, который обновляет и создает контент. Это требует некоторой настройки для работы с сайтами, которые были настроены с использованием чего-то вроде ACF.

Наш типичный рабочий процесс – использовать RAMP для перехода между контентом и живым, а затем использовать наш сценарий копирования, чтобы обновить наши сайты разработчиков и тестовых сайтов с контентом на промежуточном веб-сайте.

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