Я задаю этот вопрос, потому что я искал в Интернете, но не могу найти правильное решение. На самом деле я хочу, чтобы решение, в котором несколько разработчиков могли работать над одним проектом WordPress, не создавая путаницы друг с другом, работает, но, как мы знаем, в WordPress все поддерживается в базе данных, например, какой плагин активен, а какой нет.
Если разработчики устанавливают плагины в свой локальный проект, чем то, как они общаются друг с другом, что каждый должен установить этот конкретный плагин или плагины и т. Д., И некоторые недоразумения могут сломать сайт других, если каждый разработчик протолкнет / вытянет код.
Должны ли мы совместно использовать базу данных, чтобы поделиться настройками плагина / тем, чтобы не было конфликтов или небольших конфликтов между разработчиками.
Благодарность
Ответы:
Git для плагинов :
composer.json
.Затем используйте 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. Разработчики могут использовать это периодически, если им нужен весь текущий контент, хотя это обычно менее важно, чем иметь код и конфигурацию. Скрипт выполняет следующие задачи:
Есть несколько многообещающих решений для быстрого создания версий базы данных. 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
. Это делает код проекта намного чище. Здесь вы узнаете, как установить плагины для WordPresscomposer
.Теперь перейдем к самой важной части, как синхронизировать базу данных. Я думаю, что это может быть легче сделать ниже 2-х способов -
Надеюсь, это поможет вам.
источник