Verbeterde Ajax-technieken voor WordPress procedurele programmering

Een paar jaar geleden schreef ik een reeks berichten over het gebruik van Ajax in het WordPress Frontend. Het doel van de serie is eenvoudig:

We gaan een heel kort overzicht geven van wat Ajax is, hoe het werkt, hoe je het op de voorkant instelt en de haken begrijpt die WordPress biedt. We zullen ook daadwerkelijk een klein project bouwen dat de theorie in de praktijk brengt. We lopen de broncode door en we zorgen er ook voor dat deze beschikbaar is op GitHub.

Over het algemeen blijft de reeks goed, maar zoals bij alle software die voortdurend wordt ontwikkeld, veranderen technieken, API's en benaderingen. Naarmate de jaren verstreken en we onze vaardigheden verder verfijnen, worden we bovendien beter in de ontwikkeling en worden we beter in het gebruik van nieuwe API's.

Vanwege al het bovenstaande wil ik het concept van Ajax opnieuw bekijken in WordPress, zodat u enkele van de nieuwe API's ziet en hoe u ze kunt gebruiken in uw dagelijkse werk of hoe u een deel van de code die u mogelijk werkt kunt refactoren met nu.

Een woord van waarschuwing voordat je te ver gaat in deze tutorial: ik neem aan dat je de serie die in de introductie van dit artikel is gelinkt al hebt gelezen en dat je enige ervaring hebt met het bouwen van WordPress-plug-ins.

De invoegtoepassing definiëren

Zoals met elke WordPress plug-in, is het belangrijk om ervoor te zorgen dat u de header definieert, zodat WordPress het bestand kan lezen om de nieuwe functionaliteit in de kernapplicatie te introduceren.

Ik noem deze variant van de plug-in Eenvoudige Ajax-demo, en het bevindt zich in wp-content / plugin / wp-simple-ajax. Het eerste bestand dat ik aan het maken ben, bevindt zich in de hoofdmap van wp-simple-ajax en wordt genoemd wp-simple-ajax.php.

Het ziet er zo uit:

De code moet vanzelfsprekend zijn, vooral als u gewend bent om met WordPress-plug-ins te werken; Het belangrijkste om te begrijpen is echter dat alle bovenstaande informatie de indruk wekt van wat de gebruiker ziet in het WordPress-dashboard.
Dat wil zeggen dat gebruikers de naam, beschrijving en versie van de plug-in te zien krijgen, evenals de naam van de auteur (die aan de opgegeven URL wordt gekoppeld) wanneer ze de optie krijgen om de plug-in te activeren.
Ajax-bestand van WordPress toevoegen
Op dit punt zal de plug-in verschijnen in het WordPress Plugin-dashboard, maar het zal eigenlijk niets doen, omdat we geen code hebben geschreven. Om dit mogelijk te maken, benaderen we deze specifieke plug-in met behulp van de procedurele programmeermethode in plaats van de objectgerichte benadering die ik in de meeste van mijn zelfstudies heb gebruikt.
Hoe we oorspronkelijk Ajax-ondersteuning hebben toegevoegd
De reden om objectgeoriënteerd programmeren nu te vermijden, is tweeledig:
 
Dit komt omdat de plug-in heel eenvoudig gaat worden. Ik ben meer geïnteresseerd in de focus op de opgegeven API's van WordPress, zodat je je kunt concentreren op de belangrijkste zaken waarop je je kunt concentreren in je werk.
 
Het tweede deel van deze serie zal zich richten op het refactoren van deze code in een objectgeoriënteerd systeem, zodat je kunt zien hoe dit alles eruitziet binnen de context van een groter systeem met behulp van klassen.
 
Uiteindelijk zal deze serie betrekking hebben op beide soorten programma's die worden ondersteund door PHP en WordPress.
Hoogstwaarschijnlijk, als je in het verleden met Ajax hebt gewerkt, dan heb je zoiets gedaan om je plug-in de ondersteuning te geven om asynchrone oproepen te doen:
  
Deze specifieke methode is niet inherent verkeerd, maar verwaarloost wel enkele van de nieuwere API's die ik tijdelijk zal behandelen. Het mengt ook PHP, HTML en JavaScript allemaal in een enkele functie.
Het is niet geweldig omdat het de klus wordt geklaard, maar er is een schonere manier om dit te doen.
Hoe we Ajax-ondersteuning toevoegen
Ten eerste, om ervoor te zorgen dat de plug-in niet rechtstreeks door iemand kan worden benaderd, voegt u de volgende voorwaardelijke toe net onder de header van de plug-in:
Merk op dat de PHP-openingstoets niet nodig zal zijn, omdat deze code later zal komen in een reeds bestaand PHP-bestand (het is nu noodzakelijk voor het markeren van syntaxis).
Laten we vervolgens een functie instellen om WordPress-ondersteuning voor Ajax op te nemen door het gebruik van enkele van de bestaande API's waarbij geen talen worden gecombineerd. 
Dit is wat we moeten doen:
 
