club762.ruВ части 2 серии статей мы рассмотрели то, как использовать Composer для управления темами и плагинами в WordPress. В данной статье мы познакомимся с альтернативным способом управления темами и плагинами, который не требует никаких сторонних инструментов.
Небольшая выдержка из документации к подмодулям Git:
«Подмодули (Submodules) позволяют вам поддерживать Git репозиторий в виде подкаталога другого Git-репозитория. Вы можете клонировать другой репозиторий в своем проекте и тем самым отделить ваши коммиты»
Подмодули могут оказаться очень полезными, если вы хотите сохранить стороннюю библиотеку в своем проекте, поддерживая репозитории обособленными в Git. В нашем случае мы хотим сохранить темы и плагины в том же самом репозитории Git, что и наша сборка WordPress из первой статьи. Подмодули Git – это эквивалент «externals» в Subversion.
Добавляем подмодули Git
К счастью, весь Subversion репозиторий WordPress-плагинов отзеркален на GitHub, что упрощает поиск Git-версий любого wordpress.org плагина. Однако, увы, для тем зеркала нет, поэтому вам нужно будет искать их самостоятельно.
Давайте создадим Github зеркало нашего плагина WP Migrate DB. Процесс добавления подмодулей к вашему Git репозиторию достаточно прост. Выполняем следующую команду из корня вашего Git репозитория:
git submodule add -f https://github.com/wp-plugins/wp-migrate-db.git ./wp-content/plugins/wp-migrate-db
Тем самым мы добавим подмодуль к нашему Git репозиторию и скачаем все необходимые файлы. Здесь мы используем зеркало GitHub в качестве URL нашего репозитория, однако стоит отметить, что вы можете использовать URL любого Git репозитория (к примеру, приватного). Мы использовали здесь -f, чтобы заставить Git добавить подмодуль, в противном случае он будет жаловаться на то, что папка игнорируется (см. gitignore в первой части). Коммитим этим изменения при помощи команды:
git commit -m "Added WP Migrate DB plugin"
Теперь мы имеем установленный плагин WP Migrate DB, и мы можем активировать его и использовать в своей сборке. Для добавления тем процесс полностью идентичен – убедитесь лишь в том, что вы устанавливаете их в директорию themes.
Обновление Git подмодулей
К несчастью, обновление Git подмодулей не настолько простое, как вы могли бы это себе представить. Это один из недостатков использования подмодулей Git. Структура подмодулей Git действительно упрощает коммит изменений в ваших репозиториях, поскольку вы можете редактировать файлы подмодуля, как и в случае с любым другим Git репозиторием. Однако для обновления подмодуля до последней версии (что мы и хотим сделать в случае с нашими WordPress-плагинами) вам придется перейти к папке подмодуля, проверить последнюю версию, затем закоммитить эти изменения обратно в основной репозиторий. Команда для этого будет следующей:
cd wp-content/plugins/wp-migrate-db git checkout master git pull cd ../../.. git commit -am "Updated WP Migrate DB"
Есть также и достаточно простое решение в одну строку, которое позволит вам сохранить время, особенно если вы имеете многочисленные подмодули плагинов:
git submodule foreach git pull origin master
Как быть, если вы хотите использовать определенную версию плагина? Вы можете реализовать это с помощью проверки тега, соответствующего необходимой версии:
cd wp-content/plugins/wp-migrate-db git checkout tags/0.7.1 cd ../../.. git commit -am "Updated WP Migrate DB to v0.7.1"
Удаление подмодулей Git
Как и в случае с обновлениями, удаление подмодулей Git является не такой уж простой задачей, но все же проще, чем при обновлениях. Чтобы удалить подмодуль плагина, нам нужно будет выполнить команду:
git submodule deinit wp-content/plugins/wp-migrate-db git rm wp-content/plugins/wp-migrate-db git commit -am "Removed WP Migrate DB"
Папка плагина должна быть полностью удалена из вашего репозитория, и .gitmodules должен быть обновлен, чтобы отразить это изменение.
Развертывания
Как и в случае с Composer, вам нужно будет найти способ поддержания в актуальном виде ваших подмодулей на вашем продакшн-сервере (или на любых других серверах, где вы производите развертывание). Стратегии развертывания выходят за рамки данной статье, однако давайте на минуту предположим, что на вашем продакшн-сервере установлен post-receive хук Git. Хук post-receive – это обычный скрипт, который будет выполняться после всех действий. Один из способов автоматического обновления ваших подмодулей – это добавление следующих команд к хуку post-receive:
git submodule init git submodule sync git submodule update
Эти команды гарантируют, что ваши подмодули Git будут обновляться всякий раз, как только вы делаете push к вашему продакшн-репозиторию. Команда submodule sync просто обновляет ваш локальный конфиг подмодуля, добавляя к нему все изменения.
Произвольные темы и плагины
Процесс установки произвольных тем и плагинов практически идентичен тому процессу, который был описан в статье 2, поэтому я не буду возвращаться к нему снова. Достаточно сказать, что вы можете легко сохранять ваши произвольные темы/плагины вместе с вашими подмодулями в Git-репозитории.
Какой способ предпочесть?
Что именно использовать: Composer, Git подмодули или что-то совсем другое (к примеру, WP-CLI) для управления темами и плагинами? Все зависит от требований вашего проекта. Composer великолепно подходит для тех, кому нужно что-то очень простое и кто не возражает против SSH-подключения к своему серверу. Подмодули прекрасны, если вы разрабатываете плагины в WordPress и вам нужно закоммитить ваши изменения обратно в ваш репозиторий (то, что не получится сделать с помощью Composer). Оба подхода имеют свои плюсы и минусы.
Источник: deliciousbrains.com
