Comment rendre un plugin WordPress extensible

Publié: 2022-03-10
Résumé rapide ↬ Juste au moment où vous pensiez avoir enfin trouvé un plugin qui fait tout ce dont vous avez besoin, il y a encore une petite chose importante qu'il ne peut pas faire. Découvrez comment rendre votre plugin extensible et réduire les maux de tête.

Avez-vous déjà utilisé un plugin et souhaité qu'il fasse quelque chose d'un peu différent ? Peut-être aviez-vous besoin de quelque chose d'unique qui dépassait le cadre de la page des paramètres du plugin.

J'ai personnellement rencontré cela, et je parie que vous aussi. Si vous êtes un développeur de plugin WordPress, il est fort probable que certains de vos utilisateurs aient également rencontré ce problème lors de l'utilisation de votre plugin.

Voici un scénario typique : vous avez enfin trouvé ce plugin qui fait tout ce dont vous avez besoin, à l'exception d'une petite chose importante. Il n'y a pas de paramètre ou d'option pour activer cette petite chose, vous parcourez donc la documentation et constatez que vous ne pouvez rien y faire. Vous demandez la fonctionnalité dans le forum de support du plugin WordPress - mais pas de dés. En fin de compte, vous le désinstallez et continuez votre recherche.

Imaginez si vous étiez le développeur de ce plugin. Que feriez-vous si un utilisateur demandait une fonctionnalité particulière ?

L'idéal serait de le mettre en place. Mais si la fonctionnalité était destinée à un cas d'utilisation très particulier, son ajout ne serait pas pratique. Il ne serait pas bon d'avoir un paramètre de plug-in dont seulement 0,1 % de vos utilisateurs auraient une utilité.

Vous souhaitez uniquement implémenter des fonctionnalités qui affectent la majorité de vos utilisateurs. En réalité, 80% des utilisateurs utilisent 20% des fonctionnalités (règle du 80/20). Assurez-vous donc que toute nouvelle fonctionnalité est très demandée et que 80 % de vos utilisateurs en bénéficieront avant de la mettre en œuvre. Si vous créiez un paramètre pour chaque fonctionnalité demandée, votre plugin deviendrait compliqué et gonflé - et personne ne le veut.

Votre meilleur pari est de rendre le plugin extensible, du point de vue du code, afin que d'autres personnes puissent l'améliorer ou le modifier pour leurs propres besoins.

Dans cet article, vous découvrirez pourquoi rendre votre plugin extensible est une bonne idée. Je partagerai également quelques conseils sur la façon dont j'ai appris à le faire.

Plus après saut! Continuez à lire ci-dessous ↓

Qu'est-ce qui rend un plugin extensible ?

En un mot, un plugin extensible signifie qu'il adhère à la partie "O" des principes SOLID de la programmation orientée objet - à savoir, le principe ouvert/fermé.

Si vous n'êtes pas familier avec le principe ouvert/fermé, cela signifie essentiellement que d'autres personnes ne devraient pas avoir à modifier votre code pour modifier quelque chose .

En appliquant ce principe à un plugin WordPress, cela signifierait qu'un plugin est extensible s'il contient des dispositions qui permettent à d'autres personnes de modifier son comportement. C'est comme la façon dont WordPress permet aux gens de "s'accrocher" à différents domaines de WordPress, mais au niveau du plugin.

Un exemple typique d'un plugin

Voyons comment nous pouvons créer un plugin extensible, en commençant par un exemple de plugin qui ne l'est pas.

Supposons que nous ayons un plugin qui génère un widget de barre latérale qui affiche les titres des trois derniers articles. Au cœur du plugin se trouve une fonction qui enveloppe simplement les titres de ces trois articles dans des balises de liste :

 function get_some_post_titles() { $args = array( 'posts_per_page' => 3, ); $posts = get_posts( $args ); $output = '
     ';
  foreach ( $posts as $post ) {
      $sortie .= '
  •  ' . $post->post_title . '
    •  ';
  }
  $sortie .= '
 ';

  retourne $sortie ;
}

Bien que ce code fonctionne et fasse le travail, il n'est pas tout à fait extensible.

Pourquoi? Étant donné que la fonction est définie à sa manière, il n'y a aucun moyen de modifier son comportement sans modifier directement le code.

Que se passe-t-il si un utilisateur souhaite afficher plus de trois publications, ou peut-être inclure des liens avec les titres des publications ? Il n'y a aucun moyen de le faire avec le code ci-dessus. L'utilisateur est coincé avec le fonctionnement du plugin et ne peut rien y changer.

Inclure une centaine de paramètres n'est pas la solution

Il existe plusieurs façons d'améliorer le plugin ci-dessus pour permettre aux utilisateurs de le personnaliser.

Une telle façon serait d'ajouter beaucoup d'options dans les paramètres, mais même cela pourrait ne pas satisfaire toutes les possibilités que les utilisateurs voudraient du plugin.

