Utiliser WordPress Hooks pour nettoyer le code, activer et désinstaller

Les auteurs de plugins consacrent tellement de temps et d'énergie à la fonctionnalité principale de leurs produits qu'ils laissent tomber des éléments moins importants.

Prenez l'activation et la désactivation, par exemple. Bien que les crochets d'activation soient répandus - de nombreux plugins doivent ajouter des options, vider les règles de réécriture, créer peut-être une table de base de données ou vérifier les différences de version lors de l'installation - les crochets de désactivation et de désinstallation sont beaucoup moins courants.

Le point ici? De nombreux auteurs de plugins ne prennent pas le temps de nettoyer après eux-mêmes. L'installation de WordPress a-t-elle vraiment besoin du tableau personnalisé que vous avez créé après avoir supprimé le plugin ? Pourquoi ne pas effacer quelques options exclusives au plugin avant de le supprimer ?

Dans cet article, je vais vous montrer comment utiliser les crochets d'activation, de désactivation et de désinstallation pour initialiser votre plugin et nettoyer les choses plus facilement une fois que les utilisateurs ont fini avec votre produit.

• Le crochet d'activation
  • La séquence d'installation
  • Rinçage des règles de réécriture
  • Création de tables de base de données
  • Contrôles de dépendance
• Le crochet de désactivation
• Le crochet de désinstallation
• Sécurité supplémentaire
• Il est temps de nettoyer

Remarque : Si vous envisagez de parcourir cet article, je vous suggère fortement de jeter un coup d'œil à la section "Sécurité supplémentaire" à la fin, qui complète le code avec quelques contrôles de sécurité précieux. De plus, si vous avez besoin d'aide avec les hooks de plugin WordPress, voici un rappel rapide sur l'utilisation des hooks WordPress et comment activer une fonction dans WordPress.

Le crochet d'activation

Bien que le crochet d'activation soit assez simple, son installation est un peu un cas particulier, nous devrons donc faire attention à la séquence des événements. Avant d'entrer dans tout cela, voici un exemple simple :

La clé de tout cela est la fonction register_activation_hook() . Le premier paramètre est le chemin d'accès au fichier principal du plugin ; le deuxième paramètre définit la fonction à exécuter. En interne, la fonction register_activation_hook() est un wrapper pour l'action "activate_[plugin_name]", mais comme c'est un peu plus facile à utiliser, il est inhabituel de voir le hook dans les plugins.

La séquence d'installation

Il est important de comprendre la séquence d'installation car cela évite d'utiliser des méthodes auxquelles vous êtes peut-être habitué. register_activation_hook() est appelé entre l'utilisateur qui clique sur le lien d'activation et voit par conséquent l'avis d'activation. Il s'exécute sur une page intermédiaire, qui redirige immédiatement avant que les crochets puissent avoir une chance de s'exécuter.

Regardons un exemple pour voir pourquoi c'est une énorme déception :

Rinçage des règles de réécriture

Un certain nombre de plugins créent des types de publication personnalisés. Vider les règles de réécriture lors de l'activation pour s'assurer que les utilisateurs n'obtiennent pas d'erreur 404 lorsqu'ils consultent une publication à partir du nouveau type de publication personnalisé est une décision intelligente.

Le code ci-dessous semble logique mais échouera.

Cela semble parfaitement bien. Le type de publication personnalisé est créé et lors de l'activation, nous vidons les règles de réécriture. Le problème est que les types de publication personnalisés n'ont pas encore été créés lorsque nous vidons les règles de réécriture.

Voici à quoi ressemble le flux de processus :

1. L'utilisateur installe le plugin.
2. L'utilisateur clique sur le lien d'activation.
3. Une page intermédiaire exécute uniquement le crochet d'activation, rien d'autre. Cela vide les règles de réécriture.
4. Le plugin est actif et le code s'exécute comme d'habitude. Le type de publication personnalisé est enregistré.

Une solution publiée sur Stack Overflow, qui est officiellement approuvée par le WordPress Codex, résout notre petit problème. La solution consiste à ajouter une option pour indiquer que le plugin vient d'être installé.

Si cette option existe, nous effectuons nos opérations d'activation, puis nous la supprimons.

Quelque chose comme ça:

Personnellement, je n'aime pas trop cette solution. Le problème est que la vérification de la ligne huit s'exécute à chaque chargement de page. Il n'y a pas lieu de s'inquiéter, car cela n'alourdira pas la charge de vos serveurs et ne ralentira pas le site Web pour vos utilisateurs. C'est une vérification très rapide avec un impact négligeable sur les performances. Il est cependant inutile 99,9% du temps.

Il existe une meilleure solution mentionnée dans le Codex dans la documentation de la fonction flush_rewrite_rules() . Dans cette solution, nous utilisons la modularité de nos fonctions pour enregistrer séparément le type de publication personnalisé à l'activation :

Au lieu de compter sur une vérification qui doit s'exécuter tout le temps, nous utilisons la fonction d'activation pour enregistrer nos types de publications. Notez qu'une fois notre plugin activé, les types de publication seront toujours enregistrés à partir du crochet d' init .

C'est un triste exemple du Codex qui se retrouve partout. Généralement, WordPress a une bonne documentation, mais si quelque chose semble inutile ou illogique, n'ayez pas peur de faire vos propres recherches.

Création de tables de base de données

Une autre tâche que certains plugins effectuent est de créer des tables de base de données. Le plus souvent, cela n'est pas nécessaire, mais il existe des cas d'utilisation légitimes.

Cet exemple de l'article du Codex sur la création de tables montre comment plusieurs appels d'activation peuvent être utilisés :

