Vous avez une idée d’extension et vous voulez la partager avec des millions d’utilisateurs sur le répertoire officiel de WordPress ? Excellent !

Dans cet article, on va passer en revue les pré-requis et recommandations pour publier une extension sur le répertoire officiel de WordPress dans les règles de l’art, maximiser vos chances de le faire sans des dizaines d’allers-retours/essais-erreurs frustrants, et tout mettre en place pour faciliter ses mises à jour futures.

Comment ça marche

Le répertoire officiel contient plus de 58,000 extensions. C’est énorme. Gigantesque. C’est aussi un moyen privilégié d’être visible par des millions d’utilisateurs, directement dans leur tableau de bord !

Le répertoire est géré par une équipe de contributeurs bénévoles, qui, entre autres, sont chargés de lire le code des nouveaux plugins soumis par la communauté pour s’assurer de leur qualité, gérer les accès des contributeurs, communiquer avec les auteurs pour les assister, écrire de la documentation, assister à des meetings d’équipes, etc…. Du GROS boulot.

Une fois notre super extension développée, nous allons la soumettre au répertoire de WordPress, et un des membres de cette équipe va lire son code, pour s’assurer de sa qualité et du respect des guidelines, et s’il repère des soucis, que ce soit de convention, de sécurité ou autre, il va prendre le temps d’écrire un rapport formel et détaillé, en nous demandant de faire les modifications demandées rapidement pour que l’extension soit validée.

Donc, pour leur faciliter leur travail (et notre futur travail aussi !), on va essayer de bien préparer et planifier notre extension.

Planifier votre extension

Avant de se lancer dans le développement, il peut être utile de comprendre un peu ce qui est attendu des développeurs et contributeurs de WordPress. Rien de bien compliqué, juste quelques règles, recommandations, et un peu de bon sens.

Les guidelines

Toutes les extensions ne sont pas acceptées sur le répertoire officiel de WordPress. WordPress véhicule certaines valeurs, et il y a un certain nombre de critères à respecter, qu’ils concernent l’éthique de votre extension ou sa qualité.

Par exemple, TOUTES les extensions doivent être distribuées sous une licence compatible avec la GPL 2 ou plus. WordPress utilise la GPL 2 ou plus, il est donc fortement recommandé d’utiliser cette licence. Autre exemple, les trialwares ne sont pas autorisés. Autrement dit vous n’avez pas le droit de bloquer le fonctionnement de votre extension après X jours par exemple. Vous n’avez pas non plus le droit de tracker vos utilisateurs sans leur consentement.

La liste complète des lignes de conduites du répertoire se trouvent ici : https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

Honnêtement, ce n’est pas très compliqué et la plupart tombent sous le sens. Mais ça vaut toujours le coup de les lire AVANT d’entamer le développement de votre extension.

Les Codings Standards

Les Codings Standards sont un ensemble de règles et conventions utilisées pour écrire votre code. Il n’est pas obligatoire de toutes les respecter à la lettre, mais elles permettent d’uniformiser un peu le code produit par les différents (les milliers / millions ?) de contributeurs et auteurs d’extensions et thèmes.

Respecter les standards permet à tout le monde de lire votre code plus facilement, et inversement, vous pourrez lire et comprendre facilement le code écrit dans le respect des standards.

La plupart des “règles” sont très simples à appliquer. Par exemple, il est recommandé de placer les accolades ouvrantes des déclarations de fonction en bout de ligne, et pas à la ligne. Ou alors, un tableau devrait être en général déclaré avec la notation longue array() plutôt que la notation [].

// This is correct
function my_function( $param ){
    $array = array();
    // code
}

// This is NOT correct
function my_function($param)
{
    $array = [];
    // code
}

Il existe des recommandations pour tous les langages, et vous pouvez les trouver ici : https://make.wordpress.org/core/handbook/best-practices/coding-standards/

Un bon nom

Cela peut paraître évident, mais quand vous choisissez un nom pour votre extension, vérifiez qu’une extension du même nom n’existe pas déjà ! Cela peut arriver !

