Ви випустили нову версію плагіна на 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-архівами на роки вперед.