Förbättrade Ajax-tekniker för WordPress Programplanering

För några år sedan skrev jag en serie inlägg som diskuterar hur man använder Ajax i WordPress Frontend. Syftet med serien är enkelt:

Vi ska ge en mycket kort översikt över vad Ajax är, hur det fungerar, hur man ställer upp det på framsidan och förstår krokarna som WordPress tillhandahåller. Vi ska också faktiskt bygga ett litet projekt som sätter teorin i bruk. Vi går igenom källkoden och vi ser också till att den är tillgänglig på GitHub också.

Generellt sett håller serierna bra upp, men som med all programvara under konstant utveckling, förändras tekniker, API och metoder. Dessutom, som år passerar och vi fortsätter att förfina våra färdigheter, blir vi bättre på utvecklingen och vi blir bättre med att använda nya API.

På grund av allt ovan vill jag återkomma till Ajax-konceptet i WordPress så att du kan se några av de nya API-erna och hur du använder dem i ditt dagliga arbete eller hur du kan refactor några av de koden du kanske arbetar med just nu.

Ett försiktighetssvar innan du går för långt in i denna handledning: Jag antar att du redan har läst igenom serien länkad i introduktionen av den här artikeln och att du har erfarenhet av att bygga WordPress-plugins.

Definiera plugin

Som med alla WordPress-plugin är det viktigt att du definierar rubriken så att WordPress kan läsa filen för att introducera den nya funktionaliteten i kärnanvändningen.

Jag ringer denna variant av plugin Enkel Ajax Demo, och det ligger i wp-content / plugin / wp-simple-ajax. Den första filen jag skapar finns i rotkatalogen av wp-simple-ajax och kallas wp-simple-ajax.php.

Det ser ut så här:

Koden borde vara självklarande, särskilt om du är van vid att arbeta med WordPress-plugins; Det viktigaste att förstå är dock att all information ovan är vad som kommer att driva vad användaren ser på WordPress instrumentpanel.
Det vill säga att användarna kommer att se namnet, beskrivningen och versionen av plugin liksom författarens namn (som kommer att kopplas till den angivna webbadressen) när de presenteras med alternativet att aktivera pluginprogrammet.
Lägga till WordPress Ajax-fil
Vid denna punkt kommer plugin att visas i WordPress Plugin-instrumentpanelen, men det kommer inte att göra någonting för att vi inte har skrivit någon kod. För att få det att hända kommer vi att närmar oss det här pluginet med procedurprogramplanering snarare än det objektorienterade tillvägagångssätt som jag har använt i de flesta av mina handledning.
Hur vi ursprungligen tillagde Ajax Support
Anledningen till att man förhindrar objektorienterad programmering just nu är tvåfaldig:
 
Detta beror på att plugin kommer att bli väldigt enkelt. Jag är mer intresserad av att fokusera på de angivna API-erna som tillhandahålls av WordPress så att du kan fokusera på de viktigaste sakerna att fokusera på i ditt arbete.
 
Den andra delen av denna serie kommer att fokusera på att refactoring denna kod till ett objektorienterat system så att du kan se hur allt detta kan se ut inom ramen för ett större system med klasser.
 
I slutändan kommer denna serie att täcka båda typerna av programmering som stöds av PHP och WordPress.
Mest troligt, om du har arbetat med Ajax tidigare, har du gjort något så här för att ge din plugin supporten för att göra asynkrona samtal:
  
Denna speciella metod är inte i sig fel, men det försummar några av de nyare API: erna som jag kommer att täcka tillfälligt. Det blandar också PHP, HTML och JavaScript i en enda funktion.
Det är inte bra eftersom det blir jobbet gjort, men det finns ett renare sätt att göra detta.
Hur vi lägger till Ajax Support
För att se till att plugin inte kan nås direkt av någon, lägg till följande villkorligt under pluginens rubrik:
Observera att den öppna PHP-taggen inte kommer att behövas eftersom den här koden kommer senare i en befintlig PHP-fil (det är nödvändigt för syntaxmarkering just nu).
Låt oss sedan skapa en funktion för att inkludera WordPress-stöd för Ajax genom att använda några av de befintliga API-erna som inte involverar blandningsspråk. 
Här är vad vi behöver göra:
 