We gaan een functie creëren die verantwoordelijk is voor het toevoegen van Ajax-ondersteuning.
 
We zullen de functie inhaken in de wp_enqueue_script actie.
 
We zullen profiteren van de wp_localize_script API-oproep om WordPress-ondersteuning voor Ajax in te huren (die afkomstig is van admin-ajax.php).
 
Het lijkt eenvoudig genoeg, nietwaar? Opmerking: als u vragen heeft, kunt u deze altijd toevoegen in de opmerkingen. Bekijk de volgende code om te zien of je kunt volgen:
 admin_url ('admin-ajax.php'))); 
Nogmaals, merk op dat de PHP-openingstag niet nodig is in de definitieve versie van de plug-in, omdat het hier alleen is om te profiteren van de syntax highlighting-functionaliteit.
Met dat gezegd, neem een ​​kijkje op wp_localize_script. Voordat we elke parameter onderzoeken, laten we het doel van deze functie bekijken. Vanaf de Codex is de korte versie als volgt:
Lokaliseert een geregistreerd script met gegevens voor een JavaScript-variabele.
De langere beschrijving is echter belangrijk:
Hiermee kunt u correct gelokaliseerde vertalingen aanbieden van alle strings die in uw script worden gebruikt. Dit is nodig omdat WordPress momenteel alleen een lokalisatie-API aanbiedt in PHP, niet rechtstreeks in JavaScript.
Hoewel localisatie het primaire gebruik is, kan het worden gebruikt om gegevens beschikbaar te maken voor uw script die u normaal alleen van de serverzijde van WordPress kunt krijgen..
Bekijk nu de parameters die worden geaccepteerd:
 
De eerste parameter wordt de handvat en wordt gebruikt om het script dat wordt toegevoegd aan de pagina uniek te identificeren.
 
De tweede parameter is de naam, en dit is belangrijk, want het is hoe je het script in je hele code zult identificeren. Je zult dit later in de tutorial in meer detail zien.
 
De derde parameter is de gegevens parameter. Het verwijst naar een array die als een JavaScript-object naar de browser wordt verzonden. Aangezien we de URL van een pad naar een bestand doorgeven, wordt Ajax-ondersteuning geboden.
 
Let op de eerste parameter is ajax-script. Houd hier rekening mee wanneer we onze aandacht richten op het schrijven en bijhouden van ons eigen JavaScript, omdat we dit handvat nog een keer moeten gebruiken. 
Onthoud ook dat je de naam moet noteren die je hebt geselecteerd voor je aanroep naar de API, omdat we dit later zullen gebruiken bij het werken met de client-side code in deze tutorial.
Een belangrijke opmerking over Ajax-ondersteuning
Merk op dat we de alleen gebruiken wp_enqueue_script haak en we gebruiken het niet admin_enqueue_script. Dit is zo omdat ajaxurl is al gedefinieerd in het dashboard.
Dit betekent dat als u op zoek bent naar Ajax-verzoeken in het beheergebied van WordPress, u niets hoeft in te leveren. Alles wat we doen in het kader van deze tutorial is specifiek bedoeld voor de voorkant van de website.
Uw server-side code instellen
Nu is het tijd om een ​​functie te schrijven die je JavaScript via Ajax zal bellen. Dit kan alles zijn wat je wilt, maar voor de doeleinden van deze plug-in gaan we een functie instellen die informatie teruggeeft over de gebruiker die is ingelogd op de site.
De plug-in doet het volgende:
 
Vraag een verzoek aan de server om informatie over de huidige gebruiker.
 
Als de gebruiker is aangemeld bij de site, retourneert deze een JSON-antwoord van de gebruikersinformatie.
 
Als de gebruiker niet is aangemeld, retourneert deze een foutcode.
 
We zullen de gebruiken troosten object dat beschikbaar is in de meeste moderne browsers, dus zorg ervoor dat u Chrome, Safari of Firefox gebruikt wanneer u werkt met de JavaScript-bron die u gaat schrijven.
Een verzoek doen
Nu we hebben uitgelegd hoe de code precies werkt wanneer een gebruiker een Ajax-aanvraag naar de server doet, laten we beginnen met het schrijven van een functie om precies dat te doen. We zullen het noemen sa_get_user_information.
De implementatie van de functie komt later in deze zelfstudie, maar de primaire afhaalmogelijkheid van de bovenstaande code is dat we beide hebben gekoppeld aan wp_ajax_get_current_user_info en wp_ajax_nopriv_get_current_user_info. 
Deze twee haken zijn goed gedocumenteerd in de Codex, maar de eerste haak zal degenen die ingelogd zijn op de site toegang geven tot deze functie. De tweede haak zal degenen die dat zijn toestaan niet ingelogd op deze site om toegang te krijgen tot deze functie.
Noteer ook alles na wp_ajax_ en wp_ajax_nopriv_ is aan jou, als ontwikkelaar, om te definiëren. Dit is de naam van de functie die u vanaf de client aanroept, zoals u verderop in deze tutorial zult zien.
Onjuiste verzoeken verwerken
Voordat de functie wordt geïmplementeerd, is het JavaScript-bronbestand (dat nog moet worden geschreven) opgevraagd en moeten we ervoor zorgen dat we eventuele fouten kunnen verwerken..
In ons geval kunnen de mogelijke fouten zijn:
 
