Création de pages d’administration WordPress personnalisées, partie 4

Alors que nous entamons le dernier article de la série sur la création de pages d’administration WordPress personnalisées dans WordPress, je pense qu’il est important de rappeler que cela ne veut pas dire que nous devrions contourner l'API Settings (ou l'une des API natives).. 

En fait, chaque API a sa place, et nous en utilisons évidemment beaucoup par le biais de ce code. Mais il est probable que vous travailliez parfois sur un plugin ou une application personnalisée et que vous deviez être en mesure d'implémenter vos propres fonctions de validation, de sérialisation, de routage, etc..

Et c'est ce que nous avons fait tout au long de cette série. Alors, au fur et à mesure que nous terminons notre plugin, je veux m'assurer que vous comprenez bien que je ne préconise pas de contourner les API natives. Je préconise l'utilisation des API disponibles pour les besoins de votre projet..

Pour votre avis

À ce stade, je suppose que vous êtes rattrapé par les articles précédents. Sinon, vous aurez du mal à comprendre d'où nous venons et pourquoi nous prenons certaines des décisions que nous prenons en ce qui concerne le code.

En outre, vous allez manquer certains des principes dont nous avons déjà discuté. En bref, je recommande de rattraper son retard, puis de revenir à cet article.

Avant de commencer

Cela dit (et en ce qui concerne les exigences), il ne reste que quelques petites choses à conclure en ce qui concerne ce plugin..

Plus précisément, nous devons:

• récupérer les informations de la base de données
• valider l'information
• l'afficher sur le tableau de bord
• afficher les informations sur le front-end

Heureusement, la majeure partie du travail a été effectuée pour nous. Nous avons toutes les informations dont nous avons besoin dans la base de données. À ce stade, il s’agit d’introduire une fonctionnalité qui faire quelque chose avec ces données.

Comme d'habitude, je suppose que vous disposez de la dernière version du code source et que vous êtes prêt à continuer avec cette série en y ajoutant le peu de code restant.. 

Cela dit, commençons.

Compléter le plugin

Avant de commencer à écrire du code, je tiens à préciser que le code que nous allons écrire est simple. Cependant, il est possible que nous devions introduire un certain niveau de refactorisation une fois que nous aurons atteint le point de rendre les informations disponibles à la fois. back-end et le front-end.

C'est une bonne chose, cependant.

Cela nous donnera non seulement l'occasion de réfléchir de manière critique à l'organisation de notre code, mais cela nous exposera également à des techniques supplémentaires orientées objet que nous n'avons pas vues jusqu'à présent dans la série de didacticiels..

Dans cet esprit, essayons de récupérer les informations de la base de données.

Récupérer des informations de la base de données

Récupérer les informations de la base de données est un processus simple. Depuis que nous avons déjà travaillé avec des fonctions telles que update_option, Cela devrait être très facile. 

Nous allons travailler avec get_option. Il ne nécessite qu'un seul argument, il s'agit de l'ID ou de la clé utilisée pour stocker les informations. Dans notre cas, c'est tutsplus-custom-data. Si vous voulez faire preuve de créativité, vous pouvez passer un deuxième argument facultatif qui sera renvoyé si les informations ne sont pas trouvées..

Afin de montrer comment cela peut être utilisé, je vais demander à la fonction de retourner une chaîne vide afin que nous ayons quelque chose valide pour afficher à l'utilisateur (même si ce n'est rien). L'extrait de code pour faire cela ressemble à ceci:

Mais cela soulève deux questions:
 
Où cela va-t-il (surtout si nous allons le rendre à deux endroits du plugin)?
 
Ne devrions-nous pas valider cette information?
 
