Wordpress с Git

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

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

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

Благодарность

Git для плагинов :

• Используйте Composer для плагинов, которые уже упакованы в packagist или wpackagist . Добавьте их в composer.json.
• Используйте активацию плагинов TGM для других плагинов.

Затем используйте Git для управления composer.jsonизменениями в плагине TGM.

Сложнее всего синхронизировать базу данных :

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

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

Если вы хотите что-то попробовать вручную, включите wp-cli с ответом @Wyck.

Моя команда столкнулась с подобной проблемой. Мы используем git для версии нашего собственного пользовательского кода, такого как плагины и тема, которую мы пишем. Мы используем Composer для управления такими зависимостями, как плагины, которые мы не написали. Мы проверяем файлы composer.json и composer.lock в git, чтобы синхронизировать всех. Предполагается, что каждый разработчик будет тянуть ветку git master и composer updateчасто запускать свои игровые приставки, чтобы каждый оставался в курсе событий.

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

У нас также есть сценарий perl, который полностью клонирует базу данных с нашего промежуточного сервера контента на хост QA или dev. Разработчики могут использовать это периодически, если им нужен весь текущий контент, хотя это обычно менее важно, чем иметь код и конфигурацию. Скрипт выполняет следующие задачи:

• mySQL dump базы данных сервера промежуточного содержимого, изменение имен таблиц, загрузка в базу данных целевого сервера
• используйте wp-cli для изменения ссылок на промежуточный сервер в базе данных для ссылки на целевой сервер
• синхронизировать каталог загрузки на целевом сервере с загрузками сервера подготовки контента

Есть несколько многообещающих решений для быстрого создания версий базы данных. VersionPress и Mergebot - это те, кого я знаю, и могут быть другие.

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

Лучшее решение, которое я видел в этом, - это использовать Bedrock ( https://roots.io/bedrock/ ).

Другие ответы на этот вопрос (Composer и что-то для управления вашими плагинами) - хорошие ответы; но Bedrock предоставляет систематизированный, поддерживаемый, документированный, постоянно улучшающийся способ сделать это, что предпочтительнее, чем ваш собственный.

Кроме того, помните, что вы можете иметь более одного git-репо - по одной для вашей темы, по одному для каждого пользовательского плагина, который вы разрабатываете, а затем по одному «основному» для самой установки Bedrock / Wordpress.

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

Мы используем git и composer, чтобы поддерживать различные среды разработки в актуальном состоянии. Просто извлеките последние изменения и перезапустите композитор, и все готово.

Для этого прежде всего нам нужно понять структуру каталогов WordPress. Структура каталогов WordPress не так удобна для использования git. Поэтому я бы предложил вам использовать это с довольно gitдружественной модифицированной архитектурой. Нет, не нужно паниковать. Вам не обязательно создавать это. Существует множество таких типовых или структурированных систем WordPress. Просто выберите один из них и начните кодировать.

Теперь приступим к написанию хорошо организованного кода или кода, пригодного для использования. Мы фактически ставим наш код на wp-content\themes\your-themeили wp-content\themes\your-theme. Так что в большинстве gitдружественных шаблонов WordPress эта wp-contentчасть отделена. И они в основном тянуть throuh WordPress репо composer. Это делает весь проект намного чище.

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

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

• Все разработчики должны использовать одну удаленную базу данных. И часто создавайте резервную копию этого.
• Автоматизация импорта и экспорта WordPress. Это кажется сложным, но это не так. Просто сделайте Google, надеюсь, вы можете сделать это.

Надеюсь, это поможет вам.