# Publier une extension sur WordPress.org : guide du dépôt SVN et de la revue

> readme.txt, trunk, tags, assets : la mécanique SVN du répertoire officiel expliquée pas à pas, et ce qui bloque le plus souvent une extension lors de la revue initiale.

- Auteur : Clément Hadrot
- Publié le : 2023-08-09
- Mis à jour le : 2023-08-09
- Catégorie : Extensions
- URL : https://wpmoderne.dev.wordpress-developpement.fr/extensions/publier-wordpress-org-guide-svn-review/

## L’essentiel

- Le répertoire officiel utilise Subversion, pas Git
- trunk n'est jamais ce que les utilisateurs installent en production
- La revue initiale peut prendre plusieurs semaines

Publier une extension sur le répertoire officiel de WordPress.org reste, malgré la montée en puissance des marketplaces premium, le canal de distribution le plus visible pour toucher un large public. La mécanique de publication surprend souvent les développeurs habitués à Git : le répertoire fonctionne exclusivement avec Subversion (SVN), un système de gestion de version plus ancien, avec une structure de dossiers précise qu'il faut respecter à la lettre.

Cet article détaille le processus complet, de la soumission initiale à la mise à jour d'une version, avec les blocages les plus fréquents rencontrés lors de la revue par l'équipe de WordPress.org.

## Avant la soumission : le readme.txt, souvent sous-estimé

Le fichier `readme.txt`, au format Markdown simplifié propre à WordPress.org, n'est pas une simple formalité : il détermine l'affichage de la fiche de l'extension (description, captures d'écran, FAQ) et surtout les métadonnées de compatibilité vérifiées automatiquement par les outils de revue.

```
=== Mon Extension Acme ===
Contributors: acmedev
Tags: produits, stock, gestion
Requires at least: 6.2
Tested up to: 6.3
Requires PHP: 7.4
Stable tag: 1.0.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Courte description de l'extension, moins de 150 caractères.

== Description ==

Description complète de l'extension...

== Installation ==

1. Téléverser le dossier dans /wp-content/plugins/
2. Activer l'extension depuis le menu Extensions

== Changelog ==

= 1.0.0 =
* Première version publique
```

Le champ `Stable tag` mérite une attention particulière : il indique à WordPress quelle version du dossier `tags/` du dépôt SVN correspond à la version stable que les utilisateurs doivent recevoir. Une erreur fréquente chez les débutants consiste à modifier uniquement `trunk` sans jamais créer de nouveau tag correspondant, ce qui fige la version distribuée aux utilisateurs alors même que le code a évolué.

## La structure SVN imposée

```
mon-extension/
  trunk/          # développement en cours, jamais installé directement par les utilisateurs
  tags/
    1.0.0/        # version figée correspondant exactement à une release publiée
    1.1.0/
  assets/         # bannière, icône et captures d'écran affichées sur la fiche
    banner-1544x500.png
    icon-256x256.png
    screenshot-1.png
```

Le dossier `assets/` à la racine du dépôt, distinct du dossier `trunk/assets/` s'il existe, contient les visuels de présentation de la fiche WordPress.org et n'est jamais inclus dans le zip téléchargé par les utilisateurs. Confondre les deux emplacements est une erreur fréquente qui fait apparaître, ou disparaître, des visuels au mauvais endroit.

> L'essentiel à retenir : Le répertoire officiel utilise Subversion, pas Git ; trunk n'est jamais ce que les utilisateurs installent en production ; La revue initiale peut prendre plusieurs semaines

## Le workflow SVN concret

```
# Récupérer le dépôt attribué après acceptation
svn checkout https://plugins.svn.wordpress.org/mon-extension

cd mon-extension

# Copier le code source dans trunk
cp -r /chemin/vers/mon-code/* trunk/

# Ajouter les nouveaux fichiers au suivi de version
svn add trunk/* --force

# Créer le tag correspondant à la version stable
svn copy trunk tags/1.0.0

# Envoyer le tout sur le serveur WordPress.org
svn commit -m "Version 1.0.0"
```

Une mise à jour ultérieure suit exactement le même schéma : modifier `trunk`, créer un nouveau tag correspondant, mettre à jour le champ `Stable tag` du `readme.txt`, puis commit. Oublier de créer le nouveau tag est l'erreur la plus fréquente lors d'une mise à jour : le code de `trunk` change bien sur le serveur, mais aucun utilisateur ne reçoit la mise à jour tant que `Stable tag` ne pointe pas vers un tag existant.

## Les causes de rejet les plus fréquentes lors de la revue

- **Appels réseau non déclarés** : toute requête vers un service tiers (mise à jour de licence, suivi analytique) doit être clairement documentée dans le `readme.txt`, avec mention explicite si des données utilisateur sont transmises.
- **Fonctions de sécurité contournées** : sorties non échappées avec `esc_html()` ou `esc_attr()`, requêtes SQL non préparées avec `$wpdb->prepare()`, absence de vérification de nonce sur un traitement de formulaire.
- **Text domain incohérent** : un `Text Domain` déclaré dans l'en-tête qui ne correspond pas exactement au slug final attribué par WordPress.org.
- **Code obfusqué ou minifié sans source** : l'équipe de revue doit pouvoir lire l'intégralité du code exécuté, sans fichier compilé illisible sans son équivalent source.
- **Fonctionnalités « premium » masquées trompeuses** : présenter une extension comme gratuite tout en désactivant l'essentiel de ses fonctionnalités derrière un mur payant non annoncé clairement.

> Sur nos premières soumissions, le rejet le plus instructif a porté sur une requête `$wpdb->query()` directe sans `prepare()`, pourtant sur un champ qu'on jugeait « sans risque » côté interne. La revue de WordPress.org ne fait aucune exception, quel que soit le contexte apparent : c'est précisément ce niveau d'exigence qui protège l'ensemble de l'écosystème.

## Le délai de revue, à anticiper dans le planning

Le premier retour de l'équipe de revue peut prendre plusieurs semaines, un délai qui varie fortement selon la période et le nombre de soumissions en attente. Ce délai doit être anticipé dans tout planning de lancement : publier une extension n'est jamais une action instantanée, contrairement à un déploiement classique par Git.

## En résumé

Publier sur WordPress.org exige de maîtriser une mécanique SVN différente des habitudes Git courantes, avec une distinction stricte entre `trunk`, `tags` et `assets`. La revue de sécurité, exigeante mais prévisible une fois ses critères connus, protège l'ensemble de l'écosystème et mérite d'être anticipée dès la conception du code plutôt que corrigée dans l'urgence après un premier rejet.