Vi ska skapa en funktion som är ansvarig för att lägga till Ajax-support.
 
Vi kopplar in funktionen i wp_enqueue_script verkan.
 
Vi kommer att dra nytta av wp_localize_script API-samtal för att inskränka WordPress stöd för Ajax (som kommer från admin-ajax.php).
 
Det verkar enkelt nog, eller hur? Observera att om du har några frågor, kan du alltid lägga till dem i kommentarerna. Kolla in följande kod för att se om du kan följa med:
 admin_url ('admin-ajax.php'))); 
Observera att den inledande PHP-taggen inte kommer att krävas i den slutliga versionen av plugin-programmet, eftersom det bara är här för att utnyttja syntaxmarkeringsfunktionaliteten.
Med det sagt, ta en titt på wp_localize_script. Innan vi granskar varje parameter, låt oss granska syftet med den här funktionen. Från Codex är den korta versionen följande:
Lokaliserar ett registrerat skript med data för en JavaScript-variabel.
Den längre beskrivningen är dock viktig:
Detta låter dig erbjuda korrekt lokaliserade översättningar av några strängar som används i ditt skript. Detta är nödvändigt eftersom WordPress för närvarande bara erbjuder ett lokaliserings API i PHP, inte direkt i JavaScript.
Även om lokalisering är den primära användningen kan den användas för att göra data tillgänglig för ditt skript som du normalt bara kan få från serverns sida av WordPress.
Granska nu parametrarna som den accepterar:
 
Den första parametern kallas för hantera och används för att unikt identifiera skriptet som läggs till på sidan.
 
Den andra parametern är namn, och det här är viktigt eftersom det är hur du identifierar skriptet genom hela koden. Du kommer att se detta i mycket mer detalj senare i handledningen.
 
Den tredje parametern är data parameter. Det hänvisar till en array som kommer att skickas till webbläsaren som ett JavaScript-objekt. Eftersom vi skickar URL-adressen till en sökväg till en fil, kommer Ajax-stöd att tillhandahållas.
 
Observera att den första parametern är ajax-script. Tänk på detta när vi lägger märke till att du skriver och gör en egen JavaScript, eftersom vi måste använda det här handtaget en gång till. 
Kom också ihåg att notera det namn du har valt för ditt samtal till API: n, eftersom vi kommer att använda det här när du arbetar med klientsidkoden senare i denna handledning.
En viktig anteckning om Ajax Support
Lägg märke till att vi bara använder wp_enqueue_script krok och vi använder inte admin_enqueue_script. Det här är för att ajaxurl är redan definierad i instrumentbrädan.
Det betyder att om du vill göra Ajax-förfrågningar i administrationsområdet för WordPress behöver du inte göra något. Allt vi gör i samband med denna handledning är specifikt för fronten på webbplatsen.
Ställa in din server-sidokod
Nu är det dags att skriva en funktion som JavaScript kommer att ringa via Ajax. Det här kan vara allt du vill att det ska vara, men i det här pluginets syfte ska vi skapa en funktion som kommer att returnera information om användaren som är inloggad på webbplatsen.
Pluggen kommer att göra följande:
 
Gör en förfrågan till servern som begär information om den aktuella användaren.
 
Om användaren är inloggad på webbplatsen kommer den att returnera ett JSON-svar av användarens information.
 
Om användaren inte är inloggad kommer den att returnera en felkod.
 
Vi ska använda trösta objekt som är tillgängligt i de flesta moderna webbläsare, så se till att du använder Chrome, Safari eller Firefox när du arbetar med JavaScript-källan du skriver.
Lämnar in en ansökan
Nu när vi har skisserat exakt hur koden ska fungera när en användare gör en Ajax-förfrågan till servern, låt oss börja skriva en funktion för att göra exakt det. Vi ringer det sa_get_user_information.
Funktionens genomförande kommer senare i denna handledning, men den primära takeawayen från koden ovan är att vi har kopplat till båda wp_ajax_get_current_user_info och wp_ajax_nopriv_get_current_user_info. 
Dessa två krokar är väl dokumenterade i Codex, men den första kroken tillåter de som är inloggade på webbplatsen för att komma åt denna funktion. Den andra kroken tillåter de som är inte inloggad på den här sidan för att komma åt den här funktionen.
Observera också allt efter wp_ajax_ och wp_ajax_nopriv_ Det är upp till dig som utvecklaren att definiera. Detta kommer att vara namnet på den funktion du ringer från klientsidan som du kommer se senare i den här handledningen.
Hantera Felaktiga Förfrågningar
Innan du genomför funktionen har JavaScript-källfilen (som ännu inte skrivs) kallats, och vi måste se till att vi kan hantera eventuella fel som kan uppstå.
I vårt fall kan eventuella fel vara:
 
