Når det gjelder å bygge en webapp med WordPress, gir de kraftige API-ene en stor hjelp. Å legge til eller hente data med Options API er ikke en stor avtale. Men noen ganger må vi lagre midlertidige data med en utløpstid.
WordPress tilbyr en intuitiv caching via Transients for å gjøre nettopp det, dvs. lagre midlertidige data med en utløpstid. Vi skal bruke transienter, så jeg trodde hvorfor ikke ta en frisk titt på WordPress Transients API i denne artikkelen.
I følge WordPress Codex:
Transient-API-en ligner veldig på Alternativ-API, men med den ekstra funksjonen av en utløpstid, noe som forenkler prosessen med å bruke wp_options databasetabell for midlertidig lagring av bufret informasjon.
I omfanget av denne serien gir transienter en effektiv måte å omdirigere brukere til velkomstsiden når de aktiverer et plugin ved å lagre midlertidige data.
I denne artikkelen vil vi utforske begrepet Transient-API i WordPress og hvordan det skiller seg fra Alternativer-API. Så, la oss komme til det.
Transienter gir oss muligheter til midlertidig lagring av bufret informasjon ved å gi et egendefinert navn (nøkkelverdierpar) og en utløpstid. Når den definerte tidsrammen er over, går transientene ut og blir slettet. Disse transientene forbedrer ytelsen og øker hastigheten på den generelle ytelsen til webapplikasjonen.
Men et spørsmål oppstår: Er utløpsperioden den eneste grunnen til bruker WP Transient API?
Svaret er nei! Til tross for at Options API har samme formål med datalagring, sanitisering og gjenfinning, kan det ikke gi best mulig ytelse med store datamengder.
Med tiden som legges til, blir transienter den mest hensiktsmessige måten å lagre data midlertidig på. For å sikre et mindre antall webspørsmål har transienter muligheten til å lagre data i hurtigminnet, f.eks. Memcached, i stedet for den tradisjonelle WordPress-databasen. Det er også oppmerksom på at transienter er iboende sped opp av caching plugins, hvor normale alternativer ikke er. Som nevnt i kodeksen:
Et Memcached-plugin, for eksempel, ville gjøre WordPress lagre forbigående verdier i raskt minne i stedet for i databasen. Av denne grunn bør transienter brukes til å lagre data som forventes utløpt, eller som kan utløpe når som helst. Transienter bør heller ikke antas å være i databasen, siden de kanskje ikke lagres der i det hele tatt.
Derfor, når du trenger en funksjonalitet som utløper eller blir slettet etter en bestemt tidsperiode, bruk transienter i stedet for alternativer. Mer om det senere.
Transienter arbeider med et utrolig enkelt grensesnitt. Du kan utføre tre grunnleggende funksjoner med dem:
set_transient ()
funksjonget_transient ()
funksjondelete_transient ()
funksjonDisse tre grunnleggende operasjonene kan hjelpe deg med å øke hastigheten på webytelsen.
Bruke set_transient ()
funksjon for å opprette eller oppdatere noen forbigående. Funksjonen tar tre parametere:
string
) Navn på forbigående. Må være 172 tegn eller færre i lengden.mixed
) Det er dataene som må lagres. Kan være en PHP-variabel eller en arrayobjekt.int
) Maks tid til utløpet i sekunder. Standard 0 (ingen utløp).Punkt å tenke på: Utløpsdatoen du angir, er den maksimale tiden for hvilken en forbigående blir lagret. Etter den tiden blir transienten slettet. Men det kan også bli slettet før den tiden. Siden det er en del av hurtigbufferen, kan den slettes av brukeren før den tiden. Så tenk alltid på utløpstid som den maksimale tiden for livet av en forbigående med bare garantien for at den vil bli slettet etter det.
De to første parameterne er nøkkelverdi par og er obligatorisk, mens den tredje parameteren, som definerer maksimal tid for utløp, er valgfri.
Et praktisk eksempel på å ringe denne funksjonen er som følger:
I eksemplet ovenfor la jeg til 60 sekunder som den tredje parameteren, som definerer utløpstidspunktet hvoretter forbigående blir slettet. I følge eksemplet ovenfor er objektet _welcome_redirect_wpw
kan bare ha en maksimal alder på 60 sekunder.
I WordPress 3.5 ble flere konstanter introdusert for å enkelt uttrykke tid. Disse konstantene gjør koden mer omfattende og presis. Her er listen:
MINUTE_IN_SECONDS = 60 (sekunder) HOUR_IN_SECONDS = 60 * MINUTE_IN_SECONDS DAY_IN_SECONDS = 24 * HOUR_IN_SECONDS WEEK_IN_SECONDS = 7 * DAY_IN_SECONDS YEAR_IN_SECONDS = 365 * DAY_IN_SECONDS
Etter lagring av en verdi via set_transient ()
funksjon, kan du hente verdien ved å ringe get_transient ()
funksjon.
Det krever en enkelt parameter, nøkkelen (dvs. navnet) på transienten $ transient
, og returnerer (type mixed
) verdi av forbigående.
Standardformatet er:
I tilfelle av vårt eksempel hentes verdien via:
Ganske enkelt? Men hva ville skje hvis forbigående ikke eksisterer eller er utløpt? Hvis så er tilfelle, så get_transient ()
funksjon returnerer a falsk
verdi.
Jeg anbefaler at du bruker identitetsoperatøren (===
) når du får verdien av en forbigående for å teste om det er feil eller ikke.
$ a === $ b | Identisk | EKTE hvis $ a er lik $ b, og de er av samme type. |
Det kan være situasjoner når du kanskje vil slette transientene før de utløper. De delete_transient ()
funksjonen hjelper deg med det. Dens format ligner på get_transient ()
funksjon.
Det krever en enkelt parameter, nøkkelen (dvs. navnet) på transienten $ transient
, og sletter forbigående permanent.
Her er det generelle formatet:
I vårt tilfelle kan vi slette det slik:
Transienter kan brukes til å cache alt fra den mest grunnleggende typen data til en komplett widget. Siden lanseringen har transienter blitt benyttet i ulike nettprosjekter. Her er noen praktiske anvendelser av transienter:
Vi er alle ferdige med grunnleggende om WordPress Transients API. I de neste to artiklene skal jeg bygge en velkommen side for et WordPress-plugin. Jeg legger mine rå tanker til noe mer meningsfylt og praktisk.
Endelig kan du fange alle kursene og opplæringsprogrammene på profilen min, og du kan følge meg på bloggen min og / eller nå ut på Twitter @mrahmadawais hvor jeg skriver om utviklingsarbeid i WordPress.
Som vanlig, ikke nøl med å legge igjen noen spørsmål eller kommentarer nedenfor, og jeg vil sikte på å svare på hver av dem.