Share
Dans le précédent article de cette série, nous avons finalement commencé à préparer les bases du plugin que nous allons écrire.
Plus précisément, nous avons examiné l'organisation des fichiers, les composants et les détails de ce que le plugin va faire. Nous avons également stubé le code que nous allons remplir dans ce tutoriel.
En plus de faire en sorte que notre plug-in fasse réellement quelque chose, nous allons parler d'un certain nombre de principes, techniques et idées orientés objet différents à mesure que nous travaillons à travers le plug-in..
Notez que dans ce tutoriel, nous allons faire très peu de documentation. Nous avons couvert les détails à ce sujet dans l'article précédent; Cependant, nous parlerons plus à ce sujet dans l'article qui suit celui-ci.
Comme pour le reste des articles de cette série, assurez-vous de revenir sur tout ce que nous avons couvert jusqu'à présent dans la série, car tout ce que nous faisons s'appuie sur les sujets précédents..
Pour référence, nous avons couvert:
Cela dit, reprenons là où nous nous sommes arrêtés.
Quel que soit le paradigme utilisé, l’écriture de logiciels n’est pas linéaire. C'est-à-dire que nous n'écrivons pas nécessairement au point de départ du programme. Souvent, mais pas toujours, cela pourrait être l’une des dernières parties que nous avons raison.
Cela dit, nous allons commencer à travailler sur chaque fichier qui constitue le plug-in d'une manière qui a du sens lorsque nous travaillons à travers le plug-in. J'entends par là que, au fil de cet article, les choses peuvent sembler éparpillées au début, mais devraient devenir un peu plus claires, nous, en examinant chaque fichier..
La première classe que nous allons terminer se situe dans includes / class-single-post-meta-manager-loader.php. Si vous vous souvenez de l'article précédent, cette classe est responsable de la coordination des actions et des filtres entre le plugin principal et la classe d'administration..
En un sens, il fournit un wrapper autour des API de hooks natives de WordPress; Cependant, cela nous permet de découpler (et donc d'imposer une séparation des préoccupations) nos classes afin que chacune puisse se spécialiser dans un but spécifique..
Tout d’abord, regardons la classe:
Accentsconagua
actions = array (); $ this-> filters = array (); fonction publique add_action ($ hook, $ composant, $ callback) $ this-> actions = $ this-> add ($ this-> actions, $ hook, $ composant, $ callback); fonction publique add_filter ($ hook, $ composant, $ callback) $ this-> filters = $ this-> add ($ this-> filtres, $ hook, $ composant, $ callback); fonction privée add ($ hooks, $ hook, $ composant, $ callback) $ hooks [] = array ('crochet' => $ hook, 'composant' => composant $, 'rappel' => $ rappel); retourne $ hooks; fonction publique run () foreach ($ this-> filtre en tant que $ hook) add_filter ($ hook ['hook'], tableau ($ hook ['composant'], $ hook ['callback']))); foreach ($ this-> actions en tant que $ hook) add_action ($ hook ['hook']], array ($ hook ['composant'], $ hook ['callback'])); À ce stade de la série, vous devriez remarquer plusieurs éléments clés concernant le cours en vous basant sur les discussions que nous avons eues jusqu'à présent dans la série..
protégé attributions dont chacune se réfère tableaux tel que défini dans le constructeur. L'un est destiné aux actions, l'autre aux filtres.Publique les fonctions. L'un est conçu pour ajouter facilement des actions, l'autre est conçu pour ajouter facilement des filtres. Notez que chacun accepte trois composants: le nom du hook, l'objet principal qui a la fonction à appeler et la fonction à appeler lors de l'exécution réelle du hook. Pour plus d'informations sur les actions et les filtres, voir cette référence..privé fonction utilisée pour simplifier les deux précédentes Publique des fonctions telles que nous avons un seul endroit pour ajouter le crochet au bon tableau.courir fonction est celle utilisée pour câbler tous les crochets définis. C’est ce qui permettra d’enregistrer toutes nos fonctions personnalisées avec WordPress..Comme nous continuons à construire le reste du plugin, nous verrons cette classe en cours d'utilisation.
Cette partie du plugin contient tous les fichiers situés dans le répertoire. admin annuaire. Si vous vous souvenez de l'article précédent, nous avons une classe primaire, une feuille de style et un seul fichier utilisé pour rendre la vue du contenu..
Nous allons examiner chacun de ces fichiers pour qu'ils soient utilisés en commençant par la classe admin principale.
Il s'agit de la classe principale chargée de l'enregistrement des feuilles de style, de la boîte méta et du fichier qui rendra le contenu de la boîte méta..
Jetons un coup d'oeil au code complet et ensuite nous passerons en revue ce qu'il fait.
version = $ version; public function enqueue_styles () wp_enqueue_style ('single-post-meta-manager-admin', plugin_dir_url (__FILE__). 'css / unique-post-meta-manager-admin.css', array (), $ this-> version, FALSE); fonction publique add_meta_box () add_meta_box ('single-post-meta-manager-admin', 'Single Post Meta Manager', tableau ($ this, 'render_meta_box'), 'post', 'normal', 'core') ; fonction publique render_meta_box () require_once plugin_dir_path (__FILE__). 'partiels / single-post-meta-manager.php'; Ceci est une classe relativement simple qui suppose que vous êtes familier avec wp_enqueue_style et add_meta_box. Sinon, passez en revue les articles liés, puis revenez à cet article..
Ensuite, examinons ce que fait le reste de la classe:
privé attribut utilisé pour suivre la version du plugin. Cette valeur est transmise au constructeur de la classe et est principalement utilisée pour s'assurer que nous incluons la version la plus récente du plug-in lors de la mise en file d'attente de nos feuilles de style afin de nous assurer de supprimer tous les fichiers susceptibles d'être mis en cache lors de l'exécution. ce plugin.Publique fonction utilisée pour enregistrer la feuille de style associée au tableau de bord, et nous avons une fonction publique qui permet d’ajouter une méta-boîte à la poster type tableau de bord.Bien que nous verrions tout plus en détail plus tard, vous remarquerez peut-être que la fonction qui met en file d'attente les feuilles de style n'est référencée nulle part ailleurs. C'est là que le Chargeur la classe finira par jouer.
Certains développeurs aiment écrire le balisage pour les vues de boîte à méta dans PHP et les stocker dans des chaînes très longues..
Je ne suis pas partisan de cette approche, car les vues (ou les partiels, les modèles ou tout ce que vous souhaitez appeler) sont généralement utilisées pour afficher des données et consister ainsi en davantage de balises. À cette fin, je pense qu'ils devraient être leur propre dossier.
Dans ce cas, nous voulons avoir un fichier qui rend toutes les métadonnées associées à la publication en cours dans un fichier. table élément qui est contenu dans la boîte à méta.
Le balisage pour ce fichier ressemble à ceci:
$ post_meta_value) ?>
Bien que le balisage et le minimum PHP contenu dans ce fichier soient relativement explicites, il Est-ce que dépend de votre connaissance du get_post_meta et get_the_ID les fonctions.
Une fois que toutes les métadonnées de la publication sont récupérées, nous parcourons ensuite les informations (en utilisant l'une des constructions de boucle que nous avons abordées beaucoup plus tôt), puis nous affichons à la fois la clé méta et la valeur..
La dernière chose que nous devons faire pour le contenu de la boîte méta est de fournir les styles de la feuille de style que nous avons mis en file d'attente dans la classe admin principale..
Pour ce faire, nous allons éditer css / simple-post-meta-manager.css.
# single-post-meta-manager-data width: 100%; # single-post-meta-manager-data .key font-weight: bold;
Évidemment, c'est très simple. Il ne fournit rien de plus sophistiqué que de définir la largeur de la table à 100% de son conteneur, et il met en gras les valeurs de la clé méta..
Mais cela suffit pour ce que nous cherchons à faire maintenant.
À ce stade, nous devons définir le fichier de plug-in principal. C'est le fichier qui définit la version du plugin, le slug du plugin (qui est normalement utilisé dans l'internationalisation ainsi que d'autres fonctionnalités), instancie le Loader et enregistre tous les points d'ancrage nécessaires avec WordPress..
Jetons un coup d'oeil au code, puis révisons-le une fois que tout est défini:
plugin_slug = 'single-post-meta-manager-slug'; $ this-> version = '0.2.0'; $ this-> load_dependencies (); $ this-> define_admin_hooks (); fonction privée load_dependencies () require_once plugin_dir_path (nom_répertoire (__FILE__)). 'admin / class-single-post-meta-manager-admin.php'; require_once plugin_dir_path (__FILE__). 'class-single-post-meta-manager-loader.php'; $ this-> loader = new Single_Post_Meta_Manager_Loader (); fonction privée define_admin_hooks () $ admin = new Single_Post_Meta_Manager_Admin ($ this-> get_version ()); $ this-> loader-> add_action ('admin_enqueue_scripts', $ admin, 'enqueue_styles'); $ this-> loader-> add_action ('add_meta_boxes', $ admin, 'add_meta_box'); fonction publique run () $ this-> loader-> run (); fonction publique get_version () return $ this-> version; La classe contient les attributs suivants:
Les attributs ci-dessus sont tous définis dans le constructeur, mais il existe également des appels à plusieurs autres fonctions..
load_dependencies est utilisé afin d'importer tous les fichiers utilisés dans ce plugin, tels que le gestionnaire d'administration et le chargeur.define_admin_hooks C’est ainsi que nous tirons parti du chargeur pour coordonner les fonctions définies dans notre classe d’administrateur qui mettent en file d'attente nos styles et notre méta-boîte avec WordPress. C’est ainsi que nous séparons les préoccupations de notre plugin et que nous nous assurons que chaque classe a un but unique..courir est la fonction qui met tout en œuvre pour que toutes les fonctionnalités du plugin soient activées lorsqu'elles sont activées dans WordPress.Sauf qu'il nous manque encore un dernier élément: comment pouvons-nous instancier réellement la classe de plug-ins et lancer le processus??
Pour ce faire, nous exploitons un fichier situé à la racine du répertoire du plugin. Certaines personnes appellent cela un fichier de démarrage de plugin, d'autres l'appellent un chargeur de démarrage, et d'autres l'appellent le fichier de plugin principal..
Quoi que vous choisissiez de l’appeler, c’est le fichier qui s’enregistre avec WordPress et qui met tout en oeuvre. Jetons un coup d'oeil au code et ensuite nous verrons ce qu'il fait après:
courir(); run_single_post_meta_manager ();
Le commentaire de code en haut du fichier indique à WordPress que le plugin existe et lui donne suffisamment d'informations sur le plugin pour qu'il puisse l'afficher dans le tableau de bord..
La première condition que vous voyez empêche l'accès direct au fichier de plug-in. Ce n'est rien de plus qu'une simple mesure de sécurité.
Enfin, nous appelons Demandez une fois pour inclure le fichier de plugin principal que nous avons examiné ci-dessus, puis nous définissons une fonction et instancie la Single_Post_Meta_Manager et après quoi nous appelons courir qui est ce qui met tout en mouvement.
Enfin, nous appelons la fonction que nous avons définie à la toute fin du fichier. Cela lance le processus et donne vie au plugin.
À ce stade, nous avons terminé les fonctionnalités de notre plugin; Cependant, nous n'avons toujours pas terminé. Il nous reste encore une chose à faire pour nous assurer de suivre toutes les meilleures pratiques d'un plugin et de fournir de la documentation..
Dans le prochain article, nous allons faire une pause dans les articles plus longs qui consistent à écrire du code, passer en revue les normes de documentation WordPress, puis documenter le plug-in de manière à compléter l'ensemble de ses fonctionnalités..
En attendant, téléchargez l'exemple de plug-in, explorez comment tout s'emboîte et assurez-vous de laisser des commentaires ou des questions sur notre travail à ce jour..