Aussi, ayez à l’esprit que le nom de votre extension va être utilisé partout : idéalement dans le nom du dossier, du fichier racine de votre extension, dans votre text-domain et dans le préfixe des fonctions disponibles globalement (plus de détails sur le sujet un peu plus loin). Donc choisissez un nom pas trop verbeux, mais assez spécifique. Votre nom doit être évocateur et décrire ce que fait votre extension, simplement.

Pendant le développement

La façon dont vous allez développer va conditionner la difficulté avec laquelle votre extension va être validée sur le répertoire officiel. Comme pour les éléments discutés précédemment, voici quelques règles, recommandations et passages obligés pour maximiser vos chances de succès.

Soignez votre entête

Pour que WordPress reconnaisse votre extension, vous devez inclure une entête dans le fichier racine de votre extension, sous forme d’un simple bloc de commentaires PHP, contenant diverses informations utiles. Au niveau purement fonctionnel, une seule entrée est nécessaire.

<?php 
/**
 * Plugin Name: My awesome plugin
 */

Cependant, cela ne sera pas suffisant pour que votre extension soit validée sur le répertoire, et il vous faudra inclure un ensemble d’informations bien plus exhaustif.

<?php
/**
 * Plugin Name:       My awesome plugin
 * Plugin URI:        https://wordpress.org/plugins/my-awesome-plugin/
 * Description:       Does awesome stuff.
 * Version:           1.0
 * Requires at least: 5.0
 * Requires PHP:      7.0
 * Author:            Vincent Dubroeucq
 * Author URI:        https://vincentdubroeucq.com/
 * License:           GPL v2 or later
 * License URI:       https://www.gnu.org/licenses/gpl-2.0.html
 * Text Domain:       my-awesome-plugin
 * Domain Path:       languages/
 */
  • Plugin URI est l’adresse à laquelle l’extension sera disponible. Si votre extension est validée, alors l’équipe des extensions vous communiquera cette URL. Vous ne pourrez donc pas forcément remplir cette entête avant qu’elle soit validée.
  • Description est une description courte apparaissant dans l’administration de WordPress (140 caractères max).
  • Version est la version de votre extension. Utilisez un numéro de version sémantique: majeure.mineure.correctif.
  • Requires at least et Requires PHP sont la version minimale de WordPress et de PHP nécessaires pour que l’extension fonctionne correctement. La version minimale de WordPress est simplement la version à laquelle est apparue la fonction la plus récente que vous utilisez. Par exemple, si vous utilisez la fonction get_theme_file_uri() dans votre extension, alors les utilisateurs ont au moins besoin de la version 4.7 de WordPress, puisque cette fonction est apparue dans cette version. Vous pouvez scanner automatiquement votre extension en utilisant l’outil de WPSeek : https://fr.wpseek.com/pluginfilecheck/.
  • Author et Author URI : C’est vous (et votre site web) ! Si vous travaillez à plusieurs sur l’extension, vous pouvez mettre plusieurs noms séparés par des virgules.
  • Licence et Licence URI sont l’intitulé et le lien vers la licence sous laquelle votre extension sera distribuée. Comme expliqué précédemment, même si techniquement, on peut utiliser n’importe quelle licence compatible avec la GPL, on utilise en général la même que WordPress : GPL 2 ou plus.
  • Text Domain : C’est un identifiant qui va être utilisé pour grouper vos traductions et distinguer les chaines de votre extension de celle des autres et du coeur.
  • Domain Path : C’est le chemin que WordPress va utiliser pour chercher les traductions de votre extension.

En hébergeant votre extension sur le répertoire officiel vous pouvez ne pas inclure ni le Text Domain ni le Domain Path, car vous allez pouvoir directement éditer vos traductions sur https://translate.wordpress.org, et les traductions sur ce site sont prioritaires à celle embarquées dans votre extension. Par contre, il faut que votre Text Domain soit identique au slug de votre extension !

