Quand utiliser les sous-actions WordPress (et quelles sont-elles ?)

J’ai récemment parcouru le processus d’utilisation du constructeur d’une classe pour empêcher un plugin de fonctionner si une dépendance attendue n’est pas chargée.

Bien que je ne considère pas cette stratégie particulière comme un problème pour une dépendance ponctuelle ou dans certaines situations, cela peut entraîner des odeurs de code.

Cela nous empêche également d’utiliser une fonctionnalité native de Core appelée sous-actions WordPress :

https://twitter.com/JJJ/status/822265137935646720

Mais avant d’examiner les sous-actions, je veux m’assurer que je suis clair sur les problèmes liés à l’approche conditionnelle (par rapport aux sous-actions) qui peuvent se reproduire avec les odeurs de code.

Sous-actions WordPress

Il existe de nombreuses façons d’expliquer les odeurs de code, mais ma façon préférée vient de Martin Fowler :

… les odeurs sont certaines structures du code qui indiquent une violation des principes de conception fondamentaux et ont un impact négatif sur la qualité de la conception.

Il y a une autre excellente page sur les odeurs de code sur Source Making que je vous recommande de lire si vous en avez l’occasion.

Et la façon dont les conditions peuvent conduire à des odeurs de code est simple : elles ont le potentiel de salir votre code avec un ensemble massif d’instructions qui incluent de nombreuses vérifications class_exists.

Et c’est un problème.

Chaque fois que vous introduisez une autre dépendance dans votre code, vous finissez par ajouter une autre vérification conditionnelle pour voir si une classe est présente dans l’application WordPress.

Je pense que c’est correct de le faire avec une seule dépendance – peut-être même deux dépendances – et si vous travaillez "assez haut" dans votre architecture, mais ce n’est pas comment gérer correctement cela avec de nombreuses dépendances ni à un niveau inférieur dans votre plugin.

C’est là que les sous-actions WordPress entrent en jeu. Vous pouvez voir une liste de sous-actions dans le tweet via John ci-dessus.

Il existe également une définition officielle des sous-actions dans le bbPress Codex :

Ces actions internes peuvent être considérées comme des "sous-actions" et vous permettent d’ajouter ou de réorganiser les actions WordPress selon les besoins pour les plugins qui dépendent de bbPress.

Et vous pouvez en voir un exemple dans ce fichier.

Bien sûr, cette définition est spécifique à bbPress, mais cela ne signifie pas qu’elle ne s’applique pas à ce que nous faisons dans WordPress.

Exemple concret : si vous avez déjà utilisé do_action pour définir une action personnalisée, ou si vous avez profité d’un crochet fourni par quelqu’un d’autre en dehors du cœur de WordPress, alors vous connaissez la stratégie d’implémentation d’une sous-action.

En d’autres termes, les sous-actions WordPress sont simplement des actions que nous pouvons utiliser pour modifier l’ordre dans lequel notre plugin dépend d’un autre plugin.

La façon dont cela est implémenté peut varier dans le contexte de votre travail, mais la manière WordPress la plus populaire et la plus «correcte» de le faire est sans doute de tirer parti de l’ argument de priorité pour le moment où votre plugin est chargé.

Autrement dit, prenez la priorité de la dépendance et assurez-vous qu’elle est antérieure à l’activation de votre plugin.

Il existe des méthodes alternatives qui peuvent être utilisées, telles que la modification du comportement des plugins chaque fois qu’ils sont activés ou non, mais cela sort du cadre de cet article particulier, et cela peut altérer négativement l’expérience utilisateur (de WordPress en général, pas moins).

Quoi qu’il en soit, le fait est que lorsqu’il s’agit d’utiliser les sous-actions WordPress, la programmation orientée objet et la gestion des dépendances tierces, assurez-vous que les décisions que vous prenez n’endommageront pas la conception de votre code.

S’il est logique de vérifier l’existence d’une classe, d’accord, mais s’il est plus logique d’attendre qu’un ensemble de classes ou de plugins soit chargé avant le vôtre, alors les sous-actions WordPress ont probablement plus de sens.