Comment publier une extension sur WordPress.org | Le guide

Vous avez développé une extension WordPress et vous souhaitez la rendre accessible à tous depuis le répertoire officiel ? Publier une extension sur WordPress.org est une excellente façon de gagner en visibilité, de toucher de nouveaux utilisateurs et de distribuer facilement vos futures mises à jour. Encore faut-il connaître les bonnes étapes pour éviter les erreurs qui peuvent ralentir ou bloquer la validation de votre plugin.

Dans ce tutoriel, vous allez découvrir comment préparer votre extension, respecter les exigences de WordPress.org, soumettre votre plugin à l’équipe de validation et publier vos premières versions comme un développeur expérimenté. Même si vous débutez avec WordPress, vous verrez que le processus est beaucoup plus simple qu’il n’y paraît lorsqu’il est expliqué étape par étape.

• Éviter les erreurs qui provoquent le refus d’une extension grâce à une préparation conforme aux exigences du répertoire officiel.
• Comprendre le rôle du fichier readme, de la sécurité et du dépôt SVN pour publier vos mises à jour sereinement.
• Transformer un plugin que vous avez développé en une extension accessible directement depuis l’administration WordPress de milliers d’utilisateurs.

Publier une extension sur WordPress.org, c’est un peu comme ouvrir la porte de votre atelier au monde entier. Votre petit plugin, développé tranquillement sur votre ordinateur, peut soudainement devenir disponible depuis le tableau de bord de millions de sites WordPress. C’est excitant, mais cela demande aussi un minimum de méthode.

Nous allons voir comment vérifier votre code, créer le fichier readme.txt, préparer le fichier ZIP de soumission, passer l’étape de validation, puis envoyer votre extension dans le dépôt officiel grâce à SVN.

L’objectif n’est pas seulement de “mettre un plugin en ligne”. L’objectif est de comprendre le protocole complet, avec des mots simples, pour éviter les erreurs classiques qui ralentissent souvent la validation.

Comprendre ce qu’est WordPress.org

Avant de publier une extension, il faut bien distinguer WordPress.org de WordPress.com.

WordPress.org est le projet open source de WordPress. C’est là que l’on trouve le logiciel WordPress à télécharger, la documentation officielle, les thèmes, les extensions et les forums communautaires.

Quand vous publiez une extension sur WordPress.org, elle devient disponible dans le répertoire officiel des plugins. Cela signifie qu’un utilisateur pourra la rechercher depuis son administration WordPress, l’installer en un clic, puis recevoir les futures mises à jour directement dans son tableau de bord.

Autrement dit, WordPress.org ne sert pas seulement à présenter votre extension. Il l’héberge réellement. C’est pour cette raison que la procédure est plus stricte qu’un simple partage de fichier ZIP sur votre site personnel.

Ce qu’il faut préparer avant de soumettre une extension

Avant d’envoyer votre extension à WordPress.org, prenez le temps de la préparer proprement. C’est l’étape que beaucoup de débutants veulent sauter, et c’est souvent là que les ennuis commencent.

Votre extension doit être terminée, fonctionnelle et prête à être utilisée. WordPress.org ne permet pas de réserver un nom pour une future idée. Vous devez proposer un plugin complet, utilisable et cohérent.

Cela signifie que votre extension doit déjà avoir été testée sur une installation WordPress locale ou en ligne. Elle ne doit pas provoquer d’erreur PHP, ne doit pas afficher de messages de debug, et ne doit pas contenir de fichiers inutiles comme des dossiers de développement, des archives ZIP ou des notes personnelles oubliées au fond d’un dossier.

Imaginez que vous invitez quelqu’un à visiter votre maison. Vous n’êtes pas obligé d’avoir un palais, mais évitez de laisser les cartons, les outils et les câbles au milieu du salon.

Respecter les règles de base de WordPress.org

WordPress.org impose plusieurs règles importantes. Elles ne sont pas là pour embêter les développeurs, mais pour protéger les utilisateurs.

Votre extension doit être compatible avec la licence GPL, idéalement GPLv2 ou ultérieure. C’est la licence utilisée par WordPress. En clair, votre code doit respecter l’esprit open source du projet.

