Вы выпустили новую версию плагина на GitHub, а пользователи сидят на старой. Скачивать ZIP руками, заливать через админку, проверять совместимость, рутина, которая съедает время и плодит ошибки.

Обычный механизм обновлений WordPress завязан на официальный каталог WordPress.org. Но не каждый плагин туда попадает: кастомные решения под клиента, внутренние инструменты команды, форки популярных плагинов с доработками. Для них нужен другой путь.

К счастью, доставка обновлений напрямую из GitHub давно решена. Ниже, два работающих способа: простой (плагин Git Updater, пара кликов) и продвинутый (встроенный PHP-класс для полного контроля).

💡 Быстрый обзор:

• Установите Git Updater: он подхватывает GitHub-релизы как обычные обновления WordPress
• Для частных репозиториев настройте токен доступа в настройках плагина
• Если пишете свой плагин и хотите встроить автообновления в код: используйте встроенный PHP-класс
• Репозиторий должен содержать корректный заголовок плагина и версионный тег

Способ 1: Git Updater, обновления в два клика

Git Updater, бесплатный плагин, который добавляет поддержку GitHub, Bitbucket, GitLab и Gitea в стандартный экран обновлений WordPress. После установки плагины и темы с GitHub обновляются там же, где и обычные, в разделе Dashboard → Updates.

Разработчик Andy Fragen поддерживает проект с 2015 года. На странице Git Updater на GitHub, больше 400 звёзд и активный репозиторий с регулярными коммитами. База знаний на git-updater.com описывает установку, настройку токенов и работу с API.

Установка простая: скачайте ZIP с релиза на GitHub, залейте через Plugins → Add New → Upload Plugin, активируйте. Плагин сразу начинает отслеживать репозитории, указанные в заголовках установленных плагинов и тем.

Для приватных репозиториев понадобится токен. Создайте Personal Access Token в GitHub Settings → Developer settings → Tokens (права: repo для приватных, для публичных токен не нужен), вставьте в Settings → Git Updater. После этого плагин видит даже закрытые репозитории.

Важный нюанс: Git Updater проверяет наличие тегов формата X.Y.Z (семантическое версионирование) в репозитории. Если тегов нет, обновление не сработает. Перед выпуском релиза всегда ставьте тег: git tag 1.2.0 && git push --tags.

Способ 2: встроенный PHP-класс для разработчиков

Если вы автор плагина и хотите встроить механизм автообновлений прямо в код (без отдельного плагина-посредника), классический подход с PHP-классом до сих пор работает. Он легче исходного класса от Joachim Kudish и radishconcepts и использует нативные хуки WordPress.

Добавьте следующий код в главный файл вашего плагина или в отдельный файл updater.php, подключённый через require_once:

1
/**
2
 * Auto-update from GitHub releases.
3
 * Place in main plugin file or include via require_once.
4
 */
5
function myplugin_check_github_update($transient) {
6
    if (empty($transient->checked)) {
7
        return $transient;
8
    }
9
 
10
    $plugin_slug = 'my-plugin/my-plugin.php';
11
    $github_repo = 'username/my-plugin';
12
 
13
    $response = wp_remote_get(
14
        'https://api.github.com/repos/' . $github_repo . '/releases/latest',
15
        array(
16
            'headers' => array(
17
                'Accept' => 'application/vnd.github.v3+json',
18
                'User-Agent' => 'WordPress/' . get_bloginfo('version'),
19
            ),
20
        )
21
    );
22
 
23
    if (is_wp_error($response) || wp_remote_retrieve_response_code($response) !== 200) {
24
        return $transient;
25
    }
26
 
27
    $release = json_decode(wp_remote_retrieve_body($response));
28
 
29
    if (!isset($release->tag_name)) {
30
        return $transient;
31
    }
32
 
33
    $latest_version = ltrim($release->tag_name, 'v');
34
    $current_version = $transient->checked[$plugin_slug] ?? '0';
35
 
36
    if (version_compare($latest_version, $current_version, '>')) {
37
        $transient->response[$plugin_slug] = (object) array(
38
            'slug'        => dirname($plugin_slug),
39
            'new_version' => $latest_version,
40
            'url'         => 'https://github.com/' . $github_repo,
41
            'package'     => $release->zipball_url,
42
        );
43
    }
44
 
45
    return $transient;
46
}
47
add_filter('pre_set_site_transient_update_plugins', 'myplugin_check_github_update');

