Techniques Ajax améliorées pour WordPress Programmation procédurale

Il y a quelques années, j'ai écrit une série de messages expliquant comment utiliser Ajax dans WordPress Frontend. Le but de la série est simple:

Nous allons donner un très bref aperçu de ce qu'est Ajax, de son fonctionnement, de sa configuration, et de la compréhension des points faibles fournis par WordPress. Nous allons également construire un petit projet qui met la théorie en pratique. Nous allons parcourir le code source et nous allons également nous assurer qu'il est disponible sur GitHub, ainsi.

D'une manière générale, la série résiste bien mais, comme tous les logiciels en développement constant, les techniques, les API et les approches changent. De plus, au fil des années et de l'amélioration de nos compétences, nous nous améliorons en développement et en employant de nouveaux API..

En raison de tout ce qui précède, je souhaite revoir le concept Ajax dans WordPress afin que vous puissiez voir certaines des nouvelles API et comment les utiliser dans votre travail quotidien ou comment refactoriser une partie du code que vous êtes susceptible de travailler. avec maintenant.

Un mot de prudence avant d’entrer trop loin dans ce didacticiel: je suppose que vous avez déjà lu les séries liées à l’introduction de cet article et que vous avez une certaine expérience de la création de plugins WordPress..

Définir le plugin

Comme pour tout plugin WordPress, il est important de définir l'en-tête afin que WordPress puisse lire le fichier afin d'introduire la nouvelle fonctionnalité dans l'application principale..

J'appelle cette variante du plugin Simple Ajax Demo, et il est situé dans wp-content / plugin / wp-simple-ajax. Le premier fichier que je crée réside dans le répertoire racine de wp-simple-ajax et s'appelle wp-simple-ajax.php.

Cela ressemble à ceci:

Le code doit être explicite, surtout si vous êtes habitué à travailler avec WordPress Plugins; Cependant, la chose la plus importante à comprendre est que toutes les informations ci-dessus déterminent ce que l'utilisateur voit dans le tableau de bord WordPress..
En d'autres termes, les utilisateurs verront le nom, la description et la version du plug-in, ainsi que le nom de l'auteur (qui sera lié à l'URL spécifiée), lorsqu'ils auront l'option d'activer le plug-in..
Ajout du fichier Ajax de WordPress
À ce stade, le plugin apparaîtra dans le tableau de bord WordPress Plugin mais ne fera rien car nous n’avons écrit aucun code. Pour y parvenir, nous allons aborder ce plugin en utilisant l'approche de programmation procédurale plutôt que l'approche orientée objet que j'ai utilisée dans la plupart de mes tutoriels..
Comment nous avons initialement ajouté le support Ajax
La raison d'éviter la programmation orientée objet est double:
 
C'est parce que le plugin va être très simple. Je suis davantage intéressé par les API spécifiées fournies par WordPress afin que vous puissiez vous concentrer sur les éléments les plus importants dans votre travail..
 
La deuxième partie de cette série se concentrera sur la refactorisation de ce code dans un système orienté objet afin que vous puissiez voir à quoi cela ressemble dans le contexte d'un système plus vaste utilisant des classes.
 
À terme, cette série couvrira les deux types de programmation supportés par PHP et WordPress.
Très probablement, si vous avez déjà travaillé avec Ajax dans le passé, vous avez fait quelque chose comme ceci pour donner à votre plugin le support nécessaire pour passer des appels asynchrones:
  
Cette méthode particulière n’est pas fondamentalement fausse, mais elle néglige certaines des API les plus récentes que je vais couvrir brièvement. Il mélange également PHP, HTML et JavaScript dans une seule fonction.
Ce n'est pas génial car le travail est fait, mais il existe un moyen plus propre de le faire..
Comment nous ajoutons le support Ajax
Tout d'abord, pour vous assurer que personne ne puisse accéder directement au plug-in, ajoutez la condition suivante juste sous l'en-tête du plug-in:
Notez que la balise PHP d'ouverture ne sera pas nécessaire car ce code viendra plus tard dans un fichier PHP préexistant (c'est nécessaire pour la coloration syntaxique maintenant).
Ensuite, configurons une fonction pour inclure le support WordPress pour Ajax via l’utilisation de certaines des API existantes qui n’impliquent pas le mélange de langages. 
Voici ce que nous devons faire:
 
Nous allons créer une fonction responsable de l'ajout du support Ajax.
 
