Как мне структурировать проект веб-сайта WP с использованием git и обновлений из WP-панели?

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

Вот что я думаю прямо сейчас, с моими мыслями о том, как я буду обращаться с git-репозиториями в скобках.

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 в настоящее время является Composer , однако мнения могут быть осторожными. :)

По вашим конкретным вопросам:

1. Как и выше - нативные обновления (тем более автоматические) не очень хорошо работают с жестко контролируемыми стеками.

2. Ядро WordPress не разработано в Git и не принимает запросы на извлечение, все вклады (пока) через файлы патчей для Subversion.

3. Скорее всего, вам придется добавить такие плагины в репозиторий. Или используйте другой подход, такой как Composer.

Вы можете взглянуть на эту проблему и эту проблему.

Также взгляните на файлы README в каждом репо:

• markjaquith / WordPress-Skeleton
• Дэвидвинтер / WordPress с Git

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

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

Стоит отметить, что если WP видит .gitпути, он автоматически отключает автоматические обновления. Для получения дополнительной информации см .:

• Автоматическое обновление ядра, обновление

Чтобы включить автоматическое обновление, необходимо выполнить несколько простых требований:

• Если установка использует FTP для обновлений (и запрашивает учетные данные), автоматические обновления отключены
• Если установка выполняется как проверка SVN или GIT, автоматические обновления отключены
• Если константы DISALLOW_FILE_MODSили AUTOMATIC_UPDATER_DISABLEDопределены, автоматические обновления отключены
• Если константа WP_AUTO_UPDATE_COREопределена как false, автоматические обновления отключены
• Ваша установка WordPress также должна иметь возможность обращаться к WordPress.org через HTTPS-соединения, поэтому ваша установка PHP также должна быть OpenSSLустановлена ​​и работать
• Wp-Cron должен быть в рабочем состоянии, если по какой-то причине cron не работает для вашей установки, автоматические обновления также будут недоступны

Другие ссылки по теме:

• WP 3.7 автообновление
• Разработка темы субмодуля GitHub?
• Установите и управляйте WordPress с помощью Git

Май 2015 обновление

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

Этот тип разработки относится к категории «не так просто и требует специального рабочего процесса, который может занять много времени, чтобы быть довольным».

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

Некоторые мысли (отслеживать все).

1. Включите автоматическое обновление с помощью git / svn, используя:
   add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' );

Безопасный метод через ручные коммиты + электронная почта:

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

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

Недостаток: копирование / вставка папок, управление.

Авто метод

Установите скрипт сборки (Phing, Ant, Bash, Capistrano и т. Д.) И некоторый пользовательский код, который будет выполнять git add + commit при применении обновления и отправлять его на работающий сервер. Вы также можете разделить плагины / репозитории тем, а затем заставить скрипт скомпилировать / переместить / что угодно их, и / или использовать 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

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