Niemand is ingelogd.
 
De gebruikers-ID bestaat niet in het systeem.
 
Het is hoogst onwaarschijnlijk dat de tweede case waar zal zijn, maar het zal ons helpen meer te weten te komen over enkele WordPress-API's en hoe we hiervan kunnen profiteren bij het verwerken van onjuiste verzoeken.
Het eerste dat je moet begrijpen is WP_Error. Zoals met veel API's, is dit beschikbaar in de Codex:
Instances van WP_Error-winkelfoutcodes en berichten die een of meer fouten vertegenwoordigen, en of een variabele een exemplaar van WP_Error is, kan worden bepaald met de functie is_wp_error ().
De constructor accepteert maximaal drie parameters (hoewel we alleen de eerste twee gebruiken):
 
Het eerste argument is de foutcode. Dit is wat we aan de client-side kunnen gebruiken om te analyseren en te bepalen wat er mis ging. Het stelt ons ook in staat om informatie naar een logbestand te schrijven, enzovoort.
 
Het tweede argument is een bericht dat de foutcode kan vergezellen. Dit is handig als we een bericht voor de gebruiker willen weergeven.
 
Het laatste argument is een reeks informatie, meestal foutcodes en berichten. Hoe dan ook, we zullen dit niet gebruiken tijdens onze code.
 