Votre plugin ne doit pas contenir de code dangereux, trompeur ou illégal. Il ne doit pas ajouter des liens publicitaires cachés sur le site public sans l’accord explicite de l’utilisateur. Il ne doit pas non plus envoyer des données sensibles vers un service externe sans l’indiquer clairement.

Vous devez aussi faire attention au nom de votre extension. Évitez de commencer le nom par une marque protégée, comme WooCommerce, Elementor ou WordPress, sauf si vous êtes officiellement autorisé à le faire. Par exemple, un nom comme “WordPress Super Optimizer” risque de poser problème. Préférez une formulation originale, plus neutre et plus personnelle.

Sécuriser son extension avant l’envoi

La sécurité est l’un des points les plus importants lors de la validation. Si votre extension accepte des données saisies par l’utilisateur, affiche des informations dans l’administration ou traite un formulaire, vous devez appliquer quelques réflexes de base.

Quand vous recevez une donnée, vous devez la nettoyer. C’est ce que l’on appelle la sanitization. Par exemple, si un champ attend un texte simple, vous pouvez utiliser une fonction comme sanitize_text_field().

$nom = sanitize_text_field($_POST['nom']);

Cette ligne permet de nettoyer la valeur reçue avant de l’utiliser. C’est un peu comme passer les légumes sous l’eau avant de les cuisiner. Ce n’est pas spectaculaire, mais c’est indispensable.

Quand vous affichez une donnée, vous devez aussi l’échapper. C’est ce que l’on appelle l’escaping. Par exemple :

echo esc_html($nom);

Cette fonction évite qu’un contenu dangereux soit interprété comme du code HTML ou JavaScript.

Enfin, si votre extension contient un formulaire dans l’administration WordPress, vous devez utiliser un nonce. Un nonce est une sorte de jeton de sécurité qui permet de vérifier que l’action vient bien d’une page prévue par votre plugin.

wp_nonce_field('mon_action_plugin', 'mon_nonce_plugin');

Puis, au moment du traitement :

if (
    ! isset($_POST['mon_nonce_plugin']) ||
    ! wp_verify_nonce($_POST['mon_nonce_plugin'], 'mon_action_plugin')
) {
    wp_die('Vérification de sécurité échouée.');
}

Ces éléments peuvent sembler techniques au départ, mais ils sont essentiels. Une extension refusée pour un problème de sécurité devra être corrigée, puis réexaminée. Autant gagner du temps dès le début.

Créer le fichier principal de l’extension

Toute extension WordPress possède un fichier principal. C’est généralement un fichier PHP placé à la racine du dossier de votre plugin.

Par exemple, si votre extension s’appelle “Mon Super Plugin”, vous pourriez avoir une structure comme ceci :

mon-super-plugin/
│
├── mon-super-plugin.php
├── readme.txt
├── includes/
│   └── functions.php
└── assets/
    └── admin.css

Dans le fichier principal, vous devez ajouter un en-tête d’extension. C’est grâce à cet en-tête que WordPress reconnaît votre plugin.

<?php
/**
 * Plugin Name: Mon Super Plugin
 * Plugin URI: https://example.com/mon-super-plugin
 * Description: Une courte description de ce que fait l’extension.
 * Version: 1.0.0
 * Author: Votre Nom
 * Author URI: https://example.com
 * License: GPLv2 or later
 * License URI: https://www.gnu.org/licenses/gpl-2.0.html
 * Requires at least: 6.0
 * Requires PHP: 7.4
 * Text Domain: mon-super-plugin
 */

if (! defined('ABSPATH')) {
    exit;
}

La ligne if (! defined('ABSPATH')) exit; empêche l’accès direct au fichier. C’est une petite protection simple, très courante dans les extensions WordPress.

Le champ Plugin Name est très important, car il influence le futur slug de votre extension sur WordPress.org. Le slug, c’est la partie de l’URL qui identifie votre plugin. Par exemple, si votre extension s’appelle “Mon Super Plugin”, son adresse pourrait devenir :

https://wordpress.org/plugins/mon-super-plugin/