Que se passe-t-il si l'utilisateur souhaite effectuer l'une des actions suivantes (scénarios que nous reviendrons plus tard) :

  • afficher des produits WooCommerce ou des publications d'une catégorie particulière ;
  • afficher les éléments dans un carrousel fourni par un autre plugin, au lieu d'une simple liste ;
  • effectuez une requête de base de données personnalisée, puis utilisez les publications de cette requête dans la liste.

Si nous ajoutions une centaine de paramètres à notre widget, nous serions en mesure de couvrir les cas d'utilisation ci-dessus. Mais que se passe-t-il si l'un de ces scénarios change et que l'utilisateur souhaite maintenant afficher uniquement les produits WooCommerce actuellement en stock ? Le widget aurait besoin d'encore plus de paramètres pour s'adapter à cela. Bientôt, nous aurions un gazillion de paramètres.

De plus, un plugin avec une énorme liste de paramètres n'est pas vraiment convivial. Éloignez-vous de cet itinéraire si possible.

Alors, comment ferions-nous pour résoudre ce problème ? Nous rendrions le plugin extensible.

Ajout de nos propres crochets pour le rendre extensible

En étudiant le code du plugin ci-dessus, nous voyons quelques opérations que la fonction main effectue :

  • Il obtient des messages en utilisant get_posts .
  • Il génère une liste de titres de messages.
  • Il renvoie la liste générée.

Si d'autres personnes devaient modifier le comportement de ce plugin, leur travail impliquerait probablement ces trois opérations. Pour rendre notre plugin extensible, nous devrions ajouter des crochets autour de ceux-ci pour les ouvrir à d'autres développeurs.

En général, ce sont de bons endroits pour ajouter des hooks à un plugin :

  • autour et dans les grands processus,
  • lors de la construction du HTML de sortie,
  • pour modifier les requêtes de publication ou de base de données,
  • avant de renvoyer les valeurs d'une fonction.

Un exemple typique d'un plugin extensible

En prenant ces règles empiriques, nous pouvons ajouter les filtres suivants pour rendre notre plugin extensible :

  • ajoutez myplugin_get_posts_args pour modifier les arguments de get_posts ,
  • ajouter myplugin_get_posts pour remplacer les résultats de get_posts ,
  • ajouter myplugin_list_item pour personnaliser la génération d'une entrée de liste,
  • ajoutez myplugin_get_some_post_titles pour remplacer la liste générée renvoyée.

Voici à nouveau le code avec tous les crochets ajoutés :

 function get_some_post_titles() { $args = array( 'posts_per_page' => 3, ); // Let other people modify the arguments. $posts = get_posts( apply_filters( 'myplugin_get_posts_args', $args ) ); // Let other people modify the post array, which will be used for display. $posts = apply_filters( 'myplugin_get_posts', $posts, $args ); $output = '
     ';
  foreach ( $posts as $post ) {

      // Laisser les autres personnes modifier l'entrée de la liste.
      $sortie .= '
  •  ' . apply_filters( 'myplugin_list_item', $post->post_title, $post ) . '
    •  ';
  }
  $sortie .= '
 ';

  // Laisser d'autres personnes modifier notre liste de sortie.
  return apply_filters( 'myplugin_get_some_post_titles', $output, $args );
}

Vous pouvez également obtenir le code ci-dessus dans l'archive GitHub.

J'ajoute ici de nombreux crochets, ce qui peut sembler peu pratique car l'exemple de code est assez simple et petit, mais cela illustre mon propos : en ajoutant seulement quatre crochets, les autres développeurs peuvent désormais personnaliser le comportement du plugin de toutes sortes de façons.

Espacement des noms et contexte pour les hooks

Avant de continuer, notez deux choses importantes concernant les hooks que nous avons implémentés :

  • Nous mettons les crochets dans un espace de noms avec myplugin_ .
    Cela garantit que le nom du crochet n'entre pas en conflit avec le crochet d'un autre plugin. C'est juste une bonne pratique, car si un autre crochet portant le même nom est appelé, cela pourrait entraîner des effets indésirables.
  • Nous passons également une référence à $args dans tous les crochets pour le contexte.
    Je fais cela pour que si d'autres utilisent ce filtre pour changer quelque chose dans le flux du code, ils peuvent utiliser ce paramètre $args comme référence pour avoir une idée de la raison pour laquelle le crochet a été appelé, afin qu'ils puissent effectuer leurs ajustements en conséquence.

Les effets de nos crochets

Vous souvenez-vous des scénarios uniques dont j'ai parlé plus tôt ? Revoyons-les et voyons comment nos crochets les ont rendus possibles :

  • Si l'utilisateur souhaite afficher les produits WooCommerce ou les publications d'une catégorie particulière , il peut soit utiliser le filtre myplugin_get_posts_args pour ajouter ses propres arguments lorsque le plugin interroge les publications, soit utiliser myplugin_get_posts pour remplacer complètement les publications par leur propre liste.
  • Si l'utilisateur souhaite afficher les éléments dans un carrousel fourni par un autre plug -in, au lieu d'une simple liste, il peut remplacer l'intégralité de la sortie de la fonction par myplugin_get_some_post_titles et générer à la place un carrousel à partir de là.
  • Si l'utilisateur souhaite effectuer une requête de base de données personnalisée , puis utiliser les publications de cette requête dans la liste, alors, comme dans le premier scénario, il peut utiliser myplugin_get_posts pour utiliser sa propre requête de base de données et modifier le tableau de publication.

