Programmation orientée objet dans WordPress Construire le plugin I

À ce stade de la série, nous sommes enfin capable de commencer à construire notre plugin en utilisant les techniques orientées objet que nous avons apprises jusqu'à présent dans la série.

Si vous venez juste de nous rejoindre, je vous recommande fortement de rattraper la série jusqu'à présent; sinon, vous risquez de passer à côté de certains des points clés que nous allons démontrer au fur et à mesure que nous développons le plugin au cours des prochains articles..

Une introduction
Des classes
Les types
Structures de contrôle: instructions conditionnelles
Structures de contrôle: boucles
Fonctions et attributs
Portée

Bon, cela dit, il est enfin temps de commencer à écrire du code. Avant de commencer, il est important de comprendre que la construction d'un plugin - ou de tout type de logiciel - nécessite un certain nombre d'étapes. Bien que nous allons écrire un peu de code dans cet article, nous ne serons pas ajouter beaucoup de fonctionnalités jusqu'à ce que nous ayons l'échafaudage ou la base du plugin.

Pour ce faire, nous devons examiner plusieurs choses:

Définir les fonctionnalités du plugin que nous allons écrire,
Partagez tout ce que nous ne construisons peut-être pas dans cette première version,
Discuter de l'architecture et de l'organisation du fichier du plugin.

Couvrons donc ces points très rapidement, puis nous entrerons dans les détails du plugin.

Post Meta Viewer

Au cours des prochains articles, nous allons créer un plug-in qui introduit une boîte à méta de publication dans l'affichage de l'éditeur de publication unique qui affiche toutes les métadonnées associées à la publication en cours..

1. Les caractéristiques

Le plugin sera en lecture seule dans la mesure où vous ne pouvez vue les métadonnées associées au plugin. Nous ne pourrons pas introduire de nouvelles métadonnées - du moins pas pour la première version.

Les autres caractéristiques sont qu'il l'affichera dans un format propre et organisé afin que nous puissions facilement identifier la clé et les valeurs de l'ID de publication. Nous allons également introduire une ancre qui nous permettra de copier une ligne de code qui nous permettra d’appeler l’information sous la forme suivante: get_post_meta ($ post_id, $ meta_key, $ meta_value);.

2. Un fort 1,0

Avant d'aller plus loin, il y a beaucoup de fonctionnalités intéressantes que nous pourrions implémenter dans ce plugin.

Nous pourrions introduire la capacité de:

ajouter de nouvelles méta-données personnalisées
mettre à jour les méta-données existantes
supprimer les méta-données post existantes
trier les colonnes par méta-clés
trier les colonnes par méta-valeurs
… etc

Mais, conformément à la philosophie de création d'une "version 1.0 forte", nous allons construire une base légère et ciblée sur laquelle nous pourrons continuer à construire le plugin comme bon nous semble après cette série..

Nous aborderons peut-être certaines des fonctionnalités ci-dessus avant la fin de la série. Peut-être voudrez-vous présenter votre propre ensemble de fonctionnalités. De toute façon, c'est bien. En bout de ligne, nous allons créer un noyau solide sur lequel nous pourrons continuer à nous appuyer pour développer des fonctionnalités..

3. L'architecture et l'organisation des fichiers

Donc, tout cela étant dit, parlons d'abord des points forts du plug-in, puis nous examinerons comment nous organiserons les fichiers et les composants du plug-in..

