Forbedret Ajax-teknikker for WordPress Prosedyreprogrammering

For noen år siden skrev jeg en serie innlegg som diskuterer hvordan man bruker Ajax i WordPress Frontend. Hensikten med serien er enkel:

Vi skal gi en veldig kort oversikt over hva Ajax er, hvordan det fungerer, hvordan du setter det opp på forsiden, og forstår kroker som WordPress gir. Vi vil også faktisk bygge et lite prosjekt som setter teorien i bruk. Vi går gjennom kildekoden, og vi sørger også for at den er tilgjengelig på GitHub også.

Generelt sett holder serien opp godt, men som med all programvare under stadig utvikling, endres teknikker, APIer og tilnærminger. Videre, etter hvert som år passerer og vi fortsetter å forfine våre ferdigheter, blir vi bedre på utvikling, og vi blir bedre til å ansette nye APIer.

På grunn av alle de ovennevnte, vil jeg gjenta konseptet Ajax i WordPress, slik at du ser noen av de nye APIene og hvordan du bruker dem i ditt daglige arbeid, eller hvordan du refactor noen av koden du kan jobbe med med akkurat nå.

Et ord med forsiktighet før du går for langt inn i denne opplæringen: Jeg antar at du allerede har lest gjennom serien knyttet i introduksjonen til denne artikkelen, og at du har erfaring med å bygge WordPress-plugins.

Definere plugin

Som med enhver WordPress-plugin, er det viktig å sørge for at du definerer toppteksten, så WordPress vil kunne lese filen for å introdusere den nye funksjonaliteten i kjerneprogrammet.

Jeg ringer denne varianten av plugin Enkel Ajax Demo, og den ligger i wp-innhold / plugin / wp-enkel-Ajax. Den første filen jeg oppretter, ligger i rotkatalogen av wp-enkel-Ajax og kalles wp-enkel-ajax.php.

Det ser slik ut:

Koden skal være selvforklarende, spesielt hvis du er vant til å jobbe med WordPress-plugins; men det viktigste er å forstå at all informasjonen ovenfor er hva som skal kjøre hva brukeren ser på WordPress dashboard.
Det vil si at brukerne vil se navnet, beskrivelsen og versjonen av pluginet, samt forfatterens navn (som vil være knyttet til den angitte nettadressen) når de presenteres med muligheten til å aktivere plugin.
Legge til WordPress Ajax-fil
På dette tidspunktet vil pluginet vises i WordPress Plugin-dashbordet, men det vil egentlig ikke gjøre noe fordi vi ikke har skrevet noen kode. For å få det til å skje, nærmer vi oss dette bestemte pluginet ved hjelp av prosedyrisk programmeringsmetode i stedet for den objektorienterte tilnærmingen jeg har brukt i de fleste av mine opplæringsprogrammer.
Hvordan har vi opprinnelig lagt til Ajax Support
Årsaken til å unngå objektorientert programmering er nå to ganger:
 
Dette skyldes at pluginet kommer til å være veldig enkelt. Jeg er mer interessert i å fokusere på de angitte APIene som tilbys av WordPress, slik at du kan fokusere på de viktigste tingene å fokusere på i arbeidet ditt.
 
Den andre delen av denne serien vil fokusere på å refactoring denne koden til et objektorientert system slik at du kan se hvordan alt dette kan se ut i sammenheng med et større system ved hjelp av klasser.
 
Til slutt vil denne serien dekke begge typer programmering støttet av PHP og WordPress.
Mest sannsynlig, hvis du har jobbet med Ajax tidligere, har du gjort noe slikt for å gi din plugin støtte for å lage asynkrone samtaler:
  
Denne spesielle metoden er ikke iboende feil, men det forsømmer noen av de nyere APIene jeg vil dekke kort tid. Det blander også PHP, HTML og JavaScript i en enkelt funksjon.
Det er ikke bra da det blir jobben gjort, men det er en renere måte å gjøre dette på.
Hvordan legger vi til Ajax-støtte
For å sikre at plugin ikke kan åpnes direkte av noen, legger du til følgende betinget bare under pluginens overskrift:
Merk at åpningen av PHP-taggen ikke vil være nødvendig siden denne koden kommer senere i en eksisterende PHP-fil (det er nødvendig for syntaxutheving akkurat nå).
Deretter la vi sette opp en funksjon for å inkludere WordPress-støtte for Ajax gjennom bruk av noen av de eksisterende APIene som ikke involverer blande språk. 
Her er hva vi trenger å gjøre:
 
