Cette fois, il y a une vraie mise en pratique. L’objectif : créer un plugin volontairement minimal (il ne fera rien de visible), pour valider tout le circuit — création, dépôt, activation, puis export et réinstallation. C’est ce circuit qu’il faut maîtriser avant de s’attaquer à un plugin qui fait réellement quelque chose.
1. Rappel : la méthode Local by Flywheel
Pour développer un plugin, mieux vaut utiliser Local by Flywheel : on peut modifier directement les fichiers depuis l’Explorateur Windows ou le Finder Mac.
Chemin d’accès : depuis l’interface Local, bouton « Site folder » → ouvre l’Explorateur/Finder → naviguer dans :
Pourquoi c’est pratique : à chaque modification, il suffit de remplacer les fichiers concernés, puis de recharger la page WordPress pour voir immédiatement le résultat — pas besoin de refaire un ZIP, de le renvoyer en ligne, ou d’utiliser FileZilla en permanence. On gagne en nombre de clics, en allers-retours, et on évite de s’emmêler au bout d’un moment.
Et ensuite ? Bien entendu, une fois le plugin validé via Local by Flywheel, c’est à partir de cette version finalisée que l’on va générer le ZIP 🙂 — c’est exactement ce qu’on va faire, en pratique, dans ce chapitre.
Cette répétition est volontaire — elle sert à ancrer le réflexe avant de passer à la pratique.
2. Le plugin le plus simple possible
Un plugin WordPress se reconnaît grâce à une déclaration d’en-tête, en commentaire PHP, en tout début de fichier. C’est cet en-tête qui permet à WordPress de reconnaître le fichier comme un plugin, de lui donner un nom, une description, et de l’afficher dans la liste des extensions.
L’en-tête complète
Voici à quoi ressemble une en-tête de plugin complète, telle qu’on peut la rencontrer dans un vrai projet :
Ligne par ligne, voici ce que chacune signifie :
- Plugin Name — le nom affiché dans la liste des extensions. C’est la seule ligne réellement obligatoire.
- Plugin URI — l’adresse d’une page web dédiée au plugin (site de présentation, documentation…).
- Description — le texte affiché juste sous le nom, dans la liste des extensions.
- Version — le numéro de version actuel du plugin.
- Requires at least — la version minimale de WordPress nécessaire pour que le plugin fonctionne.
- Requires PHP — la version minimale de PHP nécessaire.
- Author — le nom de l’auteur du plugin.
- Author URI — le site web de l’auteur.
- License — la licence sous laquelle le plugin est distribué (le plus souvent une licence compatible GPL, comme vu au chapitre 2).
- License URI — un lien vers le texte complet de cette licence.
- Text Domain — un identifiant technique utilisé si le plugin doit un jour être traduit en plusieurs langues.
La version minimale
En réalité, seule la ligne Plugin Name est strictement obligatoire pour que WordPress reconnaisse le fichier comme un plugin. Toutes les autres lignes sont optionnelles, même si elles sont recommandées pour un vrai plugin destiné à être partagé ou publié.
Pour cet exercice, une version minimale suffit amplement — c’est celle qu’on va utiliser :
C’est tout. Pas une seule ligne de logique. Pas de fonction. Juste ce commentaire, suffisant pour que WordPress le reconnaisse comme un plugin à part entière.
3. À vous de jouer : créer le plugin
Reprenez la version minimale de l’en-tête ci-dessus, et suivez ces étapes :
Étape 1 — Modifiez le champ Author en y mettant votre propre nom, à la place de « Votre nom ».
Étape 2 — Sur un dossier de votre ordinateur (n’importe où, mais pas dans Local by Flywheel), créez un dossier pour votre plugin (par exemple mon-premier-plugin), et à l’intérieur, un fichier PHP portant le même nom (par exemple mon-premier-plugin.php), contenant l’en-tête modifié.
Étape 3 — Déposez ce dossier dans Local by Flywheel, au bon endroit :
Rappel du chemin d’accès (oui, on le répète, c’est volontaire) : depuis l’interface Local, bouton « Site folder » → ouvre l’Explorateur/Finder → naviguer dans :
4. Activer le plugin depuis l’administration
Rendez-vous dans l’administration WordPress de votre site local, dans Extensions. Votre plugin, « Mon premier plugin », doit apparaître dans la liste, avec votre nom en tant qu’auteur.
Activez-le.
Il ne se passe rien de visible sur le site — et c’est normal ! L’objectif de cette étape n’était pas de créer une fonctionnalité, mais uniquement de valider que le processus complet fonctionne : un fichier correctement structuré, déposé au bon endroit, est bien reconnu et activable par WordPress.
5. Copier le plugin en dehors de Local
Copiez le dossier complet mon-premier-plugin (avec son fichier PHP à l’intérieur) quelque part en dehors du dossier de Local by Flywheel — sur votre bureau, par exemple. On va en avoir besoin dans un instant.
6. Supprimer le plugin depuis l’interface
Retournez dans l’administration WordPress. Désactivez, puis supprimez le plugin depuis l’écran des extensions.
7. Générer le ZIP
Avec les fichiers que vous avez copiés à l’étape 5, créez une archive ZIP — en conservant bien la structure du dossier à l’intérieur :
8. Réinstaller, mais cette fois via upload
Retournez dans l’administration WordPress de votre site Local. Cette fois, installez le plugin via Extensions → Ajouter une extension → Téléverser une extension, en sélectionnant le ZIP que vous venez de créer — la méthode 1 vue au chapitre précédent.
Activez-le à nouveau, et vérifiez qu’il apparaît bien dans la liste, exactement comme la première fois.
Ce que vous venez de valider : un même plugin, minimal et sans risque, installé successivement par les deux méthodes vues au chapitre 2 — dépôt direct de fichiers, puis upload d’une archive ZIP. Le circuit complet est maintenant acquis. La suite consistera à donner une vraie utilité à ce plugin.
9. Les conventions de nommage
Une question technique mérite d’être clarifiée avant de conclure ce chapitre : le nom du dossier, le nom déclaré dans l’en-tête (Plugin Name), et le nom du fichier PHP peuvent-ils être différents ?
La réponse est oui — techniquement, les trois peuvent être différents, et le plugin fonctionnera quand même. WordPress ne compare pas ces trois éléments entre eux : le champ Plugin Name n’est qu’un libellé d’affichage, et le nom du fichier PHP n’a pas besoin de correspondre au nom du dossier — WordPress se contente de scanner les fichiers .php présents à la racine de chaque dossier de plugin, à la recherche d’un en-tête valide.
La seule vraie contrainte technique : le fichier PHP principal doit se trouver directement dans le dossier du plugin, pas trop profondément imbriqué (par exemple mon-plugin/mon-plugin/fichier.php ne fonctionnerait pas) — mais ça n’a rien à voir avec une question de nommage.
Une nomenclature « clean » : ce que recommandent les bonnes pratiques
Même si ce n’est pas obligatoire, la documentation officielle WordPress et l’ensemble des guides de bonnes pratiques s’accordent sur une convention commune, à adopter systématiquement :
- Tout en minuscules — jamais de majuscule dans le nom du dossier ni du fichier.
- Des tirets pour séparer les mots (
mon-premier-plugin), jamais d’espace, ni d’underscore. - Le nom du dossier et le nom du fichier PHP principal doivent être identiques — c’est la convention universelle, qui rend le plugin immédiatement lisible pour n’importe qui d’autre qui ouvrirait le projet.
- Le champ
Plugin Namepeut rester lisible pour un humain (avec majuscules et espaces, par exemple « Mon Premier Plugin ») — mais il doit rester cohérent conceptuellement avec le nom du dossier/fichier, pour qu’on reconnaisse facilement le même plugin des deux côtés.
Avec notre exemple, la nomenclature « clean » donnerait donc :
Bonus utile pour la suite : si votre plugin est un jour soumis à l’annuaire officiel WordPress.org, un identifiant technique (le « slug ») est automatiquement généré à partir du champ Plugin Name — garder cette cohérence dès le départ évite bien des confusions le jour où ça arrive.