Arrêter l’exécution du plugin sans dépendance
Si vous abordez de nombreux développements de plugins WordPress d’un point de vue orienté objet, vous finirez par atteindre un point où vous ne ferez pas beaucoup d’interaction directement avec le cœur de WordPress lui-même.
Et, dans mon esprit, c’est une bonne chose. C’est le signe d’une architecture que vous structurez correctement votre code. C’est-à-dire:
- Vous avez WordPress assis au niveau fondamental,
- Vous avez un ensemble de classes qui se trouvent juste au-dessus de WordPress et qui sont chargées d’envoyer des informations vers et depuis WordPress entre le plugin,
- Et vous avez le reste de votre code qui comprend le reste de la fonctionnalité.
La façon dont cela est implémenté peut varier, mais la façon générale dont je l’imagine est la même que j’ai tendance à penser à l’application standard à plusieurs niveaux où vous avez la couche de données, la couche d’application et le frontal.
Sauf pour cette fois, vous avez le WordPress, une couche pour communiquer avec WordPress et le reste de votre code, et, vous savez, le reste de votre code.
Comment un plugin peut être organisé.
Alors, que se passe-t-il lorsque vous souhaitez arrêter l’exécution du plug-in lorsqu’il doit interagir avec une dépendance tierce et ne doit s’exécuter que si cette dépendance est présente ?
Arrêter l’exécution du plugin
En raison de la nature de PHP et de WordPress, il existe plusieurs façons de procéder. Le code que je vais partager ne prescrit pas la façon de le faire.
Au lieu de cela, c’est une façon de le faire (qui a été tirée de quelque chose qui est en développement). De plus, je montrerai également comment il interagit avec quelques autres composants des plugins.
1 Le Constructeur
Si vous lisez suffisamment d’articles sur WordPress et la programmation orientée objet, vous constaterez probablement que les constructeurs ne doivent pas être utilisés pour définir des hooks. Et je suis d’accord.
Cela crée un niveau de couplage inutile et rend les tests plus difficiles. Quel est alors le but d’un constructeur dans le code basé sur WordPress ?
Je l’utilise pour les mêmes raisons que vous attendez dans n’importe quel autre langage: Pour initialiser les propriétés de la classe. Dans le code ci-dessous, vous allez voir trois choses :
- J’initialise une propriété,
- Je vérifie si une dépendance tierce existe,
- Si ce n’est pas le cas, j’ajoute un message d’erreur,
- Je mets à jour la propriété.
Bien sûr, c’est verbeux, mais il n’a pas non plus recours à un code intelligent pour initialiser les valeurs.
(Plus je vieillis, plus j’aime le code spécifique car il facilite la lecture, la prise en main et la mise en route à un rythme plus rapide que l’alternative.)
2 La méthode d’initialisation
Puisque nous n’utilisons pas de constructeur pour travailler avec les crochets WordPress, cette fonctionnalité devrait exister dans le contexte d’une autre méthode.
Cela nous donne un endroit dédié pour mettre ce type de fonctionnalité, le dissocier du reste de la classe et le faire interagir avec WordPress uniquement lorsque la méthode est explicitement invoquée.
Mais rappelez-vous, tout l’intérêt de ce que je veux dire a à voir avec l’arrêt de l’exécution d’un plugin – pas où placer les crochets.
Alors disons que la dépendance tierce n’existe pas, alors quoi? Rappelons dans le constructeur, une propriété a été définie qui nous permettra de déterminer si nous devons avancer avec la mise en place des hooks ou non :
Et quand c’est en place, le reste du code ne s’exécutera pas.
Beaucoup de mots, un peu de code
Cela ressemble à beaucoup d’explications pour si peu de code.
Mais une partie de cela consiste également à essayer de transmettre l’importance d’avoir des parties d’un projet basé sur WordPress séparées du reste du noyau afin que les parties puissent interagir avec elles-mêmes sans avoir explicitement besoin de parler avec le noyau tout le temps.