Choisissez donc un nom clair, unique et durable. Vous pourrez modifier le nom affiché plus tard, mais le slug, lui, ne se change pas facilement après approbation.

Préparer le fichier readme.txt

Le fichier readme.txt est indispensable. Il sert à générer la page publique de votre extension sur WordPress.org. Description, captures d’écran, instructions d’installation, changelog : une grande partie de ce que les utilisateurs verront vient de ce fichier.

Voici une base simple :

=== Mon Super Plugin ===
Contributors: votreidentifiant
Tags: optimisation, administration, outil
Requires at least: 6.0
Tested up to: 6.5
Requires PHP: 7.4
Stable tag: 1.0.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Une courte description de l’extension en moins de 150 caractères.

== Description ==

Mon Super Plugin ajoute une fonctionnalité simple à votre site WordPress.
Il a été pensé pour être facile à utiliser, même si vous débutez.

== Installation ==

1. Envoyez le dossier de l’extension dans le répertoire `/wp-content/plugins/`.
2. Activez l’extension depuis le menu “Extensions” de WordPress.
3. Configurez les options si nécessaire.

== Frequently Asked Questions ==

= Cette extension est-elle gratuite ? =

Oui, l’extension est gratuite.

== Screenshots ==

1. Écran principal de l’extension.
2. Page de configuration.

== Changelog ==

= 1.0.0 =
* Première version publique.

Le champ Stable tag est particulièrement important. Il indique à WordPress.org quelle version doit être distribuée aux utilisateurs. Si vous publiez la version 1.0.0, le Stable tag doit généralement être 1.0.0.

Évitez de remplir le fichier readme.txt à la va-vite. C’est votre vitrine. Un bon readme rassure les utilisateurs, facilite la validation et donne une image plus professionnelle à votre travail.

Tester le readme avant l’envoi

WordPress.org propose un validateur de readme.txt. Utilisez-le avant de soumettre votre plugin. Il permet de vérifier que votre fichier respecte le format attendu.

C’est une étape rapide, mais très utile. Une simple erreur de format peut empêcher l’affichage correct de certaines informations sur la page de votre extension.

Pensez aussi à relire votre description comme si vous étiez un utilisateur qui ne connaît pas votre projet. Est-ce clair ? Est-ce que l’on comprend rapidement à quoi sert votre extension ? Est-ce que les instructions d’installation sont simples ?

Si la réponse est oui, vous êtes sur la bonne voie.

Contributors: guillieralban

WordPress vérifie que chaque nom correspond à un compte WordPress.org existant. Si le compte n’existe pas ou si l’identifiant est incorrect, il est ignoré.

Vérifiez votre identifiant WordPress.org

Connectez-vous à votre compte sur : WordPress.org

Puis regardez l’URL de votre profil. Par exemple :

https://profiles.wordpress.org/mon-identifiant/

L’identifiant à utiliser est uniquement :

Contributors: mon-identifiant

Si votre profil est :

https://profiles.wordpress.org/alban-guillier/

alors il faut écrire :

Contributors: alban-guillier

et non :

Contributors: guillieralban

Si vous n’avez jamais créé de profil WordPress.org

Avoir un compte sur un site WordPress ne suffit pas. Il faut posséder un compte sur : WordPress.org Registration et être connecté au moins une fois afin que le profil soit créé.

Préparer le fichier ZIP de soumission

Pour demander la publication d’une extension sur WordPress.org, vous devez envoyer un fichier ZIP. Ce fichier doit contenir le dossier complet de votre extension.

La structure doit ressembler à ceci :

mon-super-plugin.zip
└── mon-super-plugin/
    ├── mon-super-plugin.php
    ├── readme.txt
    └── includes/

Attention à ne pas créer une archive avec une mauvaise structure, par exemple :

mon-super-plugin.zip
└── mon-super-plugin/
    └── mon-super-plugin/
        ├── mon-super-plugin.php
        └── readme.txt

Cette double imbrication est une erreur classique. Elle peut provoquer des soucis lors de l’installation.

Votre ZIP doit être propre. Supprimez les fichiers inutiles comme :

.DS_Store
.git/
node_modules/
vendor/ non nécessaire
fichiers-de-test.php
debug.log
ancienne-version.zip

