Share
Dans le premier article de cette série, nous avons exposé les raisons pour lesquelles les plugins WordPress devraient être traités davantage comme des projets logiciels plus volumineux (mais ce n’est souvent pas le cas) et avons plaidé en faveur de l’utilisation d’un code bien organisé pour tenter de rendre nos projets plus faciles à gérer. . Tout cela a été fait dans le cadre du développement d'un widget WordPress.
Le fait est que les widgets ne sont pas le seul type de plug-in pouvant être développé pour WordPress. L'application prend également en charge les plug-ins qui étendent ses fonctionnalités grâce à l'utilisation de points d'ancrage situés dans toute l'application. En tant que tels, les widgets ne sont pas le seul type de plug-in qui pourrait tirer profit d'un passe-partout.
Dans ce tutoriel, nous définirons ce que sont exactement les hooks WordPress, comment ils fonctionnent et pourquoi ils sont bénéfiques. Ensuite, nous allons jeter un oeil à mon WordPress Widget Boilerplate et à la façon de l'exploiter dans de nouveaux projets via le contexte d'un exemple d'application.
Avant de développer des plugins, il est important de comprendre le modèle de WordPress pour la connexion à l'application et la différence entre les actions et les filtres..
Assez facile, non? En plus de cela, WordPress dispose d'une documentation solide pour ajouter des actions [1] et des filtres [2]. Vous pouvez en savoir plus sur les plug-ins dans l'API de plug-in [3] du Codex WordPress [4]..
Si vous lisez l'article précédent, vous connaissez déjà l'API Widget. C'est précis en ce sens qu'il nécessite un constructeur et pas moins de trois fonctions pour faire fonctionner quelque chose. Parce que les plugins ont la possibilité de s’accrocher à divers points du processus WordPress, l’API de plugin est un peu moins structurée. Heureusement, cela ne signifie pas que nous ne pouvons pas fabriquer une sorte de passe-partout à partir duquel créer nos plugins.
Après tout, ils contiennent toujours des fonctionnalités communes:
Semblable à notre Boilerplate WordPress Widget, nous pouvons configurer notre répertoire de modèles pour qu’il ressemble à ceci:
Ça a l'air familier, n'est-ce pas? L'aspect le plus important du Plugin Boilerplate n'est pas les détails de la structure de répertoires (bien que nous en examinions un peu plus tard), mais l'organisation du code du plugin principal lui-même..
Les plugins peuvent être développés en utilisant une poignée de fonctions ou en encapsulant chaque fonction dans une classe dans une approche orientée objet. Je suis un fan de ce dernier et mon passe-partout le représente. Voici la définition du plugin:
Accentsconagua
init_plugin_constants (); load_plugin_textdomain (PLUGIN_LOCALE, false, dirname (plugin_basename (__ FILE__)). '/ lang'); / * * TODO: * Définit la fonctionnalité personnalisée pour votre plugin. Le premier paramètre des appels * add_action / add_filter sont les points d'ancrage dans lesquels votre code doit être déclenché. * * Le deuxième paramètre est le nom de la fonction situé dans cette classe. Voir les stubs * plus tard dans le fichier. * * Pour plus d'informations: * http://codex.wordpress.org/Plugin_API#Hooks.2C_Actions_and_Filters * / add_action ('TODO', array ($ this, 'action_method_name')); add_filter ('TODO', array ($ this, 'filter_method_name')); // fin si // fin constructeur / * ------------------------------------------ ------* * Fonctions principales *--------------------------------------- ------ * / / ** * Remarque: les actions sont des points dans l'exécution d'un cycle de vie de page ou de processus * déclenché par WordPress. * / function action_method_name () // TODO définissez votre méthode d'action ici // end action_method_action / ** * Remarque: Les filtres sont des points d'exécution dans lesquels WordPress modifie des données * avant de les enregistrer ou de les envoyer au navigateur. * / function filter_method_name () // TODO définissez votre méthode de filtrage ici // end filter_method_name / * ---------------------------- ---------------- * * Fonctions privées * ----------------------------- ---------------- * / / ** * Initialise les constantes utilisées * pour plus de commodité dans le plugin. * / private function init_plugin_constants () / * TODO * * Ceci fournit l'identifiant unique de votre plugin utilisé dans * la localisation des chaînes utilisées. * * Par exemple: wordpress-widget-boilerplate-locale. * / if (! defini ('PLUGIN_LOCALE')) define ('PLUGIN_LOCALE', 'plugin-name-locale'); // end if / * TODO * * Définissez-le comme nom de votre plugin. C’est ce que montre * dans la zone Widgets de WordPress. * * Par exemple: WordPress Widget Boilerplate. * / if (! defini ('PLUGIN_NAME')) define ('PLUGIN_NAME', 'Nom du plugin'); // end if / * TODO * * c'est le slug de votre plugin utilisé pour l'initialiser avec * l'API WordPress. * Cela devrait également être le répertoire * dans lequel réside votre plugin. Utilisez des traits d'union. * * Par exemple: wordpress-widget-boilerplate * / if (! Define ('PLUGIN_SLUG')) définition ('PLUGIN_SLUG', 'plugin-name-slug'); // end if // end init_plugin_constants / ** * Fonction d'assistance pour l'enregistrement et le chargement des scripts et des styles. * * @name L'ID à enregistrer avec WordPress * @ chemin_fichier Le chemin d'accès au fichier réel * @is_script Argument facultatif pour si le chemin_fichier entrant est un fichier source JavaScript. * / private function load_file ($ name, $ file_path, $ is_script = false) $ url = WP_PLUGIN_URL. $ file_path; $ file = WP_PLUGIN_DIR. $ file_path; if (file_exists ($ file)) if ($ is_script) wp_register_script ($ name, $ url); wp_enqueue_script ($ name); else wp_register_style ($ name, $ url); wp_enqueue_style ($ name); // end if // end if // end _load_file // end class // TODO: met à jour l'appel d'instanciation de votre plug-in avec le nom donné à la définition de la classe new TODO (); ?> La plupart des IDE ont une fonction qui répertorie tous les TODO en suspens, alors je les place dans le code pour localiser facilement ce qui doit être fait pendant le développement. Notez qu'il existe trois zones principales de code:
Notez ici que le développement de plugins diffère du développement de widgets en ce qu'il n'y a pas plusieurs fonctions attendues. En fait, vous n'avez vraiment besoin que d'un constructeur. A partir de là, toutes les fonctions définies dans les appels add_action ou add_filter et votre responsabilité de les implémenter..
Avoir un sens? Voyons comment utiliser cette plaque de chaudière dans un exemple simple..
WordPress propose des points d'ancrage que vous pouvez imaginer pour presque le point d'exécution. Dans cet exemple, nous allons nous connecter au processus de post-rendu afin d'introduire un message personnalisé. Le fait est que nous voulons uniquement afficher ledit message dans le contexte d'un lecteur RSS..
Tout d'abord, les exigences:
Sur cette base, il ne semble pas que nous ayons besoin d'utiliser un code JavaScript, CSS ou un balisage pour créer notre plugin afin de pouvoir réduire notre plug-in warmplate au code du plugin principal et aux fichiers de localisation:
À ce stade, nous pouvons commencer à décomposer le passe-partout avec un nom et les constantes du plug-in:
/ ** * Initialise les constantes utilisées pour plus de commodité * dans le plugin. * / fonction privée init_plugin_constants () if (! defini ('PLUGIN_LOCALE')) define ('PLUGIN_LOCALE', 'rss-note-locale'); // fin si if (! defini ('PLUGIN_NAME')) define ('PLUGIN_NAME', 'Note RSS'); // fin si if (! defini ('PLUGIN_SLUG')) define ('PLUGIN_SLUG', 'rss-note-slug'); // fin si // fin init_plugin_constants Ensuite, nous devons déterminer quel type de hook est requis pour manipuler le contenu. Rappelez-vous que depuis que nous essayons d’ajouter quelque chose au contenu pour le rendre dans le navigateur, nous avons besoin d’un filtre. À partir de là, nous pouvons remplacer le constructeur:
/ ** * Initialise le plugin en définissant la localisation, les filtres et les fonctions d'administration. * / function __construct () // Définit les constnats utilisés dans le plugin $ this-> init_plugin_constants (); load_plugin_textdomain (PLUGIN_LOCALE, false, dirname (plugin_basename (__ FILE__)). '/ lang'); // ajoute la note à l'extrait et au fil principal add_filter ('the_content', array ($ this, 'display_rss_note')); add_filter ('the_excerpt_rss', tableau ($ this, 'display_rss_note')); // constructeur fin Notez que la fonction utilise deux filtres: un pour le_content [5] et un pour le_excerpt_rss [6]. Nous faisons cela parce que certains utilisateurs choisissent de ne publier qu'un extrait de leur blog plutôt que tout le contenu et nous voulons nous assurer que nous capturons les deux cas..
Ensuite, implémentons la définition de la fonction qui ajoutera le message au reste du message:
/ ** * Ajoute un court message au pied de page de chaque message lu dans un lecteur RSS * rappelant aux utilisateurs de visiter votre site. * / public function display_rss_note ($ content) if (is_feed ()) $ content. = ''; $ content. = ''; // end if return $ content; // end display_rss_note'; $ content. = __ ('Merci de votre lecture! Assurez-vous de suivre le reste de mes publications sur', PLUGIN_LOCALE); $ content. = ''; $ content. = get_bloginfo ('nom'); $ content. = '!'; $ content. = '
'; $ content. = '
Notez ici que la fonction accepte un paramètre référencé par la variable $ content. WordPress lui-même transmet ces données à la fonction. Pour ces filtres particuliers, nous traitons du contenu d'un article de blog. Tout ce que nous y ajoutons doit donc être concaténé afin qu'il soit ajouté à la fin de celui-ci..
Ce message que nous ajoutons dit simplement "Merci pour votre lecture! Assurez-vous de suivre le reste de mes messages sur [Nom du blog]!" via l’utilisation de la fonction get_bloginfo () [7]? Bien sûr, vous pouvez le mettre à jour pour lire ce que vous voulez. Enfin, notez que nous avons inclus cela dans une condition qui vérifie la fonction is_feed () [8]. Ceci est important car nous souhaitons que ce code ne se déclenche que si le contenu est envoyé via un flux RSS..
C'est ça - pas trop mal, non? Vous pouvez télécharger la version complète du code source de travail (y compris le fichier README associé) pour ce plugin sur GitHub ou directement ici à partir de Wptuts. Le passe-partout est également disponible sur GitHub.
Le but de cette série était non seulement d'aider à fournir un guide d'introduction à l'API du plugin WordPress, mais également de fournir un boîtier et des bases de correspondance facilitant le traitement et la maintenance des plugins WordPress comme tout autre projet logiciel..
