Wordpress з Git

Я задаю це питання, тому що я шукав в Інтернеті, але не можу знайти правильне рішення. Насправді я хочу рішення, в якому декілька розробників можуть працювати над одним проектом wordpress, не створюючи жодного безладу між собою, але, як ми знаємо, що в wordpress кожна річ зберігається в базі даних, наприклад, який плагін активний, а який ні.

Якщо розробники встановлюють плагіни для свого локального проекту, ніж те, як вони спілкуються один з одним, то кожен повинен встановити цей конкретний плагін або плагіни тощо, і деякі неправильні комунікації можуть зламати сайт інших, якщо кожен розробник натискає / витягує код.

Якщо ми також мусимо поділитися базою даних, щоб поділитися налаштуваннями плагінів / тем, щоб не виникало конфліктів і мало конфліктів між розробниками.

Спасибі

Git для плагінів :

• Використовуйте Composer для плагінів, які вже упаковані на пакувальника або wpackagist . Додайте їх до composer.json.
• Використовуйте активацію модулів TGM для інших плагінів.

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

Найважче - це синхронізувати базу даних :

Безумовно, нам слід поділитися базою даних. Перенастроювати параметри / параметри плагіна - це не дуже гарна ідея.

Є багато плагінів , як безкоштовних, так і преміум-класів, які можуть допомогти.

Якщо ви хочете спробувати щось вручну, включіть wp-cli з відповіддю @Wyck.

Моя команда зіткнулася з подібною проблемою. Ми використовуємо git для версії власного власного коду, такого як плагіни та тема, яку ми пишемо. Ми використовуємо Composer для управління залежностями, такими як плагіни, про які ми не писали. Ми перевіряємо файли composer.json і composer.lock в git, щоб всі синхронізувались. Очікується, що кожен розробник буде тягнути гіт-майстер гіта і composer updateчасто працювати на своїх манежах, тому кожен залишається в курсі.

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

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

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

Є кілька перспективних рішень щодо фактичної версії бази даних, які швидко збираються. VersionPress і Mergebot є два я знаю , і там можуть бути і інші.

Я написав більше технічних деталей про те, як ми налаштували WordPress на роботу з git та Composer у своєму блозі. Потрібно було запустити з ядром WordPress у власному каталозі, щоб зробити чіткий поділ між кодом, який ми хочемо підтримувати в git, та ядром WordPress. Ми ставимося до WordPress як до залежності та керуємо ним разом із композитором.

Найкраще рішення, що я бачив у цьому, - це використовувати Bedrock ( https://roots.io/bedrock/ ).

Інші відповіді на це запитання (Композитор та щось для управління вашими плагінами) - хороші відповіді; але Bedrock пропонує систематизований, підтримуваний, документований, постійно вдосконалюється спосіб цього, який є кращим, ніж прокрутка вашого власного.

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

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

Ми використовуємо git і композитор для того, щоб підтримувати різні середовища розвитку. Просто перетягніть останні зміни та запустіть композитор, і ви готові йти.

Для цього нам перш за все потрібно зрозуміти структуру каталогу WordPress. Структура каталогу WordPress не є такою зручною для користування gitним. Тому я б запропонував вам використовувати це з досить gitдоброзичливою модифікованою архітектурою. Ні, не потрібно панікувати. Не обов’язково це створювати. Існує багато таких типів котлоагрегату чи структурованої системи WordPress. Просто виберіть одну з них і починайте кодувати.

Тепер перейдемо до написання добре організованого коду чи підручного коду. Ми фактично ставимо свій код на wp-content\themes\your-themeабо wp-content\themes\your-theme. Тож у більшості gitдружніх котлів WordPress wp-contentдеталь відокремлена. І вони здебільшого тягнуть репо через WordPress composer. Це робить повний проект набагато чистішим.

Синхронізація плагінів - ще одна важлива частина. Було б краще, якщо ви встановите свій плагін через composer. Це робить код проекту набагато чистішим. Тут ви отримаєте огляд того, як встановити плагіни WordPress через composer.

Тепер переходимо до найважливішої частини, як синхронізувати базу даних. Я думаю, що це було б простіше зробити нижче двома способами -

• Усі розробники повинні використовувати одну віддалену базу даних. І часто створюйте резервну копію.
• Автоматизувати функцію експорту імпорту WordPress. Це здається складним, але це не так. Просто зробіть Google, сподіваюся, що ви можете це зробити.

Сподіваюся, що вам допоможе.