Un code de base pour bien démarrer vos plugins WordPress
Rien de mieux qu’un bon boilerplate pour démarrer sereinement le développement d’un nouveau plugin WordPress. Aujourd’hui je vous présente WPPB alias WP Plugin Boilerplate qui vous aidera à bien démarrer.
Pourquoi utiliser un boilerplate ?
Quand on démarre un plugin, il y a beaucoup de choses à penser : organisation des fichiers, bonnes pratiques, sécurité, approche orientée objet, fichier de langue…
Afin de ne pas avoir à réinventer la roue soi même, les boilerplates sont là pour vous faire économisant du temps en fournissant un code de base prêt à l’emploi. C’est le cas du très connu html5 boilerplate pour les projets html. Boilerplate en français se traduirait par un “fait tout”, en référence aux plats à tout faire en cuisine.
Lors du développement de la plateforme d’apprentissage pour WPChef je cherchais justement un boilerplate propre, efficace, et facile à prendre en main. Mon choix s’est porté sur WPPB, que je vous présente aujourd’hui.
WPPB et son générateur
Sur Google vous trouverez 2 sites : WPPB.io où vous pourrez télécharger l’archive standard, et WPPB.me qui dispose d’un générateur : vous allez pouvoir rentrer quelques informations, et le site génèrera pour vous le code de base, en appliquant les bons noms de classe PHP en fonction du nom de votre projet :
Une fois les infos remplies, cliquez sur Build et téléchargez votre archive !
Architecture de votre base plugin
Voyons un peu ce qu’il y a à l’intérieur de votre dossier :
On a un dossier admin, un dossier public, et un dossier includes qui sont les 3 dossiers les plus importants de votre plugin. Vient ensuite le fichier geekpress.php qui vient lancer votre plugin et déclarer toutes les classes nécessaires.
Si on regarde dans public et admin, on remarque la même structure de fichiers : une classe principale, destinée à accueillir votre code, et des dossiers pour le JS et le CSS.
Un plugin va bien souvent agir sur votre admin WordPress, par exemple en y ajoutant une page d’options, un type de publication, des nouvelles entrées dans le menu… et c’est donc dans class-geekpress-admin.php qu’ira le code nécessaire.
Et à contrario tout ce qui modifiera le site côté public ira dans le dossier public. On sépare du coup bien les 2 choses qui sont complètement différentes.
Quant au dossier include, il va contenir plusieurs classes communes :
La classe activator va s’exécuter lorsque vous activez votre plugin. Les fonctions à l’intérieur ne sont donc pas appelées à chaque exécution du plugin.
C’est l’emplacement idéal pour venir déclarer par exemple la création d’une nouvelle table SQL, ou d’un nouveau rôle utilisateur. (Attention : les CPT par contre ont besoin d’être déclarés à chaque lancement de page. Pourquoi ? va savoir)
Inversement pour deactivator, qui permet de lancer des actions lorsque la personne désactive le plugin. Vous avez également le fichier uninstall.php, à la racine, qui vous permettra de lancer un nettoyage avant que l’utilisateur supprime complètement votre plugin. Par exemple nettoyer la base de données. Ce que peu de plugins font (il y a beaucoup de mauvais développeurs en PHP).
le fichier i18n s’occupera de charger les fichiers de langue, à stocker en .po et .mo dans le dossier languages/ (Je vous conseille le logiciel poedit pour analyser les chaines de votre plugin et générer le fichier de traduction).
Le loader est un fichier que l’on a pas besoin de toucher, il contient les fonctions qui vont permettre de charger les filtres et les actions (les fameux hooks WordPress) dans le plugin.
Enfin, le fichier class-geekpress.php est un des plus importants de ce plugin, c’est d’ici que vous allez déclarer l’appel des classes vues précédemment, mais surtout de vos fonctions dans admin ou dans public :
Par défaut sont définis les appels à vos scripts et feuilles de styles.
A vous d’ajouter tous les hooks nécessaires pour que votre plugin vienne influencer le fonction par défaut de WordPress.
Dans admin par exemple on pourrait invoquer le hook save_post, qui permet de lancer une action au moment de l’enregistrement d’un article ou d’une page. On a vu comment générer un sommaire via save_post ou encore un temps de lecture grâce au hooks précédemment sur ce blog.
Sachez que presque tout fonctionne avec ces hooks, il est important de bien maitriser cette notion avant de vous lancer dans le développement d’un plugin.
Une fois déclarés, vos fonctions iront alors soit dans admin/class-geekpress-admin.php, soit dans public/class-geekpress-public.php.
en résumé on intervient surtout sur
- includes/class-geekpress.php : pour déclarer les hooks (et éventuellement des custom classes)
- admin/class-geekpress-admin.php : pour écrire ses fonctions destinées à l’admin du site
- public/class-geekpress-public.php : pour écrire ses fonctions destinés à la partie publique du site
conclusion
J’ai trouvé ce boilerplate très facile à prendre en main et pratique pour organiser son code. Organisé en POO, il permet de rester propre dans sa façon de coder.
Afin de l’utiliser dans de bonnes conditions, je vous conseille de connaitre un minimum la POO en PHP, et savoir ce qu’est un hook WordPress. Après ça roule tout seul !
Et vous, vous utilisez quoi pour vos plugins ?
2 Commentaires
La dernière extension que j’ai développée de A à Z, c’était il y a des lustres, et il n’y avait pas ce type d’outil – ou alors je n’en avais pas entendu parler :(
C’est juste top de trouver un générateur en ligne, ça évite de se casser la tête et de “standardiser” la création… et un article qui en parle !