Як я повинен структурувати проект веб-сайту WP за допомогою git та оновлення з панелі керування WP?

Протягом місяців я намагаюся розробити гарну структуру проекту для використання керування версіями git для розробки веб-сайтів WordPress, яка не приносить шкоди можливості оновлення ядра та плагінів через панель інструментів WP, не вимагає нетрадиційної структури каталогів (wp -зміст за межами батьківської папки WP), і це легко керувати та розгортати цілі веб-сайти. Я читав про підмодулі, підмережі, вкладені репости тощо, і мені ще важко підходити все це разом і вибирати правильну стратегію.

Ось що я зараз думаю, з думками про те, як би я впорався з git repos в дужках.

root (main project repo)
|-- wordpress (public git repo added as subtree)
|    |-- wp-content 
|    |    |-- plugins
|    |    |    |-- my-custom-plugin (git repo added as subtree)
|    |    |    |-- other-plugin-with-git-repo  (git repo added as subtree)
|    |    |    +-- other-plugin-without-git-repo (ignored/untracked)
|    |    |-- themes
|    |    |    |-- my-custom-theme (git repo added as subtree)
|    |    |    |-- other-theme-with-git-repo  (git repo added as subtree)
|    |    |    +-- other-theme-without-git-repo (ignored/untracked)
|    |    +-- uploads (ignored/untracked)
|    |-- wp-admin
|    +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt

Це залишає у мене кілька проблем / питань;

• Автоматичні оновлення; Мені подобається нова функція автоматичних оновлень, вона потенційно може заощадити багато часу та зусиль для оновлення та безпеки моїх сайтів, але здається, що вона кидає гайковий ключ у відстеженні змін коду за допомогою git. Чи є спосіб відстежувати зміни мого коду, поки ядро ​​WordPress дозволяє автоматично оновлюватись?

• Чи перешкоджає підтрубкам під основним репортажем WordPress перешкоджати мені використовувати git для злиття в нових оновленнях ядра чи відштовхувати свої зміни назад до основного репо WordPress (якщо я коли-небудь вирішу, що хотів би стати основним дописувачем)?

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

Отже, підсумовуючи, що таке хороша настройка git + WordPress, яка дозволяє уникнути цих проблем? Буду вдячний за Ваш відгук про запропоновану структуру проекту. Будь ласка, будь-який спосіб, який ви можете допомогти мені покращити це!

PS, якщо є кращий форум для цієї дискусії, будь ласка, вкажіть мене там.

З моєї точки зору, у вашому плані є два питання - Git та "звичайна" структура. Так в основному все. :)

1. Git (і керування версіями загалом) - поганий інструмент для цілих стеків сайтів. Був там, робив це, сильно боляче.

2. Те, що ви називаєте "нетрадиційною" структурою, із вмістом, відокремленим від ядра, на певний час було дуже звичайним та надійним вибором для будь-якого серйозного веб-сайту.

3. Немає способів "під ключ" поєднувати стек усіх сайтів із власними оновленнями. Це просто не дуже добре разом, оскільки він намагається досягти різних цілей у проектах різного рівня (розробник у контролі та кінцевий користувач у контролі).

Якщо ви запитаєте мене, найкраща ставка для всього сайту стека WordPress наразі є композитором , проте думки можуть насторожити. :)

Ваші конкретні проблеми:

1. Як зазначено вище - натільні оновлення (тим більше автоматичні) не грають добре з чітко контрольованими стеками.

2. Ядро WordPress не розроблено в Git і не приймає запити на тягнення, усі внески (поки що) проводяться через патч-файли до Subversion.

3. Вам, ймовірно, доведеться ввести такі плагіни у вашу репо. Або піти з іншим підходом, як композитор.

Ви можете поглянути на цю проблему та цю проблему.

Також перегляньте також файли README у кожному репо-файлі:

• markjaquith / WordPress-Skeleton
• davidwinter / wordpress-with-git

На основі вищезгаданих репостів, як ще один приклад налаштування Git / WP, я створив це . Я вирішив використовувати символьні посилання для тем (я намагаюсь висвітлити це у своєму README ).

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

Варто зазначити, що якщо WP бачить .gitна шляху (іх), він автоматично вимикає автоматичні оновлення. Для отримання додаткової інформації див:

• Автоматичні оновлення Core, оновлення

Для того, щоб автоматичні оновлення були включені, є кілька простих вимог:

• Якщо для встановлення використовується FTP для оновлень (і запитів на отримання облікових даних), автоматичні оновлення вимкнено
• Якщо установка працює у форматі SVN або GIT, автоматичні оновлення вимкнено
• Якщо константи DISALLOW_FILE_MODSабо AUTOMATIC_UPDATER_DISABLEDвизначені, автоматичне оновлення вимкнено
• Якщо константа WP_AUTO_UPDATE_COREвизначена як помилкова, автоматичні оновлення відключаються
• Ваша установка WordPress також повинна мати можливість зв’язуватися з WordPress.org через HTTPS-з'єднання, тому ваша установка PHP також потребує OpenSSLвстановлення та роботи
• Wp-Cron має бути функціонувати, якщо з якихось причин cron не працює для вашої установки, автоматичні оновлення також будуть недоступні

Інші пов'язані посилання:

• Автоматичне оновлення WP 3.7
• Розробка теми підмодуля GitHub?
• Встановлення та керування WordPress за допомогою Git

Оновлення травня 2015 року

Я створив це репо, що є швидким способом для початку проектів WordPress. Мій останній підхід полягає в тому, щоб лише контролювати версію теми (-ів). Іншими словами, я встановлюю WP локально (використовуючи налаштування у вищезгаданому репо) та на виробництві, потім змінюю конфігураційний файл у кожній системі та gitтягну мої теми (теми), щоб отримати функціональний сайт.

Цей тип розробок підпадає під "не так просто і вимагає спеціального робочого процесу, який може зайняти довгий час".

Я знаходжу Subtrees, субмодулі або вкладені repos, величезний біль у попці.

Деякі думки (простежити все).

1. Увімкніть автоматичні оновлення за допомогою git / svn за допомогою:
   add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' );

Безпечний метод через ручні зобов’язання + електронна пошта:

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

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

Мінус: копіювання / вставлення папок, управління.

Автоматичний метод

Налаштуйте сценарій збірки (Phing, Ant, Bash, Capistrano тощо) та якийсь спеціальний код, який зробить git add + fix при застосуванні оновлення та надішле його на живий сервер. Ви також можете відокремити плагіни / тематичні репозиції, а потім скомпілювати сценарій / перемістити / що завгодно, та / або використовувати Composer у суміші.

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

Мінус: негнучка, потрібен час для створення.

Git не слід використовувати для резервного копіювання, і взагалі кажучи, вам не потрібно клонувати історію фіксації WP.

Ще раз задумавшись, оскільки я, безумовно, хочу скористатись власними оновленнями WP, щоб заощадити роботу нігтів, не має сенсу відслідковувати нічого, що WP оновлюватиме за допомогою git. Ось переглянута ідея.

root (main project repo)
|-- wordpress (ignored/untracked)
|    |-- wp-content 
|    |    |-- plugins
|    |    |    |-- my-custom-plugin (git repo not connected to parent)
|    |    |    |-- other-plugin (ignored/untracked)
|    |    |    +-- modified-plugin (unignored, added to main project repo)
|    |    |-- themes
|    |    |    |-- my-custom-theme (git repo not connected to parent)
|    |    |    |-- other-theme (ignored/untracked)
|    |    |    +-- modified-theme (unignored, added to main project repo)
|    |    +-- uploads (ignored/untracked)
|    |-- wp-admin
|    +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt

Звичайно, тоді я втрачаю можливість відстежувати, які плагіни та теми є частиною проекту всередині VCS, але мені це дійсно потрібно лише для цілей резервного копіювання, і я все одно буду використовувати якусь звичайну систему резервного копіювання.

Отже, єдиного, чого мені дійсно не вистачає, - це можливість легко розгортати весь стек на різних серверах, не використовуючи FTP для копіювання всієї справи вручну. У когось є думки з цього приводу?

Гаразд, спостерігаючи, як Марк Джакіт тут розмовляє , можливо, я не на тому шляху. Ось ще одна коляшка на ньому, яка відстежує все.

   root (main project repo)
    |-- wordpress (repo as subtree)
    |-- wp-config.php (ignored/untracked)
    |-- wp-content 
    |    |-- plugins
    |    |    |-- my-custom-plugin (repo as subtree)
    |    |    |-- other-plugin-with-git-repo (repo as subtree)
    |    |    +-- plugin-without-git-repo
    |    |-- themes
    |    |    |-- my-custom-theme (repo as subtree)
    |    |    |-- other-theme-with-git-repo (repo as subtree)
    |    |    +-- theme-without-git-repo
    |    +-- uploads (ignored/untracked)
    +-- other-files.txt

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