Le plugin nécessite un fichier de plugin de base qui servira en quelque sorte de chargeur de démarrage (ou fichier d'amorçage) pour s'inscrire lui-même sous WordPress et pour charger les composants du plugin..
Le plugin aura besoin d'une classe qui coordonne les points d'ancrage et les rappels utilisés dans le plugin. Cela aidera à dissocier la fonctionnalité des points d'ancrage et des classes responsables de l'affichage réel du travail, ce qui nous permet de nous assurer que chacune de nos classes est spécialisée et exécute idéalement un seul travail..
Le plugin aura besoin d’une classe qui sera responsable de l’affichage des informations dans le tableau de bord unique qui rendra la méta-boîte..
Nous aurons besoin d'une classe de plug-in de base qui enregistrera toutes les dépendances et fournira des informations sur la version du plug-in, qui connaît le chargeur et la fonctionnalité d'administration afin d'enregistrer des informations entre les deux composants..
Enfin, nous aurons besoin de feuilles de style afin de nous assurer que les informations paraissent bien dans le tableau de bord..

Cela vous semble déroutant? J'espère que voir et examiner la structure du fichier et l'exemple de code de base aideront à rendre cela plus logique.

Cela dit, examinons de haut niveau les composants qui vont interagir les uns avec les autres, puis examinons la manière dont les fichiers seront organisés. Après cela, nous commencerons par écraser le code du plugin sur lequel nous remplirons dans le prochain article..

Composants de plugin

Plus précisément, le plugin sera composé des composants suivants - ou fichiers - qui constitueront la source du plugin. Après avoir jeté un coup d’œil à la liste des fichiers, nous allons jeter un coup d’œil à un diagramme montrant comment toutes les pièces vont interagir..

single-post-meta-manager.php est le fichier principal qui enregistre le plugin avec WordPress et met tout en mouvement.
classe-single-post-meta-manager-admin.php est le fichier responsable de l'enregistrement et de la mise en file d'attente des feuilles de style, ainsi que de l'affichage des éléments de l'interface utilisateur qui contiendront les métadonnées post.
single-post-meta-manager-admin.css est la feuille de style qui va styler l'interface utilisateur.
classe-single-post-meta-manager-loader.php est le fichier qui va coordonner les actions et les filtres entre le plugin principal et la classe d'administration.
classe-single-post-meta-manager.php est le fichier de plug-in principal qui conserve les informations de version de plug-in, les informations de plug-in du slug, les références au chargeur et le fichier dans lequel nous indiquons au chargeur quels objets et quelles fonctions sont responsables de l'affichage de l'interface utilisateur administrative..
LISEZMOI.md fournit les instructions habituelles pour démarrer avec le plugin.
CHANGEMENTS.md fournit une liste des modifications apportées à chaque version du plugin que nous publions.

En fonction de votre niveau d'expérience en programmation orientée objet, cela peut sembler ou ne pas ressembler à beaucoup de fichiers pour un ensemble relativement simple de fonctionnalités; Cependant, il reste encore beaucoup à faire: nous n'allons pas déposer tous ces fichiers à la racine du répertoire du plugin..

Au lieu de cela, nous allons encore plus loin et organisons les choses dans des répertoires appropriés. Une fois que nous aurons examiné cela, nous examinerons ensuite l’organisation des composants sous la forme d’un diagramme, puis nous examinerons le code qui fournit l’échafaudage du plug-in..

Organisation du fichier

L'organisation des fichiers est relativement simple et est probablement mieux illustrée par l'utilisation d'une image:

Pour être clair, voici la ventilation de ce que vous voyez dans la capture d'écran ci-dessus:

admin / classe-single-post-meta-manager-admin.php
admin / css / single-post-meta-manager.admin.css
includes / class-single-post-meta-manager-loader.php
includes / class-single-post-meta-manager.php
langues /
single-post-meta-manager.php
CHANGEMENTS.md
LISEZMOI.md
LICENSE.txt

Ceci est important à reconnaître et il y a quelques endroits dans le code où nous allons enregistrer des dépendances et il est important de savoir où les dépendances sont afin que nous puissions leur fournir les chemins appropriés.

Construire le plugin

À ce stade, nous sommes prêts à commencer à décrire les classes que nous allons utiliser. Il y a plusieurs choses importantes à noter à propos du code que vous êtes sur le point de voir:

Nous ne ferons que tronquer les classes et les méthodes; nous n'introduirons aucune fonctionnalité réelle dans cet article..
À la fin de la mise en œuvre, le plugin devrait apparaissent dans le tableau de bord WordPress et peuvent être activés (même si rien ne se passera réellement).
Malgré le fait que je pense que la documentation est la clé du développement de la qualité, nous n'introduirons pas les commentaires dans cet article car il y a un compromis à faire: cet article peut devenir excessivement long avec une quantité extraordinaire de détails, ou nous pouvons continuer de prendre pas à pas chaque aspect de cette série. J'opte pour ce dernier afin que nous ne soyons pas submergés par la quantité d'informations.

Cela dit, si vous avez des questions sur le code, n'hésitez pas à laisser des commentaires à ce sujet; cependant, je peux dire d'attendre le prochain article pour voir la réponse..

Passons maintenant au code.

Le fichier de plugin principal

Le fichier de plug-in principal est responsable de l'enregistrement du plug-in auprès de WordPress, et sera finalement responsable de l'importation de la classe de plug-in principale (que nous passerons en revue dans un instant), et de l'activation du plug-in.

Notez que la condition que nous avons au bas du fichier. Cela fera en sorte que le fichier plugin ne soit pas accessible directement dans le navigateur Web..

Fichiers administratifs

Tous ces fichiers résident dans le admin répertoire comme indiqué ci-dessus.

La classe d'administration unique Post Meta Manager

Cette classe mettra en file d'attente la feuille de style et affichera la méta-boîte qui sera utilisée pour afficher la méta post donnée..

version = $ version;  fonction publique enqueue_styles ()  fonction publique add_meta_box ()

Dans cette classe, notez qu’il possède un seul attribut protégé pour la $ version du plugin. Cet attribut est configuré dans le constructeur de la classe..

Nous verrons comment cela s’intégrera plus tard dans le code.

Feuille de style Single Post Meta Manager

À l'heure actuelle, il n'y a pas de code à afficher pour ce fichier particulier; cependant, allez-y et ajoutez-le à la admin / css sous-répertoire en tant que ce que nous utiliserons finalement pour styler le tableau de bord.

Comprend

Il s’agit de fichiers de plug-in principaux chargés de la coordination des informations entre les différents hooks et la zone administrative du plug-in..

Poste unique Meta Manager Loader

Cette classe sera utilisée par la classe de plug-in principale pour coordonner tous les points d'ancrage existant dans le plug-in et la classe d'administration définie ci-dessus..

Notez que dans la classe ci-dessus, nous avons marqué les attributs comme protégé. Ceci est fait pour que cette classe ait accès à ses attributs, mais aucune autre classe ne.

De plus, nous avons agi de la sorte au cas où nous sous-classions cette classe particulière lors d'une future itération du plugin..

Meta Manager Single Post

Enfin, nous avons la classe de plug-in primaire chargée de charger les dépendances, de définir les paramètres régionaux et de coordonner les points d'ancrage..

plugin_slug = 'single-post-meta-manager-slug'; $ this-> version = '0.1.0';  fonction privée load_dependencies ()  fonction privée define_admin_hooks ()  fonction publique run ()  fonction publique get_version () return $ this-> version;

Avis dans le code ci-dessus, nous avons supplémentaire protégé attributs, un couple de privé fonctions, et un Publique fonction utilisée comme getter que nous utiliserons alors que nous continuons à construire le plugin.

Dans le prochain article, nous allons passer beaucoup de temps dans cette classe, car il s’agit du point d’entrée pour de nombreuses fonctionnalités..

À suivre

Nous avons couvert beaucoup de matériel dans cet article, mais il y a évidemment beaucoup plus à faire. En plus de fournir de la documentation pour nos fonctions, nous devons implémenter une fonctionnalité qui donne vie à cet échafaudage..

C’est précisément ce que nous allons faire dans le prochain article de la série, après quoi nous nous concentrerons sur la documentation du code..

Comme mentionné précédemment, n'hésitez pas à laisser des questions et / ou des commentaires sur le code ci-dessus. Pour ceux qui sont intéressés, vous pouvez toujours consulter l'état actuel du projet sur GitHub..

Jusqu'au prochain article!

Code