La première fonction, jal_install() crée une nouvelle table de base de données. La deuxième fonction, jal_install_data ajoute des données initiales à la table. Au lieu d'utiliser register_activation_hook() pour ajouter une fonction contenant tout ce code, nous pouvons utiliser register_activation_hook plusieurs fois.

C'est une excellente pratique pour la modularité. D'une part, vous n'avez pas besoin d'ajouter de données de test initiales - c'est aussi simple que de retirer le crochet d'activation - vous pouvez donc conserver la fonction intacte. En revanche, vous êtes libre de réutiliser ces fonctions n'importe où puisqu'elles sont distinctes.

Contrôles de dépendance

Une autre tâche courante de la fonction d'activation consiste à vérifier les dépendances. Votre plugin peut reposer sur une version spécifique de WordPress, un autre plugin ou même une version spécifique de PHP.

Le code ci-dessous vérifie une version minimale de WP et PHP et redirige l'utilisateur (sans activer le plugin) si nécessaire :

Le crochet de désactivation

Les crochets de désactivation s'exécutent lorsqu'un utilisateur a désactivé un plug-in, mais avant qu'il ne soit désinstallé (supprimé). Les hooks de désactivation s'utilisent de la même manière que les hooks d'activation :

La désactivation signifie que l'utilisateur a uniquement désactivé votre plugin, vous ne voudrez donc pas en faire autant que vous le feriez lors d'une désinstallation. Vous voudrez peut-être vider les règles de réécriture, mais à ce stade, vous ne voudrez pas vous débarrasser de toutes vos options et de votre table de base de données (si vous en avez une).

C'est assez simple, mais je porterai une attention particulière au vidage des règles de réécriture car, encore une fois, celles-ci sont problématiques.

Le codex recommande de les faire comme indiqué ci-dessous, mais cela ne fonctionne pas :

La raison pour laquelle cela ne fonctionne pas est la même qu'avant. L'exécution d'une désactivation exécute le crochet d' init , ce qui signifie que lorsque nous désactivons notre plugin, nous enregistrons également notre type de publication personnalisé. Les règles de réécriture sont vidées, mais elles prennent en compte le type de publication personnalisé.

Un ticket Trac est en place pour faire face à cela, mais jusque-là, je ne peux pas vous donner une très bonne façon de faire cela. La seule façon que j'ai trouvée qui fonctionne est de supprimer complètement les règles de réécriture:

Bien que cela ait fonctionné pour moi dans le passé, je ne le recommanderais pas. Il introduit une plus grande incertitude que le problème d'avoir quelques règles de réécriture supplémentaires. Je préférerais afficher une note aux utilisateurs leur demandant de visiter les paramètres de permalien après la désactivation, ce qui viderait les règles de réécriture. Jusqu'à ce qu'une meilleure solution soit mise en œuvre, nous sommes coincés avec ça… désolé !

Le crochet de désinstallation

Il existe deux façons d'exécuter du code lors de la désinstallation d'un plugin. Vous pouvez utiliser le hook de désinstallation via register_uninstall_hook() ou vous pouvez utiliser un fichier uninstall.php dédié dans votre plugin. Je vais vous montrer les deux, mais la méthode préférée consiste à utiliser le fichier de désinstallation.

Le principal problème avec le crochet de désinstallation est qu'il "empêche l'exécution du fichier principal du plug-in pendant la désinstallation, ce qui peut être problématique si le plug-in exécute du code dans l'espace global. C'est aussi mieux dans la mesure où le code de désinstallation est centralisé. –Scott Riley

Le code ci-dessous montre le processus de désinstallation à l'aide d'un crochet de base :

Comme discuté, ce n'est pas la meilleure solution. Une bien meilleure façon de gérer les désinstallations consiste à utiliser le fichier uninstall.php . Tout ce que vous avez à faire est de le créer et il sera utilisé s'il est disponible.

Comme vous pouvez le constater, il s'agit en fait d'une solution plus simple. Mieux encore, il est autonome.

Sécurité supplémentaire

Je ne voulais pas trop compliquer les exemples présentés jusqu'à présent avec des problèmes liés à la sécurité, mais vous devriez vraiment prendre certaines mesures pour vous assurer que seuls ceux qui sont autorisés à le faire peuvent exécuter ces actions.

Utilisez l'extrait de code suivant lors de l'activation et de la désactivation :

Ce bloc de code garantit que l'utilisateur dispose des autorisations nécessaires pour effectuer cette action et que l'action provient de la page appropriée. Cela devrait protéger contre la plupart des tentatives malveillantes.

Le processus de désinstallation est spécial, nous devrons donc utiliser un code légèrement différent :

Il est temps de nettoyer

Si votre plugin ajoute des éléments à WordPress, il est de votre devoir en tant que développeur de le supprimer lorsqu'un utilisateur décide de supprimer votre plugin.

L'utilisation des méthodes d'activation, de désactivation et de désinstallation décrites ci-dessus vous permettra de créer un système qui le fera en toute sécurité. Je recommande également fortement de lire ce fil Stackexchange, qui décrit ces processus dans les environnements OOP.

Si vous n'êtes pas encore membre de WPMU DEV, inscrivez-vous dès aujourd'hui pour un essai gratuit, totalement sans risque. En tant que membre, vous aurez accès à tous nos excellents plugins et à notre service d'hébergement ultra-rapide, ainsi qu'à une assistance experte 24h/24 et 7j/7 pour toutes vos questions et problèmes liés à WordPress.

• Développeurs WordPress
• Crochets WordPress