Ingen är inloggad.
 
Användarnamnet finns inte i systemet.
 
Det är mycket osannolikt att det andra fallet kommer att vara sant, men det hjälper oss att lära oss mer om några av WordPress-API: erna och hur vi kan utnyttja dem för att hantera felaktiga förfrågningar.
Det första att förstå är WP_Error. Som med många API: er finns det i Codex:
Inställningar av WP_Error-felkoder och meddelanden som representerar en eller flera fel, och huruvida en variabel är en förekomst av WP_Error kan bestämmas med funktionen is_wp_error ().
Konstruktören accepterar upp till tre parametrar (även om vi bara använder de första två):
 
Det första argumentet är felkoden. Det här kan vi använda på klientsidan för att analysera och bestämma vad som gick fel. Det tillåter oss också att skriva information till en loggfil och så vidare.
 
Det andra argumentet är ett meddelande som kan åtföljas av felkoden. Detta är användbart om vi vill visa ett meddelande till användaren.
 
Det sista argumentet är en uppsättning information, vanligtvis felkoder och meddelanden. Oavsett det kommer vi inte att använda det här under vår kod.
 
Därefter skickar vi resultaten av felen tillbaka till klienten med hjälp av en funktion som heter wp_send_json_error. Det här är verkligen lätt att använda:
Skicka ett JSON-svar till en Ajax-förfrågan, vilket visar fel. Svarobjektet har alltid en framgångs nyckel med värdet falskt. Om något överförs till funktionen i parametern $ data, kommer det att kodas som värdet för en datatangent.
Genom att kombinera båda WP_Error och wp_send_json_error, Vi kan skapa funktioner som hjälper oss att ge felkoder till JavaScript som kallar serverns sida.
Låt oss till exempel säga att vi har en funktion som ger ett fel om användaren inte är inloggad på webbplatsen. Detta kan uppnås med följande funktion:
Observera att funktionen är markerad som privat även om den befinner sig i den globala namespace. Den är prefixad med ett understreck för att ange att denna funktion ska anses vara privat.
Vi kommer att se det här i nästa artikel.
För det andra måste vi hantera fallet om användaren inte existerar. För att göra detta kan vi skapa en funktion som gör följande:
Vi har nu två funktioner, som vart och ett kommer att skicka information till kunden om något har misslyckats, men vad gör vi om båda dessa funktioner passerar?
Hantera framgångsrika förfrågningar
Om funktionerna ovan inte ger några fel måste vi ha ett sätt att skicka förfrågan tillbaka till kunden med ett framgångsrikt meddelande och den information som den begär.
Namnlösa: Vi behöver skicka informationen tillbaka till klienten som innehåller den aktuella användarens information i JSON-formatet.
För att göra detta kan vi dra nytta av wp_send_json_success meddelande. Det gör precis vad du tror det skulle göra också:
Skicka ett JSON-svar till en Ajax-förfrågan, vilket indikerar framgång. Svarobjektet har alltid en framgångs nyckel med värdet true. Om något överförs till funktionen kommer det att kodas som värdet för en datatangent.
Låt oss kombinera det arbete vi hittills har gjort för att skriva en funktion som JavaScript så småningom kommer att ringa till och som utnyttjar de två mindre funktionerna vi har placerat ovanför. Faktum är att detta kommer att bli genomförandet av den funktion som vi släppte ut tidigare i denna handledning:
Om användaren är inloggad och användaren existerar skickar vi ett framgångsrikt meddelande till klienten som innehåller användarens JSON-representation. Vid den här tiden är det dags att skriva lite JavaScript.
Klientsidans begäran
Lägg först till en fil som heter frontend.js till roten till din plugin katalog. Ursprungligen bör den innehålla följande kod:
; (funktion ($) 'använd sträng'; $ (funktion () );) (jQuery);
Funktionsimplementeringen kommer att täckas tillfälligt, men vi måste se till att vi enqueuing denna JavaScript-fil i plugin också. Återgå till funktionen sa_add_ajax_support och lägg till följande ovan för samtalet till wp_localize_script:
Kom ihåg att det här skriptet måste ha samma handtag som det som definieras i wp_localize_script. Nu kan vi återkomma vår JavaScript-fil och ringa till den serverns kod som vi har arbetat med under hela denna artikel.
I frontend.js, lägg till följande kod:
/ ** * Den här filen är ansvarig för att ställa in Ajax-förfrågan varje gång * en WordPress-sida laddas. Sidan kan vara huvudindex-sidan, * en enda sida, eller någon annan typ av information som WordPress gör. * * När DOM är klar kommer det att göra ett Ajax-samtal till servern där * funktionen "get_current_user_info" är definierad och kommer då att hantera * svaret baserat på informationen som returneras från begäran. * * @since 1.0.0 * /; (funktion ($) 'use strict'; $ (function () / * Gör ett Ajax-samtal via en GET-förfrågan till URL-adressen som anges i * wp_enqueue_script-samtalet. parameter, skicka ett objekt med * åtgärdsnamnet för den funktion vi definierade för att returnera användarinformationen. * / $ .ajax (url: sa_demo.ajax_url, metod: 'GET', data: action: 'get_current_user_info' ) .done (funktion (svar) / * När förfrågan är klar, kontrollera om det lyckades eller inte. * Om så är fallet, analysera JSON och gör sedan det till konsolen. Annars visas * innehållet i den misslyckade förfrågan till konsolen. * / om (true === response.success) console.log (JSON.parse (response.data)); annat console.log (response.data););); ) (jQuery);
Med tanke på antalet kommentarer i koden och förutsatt att du är bekant med att skriva WordPress-plugins och ha lite erfarenhet av Ajax, borde det vara relativt enkelt att följa.
Kort sagt, koden ovan gör ett samtal till serverns sida när sidan laddas och sedan skriver information till webbläsarens konsol om den aktuella användaren. 
Om en användare är inloggad, skrivs informationen ut till konsolen i form av ett JavaScript-objekt eftersom det analyseras från JSON.
Om användaren däremot är inte inloggad, så kommer ett annat objekt att skrivas ut som visar en felkod tillsammans med meddelandet, som alla kommer att kunna se i konsolen.
Slutsats
Nu ska du ha en klar förståelse för API: erna som WordPress har tillgängligt för att arbeta med Ajax-förfrågningar till användare som är inloggade på webbplatsen och för dem som inte är.
I slutändan bör vårt mål vara att skriva den renaste, mest underhållbara koden möjligt så att vi har möjlighet att fortsätta arbeta med den här koden när vi flyttar in i framtiden. Dessutom borde vi skriva kod så här så att andra som kan röra vid vårt kodbas har en tydlig förståelse av vad vi försöker göra och använder också de bästa metoderna för vår miljö.
I den här handledningen använde jag en procedurform av programmering för all kod som delades, demonstrerats och tillhandahållits via GitHub. Som tidigare nämnts finns det inget som är felaktigt i detta, men jag tycker att det är värt att se hur det här ser ut ur ett objektorienterat perspektiv.
I nästa handledning kommer vi att se på att refactoring denna kod till ett objektorienterat paradigm som också använder WordPress Coding Standards för att ytterligare dokumentera vårt arbete, och det använder en klar filorganisation för att göra vårt skrivande så rent och klart som möjligt.
Kom ihåg att du kan fånga alla mina kurser och handledning på min profilsida och du kan följa mig på min blogg och / eller Twitter på @tommcfarlin där jag pratar om mjukvaruutveckling i samband med WordPress och tycker om att samtala med andra om samma ämnen (liksom andra saker också).
Under tiden, tveka inte att lämna några frågor eller kommentarer i foderet nedan och jag ska sikta på att svara på var och en av dem. 



		
			
	   
	




Koda