Ensuite, c’est toujours bien d’inclure soit le texte complet de la licence dans un fichier licence.txt, ou alors un petit message indiquant sous quelles conditions et licences l’extension est distribuée.

/*
My Awesome Plugin is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 2 of the License, or
any later version.
 
My Awesome Plugin is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
 
You should have received a copy of the GNU General Public License
along with My Awesome Plugin. If not, see https://www.gnu.org/licenses/gpl-2.0.html
*/

Remplir l’entête n’est pas compliqué, mais c’est une formalité obligatoire et utile.

Organiser vos fichiers

C’est très simple. Il n’y a pas de règle.

Mais en général, on ne trouve à la racine du dossier que le fichier racine de l’extension, la licence et quelques fichiers comme le readme.txt, .gitignore si vous travaillez sous Git ou package.json si l’extension utilise des scripts npm.

Toutes les fonctionnalités de l’extension sont en général rangées dans des dossiers distincts. Vous pouvez par exemple créer un dossier includes/ avec les fichiers inclus dans votre extension. Ou ranger les fonctionnalités du côté administration dans un dossier admin/. Les ressources CSS et JS peuvent aussi être rangées dans leurs dossiers respectifs, ou dans un dossier assets/. Si votre extension affiche du contenu sur le devant du site, un dossier templates/ peut être pertinent.

Cela dépend énormément de la complexité de votre extension, mais plus votre structure de dossier est organisée et claire, et plus vous vous faciliterez la maintenance de votre extension et plus vous faciliterez les contributions d’autres développeurs.

Utiliser au maximum l’existant de WordPress

WordPress est une grosse bécane qui dispose d’énormément d’outils. Il y a des APIs pour tout : pour effectuer des requêtes HTTP, pour lire/écrire dans la base de données, pour créer des types de contenus personnalisés, pour créer des métaboxes, pour créer des blocs, pour gérer des uploads, etc…

L’idée est simple : ne réinventez pas la roue ! Réutilisez au maximum les fonctions natives de WordPress. Quel que soit votre besoin, il y a de grande chances que WordPress dispose déjà d’un outil qui permette de le combler, ou alors de faire 80% du travail. Un peu de développement personnalisé et quelques filtres/actions peuvent suffire.

Plus vous réutiliserez l’existant de WordPress, plus vos développements seront solides et fiables, car vous vous appuyez sur du code testé, et constamment amélioré !

Tout refaire “à votre sauce” vous donne uniquement du travail supplémentaire, et est bien plus risqué. Pourquoi refaire une fonction pour afficher des images quand wp_get_attachment_image() et ses soeurs font le travail, en générant les attributs sizes et srcset automatiquement ? Pourquoi redévelopper un formulaire de connexion personnalisé quand on dispose de la fonction wp_login_form() dont on peut personnaliser les arguments ?

Avant de considérer tout développement, réfléchissez d’abord à comment intégrer votre développement dans WordPress et réutiliser au maximum les outils dont nous disposons déjà, simplement.

Pas de chaines hardcodées

Toutes les chaines de caractères affichées par votre extension doivent être traduisible. Toutes.

Jamais de texte “en dur” dans une extension. JAMAIS. Sauf pour les identifiants de vos réglages ou options évidemment.

// Nope !
<h1>My Awesome settings page</h1>

// Do this
<h1><?php __( 'My Awesome settings page', 'my-awesome-plugin' ); ?></h1>

Rendre votre extension traduisible est très simple. Il suffit d’utiliser les fonctions __(), _e(), et ses amies pour déclarer ou afficher nos chaines.

__() prends deux arguments : la chaine à traduire (qui sera par défaut en anglais car la langue par défaut de WordPress est l’anglais) et le Text Domain de votre extension, pour que WordPress s’y retrouve dans les traductions et trouve la traduction de votre chaine dans le bon groupe. La fonction retourne la chaine traduite, selon la langue courante.

