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

13

В течение многих месяцев я пытался спланировать хорошую структуру проекта для использования контроля версий 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, если есть лучший форум для этой дискуссии, пожалуйста, укажите мне там.

Джосия Спраг
источник

Ответы:

6

С моей точки зрения, в вашем плане есть две проблемы - Git и «обычная» структура. Так что в основном все. :)

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

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

  3. Практически нет способов «под ключ» объединить весь стек сайта с собственными обновлениями. Это просто не очень хорошо сочетается, так как пытается достичь разных целей в проектах разных уровней (контроль за разработчиком против контроля над конечным пользователем).

Если вы спросите меня, лучшая ставка для всего сайта, стек WordPress в настоящее время является Composer , однако мнения могут быть осторожными. :)

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

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

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

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

Rarst
источник
WordPress не использует Git для разработки, но на github.com/WordPress/WordPress есть зеркало (синхронизируется с SVN каждые 15 минут). Он не предназначен для установки патчей и т. Д. Для этого вам обязательно нужно использовать SVN & Trac. Я не знаю, подойдет ли это для целей ОП или нет, но для полноты картины оно существует.
Пэт Дж
@PatJ хорошая мысль, я вроде бы предполагал, что Q означает использовать это, но, возможно, нет
Rarst
Очень хорошие очки. У меня есть целый стек сайтов с использованием git с подмодулями, и это большая боль в заднице. Думаю, мне интересно, есть ли менее строго контролируемый способ использовать Git, но также использовать нативные обновления, чтобы избавить себя от лишней работы. В настоящий момент я работаю в команде из одного человека, поэтому я просто пытаюсь настроить сайты максимально эффективно.
Джозиа Спраг
@JosiahSprague, если вашей основной проблемой является начальная настройка (а не долгосрочное обслуживание стека), возможно, имеет смысл сосредоточиться на этом с помощью собственной install.phpподпрограммы или чего-то подобного и использовать обычную механику обновления оттуда. Стек Composer может очень хорошо обрабатывать обновления в абстрактном виде, но он зависит от качества используемых вами пакетов и таких вещей, как проксирование официальных репозиториев WP, так как оно еще не вполне готово.
'16
3

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

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

На основании вышеприведенных репозиториев, в качестве другого примера настройки 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 не работает для вашей установки, автоматические обновления также будут недоступны

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

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

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

mhulse
источник
2

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

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

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

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

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

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

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

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

Авто метод

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

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

Недостаток: негибкий, требует времени для создания.

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

Уик
источник
0

После некоторых размышлений, поскольку я определенно хочу воспользоваться преимуществами собственных обновлений 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 для ручного копирования всего этого. У кого-нибудь есть мысли по этому поводу?

Джосия Спраг
источник
0

Хорошо, смотрю выступление Марка Джакита здесь , может быть, я не на том пути. Вот еще один удар, который отслеживает все.

   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

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

Джосия Спраг
источник