Nous examinerons la première question un peu plus tard dans le didacticiel. Parlons d'abord de validation.
Valider les informations
On peut en dire beaucoup sur la validation dans WordPress. Mais pour que ce tutoriel soit aussi simple que possible, nous allons parler de validation des entrées. Après tout, nous traitons avec la saisie de l'utilisateur via un contribution élément, il est donc logique.
Vous pouvez tout lire à ce sujet dans le Codex, mais la validation des entrées est souvent définie comme suit:
La validation des données est le processus permettant de s’assurer que le programme fonctionne avec des données propres, correctes et utiles..
Dans le dernier article, nous avons abordé le thème de la désinfection, qui consiste essentiellement à s'assurer que les données sont propres avant d'être insérées dans la base de données. De la même manière, la validation consiste à s’assurer qu’elle est propre, sûre et lisible par nos utilisateurs..
Pour cela, il ne suffit pas juste saisir les informations de la base de données. Nous devons également le valider. Dans le cas de notre plugin, les données sont suffisamment simples pour que cela puisse paraître excessif de les valider; Cependant, le but de l'exercice est d'aider à développer la mentalité sur la manière dont nous devons procéder pour la désinfection, la sauvegarde, la récupération, la validation et l'affichage des données..
Techniques de validation
Et comme dans le cas de la désinfection, WordPress offre certaines fonctions qui facilitent la validation, notamment en ce qui concerne la validation des entrées. Dans cette situation, nous pouvons être aussi agressifs que nous le souhaitons. 
Dans notre cas, il suffirait peut-être d’utiliser esc_attr lors du rendu des options. Si nous avons autorisé les utilisateurs à saisir tout type de HTML, alors nous voudrons peut-être utiliser wp_kses.
Cette dernière fonction peut nécessiter un didacticiel, en particulier si vous débutez dans WordPress, nous allons donc nous en tenir à la première pour nos besoins..
Désérialisation
Plus tôt dans le projet, nous avons créé une classe spécialement pour enregistrer des informations dans la base de données. Nous avons appelé cette classe Sérialiseur. Pour ceux qui ne se souviennent pas exactement de ce qu'il fait:
 
La classe définit une fonction qui se déclenche sur le admin_post accrocher et enregistre les informations envoyées au serveur.
 
La fonction vérifie que les informations peuvent être sauvegardées en toute sécurité et que l'utilisateur est autorisé à les sauvegarder dans la base de données..
 
La fonction désinfecte les données et les écrit dans la base de données..
 
Mais nous ne voulons pas surcharger cette classe avec une responsabilité qui n’a aucun sens. Et puisque nous allons afficher ces informations à la fois sur la page des options et sur le front-end du site, il va sans dire que nous disposons d'une classe pour désérialiser la valeur et la rendre accessible à l'ensemble de l'application WordPress..
Donc, à la racine de votre répertoire de plugins, créez un partagé répertoire et ajouter un fichier appelé classe-deserializer.php.
Ensuite, nous voulons que notre code soit configuré de manière à ce qu'il:
 
est basé sur des principes orientés objet
 
récupère les informations pour lesquelles il est demandé
 
valide l'information
 
le renvoie à l'appelant
 
À cette fin, le squelette initial de la classe peut ressembler à ceci:
C'est simple, bien sûr. Nous ajouterons plus de code tout au long de ce didacticiel, mais rappelez-vous du principe de responsabilité unique: il s'agit d'une classe qui doit être utilisée entre deux parties de l'application WordPress..
Notez que dans le code ci-dessus, nous avons défini trois fonctions. Discutons de ce que chacun va faire:
 get_value utilisera la touche d’option entrante qui, dans notre cas, est tutsplus-custom-data, et renverra la valeur à l'appelant. Conformément aux normes de codage WordPress, nous devons utiliser «échappement tardif» pour nous assurer de valider correctement les informations. Nous verrons cela jouer momentanément.
Cela dit, allons de l'avant et réduisons les fonctions. Je fournirai également PHP DocBlocks pour expliquer ce que fait chaque fonction.
À ce stade, le code ci-dessus devrait être facile à suivre, compte tenu des points énumérés ci-dessus et des commentaires qu'il contient..
Afficher sur la page des options
Pour afficher cela sur la page des options, nous devons revoir la façon dont nous instancions la Submenu_Page dans le custom-admin-settings.php fichier. Plus précisément, nous devons instancier le désérialiseur et le transmettre au constructeur du Submenu_Page.
Premièrement, nous devons inclure le fichier. Cela peut se produire juste après que nous ayons vérifié si le fichier du plugin principal est accédé directement:
Le code dans la fonction principale de la racine du plugin devrait maintenant ressembler à ceci:
init (); $ deserializer = new Deserializer (); $ plugin = new Submenu (new Submenu_Page ($ deserializer)); $ plugin-> init (); 
Et puis le constructeur du Submenu_Page devrait ressembler à ceci:
désérialiseur = $ désérialiseur;  
De là, nous pouvons aborder la page des options. Nous mettons simplement à jour le valeur attribuer en appelant la fonction dans le désérialiseur. Rappelez-vous, puisque nous récupérons inconditionnellement la valeur et retournons une chaîne vide si rien n'existe, cela devrait fonctionner correctement.
 Quel message souhaitez-vous afficher au-dessus de chaque message?? 
  