Si vous utilisez des fichiers minifiés, par exemple du JavaScript compressé, gardez aussi les sources lisibles ou indiquez clairement où elles sont disponibles. WordPress.org veut que le code soit lisible et vérifiable.

Créer un compte WordPress.org

Comme vu précédemment, pour publier une extension, vous devez avoir un compte WordPress.org. Utilisez une adresse e-mail fiable, que vous consultez régulièrement.

C’est très important, car l’équipe de validation vous contactera par e-mail. Si votre plugin nécessite une correction, vous recevrez les détails à cette adresse.

Si vous publiez une extension officielle pour une entreprise, utilisez idéalement une adresse professionnelle liée au domaine de l’entreprise. Cela évite certains doutes, notamment lorsque le nom de l’extension fait référence à une marque ou à un service connu.

Soumettre l’extension à WordPress.org

Une fois connecté à votre compte WordPress.org, rendez-vous sur la page d’ajout d’extension. Vous devrez envoyer votre fichier ZIP et fournir quelques informations sur votre plugin.

À ce stade, votre extension n’est pas encore publique. Elle entre dans une file de validation manuelle.

L’équipe WordPress.org va examiner votre code. Elle vérifiera notamment que l’extension respecte les règles du répertoire, qu’elle ne contient pas de problème de sécurité évident, qu’elle est complète et qu’elle peut être distribuée aux utilisateurs.

Le délai peut varier. Parfois, cela va relativement vite. Parfois, il faut attendre davantage, surtout si le plugin est complexe ou si l’équipe reçoit beaucoup de demandes.

Pendant cette attente, évitez de renvoyer plusieurs fois le même plugin. Si vous avez fait une erreur importante, attendez les instructions reçues par e-mail.

Que se passe-t-il après la validation ?

Après examen, deux cas sont possibles.

Premier cas : votre extension est approuvée. Bonne nouvelle, vous pouvez sortir le jus de pomme pétillant. WordPress.org vous envoie alors un accès à un dépôt SVN.

Deuxième cas : l’équipe vous demande des corrections. Ce n’est pas un drame. C’est même assez courant. Vous recevrez généralement des explications sur les points à modifier : données non nettoyées, sortie non échappée, nonce manquant, problème de licence, nom non conforme, fichier inutile, etc.

Dans ce cas, corrigez calmement votre extension, puis répondez à l’e-mail avec les éléments demandés. Ne prenez pas cela comme un échec. C’est plutôt une étape de qualité.

Comprendre SVN, même si vous utilisez Git

Après approbation, WordPress.org vous donne accès à un dépôt SVN. SVN signifie Subversion. C’est un système de gestion de versions, comme Git, mais plus ancien et avec une logique différente.

Même si vous développez votre extension avec GitHub, GitLab ou Bitbucket, WordPress.org utilise SVN pour publier officiellement les plugins.

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

Il faut donc comprendre une idée simple : Git peut rester votre outil de développement, mais SVN devient votre outil de publication sur WordPress.org.

Votre dépôt SVN contient généralement trois dossiers principaux :

trunk/
branches/
tags/

Le dossier trunk contient la version de travail principale de votre extension.

Le dossier tags contient les versions publiées, par exemple :

tags/1.0.0/
tags/1.1.0/
tags/1.2.0/

Le dossier branches est moins utilisé dans le cas simple d’une extension débutante.

Installer SVN sur votre ordinateur

Pour envoyer votre plugin sur WordPress.org, vous devez avoir SVN installé sur votre machine.

Sur macOS, vous pouvez souvent l’installer avec Homebrew :

brew install svn

Sur Linux, selon votre distribution, vous pouvez utiliser :

sudo apt install subversion

Sur Windows, vous pouvez utiliser un outil comme TortoiseSVN, qui ajoute des options SVN directement dans l’explorateur de fichiers.

Pour vérifier que SVN est installé, ouvrez votre terminal et tapez :

svn --version

Si une version s’affiche, c’est bon. Si votre terminal vous répond que la commande est inconnue, SVN n’est pas encore installé correctement.

Récupérer le dépôt SVN de votre extension

