Déployer son extension Gutenberg sur le répertoire WordPress

Ca y est vos blocs sont codés, votre extension prête à voir le jour ? Voici quelques petites étapes importantes pour faire le grand saut !

Créer la build de votre extension

La première chose, si vous avez utilisé create-block, est de lancer la build, qui aura pour effet de compiler et compresser les scripts et styles situés dans le dossier /build/.

Pour cela munissez-vous de votre terminal, allez dans le dossier de votre extension et lancez la commande npm run build.

Le script s’occupe du reste. Une fois terminé il vous indique le poids des fichiers compressés :

En général vos fichiers ne devraient pas dépasser les quelques Ko. Si j’ouvre le le fichier JS, je vois bien que le code est désormais compressé : plus de retour à la ligne, de commentaires ou d’espaces inutiles, et des noms de variables raccourcis.

Ce que l’on aperçoit ici, c’est du JS natif, compris par tous les navigateurs, même les pas modernes (c’est toi que je regarde, Internet Explorer).

Voilà, c’est tout ce qu’il y a à faire dans cette partie là !

Par contre, lorsque vous relancerez npm start, le fichier sera recompilé sans compression. Pensez donc d’abord à commit la modification sur Git.

Les fichiers à garder et à supprimer

Il y a dans notre dossier d’extensions plusieurs fichiers utiles au développeur, mais qu’il n’est pas nécessaire de garder dans la version finale, voici en rouge ce que je ne conserve pas :

Le dossier .git est utile pour le versionnement du projet, et n’a donc rien à faire dans la release finale.

Pareil pour le dossier node_modules : les scripts nécessaires au bon fonctionnement de votre code on été intégrés dans votre JS, dans build. Beaucoup d’entre eux étaient d’ailleurs surtout nécessaires pour la compilation Webpack et n’ont donc pas du tout été conservés.

Tous les fichiers qui commencent par un point et sont en général des fichiers de configuration, comme .gitignore, n’ont pas non plus leur place en finale.

Le package.json ne sera pas non plus de la partie, ni le package-lock.json.

Attendez la suite cependant avant toute manipulation. Au lieu de faire une copie à la main vers SVN, je vais vous montrer un outil vraiment top !

Proposer son extension sur le répertoire

Afin de proposer votre extension sur le répertoire officiel des extensions WordPress, il faut se rendre ici :

Soumettez votre extension

Avant toute chose pensez bien à lire les guidelines pour vous assurer d’être en conformité avec la charte WordPress.

Quelques infos à connaitre :

• Le nom de votre extension ne peut pas commencer par Gutenberg, ce nom est réservé à ses éventuels add-ons officiels (même si à terme, ce ne sera plus une extension) ;
• Votre extension et ses librairies doivent être compatibles avec la licence GNU ;
• Si vous utilisez une librairie pour tracer les utilisateurs (statistiques d’usage, infos de débug) vous devez absolument demander leur consentement en amont ;
• Vous devez utiliser en priorité les librairies par défaut de WordPress, dans le sens où, si vous utilisez jQuery, utilisez la version fournie par WordPress pour éviter de faire doublon.

En proposant votre extension, vous serez averti du nombre d’extensions en attente de relecture validation avant vous :

On voit ici qu’il y a 8 extensions dans la file d’attente, vous serez la neuvième. Les choses peuvent aller plus ou moins vite, comptez 2 à 7 jours.

Heureusement cette étape n’est à faire que la première fois. Une fois que vous aurez votre validation, vous pourrez pousser vos nouvelles versions directement.

Déploiement via SVN

Ah, la pire partie ! Eh oui, WordPress avait fait le choix de SVN il y a très longtemps, mais aujourd’hui tout le monde est sur Git.

Et pour une bonne raison puisque SVN est assez complexe. Personnellement je déteste. Mais heureusement, je vais vous donner une solution bien plus simple juste après.

Prenez quand même le temps de regarder dans la documentation comment fonctionne SVN avec WordPress. Pour faire court, le but est de mettre le code dans un dossier trunk, mais également dans un dossier tag/1.0. Dans ce dossier tag il faudra conserver toutes les versions du code.

Gestion des assets

Il va falloir également préparer le nécessaire en terme de visuels : captures d’écran, logos, bannières qui seront affichés sur votre page d’extension :

Pour cela je vous conseille de lire la page dédiées aux assets de plugins. Il va vous falloir préparer des images sur plusieurs formats (standard puis retina, en bannière et en carré, pour le logo). Et il faut respecter le nommage des fichiers :

• Bannière
  • Normal Banner: banner-772x250.(jpg|png)
  • High-DPI (Retina): banner-1544x500.(jpg|png)
• Logo
  • Normal: icon-128x128.(png|jpg)
  • High-DPI (Retina): icon-256x256.(png|jpg)
  • SVG: icon.svg

Les versions RTL (pas la radio, mais Right To Left) ne sont plus utilisées dans la nouvelle interface du site wordpress.org, donc ne vous embêtez pas avec !

De Git à SVN : vous simplifier le déploiement

Libre à vous d’utiliser SVN. Personnellement ça me rend fou.

Heureusement, Maxime Culea a trouvé une solution qui fait absolument TOUT tout seul, via une simple commande.

Voici le lien vers son tutoriel :

Tutoriel Git to SVN

Il repose sur un script appelé WP Plugin Git to SVN disponible sur Github et créé par un certain Raymond Rutjes, développeur chez Algolia.

Le principe de cette extension est très simple :

Le script récupère la dernière version de votre extension sur Github, la copie sur votre ordinateur, fait le nettoyage de fichiers, le rangement dans les dossiers trunk/tag, et envoie vers wordpress.org le dossier SVN bien constitué.

Alors au lieu de tout réexpliquer, je vous invite à consulter le tutoriel de l’autre Maxime.

Quelques petites choses à savoir :

Au début j’ai cru que le script devait être placé dans votre extension, mais non : comme elle récupère les fichiers depuis Github, vous devez mettre ça dans un autre dossier, n’importe où ailleurs dans votre système ! Comme ça ce script et votre extension restent complètement indépendants.

Concernant les assets, il va vous falloir créer, dans votre plugin cette fois, un dossier .wordpress.org (le premier point est important) qui contient les images (bannière, logo, captures d’écrans).

Et enfin, il faudra ajouter un fichier .distignore, qui va permettre d’indiquer au script les fichiers à ne pas envoyer vers WordPress, tous ceux que l’on a vu un peu avant, et qui sont taggués en rouge sur la capture ci-dessus.

Adaptez bien entendu cette liste en fonction des particularités de votre projet.

Et ça marche à la perfection, c’est magique ! Une fois la commande lancée, tout se fait tout seul, et une minute après vous recevrez un e-mail de wordpress.org indiquant le bon déroulé de la manipulation. Votre mise à jour est alors disponible officiellement sur le répertoire !

Les numéros de version

Pour que la manipulation marche bien, il faut penser à mettre à jour le numéro de version de votre extension, pour cela modifiez-le dans le readme.txt mais aussi dans votre plugin.php.

Le script se base là dessus pour gérer les versions automatiquement.

Vous devrez également créer une release (un Tag) sur Git, correspondant au numéro de version. Cela vous permet en plus de garder un historique et de savoir quels étaient les modifications incluses à chaque jalon :

Et voilà, avec ça vous êtes prêt pour publier votre extension et la présenter au monde entier ! Et grâce à ce script (encore merci à Maxime Culea pour cette découverte !) vous allez pouvoir éviter de vous prendre la tête avec SVN !