Nous allons accrocher la fonction dans le wp_enqueue_script action.
 
Nous allons profiter de la wp_localize_script Appel API afin de mettre en file d'attente le support de WordPress pour Ajax (qui provient de admin-ajax.php).
 
Cela semble assez simple, n'est-ce pas? Notez que si vous avez des questions, vous pouvez toujours les ajouter dans les commentaires. Vérifiez le code suivant pour voir si vous pouvez suivre:
 admin_url ('admin-ajax.php'))); 
Encore une fois, notez que la balise PHP d'ouverture ne sera pas requise dans la version finale du plugin, car elle ne sert ici qu'à tirer parti de la fonctionnalité de coloration syntaxique..
Cela dit, jetez un oeil à wp_localize_script. Avant d'examiner chaque paramètre, examinons l'objectif de cette fonction. La version courte du Codex est la suivante:
Localise un script enregistré avec les données d'une variable JavaScript.
La description longue est importante, cependant:
Cela vous permet de proposer des traductions correctement localisées de toutes les chaînes utilisées dans votre script. Cela est nécessaire car WordPress n'offre actuellement qu'une API de localisation en PHP, pas directement en JavaScript..
Bien que la localisation soit la principale utilisation, elle peut être utilisée pour rendre disponibles à votre script toutes les données que vous ne pouvez normalement obtenir que du côté serveur de WordPress..
Maintenant, passez en revue les paramètres acceptés:
 
Le premier paramètre est appelé le manipuler et est utilisé pour identifier de manière unique le script qui est ajouté à la page.
 
Le deuxième paramètre est le prénom, et ceci est important car c'est la façon dont vous identifierez le script dans votre code. Vous verrez cela beaucoup plus en détail plus tard dans le tutoriel..
 
Le troisième paramètre est le Les données paramètre. Cela fait référence à un tableau qui sera envoyé au navigateur en tant qu'objet JavaScript. Puisque nous passons l'URL d'un chemin d'accès à un fichier, le support Ajax sera fourni..
 
Notez que le premier paramètre est ajax-script. Gardez cela à l'esprit lorsque nous nous concentrons sur l'écriture et la mise en file d'attente de notre propre code JavaScript, car nous aurons besoin d'utiliser cette poignée une fois de plus. 
Pensez également à noter le nom que vous avez choisi pour votre appel à l'API, car nous l'utiliserons lorsque nous utiliserons le code côté client plus loin dans ce didacticiel..
Une remarque importante sur le support Ajax
Notez que nous n'utilisons que le wp_enqueue_script accrocher et nous n'utilisons pas admin_enqueue_script. Ceci est dû au fait ajaxurl est déjà défini dans le tableau de bord.
Cela signifie que si vous souhaitez faire des demandes Ajax dans la zone d'administration de WordPress, vous n'avez pas besoin de mettre en file d'attente quoi que ce soit. Tout ce que nous faisons dans le cadre de ce tutoriel est spécifiquement destiné au front-end du site..
Configuration de votre code côté serveur
Il est maintenant temps d'écrire une fonction que votre JavaScript appellera via Ajax. Cela peut être ce que vous voulez, mais pour les besoins de ce plugin, nous allons configurer une fonction qui renverra des informations sur l'utilisateur connecté au site..
Le plugin va faire ce qui suit:
 
Demander au serveur de demander des informations sur l'utilisateur actuel.
 
Si l'utilisateur est connecté au site, il retournera une réponse JSON contenant les informations de l'utilisateur..
 
Si l'utilisateur n'est pas connecté, il retournera un code d'erreur.
 
Nous allons utiliser le console objet disponible dans la plupart des navigateurs modernes, assurez-vous donc que vous utilisez Chrome, Safari ou Firefox lorsque vous utilisez la source JavaScript que vous écrivez.
Faire une demande
Maintenant que nous avons expliqué comment le code va fonctionner chaque fois qu'un utilisateur envoie une demande Ajax au serveur, commençons à écrire une fonction pour le faire exactement. Nous l'appellerons sa_get_user_information.
L'implémentation de la fonction viendra plus tard dans ce tutoriel, mais la principale conclusion du code ci-dessus est que nous avons pris part à la fois wp_ajax_get_current_user_info et wp_ajax_nopriv_get_current_user_info. 
Ces deux hooks sont bien documentés dans le Codex, mais le premier hook permettra à ceux qui sont connectés au site d’avoir accès à cette fonction. Le deuxième crochet permettra à ceux qui sont ne pas connecté à ce site pour accéder à cette fonction.
Notez également tout après wp_ajax_ et wp_ajax_nopriv_ C'est à vous, en tant que développeur, de définir. Ce sera le nom de la fonction que vous appelez du côté client, comme vous le verrez plus loin dans ce tutoriel..
Traitement des demandes erronées
Avant d'implémenter la fonction, le fichier source JavaScript (qui n'a pas encore été écrit) a été appelé et nous devons nous assurer que nous sommes en mesure de gérer les erreurs éventuelles..
Dans notre cas, les erreurs potentielles peuvent être:
 