Après validation, WordPress.org vous fournit une URL de dépôt. Elle ressemble à ceci :

https://plugins.svn.wordpress.org/mon-super-plugin/

Dans votre terminal, placez-vous dans le dossier où vous voulez travailler, puis lancez :

svn co https://plugins.svn.wordpress.org/mon-super-plugin/ mon-super-plugin-svn

La commande svn co signifie checkout. Elle sert à récupérer une copie locale du dépôt SVN.

Vous obtenez alors un dossier comme ceci :

mon-super-plugin-svn/
├── assets/
├── branches/
├── tags/
└── trunk/

Si le dossier assets n’existe pas encore, vous pourrez le créer plus tard pour ajouter les images de présentation.

Ajouter les fichiers dans trunk

Vous devez maintenant placer les fichiers de votre extension dans le dossier trunk.

Attention : le fichier principal du plugin et le fichier readme.txt doivent être directement dans trunk, pas dans un sous-dossier supplémentaire.

La bonne structure est :

trunk/
├── mon-super-plugin.php
├── readme.txt
└── includes/

La mauvaise structure est :

trunk/
└── mon-super-plugin/
    ├── mon-super-plugin.php
    └── readme.txt

Cette erreur peut casser la génération du ZIP sur WordPress.org. C’est un piège fréquent, donc retenez bien cette règle : dans SVN, le contenu du plugin va directement dans trunk.

Une fois les fichiers copiés, indiquez à SVN qu’il doit les suivre :