Код делает ровно три вещи: стучится в GitHub API за последним релизом, сравнивает версию из tag_name с текущей версией плагина и, если на GitHub новее, регистрирует обновление в стандартном механизме WordPress. Версия плагина берётся из стандартного заголовка Version: X.Y.Z в главном файле.

Обратите внимание: для публичных репозиториев токен не нужен, но GitHub API без токена ограничивает частоту запросов до 60 в час на IP. Для production-плагина с большим числом пользователей добавьте кэширование результата через set_transient() на 6-12 часов. Так вы не упрётесь в лимит при каждом заходе на страницу плагинов.

Сравнение подходов

Вывод: если вы ставите чей-то GitHub-плагин на сайт, берите Git Updater. Если вы автор плагина и распространяете его через GitHub, встройте автообновления в код, чтобы пользователю не пришлось ставить дополнительный плагин.

Настройка репозитория для автообновлений

Какой бы способ вы ни выбрали, GitHub-репозиторий должен быть подготовлен правильно. Три обязательных пункта:

• Заголовок плагина. В главном PHP-файле пропишите стандартный WordPress-заголовок: Plugin Name, Version, Author и Plugin URI со ссылкой на репозиторий. Git Updater читает Plugin URI и GitHub Plugin URI, укажите хотя бы один.

• Теги версий. Каждый релиз сопровождайте тегом: git tag 1.3.0 && git push origin 1.3.0. Без тегов ни Git Updater, ни API-запрос не увидят новую версию.

• Файл Readme. Добавьте README.md с описанием, списком изменений (changelog) и ссылкой на установку. Git Updater показывает содержимое readme на экране информации о плагине, это экономит время пользователя, которому не нужно идти на GitHub за инструкцией.

С GitHub Actions можно пойти ещё дальше: при пуше тега автоматически собирать ZIP, генерировать changelog из коммитов и создавать GitHub Release с прикреплённым архивом. Готовый workflow есть в официальной документации GitHub, адаптируйте под WordPress, заменив шаг сборки на упаковку плагина.

На видео, полный процесс от установки Git Updater до первого автоматического обновления плагина. Рекомендуем посмотреть перед настройкой: 12 минут экрана сэкономят час экспериментов.

⁉️🤔 Частые вопросы

Работает ли Git Updater с плагинами из официального каталога WordPress.org?

Да, но в этом нет смысла. Плагины с WordPress.org уже получают обновления через стандартный механизм. Git Updater нужен именно для тех плагинов и тем, которых нет в каталоге, кастомные разработки, форки, плагины в процессе ревью.

Можно ли использовать Git Updater на продакшен-сайте?

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

Как быть, если GitHub API упирается в лимит запросов?

Для публичных репозиториев лимит, 60 запросов в час с одного IP. Git Updater кэширует ответы на 12 часов, поэтому проблема возникает редко. Если появилась, создайте бесплатный Personal Access Token (без дополнительных прав) и добавьте в Settings → Git Updater: лимит сразу поднимается до 5000 запросов в час.

Что делать, если плагин на GitHub использует Composer-зависимости?

Git Updater не запускает composer install при обновлении. Если ваш плагин зависит от Composer-пакетов, встройте автозагрузку через бандл (упакуйте vendor/ в ZIP релиза) либо добавьте скрипт пост-обновления, который проверяет наличие зависимостей и предупреждает администратора при их отсутствии.

Можно ли обновлять плагины из приватного репозитория на бесплатном GitHub?

Да. Бесплатные аккаунты GitHub включают неограниченное число приватных репозиториев. Создайте Personal Access Token с правом repo, добавьте в Git Updater, плагин получит доступ к вашим приватным репозиториям.

Автообновления из GitHub: что ставить в 2026 году

Для владельца сайта ответ однозначный, Git Updater. Бесплатно, стабильно, не требует кода.

Для разработчика плагина выбор зависит от аудитории. Если ваш продукт устанавливают обычные пользователи, встройте PHP-класс автообновления прямо в код плагина. Лишний плагин-посредник в цепочке снижает конверсию установок. Если продукт для технической аудитории, Git Updater в зависимостях допустим, просто укажите это в инструкции.

Проверьте свои GitHub-плагины прямо сейчас: стоят ли теги на последних релизах, заполнен ли Plugin URI в заголовке, есть ли у пользователя понятный путь обновления? Пятнадцать минут на настройку избавят вас и ваших пользователей от ручной возни с ZIP-архивами на годы вперёд.