Intereting Posts
Перечислите суб-таксономии из текущей таксономии Запросить все сообщения, где значение мета пусто Является ли страница 404 той же, что и страница «хорошо, это неловкое»? Несколько конечных точек на одной странице Пользовательский WP_Query для текущей категории (в категории.php)? Как настроить заголовок, передав строку запроса? Разбитая разметка при использовании the_excerpt () в виджетах? Почему WP_Query :: is_date () возвращает false, когда установлен параметр date_query? JQuery в детской теме WordPress популярные сообщения по недельному коду В каком файле я запускаю задание cron, чтобы чаще обновлять новостную ленту Twitter? Как сделать регистр Meta Query чувствительным? После изменения корневого сайта, как это отразить для wp-admin? WordPage Pagination не работает – всегда показывает содержимое первых страниц Как я могу установить сценарий комментариев и ответов только на определенной странице?

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

В течение нескольких месяцев я пытался спланировать хорошую структуру проекта для использования git-версии для разработки веб-сайта WordPress, которая не жертвует возможностью обновления ядра и плагинов через панель инструментов WP, не требует нетрадиционной структуры каталогов (wp -content за пределами родительской папки 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 и не принимает запросы на pull, все взносы (до сих пор) через файлы патчей в Subversion.

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

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

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

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

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

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

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

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

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

Автоматический метод

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

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

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

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

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

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

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

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

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

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

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

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

  • Если установка использует 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 вытягиваю мою тему (ы), чтобы получить функциональный сайт.

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

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