Le WordPress d'aujourd'hui, décodé pour les développeurs

Tips

Masquer le numéro de version d’une extension interne dans les notices

wp plugin list révélait un numéro de version de développement destiné à rester confidentiel. Un filtre sur le transient des mises à jour supprime la notice qui l'affichait, sans toucher au cœur WordPress.

Par Clément Hadrot • 30 avril 2026 • 4 min de lecture • Aucun commentaire
Masquer le numéro de version d'une extension interne dans les notices

wp plugin list --status=active : cette commande WP-CLI, exécutée par un client curieux disposant d’un accès limité à l’hébergement mutualisé de son site, a révélé un numéro de version explicite d’une extension maison développée par son agence, un numéro qui suivait un schéma interne de nommage encore en phase de développement (2.4.0-beta-interne). Rien de grave en soi, mais une information que l’agence préférait garder pour son propre suivi de projet plutôt que de l’exposer, même à un client de confiance.

Le problème ne venait pas de la commande elle-même, disponible pour quiconque a un accès en ligne de commande au serveur, mais d’une notice d’administration classique de WordPress, qui comparait la version installée à une version plus récente déclarée dans un dépôt de test, et affichait ce numéro en toutes lettres dans l’écran des extensions. Un simple filtre sur le transient des mises à jour a suffi à corriger ce point.

Comprendre d’où vient la notice

WordPress stocke dans le transient update_plugins la liste des extensions pour lesquelles une mise à jour est disponible, en interrogeant chaque source déclarée dans l’en-tête Update URI de l’extension. Pour une extension interne encore en développement actif, une telle notice n’a aucune utilité pour le client final, elle ne fait que révéler un numéro de version qui ne le concerne pas.

/**
 * Plugin Name: Outil interne agence
 * Version: 2.4.0-beta-interne
 * Update URI: https://depot-interne.exemple/outil-agence
 */
L'essentiel à retenir : Le transient des mises à jour de plugins peut être filtré extension par extension ; La suppression cible uniquement les extensions maison identifiées par leur préfixe ; Aucun effet sur les mises à jour des extensions tierces légitimes

Retirer l’extension interne du calcul des mises à jour

Le filtre site_transient_update_plugins permet d’intervenir juste avant que WordPress n’affiche sa notice, en supprimant l’entrée correspondant à l’extension interne du tableau des mises à jour disponibles. L’extension continue de fonctionner normalement, seule la notice disparaît.

add_filter( 'site_transient_update_plugins', function ( $transient ) {
    if ( empty( $transient->response ) ) {
        return $transient;
    }

    foreach ( $transient->response as $chemin_extension => $donnees ) {
        if ( 0 === strpos( $chemin_extension, 'outil-interne-agence/' ) ) {
            unset( $transient->response[ $chemin_extension ] );
        }
    }

    return $transient;
} );

Cette vérification par préfixe de chemin garantit que seules les extensions développées en interne par l’agence, toutes nommées selon une convention commune, sont concernées par ce filtre. Aucune extension tierce installée sur le site ne perd sa notice de mise à jour légitime.

Ne pas confondre masquer la notice et bloquer la mise à jour

Ce filtre agit uniquement sur l’affichage : il ne bloque en rien la possibilité, pour l’agence elle-même, de déployer une nouvelle version de l’extension par un autre moyen, par exemple une commande WP-CLI exécutée directement depuis son propre accès au serveur, en dehors de tout mécanisme automatique de vérification.

wp plugin install /chemin/vers/outil-interne-agence-2.5.0.zip --force

Séparer l’affichage de la notice du mécanisme de mise à jour lui-même évite une confusion fréquente : masquer une notice ne doit jamais empêcher une agence de garder la main sur ses propres déploiements, seulement éviter qu’un numéro de version interne ne s’affiche à un public qui n’en a pas l’usage.

Étendre la vigilance à d’autres points d’exposition

Une fois ce filtre en place, une revue plus large des points d’exposition possibles d’un numéro de version s’est imposée, plusieurs endroits du cœur WordPress affichant naturellement cette information sans qu’un développeur y pense systématiquement :

  • Le pied de page du code source public d’un site, où un générateur de balises meta peut révéler la version d’une extension via un commentaire HTML.
  • La colonne « Version » de l’écran des extensions en administration, visible par tout utilisateur disposant d’un accès, même restreint, à cet écran.
  • Le journal des modifications affiché dans la fenêtre de détails d’une extension, accessible par un clic sur son nom depuis la liste des extensions installées.

Une convention de nommage claire pour les extensions maison facilite tout filtrage ultérieur : sans préfixe reconnaissable, impossible de cibler précisément ce qui doit rester discret.

En résumé

Ce filtre ne traite volontairement pas le masquage des mises à jour du cœur WordPress lui-même, un sujet distinct qui répond à d’autres enjeux, notamment de sécurité liés au maintien à jour du logiciel. Il se concentre uniquement sur la discrétion des extensions internes d’une agence, encore en phase de développement, dont le numéro de version n’a aucune valeur d’information pour le client final.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi