Plugin Check : faire passer votre extension au contrôle officiel

La première fois qu’on lance Plugin Check sur une extension déjà en production depuis deux ans, la sensation est rarement agréable : une trentaine d’alertes s’affichent d’un coup, certaines pointant vers du code qui fonctionne parfaitement en pratique depuis des mois. C’est normal. L’outil ne juge pas si votre code fonctionne, il juge s’il respecte les standards que l’équipe du répertoire officiel a formalisés pour protéger l’ensemble de l’écosystème, ce qui est un exercice différent.

Plugin Check, le plugin officiel maintenu par l’équipe de la Plugin Review Team, est devenu l’outil de référence pour anticiper les retours d’une soumission ou d’une mise à jour au répertoire WordPress.org, avant même d’entamer un premier échange avec l’équipe de revue humaine.

Installation et premier lancement

L’outil s’installe comme un plugin classique, directement depuis le répertoire officiel, ou via WP-CLI pour une intégration en ligne de commande :

wp plugin install plugin-check --activate
wp plugin check mon-extension --format=table

La commande wp plugin check accepte plusieurs formats de sortie, dont json, particulièrement utile pour parser le résultat automatiquement dans un script de CI plutôt que de lire une sortie destinée à un humain.

Les quatre grandes catégories de contrôles

Les vérifications de Plugin Check se répartissent en catégories distinctes, chacune avec son propre niveau d’exigence et sa propre tolérance aux avertissements.

Sécurité

Échappement de sortie manquant, requêtes SQL non préparées, absence de vérification de capacité (current_user_can()) avant une action sensible. Ces erreurs bloquent systématiquement une soumission au répertoire.

Performance

Chargement de scripts et styles hors des hooks recommandés (wp_enqueue_scripts, admin_enqueue_scripts), requêtes directement exécutées sans mise en cache pertinente, boucles WP_Query mal paramétrées.

Accessibilité

Champs de formulaire d’administration sans étiquette associée, contrastes de couleur insuffisants dans les interfaces fournies par l’extension, attributs ARIA mal utilisés.

Pratiques recommandées

Utilisation de fonctions dépréciées, en-tête de plugin incomplet, absence de préfixe unique sur les fonctions et classes globales, ce qui expose à des collisions de noms avec d’autres extensions.

Corriger les erreurs les plus fréquentes

Sur la trentaine de projets qu’on a fait passer par l’outil, quelques erreurs reviennent nettement plus souvent que les autres et méritent d’être corrigées en priorité, avant même de traiter les avertissements moins critiques.

Sortie non échappée dans les écrans d’administration

C’est de loin l’alerte la plus fréquente. Une simple relecture avec esc_html(), esc_attr() ou wp_kses_post() selon le contexte suffit généralement, mais il faut vérifier chaque occurrence une par une : appliquer esc_html() à une valeur qui contient volontairement du HTML de mise en forme casserait l’affichage.

Scripts chargés en dehors des hooks recommandés

// Signalé par Plugin Check : chargement direct, hors hook
echo '<script src="' . plugins_url( 'app.js', __FILE__ ) . '"></script>';

// Correction attendue
add_action( 'wp_enqueue_scripts', function () {
    wp_enqueue_script(
        'mon-extension-app',
        plugins_url( 'app.js', __FILE__ ),
        [],
        '1.4.0',
        true
    );
} );

Fonctions et classes sans préfixe

Une fonction nommée simplement get_settings() déclarée dans le fichier principal de l’extension entre directement en conflit avec toute autre extension qui déclarerait la même fonction globale. Le renommage en mon_prefixe_get_settings(), ou mieux, l’encapsulation dans une classe ou un espace de noms, élimine ce risque, mais implique de retrouver tous les appels existants dans le code, ce qui peut représenter un chantier de refactorisation non négligeable sur une extension ancienne.

Distinguer les erreurs bloquantes des avertissements

Toutes les alertes remontées par Plugin Check n’ont pas la même gravité. L’outil distingue les erreurs, qui empêcheraient réellement l’acceptation d’une soumission ou d’une mise à jour au répertoire, des avertissements, qui signalent une pratique perfectible sans bloquer formellement le processus. Il est tentant d’ignorer les avertissements pour aller plus vite, mais l’expérience montre que l’équipe de revue humaine les relève souvent lors d’un contrôle manuel complémentaire, en particulier sur une première soumission.

• Traiter systématiquement toutes les erreurs de catégorie sécurité avant toute soumission
• Documenter dans le changelog les avertissements sciemment laissés en l’état, avec la justification
• Relancer l’outil après chaque correction plutôt qu’en une seule passe finale, pour éviter les régressions croisées

Un avertissement ignoré aujourd’hui devient souvent la première question posée par l’équipe de revue lors de la soumission suivante : autant le traiter tant que le contexte du code est encore frais en tête.

Intégrer Plugin Check à la CI de l’extension

Pour un projet qui publie régulièrement des mises à jour, faire tourner wp plugin check à chaque pull request, en environnement WordPress éphémère monté par la CI, évite de découvrir les régressions uniquement au moment de la soumission au répertoire, un moment où le retour arrière coûte plus cher.

En résumé

Plugin Check ne remplace pas la revue humaine du répertoire officiel, mais il en anticipe l’essentiel des retours, souvent en quelques minutes plutôt qu’en plusieurs jours d’échanges asynchrones. Traiter systématiquement les erreurs de sécurité, comprendre la logique de chaque catégorie de contrôle, et intégrer l’outil en continu plutôt qu’au dernier moment transforme la soumission d’une extension d’un exercice anxiogène en une formalité prévisible.