Vous êtes fier de votre extension et de vos blocs Gutenberg ? On va voir dans ce cours comment la mettre en production ! On va également voir comment la mettre sur le répertoire officiel des extensions WordPress afin d’en faire profiter tout le monde.
Sommaire du cours
Ca y est vos blocs sont codés, votre extension prête à voir le jour ? On va voir comment mettre en production votre extension sur votre hébergement.
Mais on va également voir les étapes pour la proposer sur le répertoire officiel des extensions WordPress si vous souhaitez la partager avec la communauté.
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/.
Vidéo premium
Cette vidéo est réservée aux détenteurs de l’offre premium.
Envie de nous rejoindre ?
Pour cela munissez-vous de votre terminal, allez dans le dossier de votre extension et lancez la commande npm run build.
Webpack s’occupe ensuite 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 plus vétustes, grâce à Babel et Webpack.
Voilà, c’est tout ce qu’il y a à faire dans cette partie là !
Par contre, lorsque vous relancerez npm start pour continuer le développement de vos blocs, les fichiers seront recompilés sans compression cette fois. Il faudra alors relancer une build ultérieurement.
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.
Vidéo premium
Cette vidéo est réservée aux détenteurs de l’offre premium.
Envie de nous rejoindre ?
Voici en rouge ce que je ne conserve pas lors d’une mise en production :
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 le dossier /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.
Même chose pour vos fichiers dans /src/, qui ont été compilés vers /build/.
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.
Pour automatiser cela dans une logique de CI/CD, vous pouvez mettre en place des Github Actions pour lancer la build automatiquement depuis votre réprtoire, et nettoyer les fichiers inutiles, puis envoyer en production.
Votre extension est désormais prête à être mise en production sur votre site !
Proposer son extension sur le répertoire
Maintenant, si vous voulez proposer votre extension au monde entier, vous pouvez la proposer sur wordpress.org à condition qu’elle ne soit pas payante.
La mise en ligne est gratuit mais demande quelques vérifications préalables.
Vidéo premium
Cette vidéo est réservée aux détenteurs de l’offre premium.
Envie de nous rejoindre ?
Soumettre son extension pour validation
Afin de publier votre extension sur le répertoire officiel des extensions WordPress, il faut se rendre tout d’abord sur cette page :
C’est la page officielle pour soumettre vos extensions, et le point de départ de votre aventure.
Avant toute chose pensez bien à lire les guidelines pour vous assurer d’être en conformité avec la charte WordPress.
Voici quelques informations importantes à connaître avant de soumettre votre extension :
- Votre extension doit être gratuite, ou à minima freemium : c’est-à-dire proposer quelques fonctionnalités gratuitement. Les extensions payantes ne peuvent pas être hébergées sur wordpress.org ;
- Le nom de votre extension ne peut pas commencer par Gutenberg même si ce n’est qu’un nom de code utilisé par les développeurs. On parle de Block Editor désormais ;
- 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.
Vérifier la conformité de votre code avec Plugin Check
Vous allez devoir ensuite vérifier que votre extension est conforme aux recommandations de WordPress en installant plugin check sur votre site.
Allez ensuite dans Outils > Plugin Check, sélectionnez votre extension puis lancez l’analyse :
Ici, on peut voir quelques erreurs que je dois absolument corriger avant de pouvoir soumettre l’extension sur le répertoire.
La première erreur indique que je n’ai pas échappé une donnée que j’affiche, conformément aux bonnes pratiques de sécurité WordPress.
Au lieu décrire ça dans mon render.php :
J’aurais dû plutôt écrire cela :
Ici, j’utilise les fonctions de sécurité WordPress pour s’assurer qu’aucune faille n’est possible. Toutes les données affichées sont nettoyés préalablement.
wp_kses_post()va nettoyer la chaîne d’attributs pour l’insérer dans le HTML ;esc_html_e()va nettoyer la chaîne traduite.
Cela permet d’éviter des injections de scripts de la part des administrateurs et des traductions.
Ici, ça semble un peu ridicule car get_block_wrapper_attributes() échappe déjà ses propres données. Mais comme on stocke l’information dans une variable entre temps, on doit d’assurer qu’elle n’a pas été modifiée et corrompue avant son l’affichage.
Côté traduction, on décide de ne pas faire confiance aux potentiels traducteurs externes.
Lorsque je fais une extension pour mon propre usage et que je suis le seul développeur et traducteur, je ne m’astreints pas à une telle rigueur. Mais sur le répertoire WordPress, il faut assurer ses arrières.
Délai d’analyse de votre extension
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 306 extensions dans la file d’attente. Les choses peuvent aller plus ou moins vite, mais dans ce cas comptez tout de même 11 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.
Une fois votre extension en ligne, elle sera disponible sur le répertoire et les utilisateurs de WordPress pourront la trouver depuis le menu Extension > Ajouter une extension de leur interface d’administration de WordPress.
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.
Vidéo premium
Cette vidéo est réservée aux détenteurs de l’offre premium.
Envie de nous rejoindre ?
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 haute définition, 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)
- Normal Banner:
- Logo
- Normal:
icon-128x128.(png|jpg) - High-DPI (Retina):
icon-256x256.(png|jpg) - SVG:
icon.svg
- Normal:
Vous pouvez même localiser vos bannière pour chaque langue si vous le souhaitez. Pour cela ajoutez la langue à la fin du nom de fichier : banner-772x250-fr_FR.jpg.
Pratique pour améliorer la conversion de vos utilisateurs, même si peu d’extensions aujourd’hui tirent parti de cet avantage.
De Git à SVN : vous simplifier le déploiement
Libre à vous d’utiliser SVN. Personnellement ça me rend fou.
Heureusement, l’agence anglaise 10up a mis au point une solution qui fait absolument TOUT tout seul, grâce aux actions Github.
Voici le lien vers le répertoire :
Ce projet est une action Github que vous allez pouvoir ajouter à votre répertoire. Cette action pourra être lancée automatiquement lorsque vous poussez sur la branche production par exemple.
Pour que cela fonctionne, vous allez devoir définir 2 constantes, à savoir les clés d’accès à votre répertoire SVN qui vous seront données par WordPress lorsque votre extension sera validée.
SVN_USERNAME: votre nom d’utilisateur SVN ;SVN_PASSWORD: le mot de passe du répertoire.
Afin d’ignorer tous les fichiers non-nécessaires à la mise en production, comme on l’a vu précédemment, vous allez pouvoir définir un fichier .distignore qui fonctionne de la même manière que le .gitignore.
Enfin, il faudra créer les dossiers .github/workflows/ et y placer à l’intérieur un fichier deploy.yml.
C’est ici que vous allez écrire vos actions Github. Pour cela, basez-vous sur les exemples fournis par 10up.
Une fois en place, votre process devrait être opérationnel, et votre extension sera mise à jour sur wordpress.org dès lors que vous aurez poussé sur une branche ou un tag particulier.
Et voilà, avec ça vous êtes prêt pour publier votre extension et la présenter au monde entier ! Et grâce à l’action github de 10up, vous allez pouvoir éviter de vous prendre la tête avec SVN !
On arrive presque au terme de cette formation. Je vous ai maintenant montré tout ce que je savais !
Dans l’ultime chapitre, je vous présente quelques études de cas de blocs avancés, histoire de voir en action les concepts vus sans cette formation.
0
Questions, réponses et commentaires