Gitium — плагин для автоматического контроля версий Git и эффективного развертывания тем и плагинов в проектах

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

Работает это просто: вся директория wp-content/plugins синхронизируется с репозиторием, без участия FTP или панели хостинга. Никаких архивов, никаких ручных замен. Изменения фиксируются в коммитах, каждый из которых можно отследить, откатить или сверить с предыдущим.

Внимание! Локальные правки напрямую через редактор WordPress не сохраняются, если они не закоммичены – они исчезнут при следующем пуше.

Подключение возможно только при наличии репозитория, поддерживающего вебхуки и работу по SSH или HTTPS. Поддерживаются GitHub, GitLab, Bitbucket. При этом синхронизация работает только в одну сторону: с сервера в хранилище.

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


.gitignore:
!wp-content/plugins/my-custom-plugin/
wp-content/themes/
wp-content/uploads/**


Все операции происходят автоматически после каждого коммита в основной ветке. Можно выставить фильтрацию по тегам, веткам или определённым путям. Возможна интеграция с CI-системами через вебхуки. Но важно: структура проекта должна полностью совпадать с файловой системой сервера, иначе произойдёт частичная загрузка или конфликт данных.

Важно помнить: если включён кэш плагинов через объектное хранилище (Redis, Memcached), потребуется его сброс после каждого обновления.

Для тестирования и отката изменений рекомендуется использовать отдельную среду с аналогичной конфигурацией. Логируются все коммиты, а также IP-адрес, с которого произошёл пуш. Можно отследить, кто, когда и зачем внёс конкретную правку.

Нужна полная автоматизация? Используйте скрипт с хуком post-receive на стороне Git-сервера:


#!/bin/sh
GIT_WORK_TREE=/var/www/html git checkout -f


Жёстко. Чётко. Подконтрольно. Без ручного вмешательства. WordPress работает так, как вы ему скажете. И никак иначе.

Готовы перейти от хаоса к порядку? Не забудьте – одна лишняя загрузка ZIP-файла может стереть часы работы.

Настройка репозитория Git для интеграции с Gitium в WordPress

Создавайте удалённый репозиторий заранее. Поддерживается только SSH или HTTPS. На практике – лучше SSH: меньше возни с токенами. Подойдёт GitHub, GitLab, Bitbucket, любой, где можно задать ключи доступа.

Папка темы или расширения должна быть отдельным репозиторием. Не корень сайта. Не wp-content. Только конкретная директория, например wp-content/themes/my-theme или wp-content/mu-plugins/custom-functions.

Загрузите содержимое этой папки в новый репозиторий:

cd wp-content/themes/my-theme
git init
git remote add origin git@github.com:yourname/my-theme.git
git add .
git commit -m \"Initial commit\"
git push -u origin master

Хаос начнётся, если в корне проекта окажется .git и вы попытаетесь использовать его. Репозиторий должен быть локализован строго в рабочей папке.

Проверьте .gitignore. Не игнорируйте файлы, которые реально нужны в рабочем процессе: style.css, functions.php, plugin.php. Игнорируйте node_modules, vendor, если используете Composer или npm.

Важно! Любые изменения в директории, не отслеживаемой Git, не будут отображаться. Работайте строго в пределах репозитория!

Настройте публичный ключ SSH. Убедитесь, что сервер WordPress имеет доступ к репозиторию. На хостингах с ограничениями доступа добавляйте ключ в ~/.ssh/authorized_keys или через интерфейс Git-сервиса.

cat ~/.ssh/id_rsa.pub

Добавьте содержимое в настройки удалённого хранилища. Без этого соединения не будет. Подключения по HTTPS чаще ломаются: капча, токены, 2FA. SSH – стабильней.

Проверьте доступность:

ssh -T git@github.com

Внимание! Если команда возвращает ошибку доступа – не тратьте время, проверьте файл known_hosts и сам ключ. Проблема не в WordPress!

Добавьте .git в корень нужной директории, но не затрагивайте другие папки сайта. Один каталог – один репозиторий. Не объединяйте несколько плагинов в один. Не пытайтесь трекать wp-content целиком – бессмысленно.

В завершении – убедитесь, что HEAD смотрит на нужную ветку:

git branch --show-current

Ошиблись веткой – конфликт неизбежен. Не надейтесь на автослияние. WordPress просто перестаёт загружать файлы, и вы теряете доступ.

Автоматическое обновление плагинов через коммиты в Git

Настройте хук post-receive на стороне удалённого репозитория. Именно он будет триггерить обновление содержимого на сервере после каждого коммита.

Пример простого хука, который клонирует изменения в директорию расширений WordPress:


#!/bin/sh
GIT_WORK_TREE=/var/www/html/wp-content/plugins/my-plugin git checkout -f


Такой подход подойдёт только при наличии полного доступа к хостингу и прав на выполнение shell-скриптов. Ограничения PHP-хостинга делают этот путь недоступным.

Нужен механизм синхронизации кода без ручного доступа? Используйте Webhook и REST API WordPress. Это обходной путь, но работает в условиях ограниченного окружения.

Создайте пользовательский REST endpoint:


add_action(\'rest_api_init\', function() {
  register_rest_route(\'deploy/v1\', \'/update/\', array(
    \'methods\' => \'POST\',
    \'callback\' => \'deploy_plugin_code\',
    \'permission_callback\' => \'__return_true\'
  ));
});

function deploy_plugin_code() {
  shell_exec(\'cd /var/www/html/wp-content/plugins/my-plugin && git pull\');
  return new WP_REST_Response(\'Updated\', 200);
}


Не забудьте настроить защиту запроса. Используйте токен или IP-фильтрацию. REST-эндпоинт без аутентификации – дыра в безопасности.

Внимание! Не вызывайте git pull в корневой директории WordPress. Это может повредить файлы ядра и .htaccess.

Для автоматического обновления на каждое изменение в git добавьте Webhook в настройках репозитория, направленный на URL вышеуказанного REST-эндпоинта. GitLab, GitHub, Bitbucket – неважно, механизм идентичен.

Часто забывают: права на запись у пользователя сервера. Без этого git pull не выполнится. Никакие красивые хуки не помогут, если у Apache нет доступа к директории расширений.

Важно помнить: при каждом pull WordPress не очищает кэш, особенно если используется object caching. Применяйте wp cache flush после обновления.

Не подключайте автоматическое обновление без тестовой среды. Никогда. Каждый коммит должен сначала отработать в staging, затем попадать на production. Один синтаксический баг – и сайт уходит в 500.

Хочешь автоматику? Готовься к полной ответственности.

Обработка конфликтов при одновременном редактировании файлов в Git и WordPress

Сначала запретите автоматические коммиты с сервера. Всегда. Не давайте WordPress права коммитить без ручной проверки. Это не CMS, это мина.

Конфликт возникает, когда разработчик меняет шаблон в ветке, а контент-редактор правит тот же файл через редактор тем. Самая частая ошибка – игнорировать дату последнего коммита. Проверяйте таймстемпы. Не верьте глазам – смотрите лог.

Рекомендуется вынести критичные файлы в .gitignore, если они подвержены частому редактированию через админку. Например:


wp-content/themes/mytheme/style.css
wp-content/themes/mytheme/functions.php


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

Если конфликт уже произошёл: не мержите через UI. Только CLI. Используйте команду:


git mergetool


Только вручную, только осознанно. Не доверяйте автомержу, особенно в PHP. Один неосторожный пробел – и вы смотрите на белый экран.

Важно анализировать различия через git diff и сравнивать с действующей версией сайта, не с HEAD. Потому что WordPress не думает, он пишет.

Важно! WordPress может перезаписать файл без предупреждения при активации темы или сохранении настроек.

Используйте отдельные ветки для правок через админку, если такие вообще допустимы. Желательно – запретить такие правки на продакшене. Пусть staging горит, но не production.

В случае, если frontend перестал отображаться, проверьте wp-config.php на наличие отладочных параметров. Включите:


define(\'WP_DEBUG\', true);
define(\'WP_DEBUG_LOG\', true);


И сразу читайте wp-content/debug.log. Не гадайте. Ошибки PHP не любят интуицию.

Если используется кастомный плагин с ручным коммитом, ставьте аннотации в комментарии:




Без этих тегов ад вообще не понять. Git ничего не знает о бизнес-логике WordPress.

Помните! Никогда не объединяйте ветки вслепую, если хотя бы один файл редактировался через редактор WordPress.

Итог: автоматизация спасает от рутинных ошибок, но при конфликте помогает только ручной разбор. Git не волшебник. WordPress – тем более. Только холодный расчёт.