La fonction _e() fonctionne de la même façon, mais affiche la chaine. Il existe d’autres fonctions de traductions et je vous invite à lire l’article Internationaliser son thème ou extension WordPress pour plus de détails.

Pensez à inclure un fichier .pot dans votre extension, pour faciliter le travail de traduction.

Publier votre extension

Soignez votre readme.txt

Pour que votre extension soit acceptée sur le répertoire officiel de WordPress, il FAUT fournir un minimum de documentation sous la forme d’un fichier readme.txt. Les informations de ce fichier sont celles que les utilisateurs trouveront sur la page de votre extension.

Page de détails d&#039;une extension sur WordPress.org
Les informations de votre readme sont affichées sur cette page.

Vous pouvez trouver un modèle de readme.txt sur https://wordpress.org/plugins/readme.txt .

Chaque section titrée est encadrée par des “=”. La première section contient une entête qui ressemble à celle de l’extension. Mais aussi quelques champs particuliers :

  • Contributors: liste les identifiants wordpress.org des contributeurs
  • Tags : liste de mots clés, séparés par des virgules qui peuvent être utilisés pour trouver votre extension sur le répertoire, via la recherche.
  • Stable tag : Ce champ est très important. C’est le numéro de la version stable de votre extension, c’est-à-dire celle qui sera effectivement téléchargée quand les utilisateurs cliqueront sur le bouton pour ce faire, sur https://wordpress.org/plugins ou dans l’administration de leur site.

Sous cette entête, mais toujours dans la première section, vous pourrez ajouter une courte description qui apparaitra sur la liste des extensions,

Page des extensions sur WordPress.org
Votre description courte apparait sur la page listant les extensions.

Ensuite, on dispose de diverses sections pour classer nos informations :

  • == Description == : C’est la description longue de votre extension. Ici, vous pouvez utiliser du markdown si vous le souhaitez. C’est le contenu de la page de votre extension.
  • == Frequently Asked Questions == : Section FAQ. Chaque sous-titre est une question, et vous pouvez ajouter autant de questions et réponses que vous le souhaitez. Sur la page de votre extension, cela s’affichera sous forme de section accordéons. Nice.
  • == Screenshots == : Cette section est une liste numérotée des légendes de chacun de vos screenshots. Le nom de fichier de chacune de vos captures d’écran doit être numéroté et préfixé par screenshot- . Cela donne donc screenshot-1.png, screenshot-2.png, screenshot-3.png, etc… Chaque entrée dans cette liste numérotée correspond à la légende du screenshot du même numéro, simplement.
  • == Changelog == : Pour chaque version, listez ici les modifications effectuées.
  • == Upgrade Notice == : Pour chaque version, vous pouvez publier un message expliquant pourquoi un utilisateur devrait mettre à jour.

Aussi, vous pouvez ajouter autant de sections arbitraires que vous désirez. Il suffit d’insérer un titre entre == et le contenu en markdown juste en dessous.

Préparez vos assets

Les assets sont les médias qui vont être affichés sur la page de votre extension et sur la page listant les extensions, aussi bien sur le site https://wordpress.org/plugins que dans l’administration.

Ici, les règles sont strictes. Le répertoire attends des noms de fichiers et des dimensions bien précis pour fonctionner correctement. Idéalement, vous fournirez les fichiers suivants :

  • banner-1544x500.png : c’est l’image d’entête de votre extension, en 1544px par 500px, pour les écrans retinas. Vous pouvez fournir soit un .png, ou alors un .jpg.
  • banner-1544x500-rtl.png : si votre bannière contient du texte ou d’autres éléments dont la lecture devrait être adaptée pour les langues lisant de droite à gauche, alors vous pouvez inclure une bannière adaptée également.
  • banner-772x250.png : même chose que précédemment, mais pour les écrans standards. L’image doit faire 772px par 250px.
  • banner-772x250-rtl.png : version lisible de droite à gauche de votre bannière pour écrans standards.
  • icon-256x256.png : Vignette de votre extension. C’est la version retina de votre vignette, et doit faire 256px par 256px. Vous pouvez aussi fournir un .jpg ou un .svg ici, si vous le souhaitez.
  • icon-128x128.png : Version low-res de votre vignette.
  • screenshot-1.png : Votre première capture d’écran. N’oubliez pas sa légende dans le fichier readme.txt ! Vous pouvez aussi fournir un fichier .jpg.
  • screenshot-2.png : …

Vous pouvez mettre autant de screenshots que nécessaire.

Et c’est tout ! Une bannière dans différentes tailles, votre icone, et vos screenshots !

Soumettre votre extension

Une fois votre extension développée, votre documentation readme.txt peaufinée, et vos médias prêts, vous pouvez soumettre votre extension sur le répertoire officiel. Il vous suffit de vous rendre sur https://wordpress.org/plugins/developers/add/ et de fournir une archive zip de votre extension.

Page de soumission d&#039;extension WordPress
Page de soumission des extensions.

Par contre, il est recommandé de ne pas fournir les fichiers utilisés lors du développement. Typiquement, pas besoin d’inclure votre dossier .git/ et votre .gitignore si vous utilisez Git, ni votre dossier node_modules/ .

Ces fichiers sont utiles pour le développement et ont donc une place dans votre dépôt Git, mais pas sur le SVN de wordpress.org, simplement parce ce n’est pas un dépôt utilisé pour le développement, mais pour les releases. L’idée est que les utilisateurs ne devraient télécharger que les fichiers dont ils ont besoin dans le cadre d’une utilisation normale de l’extension.

Votre extension va ensuite simplement dans une liste d’attente, et sera revue par un membre de l’équipe des plugins quand il le pourra. Selon le nombre d’extensions dans la file d’attente, le processus de review peut prendre plus ou moins longtemps.

Encore une fois. Ces personnes sont bénévoles et ont d’autres occupations. Des extensions sont soumises sur le répertoire tous les jours. Soyez sympas, et soyez patients. Ne vous énervez pas s’ils mettent du temps. Personnellement, je n’ai jamais eu à me plaindre du service. J’ai toujours eu mes extensions validés (ou non) dans la semaine ou les 15 jours.

Aussi vous recevrez un mail vous annonçant la future URL et le futur slug de votre extension. S’il y a un souci avec votre nom de plugin, slug, ou url, surtout envoyez de suite un mail à plugins@wordpress.org. Une fois votre extension approuvée, il sera trop tard pour changer de nom/slug !

Quand votre extension sera revue, il y a deux possibilités :

  • Soit elle contient quelques erreurs ou il manque des informations dans vos entêtes ou votre readme.txt, ou alors il y a une faille de sécurité, ou tout autre souci : le responsable de votre review va vous soumettre un rapport détaillé. Lisez-le entièrement et attentivement. Pas en diagonale. Faites les modifications demandées, et soumettez de nouveau votre extension.
  • Soit elle est validée directement : champagne !

Une fois votre extension validée, vous recevrez un mail vous fournissant l’URL de votre extension sur wordpress.org et l’URL vers son dépot SVN.

Utiliser SVN

Normalement, à ce stade, votre extension est validée, vous avez donc accès au SVN du répertoire et vos assets sont prêtes ! Ya plus qu’à !

L’objectif est maintenant de publier votre extension sur le SVN distant pour la rendre publique.

SVN est un outil de contrôle de version, tout comme Git, mais il s’utilise un peu différemment. Quand on développe avec Git, on va généralement valider nos changements pas à pas, et pousser régulièrement sur le dépôt Git. On peut aussi taguer des versions stables pour guider nos utilisateurs.

Sur le dépôt de WordPress, on va uniquement publier nos versions stables. C’est-à-dire que le dépôt SVN n’est pas vraiment un outil de développement, mais plutôt un outil de publication. Vous n’allez pas publier régulièrement sur SVN, mais uniquement publier les mises à jour de votre extension, que les utilisateurs vont télécharger.