Bien mieux !

Un exemple rapide d'utilisation de nos filtres

Les développeurs peuvent utiliser add_filter pour se connecter à nos filtres ci-dessus (ou utiliser add_action pour les actions).

Prenant notre premier scénario ci-dessus, un développeur peut simplement faire ce qui suit pour afficher les produits WooCommerce en utilisant le filtre myplugin_get_posts_args que nous avons créé :

 add_filter( 'myplugin_get_posts_args', 'show_only_woocommerce_products' ); function show_only_woocommerce_products( $args ) { $args['post_type'] = 'product'; return $args; }

Nous pouvons également utiliser des crochets d'action

En plus d'utiliser apply_filters , nous pouvons également utiliser do_action pour rendre notre code extensible. La différence entre les deux est que le premier permet aux autres de modifier une variable, tandis que le second permet aux autres d'exécuter des fonctionnalités supplémentaires dans diverses parties de notre code.

Lors de l'utilisation d'actions, nous exposons essentiellement le flux du plugin à d'autres développeurs et les laissons effectuer d'autres choses en tandem.

Cela pourrait ne pas être utile dans notre exemple (car nous n'affichons qu'un shortcode), mais cela serait utile dans d'autres. Par exemple, étant donné un plugin de sauvegarde extensible, nous pourrions créer un plugin qui télécharge également le fichier de sauvegarde vers un service tiers tel que Dropbox.

"Génial! Mais pourquoi devrais-je me soucier de rendre mon plugin extensible ? »

Eh bien, si vous n'êtes toujours pas convaincu par l'idée, voici quelques réflexions sur les raisons pour lesquelles autoriser d'autres personnes à modifier le comportement de votre plugin est une bonne idée.

Il ouvre le plugin à plus de possibilités de personnalisation

Tout le monde a des besoins différents. Et il y a de grandes chances que votre plugin ne les satisfasse pas tous, et vous ne pouvez pas non plus les anticiper. Ouvrir votre plugin pour permettre des modifications aux domaines clés du comportement de votre plugin peut faire des merveilles.

Il permet aux gens d'introduire des modifications sans toucher au code du plugin

Les autres développeurs ne seront pas obligés de modifier directement les fichiers de votre plugin. C'est un énorme avantage car modifier directement le fichier d'un plugin est généralement une mauvaise pratique. Si le plugin est mis à jour, toutes vos modifications seront effacées.

Si nous ajoutons nos propres crochets pour que d'autres personnes les utilisent, les modifications du plugin peuvent être placées dans un emplacement externe - par exemple, dans un autre plugin. De cette façon, le plugin d'origine ne sera pas du tout touché, et il peut être librement mis à jour sans rien casser, et toutes les modifications de l'autre plugin resteraient intactes.

Conclusion

Les plugins extensibles sont vraiment géniaux et nous offrent de nombreuses possibilités de personnalisation. Si vous rendez votre plugin extensible, vos utilisateurs et autres développeurs vous aimeront pour cela.

Jetez un œil aux plugins tels que WooCommerce, Easy Digital Downloads et ACF. Ces plugins sont extensibles, et vous pouvez facilement le dire car de nombreux autres plugins dans le répertoire des plugins de WordPress leur ajoutent des fonctionnalités. Ils fournissent également un large éventail de crochets d'action et de filtre qui modifient divers aspects des plugins. Les règles empiriques que j'ai énumérées ci-dessus sont ressorties de mon étude.

Voici quelques points à retenir pour rendre votre plugin extensible :

  • Suivez le principe ouvert/fermé. D'autres personnes ne devraient pas avoir à éditer votre code pour modifier quelque chose.

  • Pour rendre votre plugin extensible, ajoutez des crochets à ces endroits :

    • autour et au sein des grands processus,
    • lors de la construction du HTML de sortie,
    • pour modifier les requêtes de publication ou de base de données,
    • avant de renvoyer les valeurs d'une fonction.

  • Espacez les noms de vos hooks avec le nom de votre plugin pour éviter les conflits de nommage.
  • Essayez de passer d'autres variables liées au crochet, afin que d'autres personnes obtiennent un contexte de ce qui se passe dans le crochet.
  • N'oubliez pas de documenter les hooks de votre plugin, afin que d'autres personnes puissent en prendre connaissance.

Lectures complémentaires

Voici quelques ressources si vous souhaitez en savoir plus sur l'extension des plugins :

  • Comment rendre votre plugin WordPress extensible, GitHub
    Tous les exemples de code dans cet article.
  • "Conseils utiles pour démarrer avec les hooks WordPress", Thomas Maier, Smashing Magazine
  • "Comment créer un plugin WordPress", Daniel Pataki, Smashing Magazine
  • "Hooks", Manuel des plugins, WordPress.org