Vervolgens sturen we de resultaten van de fouten terug naar de client met behulp van een functie genaamd wp_send_json_error. Dit is echt gemakkelijk te gebruiken:
Stuur een JSON-antwoord terug naar een Ajax-verzoek, met vermelding van een fout. Het antwoordobject heeft altijd een succescode met de waarde false. Als er iets wordt doorgegeven aan de functie in de parameter $ data, wordt deze gecodeerd als de waarde voor een gegevenssleutel.
Door beide te combineren WP_Error en wp_send_json_error, we kunnen functies maken die ons helpen bij het leveren van foutcodes aan het JavaScript dat de server oproept.
Laten we zeggen dat we een functie hebben die een fout oplevert als de gebruiker niet op de website is ingelogd. Dit kan worden bereikt met behulp van de volgende functie:
Merk op dat de functie is gemarkeerd als privé, ook al bevindt deze zich in de algemene naamruimte. Het is voorafgegaan door een onderstrepingsteken om aan te geven dat deze functie als privé moet worden beschouwd.
We zullen dit in het volgende artikel opnieuw bekijken.
Ten tweede moeten we de zaak behandelen als de gebruiker niet bestaat. Om dit te doen, kunnen we een functie maken die het volgende doet:
We hebben nu twee functies, die elk informatie terugsturen naar de client als iets is mislukt, maar wat doen we als beide functies zijn voltooid?
Omgaan met succesvolle aanvragen
Als de bovenstaande functies geen fouten opleveren, moeten we een manier hebben om het verzoek naar de klant terug te sturen met een succesvol bericht en de informatie die wordt opgevraagd.
We moeten de informatie namelijk terugsturen naar de client met de informatie van de huidige gebruiker in JSON-indeling.
Om dit te doen, kunnen we profiteren van de wp_send_json_success bericht. Het doet precies wat u denkt dat het ook zou doen:
Stuur een JSON-antwoord terug naar een Ajax-verzoek, met vermelding van succes. Het antwoordobject heeft altijd een successleutel met de waarde true. Als er iets aan de functie wordt doorgegeven, wordt het gecodeerd als de waarde voor een gegevenssleutel.
Laten we het werk dat we tot nu toe hebben gedaan combineren om een ​​functie te schrijven die de JavaScript uiteindelijk zal bellen en die de twee kleinere functies die we hierboven hebben geplaatst, gebruikt. In feite zal dit de implementatie zijn van de functie die we eerder in deze tutorial hebben weggelaten:
Als de gebruiker is aangemeld en de gebruiker bestaat, sturen we een succesbericht naar de client met de JSON-weergave van de gebruiker. Op dit moment is het tijd om wat JavaScript te schrijven.
Het client-side verzoek
Voeg eerst een bestand toe met de naam frontend.js naar de root van uw plugin-map. In eerste instantie zou het de volgende code moeten bevatten:
; (functie ($) 'gebruik strict'; $ (function () );) (jQuery);
De functie-implementatie wordt tijdelijk behandeld, maar we moeten er ook voor zorgen dat we dit JavaScript-bestand in de plug-in in de wachtrij plaatsen. Keer terug naar de functie sa_add_ajax_support en voeg het volgende toe boven de oproep aan wp_localize_script:
Onthoud dat dit script dezelfde hendel moet hebben als degene die is gedefinieerd in wp_localize_script. Nu kunnen we ons JavaScript-bestand opnieuw bekijken en bellen naar de code aan de server waaraan we in dit hele artikel hebben gewerkt.
In frontend.js, voeg de volgende code toe:
/ ** * Dit bestand is verantwoordelijk voor het instellen van het Ajax-verzoek elke keer dat een WordPress-pagina wordt geladen. De pagina kan de hoofdindexpagina zijn, * een enkele pagina of elk ander type informatie dat door WordPress wordt gerenderd. * * Zodra de DOM gereed is, maakt deze een Ajax-oproep naar de server waar * de functie 'get_current_user_info' is gedefinieerd en verwerkt vervolgens de * reactie op basis van de informatie die uit de aanvraag is geretourneerd. * * @since 1.0.0 * /; (function ($) 'gebruik strict'; $ (function () / * Maak een Ajax-oproep via een GET-verzoek naar de URL die is opgegeven in de * wp_enqueue_script-aanroep. parameter, geef een object door * de actienaam van de functie die we hebben gedefinieerd om de gebruikersinformatie te retourneren. * / $ .ajax (url: sa_demo.ajax_url, methode: 'GET', data: action: 'get_current_user_info' ) .done (functie (antwoord) / * Als het verzoek klaar is, bepaalt u of het is geslaagd of niet. * Als dit het geval is, analyseert u de JSON en geeft u deze vervolgens weer door aan de console. Anders geeft * de inhoud van het mislukte verzoek weer naar de console. * / if (true === response.success) console.log (JSON.parse (response.data)); else console.log (response.data););); ) (jQuery);
Gezien het aantal reacties in de code en ervan uitgaande dat je bekend bent met het schrijven van WordPress-plug-ins en wat ervaring hebt met Ajax, zou het relatief gemakkelijk te volgen moeten zijn.
Kort gezegd, de bovenstaande code belt naar de server wanneer de pagina wordt geladen en schrijft dan informatie naar de consoleschakelaar over de huidige gebruiker. 
Als een gebruiker is aangemeld, wordt de informatie in de vorm van een JavaScript-object weggeschreven naar de console, omdat deze wordt geparseerd vanuit JSON.
Als, aan de andere kant, de gebruiker is niet ingelogd, dan zal een ander object worden uitgeschreven met een foutcode samen met het bericht, die je allemaal in de console kunt zien.
Conclusie
Inmiddels zou u een duidelijk begrip moeten hebben van de API's die WordPress beschikbaar heeft voor het werken met Ajax-verzoeken voor gebruikers die zijn ingelogd op de site en voor degenen die dat niet zijn.
Uiteindelijk zou ons doel moeten zijn om de schoonste, meest onderhoudbare code te schrijven die mogelijk is, zodat we de mogelijkheid hebben om te blijven werken met deze code terwijl we naar de toekomst gaan. Bovendien moeten we code op deze manier schrijven, zodat anderen die onze codebasis kunnen aanraken, een duidelijk beeld hebben van wat we proberen te doen en ook de best practices gebruiken in onze omgeving.
In deze zelfstudie heb ik een procedurele vorm van programmeren gebruikt voor alle code die via GitHub is gedeeld, gedemonstreerd en geleverd. Zoals eerder vermeld, is er niets inherends mis mee, maar ik denk dat het de moeite waard is om te zien hoe dit eruit ziet vanuit een objectgericht perspectief.
In de volgende tutorial gaan we kijken naar het refactoren van deze code in een objectgeoriënteerd paradigma dat ook WordPress Coding Standards gebruikt voor het verder documenteren van ons werk, en dat een duidelijke bestandsorganisatie gebruikt om ons schrijven zo schoon en duidelijk mogelijk te maken.
Onthoud dat je al mijn cursussen en tutorials op mijn profielpagina kunt vinden, en je kunt me volgen op mijn blog en / of Twitter op @tommcfarlin, waar ik het heb over softwareontwikkeling in de context van WordPress en geniet van het praten met anderen over hetzelfde onderwerpen (evenals andere dingen, ook).
Aarzel in de tussentijd niet om vragen of opmerkingen in de feed hieronder te laten en ik zal ernaar streven om op elk van hen te reageren. 



		
			
	   
	




Code