Vi skal lage en funksjon som er ansvarlig for å legge til Ajax-støtte.
 
Vi hekker funksjonen i wp_enqueue_script handling.
 
Vi vil dra nytte av wp_localize_script API-anrop for å gjenkjenne WordPress støtte for Ajax (som kommer fra admin-ajax.php).
 
Det virker rettferdig nok, ikke sant? Merk at hvis du har spørsmål, kan du alltid legge dem til i kommentarene. Sjekk ut følgende kode for å se om du kan følge med:
 admin_url ('admin-ajax.php'))); 
Igjen, merk at åpningen PHP-tag ikke vil bli påkrevd i den endelige versjonen av pluginet, da det bare er her for å dra nytte av syntaksuthevingsfunksjonaliteten.
Med det sagt, ta en titt på wp_localize_script. Før vi undersøker hver parameter, la oss se gjennom formålet med denne funksjonen. Fra Codex er den korte versjonen som følger:
Lokaliserer et registrert skript med data for en JavaScript-variabel.
Den lengre beskrivelsen er viktig, skjønt:
Dette lar deg tilby riktige, lokaliserte oversettelser av strenger som brukes i skriptet ditt. Dette er nødvendig fordi WordPress for øyeblikket bare tilbyr en lokaliserings-API i PHP, ikke direkte i JavaScript.
Selv om lokalisering er primært, kan den brukes til å gjøre data tilgjengelig for skriptet ditt, som du vanligvis bare kan få fra serversiden av WordPress.
Nå gjennomgå parametrene det aksepterer:
 
Den første parameteren er referert til som håndtak og brukes til å unikt identifisere skriptet som legges til siden.
 
Den andre parameteren er Navn, og dette er viktig fordi det er hvordan du vil identifisere skriptet gjennom hele koden din. Du vil se dette i mye mer detalj senere i opplæringen.
 
Den tredje parameteren er data parameter. Det refererer til en matrise som vil bli sendt til nettleseren som et JavaScript-objekt. Siden vi sender URLen til en bane til en fil, vil Ajax-støtte bli gitt.
 
Legg merke til at den første parameteren er ajax-skript. Vær oppmerksom på dette når vi legger merke til at du skriver og legger inn vår egen JavaScript, siden vi må bruke dette håndtaket en gang til. 
Husk også å legge merke til navnet du har valgt for anropet ditt til API-en, da vi skal bruke dette når du arbeider med klientsidenskoden senere i denne opplæringen.
En viktig kommentar om Ajax-støtte
Legg merke til at vi bare bruker wp_enqueue_script krok og vi bruker ikke admin_enqueue_script. Dette er fordi ajaxurl er allerede definert i dashbordet.
Dette betyr at hvis du ønsker å gjøre Ajax-forespørsler i administrasjonsområdet til WordPress, trenger du ikke å kreve noe. Alt vi gjør i sammenheng med denne opplæringen er spesielt for fronten av nettstedet.
Sette opp server-sidekoden
Nå er det på tide å skrive en funksjon som JavaScript vil ringe via Ajax. Dette kan være alt du vil at det skal være, men i forbindelse med dette pluginet skal vi sette opp en funksjon som vil returnere informasjon om brukeren som er logget inn på nettstedet.
Pluggen gjør følgende:
 
Forespørsel til serveren ber om informasjon om den aktuelle brukeren.
 
Hvis brukeren er logget inn på nettstedet, returnerer det et JSON-svar av brukerens informasjon.
 
Hvis brukeren ikke er logget inn, vil den returnere en feilkode.
 
Vi skal bruke konsoll objekt som er tilgjengelig i de fleste moderne nettlesere, så sørg for at du bruker Chrome, Safari eller Firefox når du arbeider med JavaScript-kilden du skal skrive.
Lager en forespørsel
Nå som vi har skissert nøyaktig hvordan koden skal fungere når en bruker gjør en Ajax-forespørsel til serveren, la oss begynne å skrive en funksjon for å gjøre akkurat det. Vi ringer det sa_get_user_information.
Funksjonens implementering kommer senere i denne opplæringen, men den primære takeaway fra koden ovenfor er at vi har hektet inn i begge wp_ajax_get_current_user_info og wp_ajax_nopriv_get_current_user_info. 
Disse to krokene er godt dokumentert i Codex, men den første kroken vil tillate de som er logget inn på nettstedet for å få tilgang til denne funksjonen. Den andre kroken vil tillate de som er ikke logget inn på dette nettstedet for å få tilgang til denne funksjonen.
Legg også merke til alt etter wp_ajax_ og wp_ajax_nopriv_ Det er opp til deg som utvikler, å definere. Dette vil være navnet på funksjonen du ringer fra klientsiden som du vil se senere i denne opplæringen.
Håndtering av feilaktige forespørsler
Før du implementerer funksjonen, er JavaScript-kildefilen (som ennå ikke er skrevet) blitt kalt, og vi må sørge for at vi klarer å håndtere eventuelle feil som kan oppstå.
I vårt tilfelle kan de potensielle feilene være:
 