Aussi, la structure du dépôt SVN distant est spécifique à WordPress, et il faudra vous y plier pour que tout fonctionne directement.

Pour utiliser SVN, il faudra installer soit l’outil en ligne de commande, soit un client comme TortoiseSVN, qui va vous offrir une intégration dans votre environnement. Personnellement, je préfère utiliser la ligne de commande que polluer mon interface de navigation de tous les jours.

Une fois l’outil installé, on peut commencer ! On va devoir :

  • Télécharger notre dépôt distant, qui est prêt à recevoir nos fichiers
  • Y copier nos fichiers et nos assets.
  • Valider nos changements et téléverser nos modifications.

Télécharger le dépôt distant

La première étape est de créer une copie de travail locale de notre dépôt. La structure du dossier distant est différente de celle de notre extension, donc on va faire ça dans un nouveau dossier.

Dans le dossier de notre extension, on va créer un dossier svn/ pour y mettre notre copie de travail. Ouvrez un terminal et créez un dossier. J’utilise le terminal intégré de VSCode, mais vous pouvez utiliser ce que vous voulez.

mkdir svn
Créez un dossier pour votre dépôt SVN
Créez un sous dossier svn/ dans le dossier de notre extension

Une fois notre dossier prêt, on va télécharger le contenu du dépôt distant dans ce dossier. Dans votre terminal, entrez les commandes suivantes : 

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

Evidemment, remplacez l’url donnée ici en exemple par l’url de votre extension, donnée dans le mail de validation de cette dernière.

svn checkout permet de valider vos changements
Le dossier distant a bien été téléchargé.

Pour l’exemple, j’ai pris une de mes extensions, Tiny Default Thumbnail. Vous remarquerez que dans mon dossier svn/, j’ai un dossier tiny-default-thumbnail/ avec trois sous-dossiers :

  • assets/ : ce dossier va contenir toutes les images, bannières et screenshots nécessaires pour que notre page d’extension sur https://wordpress.org/plugins fonctionne correctement. Copiez-y simplement les assets préparées précédemment, en vous assurant qu’elles aient le bon nom de fichier.
  • tags/ va contenir toutes vos versions stables, c’est-à-dire toutes les versions successives que vous avez publiées.
  • trunk/ va contenir la dernière version de notre code, même si c’est encore une beta. Normalement, les versions que les utilisateurs vont télécharger sont les versions dans le dossier tags/. Mais il convient de mettre ici la dernière version stable de votre extension.

Préparez votre copie de travail

Dans le dossier trunk/, copiez-collez les fichiers de votre extension. Ne copiez pas les assets, ni les fichiers de développement (node_modules/, package.json, etc…). Juste les fichiers nécessaires pour que votre extension soit utilisable. Aussi, prenez garde à ne pas copier-coller dans un sous-dossier. Le fichier racine de votre extension doit être à la racine de trunk/.

Ce dossier doit contenir la dernière version de votre code, et c’est le fichier readme.txt de ce dossier qui sera lu pour déterminer la version taguée à aller chercher et zipper pour vos utilisateurs.

Dans le dossier tags/, créez un dossier avec pour nom le numéro de version de votre extension, (celui de votre readme.txt !), et copiez-collez-y la même chose.

Si vous observez bien la capture d’écran juste au dessus, vous verrez que j’ai deux sous-dossiers dans tags/, car j’ai publié une petite mise à jour pour cette extension. Mon dossier trunk/ contient cette version 0.1.1, et le readme.txt pointe bien vers le tag 0.1.1

Dans votre dossier assets/ , copiez vos screenshots, bannières et icones. si vous ne l’avez pas déjà fait.

C’est tout ! Votre copie de travail est à jour ! Vous êtes prêts à publier !

Publier votre extension

Pour publier votre extension, retour au terminal. Naviguez dans votre dossier d’extension et inspectons les changements.

cd tiny-default-thumbnail
svn status