Personne n'est connecté.
 
L'ID utilisateur n'existe pas dans le système.
 
Il est hautement improbable que le second cas soit vrai, mais cela nous aidera à en apprendre davantage sur quelques API supplémentaires de WordPress et sur la manière dont nous pouvons en tirer parti pour traiter les demandes erronées..
La première chose à comprendre est WP_Error. Comme avec beaucoup d’API, cela est disponible dans le Codex:
Les instances de WP_Error stockent des codes d'erreur et des messages représentant une ou plusieurs erreurs, et indiquant si une variable est une instance de WP_Error ou non, peut être déterminée à l'aide de la fonction is_wp_error ().
Le constructeur acceptera jusqu'à trois paramètres (nous n'utiliserons que les deux premiers):
 
Le premier argument est le code d'erreur. C’est ce que nous pouvons utiliser du côté client pour analyser et déterminer ce qui ne va pas. Cela nous permet également d'écrire des informations dans un fichier journal, etc..
 
Le deuxième argument est un message pouvant accompagner le code d'erreur. Ceci est utile si nous voulons afficher un message à l'utilisateur.
 
Le dernier argument est un tableau d’informations, généralement des codes d’erreur et des messages. Quoi qu'il en soit, nous n'utiliserons pas cela pendant notre code.
 