Ingen er logget inn.
 
Bruker-IDen finnes ikke i systemet.
 
Det er svært lite sannsynlig at det andre tilfellet vil være sant, men det vil hjelpe oss å lære mer om noen flere WordPress-APIer, og hvordan vi kan dra nytte av dem for å håndtere feilaktige forespørsler.
Den første tingen å forstå er WP_Error. Som med mange APIer, er dette tilgjengelig i Codex:
Forekomster av WP_Error-lagringsfeilkoder og meldinger som representerer en eller flere feil, og om en variabel er en forekomst av WP_Error, kan bestemmes ved hjelp av is_wp_error () -funksjonen.
Konstruktøren vil akseptere opptil tre parametre (selv om vi bare bruker de to første):
 
Det første argumentet er feilkoden. Dette er hva vi kan bruke på klientsiden for å analysere og bestemme hva som gikk galt. Det tillater oss også å skrive informasjon til en loggfil og så videre.
 
Det andre argumentet er en melding som kan følge feilkoden. Dette er nyttig hvis vi vil vise en melding til brukeren.
 
Det endelige argumentet er en rekke opplysninger, vanligvis feilkoder og meldinger. Uansett vil vi ikke bruke dette under vår kode.
 
Deretter sender vi resultatene av feilene tilbake til klienten ved hjelp av en funksjon som kalles wp_send_json_error. Dette er veldig enkelt å bruke:
Send en JSON-respons tilbake til en Ajax-forespørsel, som angir feil. Responsobjektet vil alltid ha en suksessnøkkel med verdien false. Hvis noe går til funksjonen i parameterdataparameteren, blir den kodet som verdien for en datanøkkel.
Ved å kombinere begge WP_Error og wp_send_json_error, Vi kan skape funksjoner som kan hjelpe oss med å gi feilkoder til JavaScript som kaller server-siden.
For eksempel, la oss si at vi har en funksjon som gir en feil hvis brukeren ikke er logget inn på nettsiden. Dette kan oppnås ved å bruke følgende funksjon:
Legg merke til at funksjonen er merket som privat, selv om den er i det globale navneområdet. Det er prefiks med et understreke for å betegne denne funksjonen bør anses som privat.
Vi vil se dette i neste artikkel.
For det andre må vi håndtere saken hvis brukeren ikke eksisterer. For å gjøre dette kan vi opprette en funksjon som gjør følgende:
Vi har nå to funksjoner, som hver vil sende informasjon tilbake til klienten hvis noe har feilet, men hva gjør vi hvis begge disse funksjonene passerer?
Håndtering vellykkede forespørsler
Hvis funksjonene ovenfor ikke gir noen feil, må vi ha en måte å sende forespørselen tilbake til klienten med en vellykket melding og informasjonen som den ber om.
Nemlig, vi må sende informasjonen tilbake til klienten som inneholder den nåværende brukerens informasjon i JSON-formatet.
For å gjøre dette kan vi dra nytte av wp_send_json_success budskap. Det gjør akkurat det du tror det ville gjøre også:
Send en JSON-respons tilbake til en Ajax-forespørsel, som indikerer suksess. Svarobjektet vil alltid ha en suksessnøkkel med verdien sant. Hvis noe overføres til funksjonen, blir det kodet som verdien for en datatast.
La oss kombinere arbeidet vi har gjort så langt for å skrive en funksjon som JavaScript til slutt vil ringe til og som utnytter de to mindre funksjonene vi har plassert ovenfor. Faktisk vil dette være implementeringen av funksjonen vi slått ut tidligere i denne opplæringen:
Hvis brukeren er logget inn og brukeren eksisterer, sender vi en suksessmelding til klienten som inneholder brukerens JSON-representasjon. På dette tidspunktet er det på tide å skrive litt JavaScript.
Klientsiden forespørsel
Først legger du til en fil som heter frontend.js til roten til plugin katalogen din. I utgangspunktet bør den inneholde følgende kode:
; (funksjon ($) 'bruk streng'; $ (funksjon () );) (jQuery);
Funksjonen implementeringen vil bli dekket kort, men vi må sørge for at vi enqueuing denne JavaScript-filen i pluginet også. Gå tilbake til funksjonen sa_add_ajax_support og legg til følgende over anropet til wp_localize_script:
Husk at dette skriptet må ha samme håndtak som det som er definert i wp_localize_script. Nå kan vi se vår JavaScript-fil og ringe til server-side-koden vi har jobbet med gjennom hele denne artikkelen.
I frontend.js, legg til følgende kode:
/ ** * Denne filen er ansvarlig for å sette opp Ajax-forespørselen hver gang * en WordPress-side er lastet inn. Siden kan være hovedindekssiden, * en enkelt side, eller annen form for informasjon som WordPress gjør. * * Når DOM er klar, vil det gjøre et Ajax-anrop til serveren der * funksjonen 'get_current_user_info' er definert og vil da håndtere * svaret basert på informasjonen som returneres fra forespørselen. * * @since 1.0.0 * /; (funksjon ($) 'bruk streng'; $ (funksjon () / * Lag et Ajax-anrop via en GET-forespørsel til nettadressen som er angitt i * wp_enqueue_script-anropet. parameter, send et objekt med * handlingsnavnet til funksjonen vi definerte for å returnere brukerinformasjonen. * / $ .ajax (url: sa_demo.ajax_url, metode: 'GET', data: action: 'get_current_user_info' ) .done (funksjon (svar) / * Når forespørselen er ferdig, må du avgjøre om det var vellykket eller ikke. * Hvis det er tilfelle, analyser JSON og gjør det til konsollen. Ellers * vis innholdet i den mislykkede forespørselen til konsollen. * / hvis (true === response.success) console.log (JSON.parse (response.data)); else console.log (response.data););); ) (jQuery);
Gitt antall kommentarer i koden og antar at du er kjent med å skrive WordPress-plugins og har litt erfaring med Ajax, bør det være relativt enkelt å følge.
Kort sagt, koden ovenfor ringer til server-siden når siden er lastet og skriver deretter informasjon til nettleserens konsoll om den nåværende brukeren. 
Hvis en bruker er logget inn, blir informasjonen skrevet ut til konsollen i form av en JavaScript-objekt siden den blir analysert fra JSON.
Hvis derimot brukeren er ikke logget inn, vil et annet objekt bli skrevet ut som viser en feilkode sammen med meldingen, som alle vil kunne se i konsollen.
Konklusjon
Nå skal du ha en klar forståelse av APIene som WordPress har tilgjengelig for å arbeide med Ajax-forespørsler for brukere som er logget inn på nettstedet, og for de som ikke er.
Til slutt skal vårt mål være å skrive den reneste, mest vedlikeholdbare koden mulig, slik at vi har muligheten til å fortsette å jobbe med denne koden når vi beveger oss inn i fremtiden. I tillegg bør vi skrive kode slik dette, slik at andre som kan røre vår kodebase, har en klar forståelse av hva vi prøver å gjøre og bruker også de beste praksiser gitt vårt miljø.
I denne opplæringen brukte jeg en prosessform for programmering for all koden som ble delt, demonstrert og levert via GitHub. Som tidligere nevnt er det ingenting iboende feil med dette, men jeg synes det er verdt å se hvordan dette ser ut fra et objektorientert perspektiv.
I den neste opplæringen skal vi se på å refactoring denne koden til et objektorientert paradigme som også benytter WordPress Coding Standards for å dokumentere vårt arbeid videre, og det bruker klar filorganisasjon for å gjøre skrivingen så ren og klar som mulig.
Husk at du kan fange alle mine kurs og opplæringsprogrammer på min profilside, og du kan følge meg på bloggen min og / eller Twitter på @tommcfarlin hvor jeg snakker om programvareutvikling i forbindelse med WordPress og liker å snakke med andre om det samme emner (så vel som andre ting også).
I mellomtiden, vennligst ikke nøl med å legge igjen noen spørsmål eller kommentarer i feedet nedenfor, og jeg vil sikte på å svare på hver av dem. 



		
			
	   
	




Kode