svn status va afficher l’état de votre copie de travail, et va vous indiquer quels sont les nouveaux fichiers dont SVN n’avait pas connaissance (marqués d’un “?”) et les fichiers modifiés (marqués d’un “M”).

svn status vérifie l&#039;état de votre dépôt
Le rapport de SVN indique qu’il y a des nouveaux fichiers et des fichiers modifiés.

Dans mon exemple, j’ai ajouté une version 0.1.2, donc j’ai modifié le contenu du dossier trunk/ , mis à jour le readme.txt pour que ce dernier pointe bien vers ma dernière version, et créé un dossier tags/0.1.2/ avec la dernière version de mon code.

SVN m’indique qu’il y a un nouveau dossier tags/0.1.2/ et que deux fichiers ont été modifiés dans trunk/.

Dans le cas d’une nouvelle extension, il y aura bien plus de fichier inconnus de SVN, ce qui est normal.

On va indiquer à SVN qu’on veut ajouter nos nouveaux fichiers et qu’il devra tracker les changements sur ces fichiers.

svn add tags/0.1.2
svn status
svn add prépare vos changements pour validation
Nos nouveaux fichiers sont maintenant ajoutés au système de contrôle de version.

On peut voir ici que les nouveaux fichiers sont marqués d’un “A”, comme “Added”. Maintenant, SVN les reconnait et va tracker les changements sur ces nouveaux fichiers.

Dans le cas d’une nouvelle extension, il faudra ajouter plus de fichiers : les fichiers du dossier trunk/ de votre premier tag, et des assets/ .

Une fois vos fichiers ajoutés, il est temps de publier.

svn commit -m "A message to help identify the commit"

Cette commande va propager votre copie de travail sur https://plugins.svn.wordpress.org, ce qui va rendre votre extension publique. Pensez à utiliser un message court mais explicite.

Si SVN ne l’a pas déjà fait, il va vous demander vos identifiants. Pour pousser sur le répertoire officiel, utilisez les identifiant et mot de passe de votre compte https://wordpress.org. Tout simplement.

Félicitations !

Mettre à jour votre extension

Quelques jours plus tard (ou minutes dans mon cas, car j’oublie toujours quelque chose, ou j’ajuste toujours quelque chose après avoir visité la page de mon extension ! ) vous décidez de publier une mise à jour pour votre extension.

Le procédé est exactement le même :

  • Mettez à jour votre copie de travail locale avec svn checkout
  • Copiez vos changements dans trunk/, créez votre version dans tags/ et assurez vous que le fichier readme.txt ainsi que l’entête de votre extension soient à jour (notamment au niveau du numéro de version).
  • Vérifiez que SVN ait bien pris en compte tous vos nouveaux fichiers et modifications à l’aide de svn status
  • Utilisez svn add pour ajouter vos nouveaux fichiers.
  • Utilisez svn commit -m "Super message" pour valider vos changements et pousser sur le répertoire officiel.

Félicitations !

Votre extension est publiée ! Vous avez officiellement contribué à WordPress ! Maintenant l’aventure commence ! Vous allez devoir la maintenir, la promouvoir, répondre au support, etc…

Au final, publier n’est pas très compliqué ni technique. c’est juste un peu de bon sens et quelques règles d’organisation, pour la santé du répertoire, et la votre !

Pour résumer un peu :

  • Préparez votre projet, en lisant les guidelines officielles, les coding standards, et en trouvant un nom qui n’existe pas déjà.
  • Développez votre projet en préparant bien votre entête, en réutilisant au maximum l’existant de WordPress, et en facilitant la localisation de votre extension.
  • Préparez votre publication et préparant soigneusement votre readme.txt, vos screenshots, vos bannières et vos icones.
  • Soumettez votre extension et soyez sympa et patient. Effectuez les modifications demandées s’il y en a et répétez l’opération.
  • Quand tout est ok, utilisez SVN pour mettre en ligne.

J’espère que cet article vous aura aidé à y voir plus clair et que vous êtes prêts et motivés à contribuer à WordPress ! Go !

Enjoy !