On me demande parfois pourquoi la version gratuite de DRW a mis autant de temps à apparaître sur WordPress.org alors que le plugin fonctionnait déjà très bien sur mon environnement de développement. La réponse tient en un mot : Plugin Check, l’outil (et les humains derrière) qui vérifie qu’un plugin respecte les standards de sécurité et de qualité de l’écosystème avant sa mise en ligne publique. Voici ce que ça a concrètement impliqué.
Le premier rejet, pour la mauvaise raison
Premier envoi, premier refus — mais pas pour un problème de code. L’équipe de revue avait pointé la présence de code de gestion de licence (la partie SDK liée à SureCart) dans le ZIP soumis. Sauf que cette partie n’a jamais eu vocation à se trouver dans la version gratuite : c’était une erreur d’upload de mon côté, un ancien build qui avait glissé dans le mauvais dossier au moment de zipper. Frustrant, mais rapide à corriger une fois identifié — la vraie difficulté commençait juste après.
Le renommage de préfixe : plus gros que prévu
WordPress.org impose que tout plugin utilise un préfixe suffisamment long et unique sur ses fonctions, classes et variables globales, pour éviter les collisions avec d’autres extensions installées sur le même site. Mon préfixe d’origine, DRW_ / drw_, ne faisait que 3 caractères — trop court pour les standards actuels.
Ce qui semblait être un simple renommage global s’est avéré plus long que prévu : il fallait le changer partout — dans le PHP, le JS, le CSS, jusque dans les noms physiques des fichiers de classe (class-drw-*.php devenant class-msdr-*.php), sans oublier les fichiers de traduction dont le nom doit correspondre exactement au nouveau domaine de texte. Un renommage bâclé à un seul endroit, et c’est toute la chaîne de chargement des fichiers qui casse silencieusement.
Les avertissements Plugin Check, un par un
Une fois le préfixe réglé, restait la liste des avertissements de sécurité remontés par l’outil automatique. Quelques exemples représentatifs :
- Vérification des nonces manquante sur certaines actions AJAX : il a fallu s’assurer que chaque action qui modifie une donnée vérifie bien un nonce, et documenter clairement dans le code les cas où cette vérification se fait ailleurs dans le flux (pour que l’outil de vérification comprenne que ce n’est pas un oubli).
- Requêtes base de données non échappées : plusieurs appels directs à la base nécessitaient soit un échappement plus strict, soit une annotation explicite justifiant pourquoi la requête est sûre telle quelle.
- Variables non préfixées dans certains fichiers de templates, qui remontaient comme faux positifs une fois le contexte du fichier pris en compte, mais qu’il fallait tout de même signaler explicitement à l’outil.
Rien d’insurmontable individuellement, mais additionné, ça représente un vrai travail de fond — pas du bricolage de dernière minute avant publication.
Pourquoi j’en parle publiquement
Ce niveau d’exigence est probablement invisible pour la plupart des utilisateurs d’un plugin : personne ne voit le nombre d’allers-retours qu’il a fallu pour en arriver à une version publiable. Mais c’est précisément ce qui distingue, à terme, un plugin bien maintenu d’un autre qui aurait été mis en ligne plus vite en coupant les coins ronds sur ces vérifications. Si vous développez vous-même des extensions WordPress, sachez que ce parcours fait clairement partie du jeu — mieux vaut le prévoir dans votre calendrier de lancement que de le découvrir en cours de route.
DRW reste, à l’heure où j’écris ces lignes, en cours de validation. Dès qu’il sera en ligne, ce sera avec la certitude d’avoir traversé ce filtre dans les règles.
