Le répertoire officiel des extensions WordPress fonctionne encore sur Subversion, un système de gestion de version que la majorité des développeurs actuels n’a jamais utilisé au quotidien — Git a pris toute la place depuis longtemps. Publier une mise à jour d’extension impliquait donc traditionnellement d’installer un client SVN, de cloner le dépôt du plugin, de copier les fichiers à la main dans trunk, puis de créer un tag manuellement. Une action GitHub maintenue par la communauté élimine cette friction : elle traduit un push Git en opérations SVN équivalentes, en coulisse.
Ce tutoriel construit ce pipeline de bout en bout. La question de la revue initiale par l’équipe du répertoire WordPress.org, nécessaire avant la toute première publication d’une extension, ne fait pas partie de ce sujet.
Structurer le dépôt pour distinguer code et distribution
Un dépôt Git de développement contient généralement des fichiers qui n’ont rien à faire dans la version distribuée aux utilisateurs finaux : tests, configuration CI, dépendances de développement, fichiers de build source. Le fichier .distignore, à la racine, liste ce qu’il faut exclure au moment de la publication, par analogie avec .gitignore :
.git
.github
.gitignore
.distignore
node_modules
tests
phpunit.xml.dist
composer.json
composer.lock
package.json
package-lock.json
webpack.config.js
src
.editorconfig
README.md
Notez que README.md (destiné aux développeurs sur GitHub) est exclu, mais le fichier readme.txt au format spécifique attendu par WordPress.org, lui, doit être conservé — c’est ce dernier qui alimente la page de présentation de l’extension sur le répertoire officiel.
Le workflow GitHub Actions
L’action communautaire 10up/action-wordpress-plugin-deploy encapsule toute la mécanique SVN. Le workflow se déclenche à la publication d’une release GitHub :
name: Déploiement WordPress.org
on:
release:
types: [published]
jobs:
tag:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Installer les dépendances de production
run: composer install --no-dev --optimize-autoloader
- name: Déployer vers WordPress.org
uses: 10up/action-wordpress-plugin-deploy@stable
env:
SVN_USERNAME: ${{ secrets.SVN_USERNAME }}
SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
Les identifiants SVN — ceux du compte WordPress.org de l’auteur de l’extension — sont stockés en secrets protégés du dépôt GitHub, jamais en clair dans le fichier de workflow.
Gérer les assets visuels (icône, bannière, captures d’écran)
Les éléments visuels de la page du répertoire (icône, bannière, captures d’écran) vivent dans un dossier .wordpress-org à la racine du dépôt Git, séparé du code de l’extension lui-même :
.wordpress-org/
├── icon-128x128.png
├── icon-256x256.png
├── banner-772x250.png
└── screenshot-1.png
L’action de déploiement synchronise automatiquement ce dossier vers le répertoire assets du dépôt SVN, distinct de trunk, sans qu’il soit nécessaire de le référencer explicitement dans .distignore.
Synchroniser le numéro de version
WordPress.org attend une cohérence stricte entre trois emplacements : l’en-tête du fichier principal du plugin, la constante de version PHP éventuelle, et le champ Stable tag du readme.txt. Une divergence entre ces valeurs peut entraîner un mauvais affichage de version sur la page du répertoire, voire empêcher WordPress d’informer les utilisateurs d’une mise à jour disponible.
- En-tête du fichier principal :
Version: 2.4.0 readme.txt:Stable tag: 2.4.0- Éventuelle constante PHP :
define( 'MON_PLUGIN_VERSION', '2.4.0' );
Un petit script exécuté en amont du workflow, ou un outil comme release-please, peut automatiser cette synchronisation pour éviter l’erreur humaine classique d’un oubli sur l’un des trois emplacements.
Cycle complet, du tag Git au tag SVN
Une fois ce pipeline en place, publier une nouvelle version d’extension revient à créer une release GitHub avec le bon numéro de tag — le reste, y compris la mécanique SVN que je ne maîtrise toujours pas dans le détail, se déroule automatiquement.
git tag v2.4.0
git push origin v2.4.0
# Puis créer la release depuis l'interface GitHub, ou :
gh release create v2.4.0 --title "2.4.0" --notes "Voir CHANGELOG.md"
La création de la release GitHub déclenche automatiquement le workflow, qui pousse le contenu du dépôt (filtré par .distignore) vers trunk, crée le tag SVN correspondant, et synchronise les assets visuels — sans qu’aucune commande SVN n’ait été tapée manuellement.
Pour aller plus loin
Ce pipeline supprime la barrière technique de SVN pour les équipes qui ne travaillent qu’en Git au quotidien, sans nécessiter d’apprendre ses commandes. Le point de vigilance principal reste la rigueur du .distignore : un oubli peut publier accidentellement des fichiers de développement, voire des identifiants de test, sur le répertoire public de WordPress.org.