Et avec cela, vous devriez être capable de sauvegarder et de récupérer votre valeur sur la page des options.
Montrer sur le front-end
Nous avons presque fini. La dernière chose à faire est de configurer le plug-in pour qu'il affiche le message personnalisé sur le front-end. Plus précisément, nous voulons afficher ce que l'utilisateur a saisi sur la page d'un article (par opposition à une page d'archive ou tout autre type de page) et le faire au-dessus de chaque article..
Cela signifie que nous devrons procéder comme suit:
 
Configurez une fonction qui utilisera le hook the_content.
 
Lire la valeur en utilisant notre désérialiseur.
 
Ajouter la valeur avant le contenu (peut-être dans son propre élément).
 
Heureusement ce n'est pas cette beaucoup de travail, surtout parce que nous avons la plupart du travail dont nous aurons besoin pour commencer. Néanmoins, nous devons créer une zone du plug-in spécifiquement responsable de la gestion du front-end du site..
À cette fin, créez un Publique répertoire à la racine de votre répertoire plugin et ajoutez class-content-messenger.php.
Dans la classe, nous devons définir un constructeur qui acceptera le désérialiseur en tant que dépendance. Le constructeur (et la propriété nécessaire) devrait ressembler à ceci:
désérialiseur = $ désérialiseur; 
Ensuite, nous devons créer un init fonction qui va enregistrer une fonction interne (que nous appellerons afficher) pour rendre le contenu avec le nouveau message.
Après cela, nous devrons mettre à jour le fichier de plugin principal afin qu’il instancie notre nouvelle classe et transmette le désérialiseur au constructeur. Ensuite, il initialisera la classe.
Tout d'abord, nous allons l'inclure:
Ensuite, nous allons l'instancier:
init (); 
De là, nous devrions être prêts à partir. Assurez-vous que vous avez entré une valeur sur la page des options. Enregistrez votre travail et consultez une seule page de publication sur votre site. Ça devrait ressembler a quelque chose comme ca:
Si ce n'est pas le cas, comparez votre code avec ce qui est ci-dessus (ou ce qui est attaché) et assurez-vous d'avoir correctement configuré toutes vos classes, fonctions et hooks..
Un mot sur les vues et les dépendances
Bien que nous ayons parlé du principe de responsabilité unique tout au long de cette série, nous n'avons pas beaucoup parlé de sujets plus avancés que nous pourrions utiliser pour rendre le code encore plus propre et suivre de meilleures pratiques..
Certaines de ces rubriques incluent des éléments tels que le chargement automatique de PHP et des éléments tels que l’injection de dépendances. Je n’en ai pas parlé, car ils ne font pas partie de l’objectif principal et le point principal de cette série vise à enseigner.
En fonction de la réception de cette série, je vais envisager de créer des tutoriels spécifiquement consacrés à ces sujets..
Conclusion
Et avec cela, nous concluons la série sur la création de pages d’administration personnalisées. J'espère que tout au long de cette série, vous avez appris quelques choses au-delà de la méthode standard de création de pages d'administration..
De plus, j'espère que vous avez vu comment vous pouvez appliquer quelques techniques de développement logiciel dans votre travail quotidien avec WordPress. En outre, j'espère que la discussion sur les points de vue et les dépendances a également suscité un intérêt pour des sujets plus avancés. Ce sont des choses que j'espère couvrir dans les prochains tutoriels, ainsi.
Comme d'habitude, vous pouvez voir mes cours et tutoriels sur ma page de profil, et vous pouvez me suivre sur mon blog et / ou Twitter à @tommcfarlin où je parle de différentes pratiques de développement de logiciels et de la façon dont nous pouvons les utiliser dans WordPress..
N'oubliez pas de télécharger le code dans la barre latérale de ce message, de le réviser, de l'utiliser et de voir ce que vous pouvez faire pour l'étendre et y ajouter vos propres fonctionnalités. Comme d'habitude, n'hésitez pas à me contacter via les commentaires concernant le tutoriel.
Ressources
 
L'API Paramètres
 
Le guide complet de l'API de configuration
 
update_option
 
get_option
 
Validation d'entrée
 
La validation des données
 
esc_attr
 
wp_kses
 
admin_post
 
Principe de responsabilité unique
 
Échappée tardive
 



		
			
	   
	




Code