Ensuite, nous enverrons les résultats des erreurs au client en utilisant une fonction appelée wp_send_json_error. C'est vraiment facile à utiliser:
Renvoie une réponse JSON à une demande Ajax, indiquant un échec. L'objet de réponse aura toujours une clé de réussite avec la valeur false. Si quelque chose est passée à la fonction dans le paramètre $ data, elle sera codée comme valeur pour une clé de données..
En combinant les deux WP_Error et wp_send_json_error, nous pouvons créer des fonctions qui nous aideront à fournir des codes d'erreur au JavaScript appelant le côté serveur.
Par exemple, supposons qu'une fonction génère une erreur si l'utilisateur n'est pas connecté au site Web. Ceci peut être réalisé en utilisant la fonction suivante:
Notez que la fonction est marquée comme privée même si elle se trouve dans l’espace de noms global. Il est préfixé par un trait de soulignement pour indiquer que cette fonction doit être considérée comme privée..
Nous y reviendrons dans le prochain article.
Deuxièmement, nous devons gérer le cas si l'utilisateur n'existe pas. Pour ce faire, nous pouvons créer une fonction qui effectue les tâches suivantes:
Nous avons maintenant deux fonctions, qui renverront chacune des informations au client si quelque chose a échoué, mais que faisons-nous si ces deux fonctions passent??
Traitement des demandes réussies
Si les fonctions ci-dessus ne génèrent aucune erreur, nous avons besoin d'un moyen de renvoyer la demande au client avec un message réussi et les informations qu'il demande..
Nous devons notamment renvoyer au client les informations contenant les informations de l'utilisateur actuel au format JSON..
Pour ce faire, nous pouvons profiter de la wp_send_json_success message. Il fait exactement ce que vous pensez qu'il ferait aussi:
Envoyez une réponse JSON à une demande Ajax, indiquant le succès. L'objet de réponse aura toujours une clé de réussite avec la valeur true. Si quelque chose est passée à la fonction, elle sera codée comme valeur pour une clé de données..
Combinons le travail que nous avons réalisé jusqu'à présent pour écrire une fonction que JavaScript appellera finalement et qui s'appuiera sur les deux fonctions plus petites que nous avons placées plus haut. En fait, ce sera l’implémentation de la fonction que nous avons laissée de côté dans ce tutoriel:
Si l'utilisateur est connecté et que l'utilisateur existe, nous enverrons un message de réussite au client contenant la représentation JSON de l'utilisateur. A ce stade, il est temps d'écrire du JavaScript.
La demande côté client
Premièrement, ajoutez un fichier appelé frontend.js à la racine de votre répertoire plugin. Initialement, il devrait inclure le code suivant:
; (function ($) 'use strict'; $ (function () );) (jQuery);
L'implémentation de la fonction sera couverte dans un instant, mais nous devons également veiller à mettre ce fichier JavaScript dans le plugin. Retour à la fonction sa_add_ajax_support et ajoutez ce qui suit au-dessus de l'appel à wp_localize_script:
Rappelez-vous que ce script doit avoir le même descripteur que celui défini dans wp_localize_script. Nous pouvons maintenant revoir notre fichier JavaScript et appeler le code côté serveur sur lequel nous avons travaillé tout au long de cet article..
Dans frontend.js, ajoutez le code suivant:
/ ** * Ce fichier est responsable de la configuration de la demande Ajax à chaque fois * qu'une page WordPress est chargée. La page peut être la page d'index principale *, une seule page ou tout autre type d'informations fournies par WordPress. * * Une fois que le DOM est prêt, il appelle le serveur via Ajax où * la fonction 'get_current_user_info' est définie, puis gérera la réponse * en fonction des informations renvoyées par la demande. * * @since 1.0.0 * /; (function ($) 'use strict'; $ (function () / *) Effectue un appel Ajax via une requête GET à l'URL spécifiée dans l'appel * wp_enqueue_script. Pour les données paramètre, transmettez un objet avec * le nom d'action de la fonction que nous avons définie pour renvoyer les informations utilisateur. * / $ .ajax (url: sa_demo.ajax_url, méthode: 'GET', données: action: 'get_current_user_info' ) .done (function (response) / * Une fois la requête effectuée, déterminez si elle a abouti ou non. * Si tel est le cas, analysez le JSON puis transmettez-le à la console. Sinon, * affichez le contenu de la requête ayant échoué. sur la console. * / if (true === response.success) console.log (JSON.parse (response.data)); else console.log (response.data););); ) (jQuery);
Étant donné le nombre de commentaires dans le code et en supposant que vous maîtrisez l’écriture de plugins WordPress et que vous ayez une certaine expérience d’Ajax, il devrait être relativement facile à suivre..
En bref, le code ci-dessus appelle le serveur lorsque la page est chargée, puis écrit des informations sur l'utilisateur actuel sur la console du navigateur.. 
Si un utilisateur est connecté, les informations sont écrites dans la console sous la forme d'un objet JavaScript, car elles sont analysées à partir de JSON..
Si, en revanche, l'utilisateur est ne pas connecté, un autre objet sera affiché avec un code d'erreur ainsi que le message, que vous pourrez tous voir dans la console.
Conclusion
A présent, vous devez bien comprendre les API que WordPress a à disposition pour traiter les demandes Ajax pour les utilisateurs connectés au site et pour ceux qui ne le sont pas..
En fin de compte, notre objectif devrait être de rédiger le code le plus propre et le plus maintenable possible afin de pouvoir continuer à utiliser ce code au cours des prochaines années. De plus, nous devrions écrire un code comme celui-ci pour que les autres personnes qui touchent à notre base de code comprennent bien ce que nous essayons de faire et utilisent également les meilleures pratiques compte tenu de notre environnement..
Dans ce tutoriel, j'ai utilisé une forme de programmation procédurale pour tout le code partagé, présenté et fourni via GitHub. Comme mentionné précédemment, il n’ya rien de mal à cela, mais je pense que cela vaut la peine de voir à quoi cela ressemble dans une perspective orientée objet..
Dans le prochain didacticiel, nous examinerons le refactoring de ce code dans un paradigme orienté objet qui utilise également les normes de codage WordPress pour documenter davantage notre travail et qui utilise une organisation de fichiers claire pour rendre notre écriture aussi claire et claire que possible..
N'oubliez pas que vous pouvez consulter tous 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 développement logiciel dans le contexte de WordPress et profite de la conversation avec les autres à propos de la même chose. sujets (ainsi que d'autres choses aussi).
En attendant, n'hésitez pas à laisser des questions ou des commentaires dans le flux ci-dessous et je m'efforcerai de répondre à chacun d'entre eux.. 



		
			
	   
	




Code