Skip to Content
WordPressPartie 11 — Niveau expertPublier sur wp.org

Chapitre 11.8 — Publier sur wp.org

⏱️ TL;DR — Publier un plugin gratuit sur le répertoire officiel (wordpress.org/plugins ) lui donne une visibilité énorme, l’installation en un clic, et des mises à jour automatiques. Le processus : un readme.txt au format spécial, une soumission relue manuellement par l’équipe Plugins (guidelines, sécurité, GPL), puis la gestion du code via SVN (oui, SVN) avec un dossier assets/ pour l’icône/bannière/captures. C’est un canal d’acquisition majeur et la base d’un modèle freemium (Partie 13).

🎯 Objectifs

  • Préparer un plugin pour la soumission (readme, guidelines).
  • Comprendre la review manuelle et ses critères.
  • Gérer les releases via SVN et le dossier assets/.
  • Situer la publication dans une stratégie de revenus.

1. Le readme.txt

Le répertoire lit un readme.txt (format WordPress, proche du Markdown) qui alimente la page du plugin :

=== WPR Books ===
Contributors: votrepseudo
Tags: books, catalog, cpt
Requires at least: 6.4
Tested up to: 6.6
Requires PHP: 8.1
Stable tag: 1.0.0
License: GPLv2 or later

Un catalogue de livres (CPT, taxonomie, bloc, REST).

== Description ==
Description détaillée, fonctionnalités, captures…

== Installation ==
1. Installer et activer.
2. …

== Frequently Asked Questions ==
= Comment… ? =
Réponse.

== Changelog ==
= 1.0.0 =
* Version initiale.
  • Stable tag : la version publiée (doit correspondre à un tag SVN).
  • Tested up to : la dernière version WordPress testée (à tenir à jour — un plugin « non testé récemment » inspire la méfiance).
  • Tags : mots-clés pour la recherche (limités, pertinents).

⚠️ Piège n°1 — Tested up to périmé. Un readme qui indique « testé jusqu’à une vieille version » fait apparaître le plugin comme abandonné (et un bandeau d’avertissement s’affiche). À chaque sortie majeure de WordPress, testez et bumpez Tested up to. C’est un signal de maintenance essentiel.

2. La soumission et la review

  • On soumet le plugin (une archive) sur wordpress.org/plugins/developers.
  • Une équipe humaine relit le code : respect des guidelines (pas de code obscurci, pas de « phone home » non déclaré, licences compatibles GPL), sécurité (sanitize/escape/nonces, ch. 7.7), pas de fonctionnalités interdites, pas de code de suivi caché.
  • Des allers-retours sont fréquents (corrections demandées). La review peut prendre du temps (jours à semaines).

⚠️ Piège n°2 — les motifs de rejet classiques. Les rejets fréquents : failles de sécurité (sorties non échappées, nonces manquants), appels externes non déclarés, chargement d’assets hors enqueue, noms de fonctions non préfixés (collisions), licences incompatibles, ou tenter de charger du code depuis un serveur distant. Passez un coup de PHPCS/WPCS (ch. 11.4) et sécurisez avant de soumettre : ça accélère l’acceptation.

3. SVN (oui, SVN) et les releases

Une fois accepté, le code se gère via un dépôt Subversion (SVN) fourni par wp.org (même si vous développez sur Git) :

/trunk            ← le code en développement
/tags/1.0.0       ← une version publiée (fige le code)
/assets           ← icône, bannière, captures d'écran (PAS dans le plugin)
  • On développe sur Git, puis on copie vers trunk et on tag la version (/tags/1.0.0) qui correspond au Stable tag du readme.
  • Un tag = une release ; c’est ce qui déclenche la mise à jour chez les utilisateurs.

💡 Astuce — Des GitHub Actions (ex. « 10up/action-wordpress-plugin-deploy ») publient automatiquement sur le SVN wp.org à chaque tag Git (ch. 11.4 : CD). Vous gardez Git comme source de vérité ; la CI s’occupe du SVN. Personne ne fait de SVN à la main aujourd’hui.

4. Le dossier assets/ (la vitrine)

Dans /assets du SVN (séparé du code du plugin) :

  • icon-256x256.png : l’icône du plugin.
  • banner-772x250.png : la bannière de la page.
  • screenshot-1.png, … : les captures (référencées dans le readme == Screenshots ==).

Ces éléments font la première impression sur la page du plugin — soignez-les (comme la vitrine d’un produit).

5. Publication et stratégie de revenus

Un plugin gratuit sur wp.org est rarement un revenu direct, mais un actif puissant :

  • Distribution & lead-gen : installé sur des sites, votre page attire des demandes de sur-mesure et de support.
  • Base freemium : la version gratuite (wp.org) alimente une version Pro (fonctions +, support, updates) vendue à part (via Freemius/EDD) — le modèle dominant des éditeurs (Partie 13).
  • Réputation : un plugin bien noté, maintenu, CI verte = crédibilité professionnelle.

💡 Pour un dev React — Publier sur wp.org, c’est comme publier un paquet open-source populaire : gratuit, forte portée, review avant diffusion (plus stricte que npm), et un tremplin vers une offre commerciale (open-core). Un plugin moderne (un bloc React utile, un connecteur headless) publié sur wp.org démarque immédiatement votre profil — peu de plugins exploitent bien React/headless. C’est un actif de carrière autant qu’un canal de revenus (Partie 13).

✏️ Exercices

  1. Que se passe-t-il si votre Tested up to reste sur une vieille version de WordPress ?
  2. Citez trois motifs fréquents de rejet à la review, et comment les prévenir.
  3. Vous développez sur Git ; comment publier sur wp.org sans faire de SVN à la main ?

✅ Solution

  1. Le plugin apparaît comme potentiellement abandonné (avertissement affiché), ce qui décourage les installations. Il faut tester à chaque version majeure et bumper Tested up to.
  2. Par exemple : failles de sécurité (sorties non échappées, nonces manquants) → passer PHPCS/WPCS et appliquer la Partie 7.7 ; appels externes/tracking non déclarés → les documenter/retirer ; assets hors enqueue ou fonctions non préfixées → utiliser l’enqueue (ch. 6.4) et préfixer/namespacer (ch. 7.1).
  3. Utiliser une GitHub Action de déploiement wp.org (ex. « action-wordpress-plugin-deploy ») qui publie sur le SVN à chaque tag Git — Git reste la source, la CI gère SVN (ch. 11.4).

🧠 Quiz de révision

1. Quel fichier alimente la page du plugin sur wp.org ?

Le readme.txt (format WordPress : Contributors, Tags, Stable tag, Tested up to, Changelog…).

2. La publication est-elle automatique ?

Non : une review manuelle vérifie guidelines, sécurité et licence avant acceptation.

3. Comment gère-t-on les releases sur wp.org ?

Via SVN (/trunk, /tags/x.y.z, /assets) — automatisable depuis Git par une GitHub Action.

4. Que met-on dans le dossier assets/ du SVN ?

L’icône, la bannière et les captures d’écran (séparés du code du plugin).

5. En quoi publier sur wp.org sert-il une stratégie de revenus ?

C’est un canal d’acquisition (distribution, lead-gen, réputation) et la base d’un modèle freemium (Partie 13).

Partie suivante : Partie 12 — Annexes.

Accessibilité & i18n avancéePartie 12 — Annexes