Организация процесса разработки WordPress сайта. Управление базой данных.

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

В моём цикле разработки данную проблему я решил с помощью плагина WP Sync DB. Это форк коммерческого плагина WP Migrate DB, который выложил свою полную версию пол GPL лицензией. Автор WP Sync DB выпилил код проверки лизензии и так же выложил под GRL, так что лицензионно здесь всё чисто и подкопаться не к чему. Можем смело использовать.
WP Sync DB устанавливается из GitHub. Чтобы облегчить в дальнейшем управление установим сначала плагин github updater со страницы его релизов https://github.com/afragen/github-updater/releases. И, затем, устаналиваем сам плагин синхронизации, скачав его релиз с соответсвующей страницы https://github.com/wp-sync-db/wp-sync-db/releases.
Работа с плагином интуитивно понятна. Я предлагаю воспользоваться документацией и видео описаниями к нему. В том числе очень неплохая подборка материала в коммерческом плагине.
Следующим шагом будет установка расширения для управления медиа-файлами WP Sync DB Media Files, который просто находит привязанные к постам медиа файлы и синхронизирует их.
В итоге, наша схема разработки с базой данных сводится к следующему:

• перед началом разработки мы синхронизируем базу данных продуктива и среды разработки;
• выполняем нужные манипуляции;
• заливаем базу данных обратно на продуктив.

Причём, если мы не изменяли таблицы постов или комментариев при разработке, то мы можем легко их исключить из плана обмена в плагине. Таким образом, нам даже не нужно блокировать изменение контента на продуктиве в цикле разработки.