Share
I denne serien tar vi en titt på hvordan det er mulig å bygge webprogrammer ved hjelp av WordPress.
Så langt har vi snakket om hvordan WordPress er et fundament (snarere enn et rammeverk), dets arkitektur, hvordan vi trenger å tenke på det når vi nærmer oss det spesielt kommer fra andre språk, og da begynte vi å snakke om komponentene som utgjør en grunnleggende webapplikasjon.
Som en påminnelse nevnte vi:
Og begynner i det siste innlegget, dekket både brukerhåndtering og tillatelser.
I dette innlegget skal vi ta en titt på hvordan å innlemme økter i et WordPress-basert program; Vi kommer imidlertid til å anta at du - eller andre lesere - ikke er kjent med økter i det hele tatt.
Så vi starter på et høyt nivå av økter, snakk om forholdet mellom økter og WordPress, og deretter hvordan du begynner å inkorporere økter i WordPress-basert applikasjon.
For de som ikke er kjent med begrepet økter, er det relativt enkelt å forstå (men det kan være vanskelig å implementere avhengig av rammen eller fundamentet du bruker).
Kort sagt, økter er en måte å opprettholde tilstanden til et program på tvers av sidelaster.
Men her er saken: Dette kan implementeres på en rekke måter. I ett scenario kan du bare skrive data til databasen på en side, og deretter hente den på den neste.
Dette er ikke akkurat den mest effektive måten å sette inn en økt på spesielt hvis du har mange aktive brukere, men det gjør tillate deg å opprettholde tilstanden.
Så igjen, det er ikke det vi snakker om når vi henviser til økter. I stedet snakker vi om å holde et sett med informasjon vedvarende i minnet - bokstavelig talt, i RAM - hele tiden brukeren er aktiv på nettstedet.
I fare for å bli mer teknisk enn jeg vil ha i denne serien av artikler, der er måter hvor økter styres litt annerledes, slik at du kan legge igjen et nettsted, komme tilbake, og fortsatt ha den aktive økten opprettholdt.
Tenk på tjenester som Twitter når du ikke trenger å logge inn Hver gang du besøker nettstedet. Uansett, detaljene til at implementering er utenfor omfanget av denne serien.
I stedet la vi vurdere et øyeblikk hva en økt ville se ut fra den tiden en bruker landet på hjemmesiden til et program, logget inn, opprettet en økt og deretter logget ut.
Så her er hva en typisk database-støttet applikasjon ser ut fra perspektivet til ikke opprettholde eventuell øktinformasjon. I stedet er alt statisk gitt på sider og / eller det er lastet fra databasen:
Ganske lett å forstå, er det ikke?
I utgangspunktet, hver gang en side lastes - eller hver gang en bruker navigerer til en ny side - vil siden hente den nødvendige informasjonen fra databasen og deretter presentere den til brukeren.
Hvis diagrammet over viser hvordan et databasebasert nettapplikasjon ser ut uten hvilken type øktmekanisme, hvordan ser det ut når den er gjør tilbyr støtte til økter?
Før vi ser på et diagram over hvordan det er, la oss sette ut følgende parametere:
Kort sagt betyr dette at når brukeren er logget inn, vil noen informasjon bli vist fra statisk informasjon, informasjon i databasen og informasjon lagret i sesjonen.
Ingenting veldig komplisert, hei?
Kort sagt, er informasjon lastet inn i en økt som er lagret i minnet og hentet derfra når det trengs. Øvrig informasjon som ikke er i økt, men som er relevant for siden som vises, hentes fra dataene.
Tillat dette er implementert på riktig måte, du kan virkelig klemme mye ytelse ut av et program og gjøre den generelle brukeropplevelsen litt bedre; Men detaljene i det er utenfor denne spesielle artikkelen.
Den viktigste ta bort fra denne delen er hvordan økter fungerer, og hvilke fordeler de tilbyr.
For alle som har jobbet med å bygge webapplikasjoner i andre rammer, er du sannsynligvis kjent med økter og hvordan de fungerer innenfor rammen av de oppgitte verktøyene du brukte.
Faktisk, hvis du har gjort noe tidligere arbeid med PHP, er du sannsynligvis kjent med hvordan øktene fungerer, også.
Men her er et interessant faktum (minst, Jeg tror det er interessant!):
Kjerne-WordPress-programmet bruker ikke økter.
Faktisk er den eneste tiden det kommer nær å opprettholde en hvilken som helst type tilstand, gjennom bruk av en informasjonskapsel som genereres når du logger inn på søknaden.
Når det gjelder implementering av økter i WordPress, er det mer et spørsmål om å forstå hvordan man implementerer en økt i PHP, og sørg for at du gjør den riktige housecleaning, når det er nødvendig.
Spesielt betyr dette at du vet hvordan du skal:
Høres enkelt nok, ikke sant? For det meste er det bare, som med de fleste ting i utviklingen, det er ting vi må vurdere.
Det første du må legge merke til er at øktene må startes. Dette gjøres ved å ringe til PHP session_start () funksjon.
Det er to ting å merke seg om å starte en økt i PHP:
For å gjøre dette kan du definere en funksjon ved hjelp av en passende krok, men den må være tidlig nok i WordPress-sidens livssyklus.
For eksemplet med denne artikkelen skal jeg starte en økt hvis En bruker er logget inn. Hvis en bruker er logget inn, lagrer vi den tiden de logget på. Ellers vil vi ikke gjøre noe.
Tilfelle i punkt: I koden under starter jeg en økt under WordPress ' i det handling.
Accentsconagua
funksjon example_login () if (! session_id () && is_user_logged_in ()) session_start (); add_action ('init', 'example_login'); Nå med en økt startet, kan vi faktisk begynne å lagre informasjon.
Arbeide med øktdata ligner veldig på å jobbe med data lagret i $ _GET, $ _POST, eller til og med i en normal assosiativ rekkefølge. Kort sagt, PHP tilbyr $ _SESSION samling som lar oss lagre informasjon via nøkkel / verdi par.
Ved å fortsette med eksemplet ovenfor lagrer vi gjeldende tid der brukeren logget inn. Merk imidlertid at vi må Kontroller først om verdien er satt i samlingen; Ellers overskriver vi det hver gang.
funksjon example_login () if (! session_id () && is_user_logged_in ()) session_start (); hvis (! isset ($ _SESSION ['time'])) $ _SESSION ['time'] = time (); add_action ('init', 'example_login'); Enkelt nok - først sjekker jeg for å se om a øktnummer() er satt og jeg sjekker for å se om brukeren er logget inn. Hvis så, lagre tiden.
Men nå må vi faktisk hente informasjonen fra økten andre steder i kodebase.
Akkurat som det er når vi lagrer informasjon i arrays, kan vi hente informasjonen mye på samme måte, men det er en advarsel: vi må sørge for at verdien er satt i matrisen og at det ikke er tomt.
Vi kan gjøre dette ved hjelp av en enkel betinget:
hvis (isset ($ _SESSION ['time']) &&! tomt ($ _SESSION ['time'])) print_r ($ _SESSION ['time']);
Forutsatt at verdien er tilstede i $ _SESSION samling, så bør vi være gode å gå.
Dette kan gjøres ved utlogging. Ved hjelp av koden som er oppgitt, bør du se en forskjell på nettstedet ditt basert på om du er logget inn eller ikke.
Til slutt, siden vi etablerer en økt når brukeren er logget inn, ønsker vi å ødelegge sesjonen når brukeren logger ut. Dette er relativt enkelt ved hjelp av PHP session_destroy () funksjon; Det er imidlertid noen finere nyanser som må forstås.
Rett fra PHP-håndboken:
session_destroy () ødelegger alle dataene som er knyttet til gjeldende økt. Det deaktiverer ikke noen av de globale variablene som er knyttet til økten, eller avbryter øktkaken
Kort sagt betyr dette at mekanismen for vedvarende øktinformasjon er ødelagt, men verdiene som holdes i øktsamlingen, opprettholdes fortsatt.
funksjon example_logout () if (session_id ()) session_destroy (); add_action ('wp_logout', 'example_logout'); Men igjen, som med andre tilknyttede arrays og samlinger i PHP, kan du tilbakestille disse verdiene (eller overskrive dem). Uansett, det går utover omfanget av denne serien.
Hva ville en artikkel om programmering være uten noen type gotchas, rett?
Først har vi allerede etablert at WordPress-kjerne i seg selv er statsløs. Ikke bare det, men det opprettholder også en funksjon som brukes til å tilbakestille globals (du finner denne funksjonen i wp-includes / load.php - bare se etter wp_unregister_GLOBALS).
Når du ser på kildekoden, merker du følgende linjer:
$ input = array_merge ($ _GET, $ _POST, $ _COOKIE, $ _SERVER, $ _ENV, $ _FILES, isset ($ _SESSION) && is_array ($ _SESSION)? $ _SESSION: array ()); foreach ($ input som $ k => $ v) hvis (! in_array ($ k, $ no_unset) && isset ($ GLOBALS [$ k])) unset ($ GLOBALS [$ k]);
Dette går til å deaktivere verdier i økten, så på en måte kan WordPress faktisk prøve å avbryte økten din.
For det andre, ikke alle webverter støtter PHP-økter eller $ _SESSION samling. Til dette formål må du sørge for at miljøet du bruker i arbeidet ditt, gir den nødvendige konfigurasjonen og støtten til det du frigjør.
Så hvis du er bekymret for å måtte håndtere mye kode for å sikre at øktene fungerer innenfor WordPress (og ikke blir søppel) mens du gjør det, og du heller ikke ønsker å håndtere de ulike hostingmiljøene og deres forskjellige konfigurasjoner , så anbefaler jeg på det sterkeste å sjekke ut Eric Manns arbeid på WP_Session.
Dette bestemte prosjektet ligger utenfor omfanget av det vi prøver å dekke her i denne artikkelen; Dette pluginet er imidlertid verdt å sjekke ut som det gir en flott session management lag for WordPress uten mye av overhead som vi har dekket her.
Først husk at økter ikke er unike for WordPress. De er en funksjon av PHP som vi kan implementere innenfor kontekst av WordPress. Og for det formål kan vi introdusere noen veldig kul funksjonalitet basert på brukerens behov.
Men dette reiser spørsmålet: sessioner betyr noe?
Jeg finner dette spørsmålet er litt subjektivt.
Hvis du bygger et webapplikasjon der hver bruker må vandre rundt på siden med informasjon som er unik for sin økt - for eksempel, fornavn, etternavn, siste innloggingstid og andre morsomme ting - da, ja, jeg tror du har et tilfelle for å bruke en økt.
Men hvis du bygger noe som krever ingenting mer enn autentisering før du gir informasjon fra en database, så vil jeg spørre om du må implementere en økt eller ikke.
Alt dette å si: Det avhenger av arten av prosjektet ditt.
På dette tidspunktet er vi klare til å gå videre til neste vanlige del av webprogrammer: e-post.
I stedet for å stole på PHP og koble det inn i WordPress-livssyklusen, gjør WordPress API det å arbeide med e-post relativt trivielt og virkelig kraftig. Og med det, vil vi se gjennom det i neste artikkel.