cd mon-super-plugin-svn
svn add trunk/*

Puis envoyez les fichiers :

svn ci -m "Ajout de la première version de l’extension"

La commande svn ci signifie commit. Elle envoie vos modifications vers le dépôt WordPress.org.

Créer un tag de version

Envoyer les fichiers dans trunk ne suffit pas toujours. Pour publier proprement une version stable, vous devez créer un tag.

Un tag est une copie figée de votre extension à un moment précis. Par exemple, pour publier la version 1.0.0, vous créez un dossier :

tags/1.0.0/

Depuis la racine du dépôt SVN, lancez :

svn cp trunk tags/1.0.0

Puis envoyez cette nouvelle version :

svn ci -m "Publication de la version 1.0.0"

Votre fichier readme.txt doit contenir :

Stable tag: 1.0.0

WordPress.org regarde cette ligne pour savoir quelle version proposer au téléchargement.

Ajouter les images de l’extension

La page WordPress.org de votre extension peut afficher une bannière, une icône et des captures d’écran. Ces fichiers ne doivent pas être placés dans trunk/assets, mais dans le dossier assets situé à la racine du dépôt SVN.

Exemple :

mon-super-plugin-svn/
├── assets/
│   ├── banner-772x250.png
│   ├── icon-256x256.png
│   └── screenshot-1.png
├── trunk/
├── tags/
└── branches/

Les captures d’écran doivent correspondre à la section Screenshots de votre fichier readme.txt.

Par exemple :

== Screenshots ==

1. Écran principal de l’extension.
2. Page de configuration.

Les fichiers peuvent alors s’appeler :

screenshot-1.png
screenshot-2.png

Après avoir ajouté les images, utilisez :

svn add assets/*
svn ci -m "Ajout des visuels de l’extension"

Les images peuvent mettre un peu de temps à apparaître sur WordPress.org, car elles sont mises en cache. Pas besoin de paniquer après trois minutes. Le cache, c’est un peu le collègue qui répond “j’arrive” mais qui finit son café avant.

Vérifier la page publique de l’extension

Une fois le code envoyé dans SVN, votre extension devient publique. Vous pouvez alors consulter son URL sur WordPress.org.

Vérifiez attentivement plusieurs éléments :

Le titre doit être correct. La description doit être claire. Les captures d’écran doivent apparaître dans le bon ordre. Le bouton de téléchargement doit fonctionner. Les informations de compatibilité doivent être cohérentes. Le changelog doit afficher la bonne version.

Installez ensuite votre extension depuis un site WordPress de test, directement depuis le répertoire officiel. Cela vous permet de vérifier l’expérience réelle d’un utilisateur.

Publier une mise à jour

Une fois votre extension publiée, vous devrez probablement la mettre à jour. La logique reste la même.

Vous modifiez les fichiers dans trunk, vous augmentez le numéro de version dans le fichier principal, vous mettez à jour le Stable tag dans readme.txt, puis vous créez un nouveau tag.

Par exemple, pour passer de 1.0.0 à 1.1.0, vous modifiez dans le fichier principal :

 * Version: 1.1.0

Puis dans readme.txt :

Stable tag: 1.1.0

Ajoutez aussi une entrée dans le changelog :

== Changelog ==

= 1.1.0 =
* Ajout d’une nouvelle option dans l’administration.
* Correction d’un problème d’affichage.

= 1.0.0 =
* Première version publique.

Ensuite, dans le terminal :

svn add trunk/*
svn ci -m "Mise à jour de la version 1.1.0"
svn cp trunk tags/1.1.0
svn ci -m "Publication de la version 1.1.0"

Les utilisateurs verront alors une mise à jour disponible dans leur tableau de bord WordPress.

Les erreurs à éviter

La première erreur consiste à envoyer une extension qui n’est pas prête. WordPress.org attend un plugin complet, pas une démo ou une idée en construction.

La deuxième erreur concerne la sécurité. Des données non nettoyées, des sorties non échappées ou des formulaires sans nonce peuvent entraîner un refus.

La troisième erreur est liée à la structure SVN. Ne mettez pas votre plugin dans un sous-dossier à l’intérieur de trunk. Placez directement le fichier principal et le readme.txt dans trunk.

La quatrième erreur consiste à oublier le Stable tag. Si cette valeur ne correspond pas au dossier présent dans tags, WordPress.org risque de ne pas distribuer la bonne version.

La cinquième erreur est de publier trop vite. Une fois le code envoyé dans SVN, il peut être disponible publiquement. Ne poussez donc pas une version bancale “juste pour tester”.

Conseils pour donner envie d’installer votre extension

Publier une extension sur WordPress.org, ce n’est pas seulement une opération technique. C’est aussi une petite démarche de communication.

Votre description doit expliquer clairement le problème résolu. Évitez les phrases vagues comme “Cette extension améliore votre site”. Dites plutôt ce qu’elle améliore, pour qui, et dans quel contexte.

Par exemple, au lieu de :

Cette extension ajoute des fonctionnalités utiles.

Préférez :

Cette extension ajoute un bloc simple pour afficher une liste d’articles liés à la fin de vos contenus.

C’est plus concret, plus rassurant, et beaucoup plus utile pour l’utilisateur.

Soignez les captures d’écran. Une bonne image peut convaincre plus vite qu’un long paragraphe. Montrez l’interface, les réglages et le résultat visible côté site si votre extension modifie l’affichage public.

Enfin, maintenez votre plugin. Une extension abandonnée inspire moins confiance. Même une petite mise à jour de compatibilité peut montrer que le projet est vivant.

---

---

Publier une extension sur WordPress.org peut sembler impressionnant la première fois. Entre le fichier readme.txt, les règles de sécurité, le ZIP de soumission, SVN, les tags et les assets, on a vite l’impression de devoir passer un mini-permis de conduire du développeur WordPress.

Pourtant, une fois le protocole compris, la démarche devient beaucoup plus logique. Vous préparez une extension propre, vous documentez son fonctionnement, vous la soumettez à l’équipe WordPress.org, puis vous utilisez SVN pour publier les versions officielles.

Le plus important est de ne pas voir cette procédure comme une contrainte, mais comme un cadre de qualité. Elle vous pousse à produire un plugin plus clair, plus sécurisé et plus professionnel.

Alors, si vous avez déjà créé une petite extension utile pour vos propres sites, pourquoi ne pas tenter l’aventure ? Commencez modestement, publiez une première version simple, écoutez les retours, puis améliorez-la progressivement. C’est souvent comme cela que naissent les meilleurs projets : une petite idée pratique, un premier partage, puis une communauté qui commence à s’y intéresser.

👉 Pensez à utiliser Gravatar pour gérer votre identité numérique sur l’écosystème WP.