En av de fineste tingene med å jobbe med WordPress, er kraften i API-en. Når du lager temaer og / eller plugins, gjør plattformen det utrolig enkelt å serialisere og hente data. Faktisk abstraherer API-en mange av de vanlige utfordringene ved å jobbe med data som datasanitisering og effektivt henting av data på forespørsel. Gjennom de neste to innleggene, ser vi på Transients API, hvorfor det betyr noe, hvordan du bruker det, og ser på en praktisk implementering som vi kan bruke i fremtidige prosjekter.
Generelt sett er alt dette oppnådd med WordPress Options API, som er perfekt for lagring, oppdatering og lesing, men hvis du jobber med et stort sett med data, kan ikke valgprogrammet gi optimal mulig ytelse. . Spesielt kan du forbedre den samlede ytelsen til arbeidet ditt (og dens utvidbarhet med annen programvare) hvis du skulle dra nytte av Transient API.
Enkelt sagt, gir Transients API en måte å lagre informasjon på i WordPress-databasen med en utløpstid. Når du lagrer informasjon ved hjelp av Options API, lagres verdier med en nøkkel og en verdi.
For eksempel, si at du jobber med et plugin som sparer ditt Twitter-brukernavn i et egendefinert felt kalt "Twitter". Du kan konseptualisere måten WordPress lagrer denne informasjonen, kan behandle "twitter" som nøkkel og brukernavn (si 'MoreTom') som verdien.
Forskjellen i måten Transient-API-en lagrer den informasjonen er at et tredje datafelt - en utløpstid - blir lagret i databasen. Dette er nøkkelen for å øke ytelsen, nemlig med caching.
I tillegg er data lagret via API (kalt transienter) utløst ved å cache plugins og caching-programvare mens standard WordPress-alternativer ikke er. Når du for eksempel lagrer en verdi ved hjelp av Transient-API, vil caching-programvare - for eksempel memcached - instruere WordPress til å lagre verdier på en slik måte at den enkelt kan hente den på hver sideforespørsel i stedet for å trykke databasen hver gang.
Kult, hei?
Forholdet er at siden transienter har en utløpstid, er de ikke garantert å være databaser, så vi bør sørge for at verdiene som er butikk er de som ikke er kritiske for temaet eller plugins suksess (selv om det er en måte å administrer dette at vi sjekker ut i neste innlegg).
Det viktigste å huske er at du ikke vil lagre alle valgverdier ved hjelp av Transients API. En god tommelfingerregel er å lagre verdiene som ofte er dyreste og ikke kreves for sidelaster.
Like nyttig som forståelse APIen er virkelig, kommer den virkelige fordelen i å faktisk bruke den.
Det fine med Transient APIs er at det er ekstremt godt implementert med tre funksjoner, hvorav to du vil bruke regelmessig. De tre hovedoperasjonene for transienter er å sette verdier, få verdier og slette verdier.
Lagring av en forbigående krever tre spesifikke opplysninger:
Signaturen til metoden er som følger:
Enkelt, ikke sant? Et enkelt eksempel på å ringe denne funksjonen er som følger:
set_transient ('twitter', 'MoreTom', 60 * 60 * 12);
Å hente en forbigående er enda enklere enn innstillingen. Faktisk ligner det veldig på å hente inn alternativer fra WordPress Options API. Alt du trenger å vite er nøkkelen som ble definert når du angir verdien.
Signaturen til metoden som er ansvarlig for å returnere verdien er:
I følge med eksemplet ovenfor, vil vi hente brukerens Twitter brukernavn ved å ringe:
get_transient ( 'twitter');
Enkelt, hei?
Innstilling og henting av transienter er de to mest brukte funksjonene til API, men det er tidspunkter hvor det kan hende du må fjerne en verdi før utløpet er oppnådd.
I så fall kan du dra nytte av delete_transient-funksjonen:
På samme måte som å hente en verdi, sender du bare nøkkelen som brukes til å identifisere transientverdien til funksjonen:
delete_transient ( 'twitter');
Funksjonen vil returnere sann hvis verdien er riktig fjernet, falsk hvis verdien ikke ble fjernet, eller hvis slettingen av verdien ikke fungerte riktig.
Selvfølgelig gir ytelsesfordelene utbytte i forhold til hvor vanskelig det er å utnytte API. Kanskje det viktigste å huske er at du ikke vil lagre alle valgverdier ved hjelp av Transients API - bare de som er de dyreste og som sjelden endres.
I neste innlegg ser vi en praktisk implementering av API-en ved å lage et plugin som utnytter API-en.