Modèles et logique conditionnelle avec OOP dans WordPress

Les modèles sont de plus en plus courants dans WordPress, et je considère que c’est une bonne chose.

Mais cela ne signifie pas qu’il n’y a pas de projets que nous gérons qui utilisent une approche plus traditionnelle pour afficher des modèles ou des partiels. De plus, cela ne signifie pas non plus que nous sommes dispensés de maintenir des bases de code qui utilisent du code qui n’utilise pas de moteur de template.

Bien que je pense que les modèles sont bons, je ne pense pas que ce soit toujours nécessaire. C’est le contenu d’un autre article, cependant.

Au lieu de cela, je souhaite parcourir le processus d’utilisation de la logique conditionnelle d’affichage ou non d’un partiel dans un modèle et le faire en utilisant la programmation orientée objet.

Modèles et logique conditionnelle avec OOP

Pour ce faire, supposons ce qui suit :

1. Nous avons un plugin qui dépend d’un autre plugin pour une fonctionnalité.
2. Le deuxième plugin est facultatif.
3. S’il n’est pas présent, nous afficherons un avis. S’il est présent, nous afficherons un partiel.

Assez simple, non ?

La seule chose à noter est que toute cette logique sera conservée dans le plugin principal (c’est-à-dire celui qui va vérifier la présence de l’autre plugin).

1 La logique conditionnelle du modèle

La première chose à faire est d’avoir une fonction qui vérifiera la présence du plugin secondaire. La raison en est que le modèle ressemble à ceci :

Et puis le partiel peut ressembler à ceci (cela dépend de votre implémentation):

En raison de la façon dont les modèles sont inclus dans WordPress, la fonction vivra dans une classe et la classe vérifiera la présence du plugin.

Si vous utilisez un renifleur de code, cela déclenchera probablement un avertissement indiquant que la méthode n’est pas utilisée, mais que la méthode est utilisée, elle est simplement utilisée dans un fichier de modèle. Remarque dans une classe. Tout ça pour dire que certains de nos renifleurs ne sont pas si intelligents. Encore.

2 Le code côté serveur du plugin

Une fois que vous avez une idée générale de la façon dont cela va fonctionner, il est temps d’écrire du code dans votre classe.

N’oubliez pas qu’il s’agit d’une fonction simple : il suffit de vérifier la présence d’un plugin. Vous pouvez le faire de plusieurs manières, mais la plus courante peut être d’utiliser la fonction API is_active_plugin .

Notez que lorsque vous utilisez cette fonction, elle repose sur l’idée que vous connaissez le nom du plugin que vous utilisez. Sinon, il existe d’autres moyens, mais cela sort du cadre de cet article.

Quoi qu’il en soit, puisque la logique est conditionnelle, elle doit renvoyer une valeur booléenne, et c’est exactement ce que fait la fonction API ci-dessus. Ainsi, la fonction côté serveur peut ressembler à ceci :

Et puisque le code du modèle appelle cette fonction (que vous voyez ci-dessus), il déterminera s’il doit afficher un partiel ou non.

Assez facile

Pour certains, c’est vraiment simple; pour d’autres, c’est une approche complètement différente car elle traite d’une plus grande séparation des préoccupations.

Et alors que je continue à travailler sur OOP Fundamentals avec les membres du site, je pense qu’il est également important de partager certaines des meilleures pratiques avec ceux qui ne sont peut-être pas membres mais désireux d’écrire du code plus organisé.