Supposons que vous travaillez sur un projet pour quelqu’un et que vous l’avez délimité, que les tâches sont déléguées, que vous disposez de toutes les bibliothèques et outils dont vous avez besoin pour démarrer, et que vous avez séparé ce qui sera le thème ou la présentation, et quelles seront les fonctionnalités ou les plugins.
Mais plutôt que d’avoir une poignée de plugins individuels, que se passerait-il s’il y avait un package de plugins fonctionnels plus petits ou de micro-plugins ou tout ce que vous voulez les appeler fonctionnant pour alimenter le package ?
De plus, ceux-ci sont tous construits sur la même base mais qui partagent également du code les uns avec les autres et pour rendre les choses plus intéressantes, vous choisissez d’utiliser un chargeur automatique PSR-4 via Composer pour vous occuper de tout cela ?
Plugins WordPress à chargement automatique PSR-4
Tout d’abord, la façon de penser à ce que j’essaie de dire (car qui sait si je suis clair 🙃) est que vous avez votre travail dans le wp-content/pluginsrépertoire. Et votre plugin réside, disons, acme-pluginset a des sous-répertoires pour vos micro-plugins.
Nous allons garder cela simple pour cet exemple et dire qu’il y a le plugin principal et ensuite un seul micro-plugin. Le répertoire ressemblerait à ceci ;
Maintenant, il y a les fichiers que vous vous attendez à voir dans un plugin :
- LISEZMOI,
- LICENCE,
- CHANGELOG,
- compositeur.json
- compositeur.lock
- vendeur
- le fichier d’amorçage du plugin,
- etc.
Maintenant, voici le truc : si vous utilisez le PSR-2 et que vous allez utiliser un chargeur automatique PSR-4, alors il y a deux choses que vous devez savoir :
- Les espaces de noms doivent correspondre à l’organisation de l’annuaire. J’en ai parlé un peu lors de ma présentation WordCamp Atlanta 2017 (en particulier sous organisation virtuelle et logique).
- Comment travailler avec
composer.jsonpour définir vos chargeurs automatiques. Vous pouvez lire beaucoup à ce sujet ici, mais je donnerai les notes de la falaise dans le reste de cet article.
Le problème est donc que le vendorrépertoire réside un niveau au-dessus où certains des fichiers source existent. Ainsi, la méthode standard de configuration d’un chargeur automatique personnalisé dans Composer ne fonctionnera pas.
Par exemple, il est très typique de voir ceci :
{
"name": "pressware/acme-plugins",
"description": "A demo plugin",
"autoload": {
"psr-4": {
"Acme": "src/",
}
},
// ...
}
Mais pour compenser notre travail, nous devons faire ceci :
{
"name": "pressware/acme-plugins",
"description": "A demo plugin",
"autoload": {
"psr-4": {
"Acme": "",
"AcmeMicroPlugin": "MicroPlugin/src/"
}
},
// ...
}
C’est un changement simple, mais c’est un exemple simple, non ? Alors, qu’en est-il?
Notez que nous avons mis à jour certains changements dans l’ emplacement de chargement automatique. Concrètement, voici ce qui se passe :
- Le premier élément est l’espace de noms de niveau supérieur auquel appartiendront tous les plugins qui appartiendront au plugin Acme.
- La deuxième entrée fait référence au MicroPlugin que vous voyez dans le répertoire ci-dessus. Cela représente l’espace de noms pour ce plugin particulier, et il dit à Composer de rechercher les fichiers source à charger automatiquement en utilisant le répertoire de propriétés
À partir de là, vous ajouterez une nouvelle entrée pour le chargeur automatique correspondant à chaque micro-plugin qui appartiendra au plugin de niveau supérieur.
Organisation des futurs micro-plugins
Il existe plusieurs façons de gérer l’organisation de votre code afin de pouvoir utiliser un chargeur automatique par défaut.
Si vous suivez le modèle de micro-plugin (faute d’un meilleur terme), cela ne fonctionnera pas et vous devrez donc réorganiser vos fichiers, ce qui peut être pénible avec le temps.
