Vous avez publié une nouvelle version de votre extension sur GitHub, mais vos utilisateurs restent bloqués sur l'ancienne. Télécharger des ZIP manuellement, les téléverser via l'interface d'administration, vérifier la compatibilité: des tâches routinières qui consomment du temps et génèrent des erreurs.

Le mécanisme de mise à jour standard de WordPress est lié au répertoire officiel WordPress.org. Mais toutes les extensions n'y aboutissent pas: solutions client sur mesure, outils internes d'équipe, forks d'extensions populaires avec modifications. Celles-ci nécessitent un chemin différent.

Heureusement, la distribution de mises à jour directement depuis GitHub a été résolue depuis longtemps. Voici deux méthodes opérationnelles: une simple (l'extension Git Updater, en quelques clics) et une avancée (une classe PHP intégrée pour un contrôle total).

💡 Aperçu rapide:

• Installez Git Updater: il détecte les releases GitHub comme des mises à jour WordPress classiques
• Pour les dépôts privés, configurez un jeton d'accès dans les paramètres de l'extension
• Si vous développez votre propre extension et souhaitez y intégrer les mises à jour automatiques: utilisez la classe PHP intégrée
• Le dépôt doit contenir un en-tête d'extension valide et un tag de version

Méthode 1: Git Updater, des mises à jour en deux clics

Git Updater est une extension gratuite qui ajoute la prise en charge de GitHub, Bitbucket, GitLab et Gitea à l'écran standard des mises à jour de WordPress. Après installation, les extensions et thèmes provenant de GitHub se mettent à jour au même endroit que les autres: Tableau de bord → Mises à jour.

Le développeur Andy Fragen maintient le projet depuis 2015. La page GitHub de Git Updater compte plus de 400 étoiles et un dépôt actif avec des commits réguliers. La base de connaissances sur git-updater.com couvre l'installation, la configuration des jetons et l'utilisation de l'API.

L'installation est simple: téléchargez le ZIP depuis la release GitHub, téléversez-le via Extensions → Ajouter → Téléverser une extension, puis activez-le. L'extension commence immédiatement à suivre les dépôts spécifiés dans les en-têtes des extensions et thèmes installés.

Pour les dépôts privés, vous aurez besoin d'un jeton. Créez un jeton d'accès personnel dans GitHub Settings → Developer settings → Tokens (permissions: repo pour le privé; aucun jeton nécessaire pour le public), collez-le dans Réglages → Git Updater. Ensuite, l'extension pourra voir même les dépôts fermés.

Un détail important: Git Updater vérifie la présence de tags au format X.Y.Z (versionnement sémantique) dans le dépôt. S'il n'y a pas de tags, la mise à jour ne fonctionnera pas. Avant de publier, définissez toujours un tag: git tag 1.2.0 && git push --tags.

Méthode 2: classe PHP intégrée pour les développeurs

Si vous êtes l'auteur d'une extension et souhaitez intégrer le mécanisme de mise à jour automatique directement dans votre code (sans extension intermédiaire séparée), l'approche classique par classe PHP fonctionne toujours. Elle est plus légère que la classe originale de Joachim Kudish et radishconcepts et utilise les hooks natifs de WordPress.

Ajoutez le code suivant au fichier principal de votre extension ou à un fichier updater.php séparé inclus via 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');

Le code fait exactement trois choses: il interroge l'API GitHub pour obtenir la dernière release, compare la version du tag_name avec la version actuelle de l'extension, et si GitHub en a une plus récente, il l'enregistre comme mise à jour dans le mécanisme standard de WordPress. La version de l'extension est extraite de l'en-tête standard Version: X.Y.Z du fichier principal.

Remarque: pour les dépôts publics, aucun jeton n'est nécessaire, mais l'API GitHub sans jeton limite la fréquence des requêtes à 60 par heure et par IP. Pour une extension en production avec de nombreux utilisateurs, ajoutez une mise en cache des résultats via set_transient() pour 6 à 12 heures. Ainsi, vous n'atteindrez pas la limite à chaque fois que quelqu'un visite la page des extensions.

Comparaison des approches

Conclusion: si vous installez l'extension GitHub de quelqu'un d'autre sur un site, utilisez Git Updater. Si vous êtes l'auteur d'une extension que vous distribuez via GitHub, intégrez les mises à jour automatiques dans le code pour que les utilisateurs n'aient pas à installer d'extension supplémentaire.

Préparer le dépôt pour les mises à jour automatiques

Quelle que soit la méthode choisie, le dépôt GitHub doit être correctement préparé. Trois points obligatoires:

• En-tête de l'extension. Dans le fichier PHP principal, incluez l'en-tête WordPress standard: Plugin Name, Version, Author, et Plugin URI avec un lien vers le dépôt. Git Updater lit Plugin URI et GitHub Plugin URI; spécifiez-en au moins un.

• Tags de version. Accompagnez chaque release d'un tag: git tag 1.3.0 && git push origin 1.3.0. Sans tags, ni Git Updater ni la requête API ne verront la nouvelle version.

• Fichier Readme. Ajoutez un README.md avec une description, un journal des modifications et un lien d'installation. Git Updater affiche le contenu du readme sur l'écran d'information de l'extension, ce qui fait gagner du temps aux utilisateurs qui n'ont pas besoin de visiter GitHub pour les instructions.

Avec GitHub Actions, vous pouvez aller plus loin: lors de l'envoi d'un tag, construire automatiquement le ZIP, générer un journal des modifications à partir des commits et créer une GitHub Release avec l'archive jointe. Un workflow prêt à l'emploi est disponible dans la documentation officielle de GitHub; adaptez-le pour WordPress en remplaçant l'étape de build par la mise en paquet de l'extension.

La vidéo montre le processus complet, de l'installation de Git Updater à la première mise à jour automatique d'une extension. Nous vous recommandons de la regarder avant de vous lancer: 12 minutes d'enregistrement d'écran vous feront gagner une heure d'expérimentation.

⁉️🤔 Foire aux questions

Est-ce que Git Updater fonctionne avec les extensions du répertoire officiel WordPress.org?

Oui, mais cela n'a pas d'intérêt. Les extensions de WordPress.org reçoivent déjà leurs mises à jour via le mécanisme standard. Git Updater est spécifiquement conçu pour les extensions et thèmes qui ne sont pas dans le répertoire: développements sur mesure, forks, extensions en cours de validation.

Peut-on utiliser Git Updater sur un site en production?

Oui, le projet est stable et maintenu depuis 2015. Avant l'installation, faites une sauvegarde complète (comme pour toute nouvelle extension). Sur un site de test, vérifiez la mise à jour d'au moins une extension, assurez-vous que les tags dans le dépôt sont correctement définis et que la mise à jour s'applique sans erreur.

Que se passe-t-il si l'API GitHub atteint la limite de requêtes?

Pour les dépôts publics, la limite est de 60 requêtes par heure depuis une même IP. Git Updater met en cache les réponses pendant 12 heures, donc le problème se produit rarement. Si cela arrive, créez un jeton d'accès personnel gratuit (sans permissions supplémentaires) et ajoutez-le dans Réglages → Git Updater: la limite passe immédiatement à 5000 requêtes par heure.

Que faire si l'extension sur GitHub utilise des dépendances Composer?

Git Updater n'exécute pas composer install pendant les mises à jour. Si votre extension dépend de paquets Composer, intégrez l'autochargement via un bundle (incluez vendor/ dans le ZIP de la release) ou ajoutez un script post-mise à jour qui vérifie les dépendances et avertit l'administrateur si elles sont absentes.

Peut-on mettre à jour des extensions depuis un dépôt privé sur un compte GitHub gratuit?

Oui. Les comptes GitHub gratuits incluent des dépôts privés illimités. Créez un jeton d'accès personnel avec la permission repo, ajoutez-le à Git Updater, et l'extension aura accès à vos dépôts privés.

Mises à jour automatiques depuis GitHub: que choisir en 2026

Pour un propriétaire de site, la réponse est claire: Git Updater. Gratuit, stable, ne nécessite aucun code.

Pour un développeur d'extension, le choix dépend de l'audience. Si votre produit est installé par des utilisateurs ordinaires, intégrez la classe PHP de mise à jour automatique directement dans le code de l'extension. Une extension intermédiaire supplémentaire dans la chaîne réduit la conversion à l'installation. Si le produit s'adresse à un public technique, Git Updater comme dépendance est acceptable; mentionnez-le simplement dans les instructions.

Vérifiez vos extensions GitHub dès maintenant: les tags sont-ils définis sur les dernières releases, l'en-tête Plugin URI est-il renseigné, l'utilisateur dispose-t-il d'un chemin de mise à jour clair? Quinze minutes de configuration vous épargneront, à vous et à vos utilisateurs, la corvée manuelle des archives ZIP pour les années à venir.