Share
In deze serie bekijken we hoe het mogelijk is om webtoepassingen te bouwen met behulp van WordPress.
Tot nu toe hebben we het gehad over hoe WordPress een fundament is (in plaats van een raamwerk), de architectuur, hoe we conceptueel moeten denken als we het benaderen vooral komende uit andere talen, en toen begonnen we te praten over de componenten waaruit een eenvoudige webapplicatie bestaat.
Ter herinnering vermeldden we:
En beginnend in het laatste bericht, bespraken we zowel gebruikersbeheer als machtigingen.
In dit bericht gaan we bekijken hoe sessies kunnen worden opgenomen in een op WordPress gebaseerde toepassing; we gaan er echter van uit dat u - of andere lezers - helemaal niet bekend zijn met sessies.
Dus we beginnen met een high-level weergave van sessies, praten over de relatie tussen sessies en WordPress, en dan hoe je sessies begint te integreren in je WordPress-gebaseerde applicatie.
Voor degenen onder u die niet bekend zijn met het concept van sessies, is het relatief eenvoudig te begrijpen (maar kan moeilijk te implementeren zijn, afhankelijk van het kader of de basis die u gebruikt).
Kortom, sessies zijn een manier om de status van een toepassing over de pagina te behouden.
Maar hier is het ding: dit kan op een aantal manieren worden geïmplementeerd. In één scenario kunt u eenvoudig gegevens naar de database op één pagina schrijven en deze vervolgens op de volgende pagina ophalen.
Dit is niet precies de meest efficiënte manier om een sessie in te stellen vooral als je veel actieve gebruikers hebt, maar het doet laat je toe om de staat te handhaven.
Maar nogmaals, dat is niet waar we het over hebben als we het hebben over sessies. In plaats daarvan hebben we het over het bijhouden van een reeks informatie die persistent is in het geheugen - letterlijk, in de RAM - gedurende de tijd dat de gebruiker actief is op de website.
Met het risico technischer te worden dan ik zou willen in deze serie artikelen, daar zijn manieren waarop sessies een beetje anders worden beheerd, zodat u een site kunt verlaten, terug kunt komen en uw actieve sessie nog steeds kunt behouden.
Denk aan diensten zoals Twitter als u zich niet hoeft aan te melden elk keer dat u de site bezoekt. Hoe dan ook, de details van dat implementatie valt buiten het bereik van deze serie.
Laten we in plaats daarvan even nadenken over hoe een sessie eruit zou zien vanaf het moment dat een gebruiker op de startpagina van een toepassing belandde, heeft ingelogd, een sessie heeft opgezet en vervolgens is uitgelogd.
Dus hier is wat een typische database-gesteunde applicatie eruit ziet vanuit het perspectief van niet onderhouden van sessie-informatie. In plaats daarvan wordt alles statisch op pagina's weergegeven en / of wordt het uit de database geladen:
Vrij gemakkelijk te begrijpen, is het niet?
Kortom, elke keer dat een pagina wordt geladen - of telkens wanneer een gebruiker naar een nieuwe pagina navigeert - haalt de pagina de benodigde informatie uit de database op en presenteert deze vervolgens aan de gebruiker.
Als in het bovenstaande diagram wordt weergegeven hoe een webbrowser met een databasetabel eruit ziet zonder enig type sessiemechanisme, hoe ziet dit er dan uit doet bieden ondersteuning voor sessies?
Voordat we een schema bekijken van hoe het is, laten we de volgende parameters uiteenzetten:
Kort gezegd betekent dit dat wanneer de gebruiker eenmaal is ingelogd, bepaalde informatie wordt weergegeven op basis van statische informatie, informatie in de database en informatie die in de sessie is opgeslagen.
Niks vreselijk gecompliceerd, he?
Kortom, informatie wordt in een sessie geladen die in het geheugen is opgeslagen en van daaruit wordt opgehaald wanneer dat nodig is. Andere informatie die niet in de sessie zit maar relevant is voor de pagina die wordt weergegeven, wordt opgehaald uit de gegevens.
Als dit wordt toegestaan, is het goed geïmplementeerd, je kunt echt heel veel prestaties uit een applicatie halen en de algehele gebruikerservaring een beetje beter maken; de details daarvan gaan echter verder dan dit specifieke artikel.
De belangrijkste weg te nemen van deze specifieke sectie is hoe sessies werken en welke voordelen ze bieden.
Voor iedereen die heeft gewerkt met het bouwen van webtoepassingen in andere kaders, bent u waarschijnlijk bekend met sessies en hoe ze werken binnen de context van de gegeven hulpmiddelen die u gebruikte.
Als je al eerder met PHP hebt gewerkt, weet je waarschijnlijk ook hoe sessies werken.
Maar hier is een interessant feit (tenminste, ik vind het interessant!):
De kernapplicatie van WordPress gebruikt geen sessies.
In feite is de enige keer dat het bijna in de buurt komt van het onderhouden van elk type staat, het gebruik van een cookie die wordt gegenereerd wanneer u zich aanmeldt bij de toepassing..
Als het gaat om het implementeren van sessies in WordPress, is het meer een kwestie van begrijpen hoe je een sessie in PHP kunt implementeren en ervoor zorgen dat je de juiste schoonmaak aan huis doet, wanneer nodig.
Concreet betekent dit dat u weet hoe u:
Klinkt eenvoudig genoeg, toch? Voor het grootste deel, het is maar, zoals bij de meeste dingen in ontwikkeling, zijn er dingen die we moeten overwegen.
Het eerste ding dat u moet opmerken is dat de sessies moeten worden gestart. Dit wordt gedaan door PHP's te bellen session_start () functie.
Er zijn twee dingen om op te merken over het starten van een sessie in PHP:
Om dit te doen, kunt u een functie definiëren met behulp van een geschikte haak, maar deze moet wees vroeg genoeg in de levenscyclus van de WordPress-pagina.
Voor de toepassing van het voorbeeld van dit artikel ga ik een sessie starten als een gebruiker is aangemeld. Als een gebruiker is aangemeld, slaan we het tijdstip op waarop hij / zij is ingelogd; anders doen we niets.
Voorbeeld: In de onderstaande code begin ik een sessie tijdens WordPress ' in het actie.
Accentsconagua
function example_login () if (! session_id () && is_user_logged_in ()) session_start (); add_action ('init', 'example_login'); Nu een sessie is gestart, kunnen we beginnen met het opslaan van informatie.
Werken met sessiegegevens lijkt sterk op werken met gegevens die zijn opgeslagen in $ _GET, $ _POST, of zelfs in een normale associatieve array. Kortom, PHP biedt het $ _SESSION verzameling waarmee we informatie kunnen opslaan via sleutel / waardeparen.
Als u doorgaat met het bovenstaande voorbeeld, wordt de huidige tijd opgeslagen waarop de gebruiker zich heeft aangemeld. Houd er echter rekening mee dat wij moet controleer eerst of de waarde is ingesteld in de verzameling; anders zullen we het elke keer overschrijven.
function example_login () if (! session_id () && is_user_logged_in ()) session_start (); if (! isset ($ _SESSION ['time'])) $ _SESSION ['time'] = time (); add_action ('init', 'example_login'); Eenvoudig genoeg - in de eerste plaats controleer ik of een session_id () is ingesteld en ik controleer om te zien of de gebruiker is aangemeld. Als dit het geval is, slaat u de tijd op.
Maar nu moeten we de informatie van de sessie ergens anders in de codebase terughalen.
Net zoals bij het opslaan van informatie in arrays, kunnen we de informatie grotendeels op dezelfde manier ophalen, maar er is een waarschuwing: we moeten ervoor zorgen dat de waarde in de array wordt ingesteld en dat het niet leeg is.
We kunnen dit doen met een eenvoudige voorwaardelijke:
if (isset ($ _SESSION ['time']) &&! empty ($ _SESSION ['time'])) print_r ($ _SESSION ['time']);
Ervan uitgaande dat de waarde aanwezig is in de $ _SESSION verzamelen, dan moeten we goed zijn om te gaan.
Dit kan gedaan worden bij het afmelden. Met behulp van de verstrekte code zou u een verschil in uw site moeten zien op basis van of u bent ingelogd of niet.
Omdat we tot slot een sessie starten wanneer de gebruiker is ingelogd, willen we de sessie vernietigen wanneer de gebruiker uitlogt. Dit is relatief eenvoudig met behulp van PHP's session_destroy () functie; er zijn echter enkele fijnere nuances die moeten worden begrepen.
Rechtstreeks uit de PHP-handleiding:
session_destroy () vernietigt alle gegevens die zijn gekoppeld aan de huidige sessie. Het schakelt geen van de globale variabelen uit die aan de sessie zijn gekoppeld, of schakelt de sessiecookie uit
In het kort betekent dit dat het mechanisme voor het aanhouden van sessie-informatie wordt vernietigd, maar dat de waarden die worden bewaard in de sessie-verzameling nog steeds worden gehandhaafd.
function example_logout () if (session_id ()) session_destroy (); add_action ('wp_logout', 'example_logout'); Maar, nogmaals, zoals bij andere associatieve arrays en verzamelingen in PHP, kunt u die waarden resetten (of overschrijven). Hoe dan ook, dat gaat verder dan het bereik van deze specifieke serie.
Wat zou een artikel over programmeren zijn zonder een of andere soort van gok, toch??
Ten eerste hebben we al vastgesteld dat de kern van WordPress zelf staatloos is. Niet alleen dat, maar het onderhoudt ook een functie die wordt gebruikt om globals te resetten (u kunt deze functie vinden in wp-includes / load.php - kijk gewoon naar wp_unregister_GLOBALS).
Als u naar de broncode kijkt, ziet u de volgende regels:
$ input = array_merge ($ _GET, $ _POST, $ _COOKIE, $ _SERVER, $ _ENV, $ _FILES, isset ($ _SESSION) && is_array ($ _SESSION)? $ _SESSION: array ()); foreach ($ input als $ k => $ v) if (! in_array ($ k, $ no_unset) && isset ($ GLOBALS [$ k])) unset ($ GLOBALS [$ k]);
Dit gaat naar de waarden in de sessie uit te schakelen, dus in zekere zin, kan WordPress eigenlijk proberen om uw sessie uit te schakelen.
Ten tweede ondersteunen niet alle webhosts PHP-sessies of de $ _SESSION verzameling. Daartoe moet u ervoor zorgen dat de omgeving waarin u uw werk implementeert, de nodige configuratie en ondersteuning biedt voor wat u vrijgeeft.
Dus als u zich zorgen maakt over het beheer van veel code om ervoor te zorgen dat sessies binnen WordPress werken (en niet worden weggegooid) terwijl u dit doet, en u ook niet wilt omgaan met de verschillende hostingomgevingen en hun verschillende configuraties , dan raad ik ten zeerste aan het werk van Eric Mann op WP_Session te bekijken.
Dit specifieke project valt buiten het bereik van wat we hier in dit artikel proberen te behandelen; deze plug-in is echter de moeite waard om te controleren omdat deze een Super goed sessie management laag voor WordPress zonder veel van de overhead die we hier hebben behandeld.
Ten eerste, herinner eraan dat sessies niet uniek zijn voor WordPress. Ze zijn een functie van PHP die we kunnen implementeren binnen de context van WordPress. En met dat doel kunnen we een aantal echt coole functies introduceren op basis van de behoeften van de gebruikers.
Maar dit roept de vraag op: doen sessies ertoe?
Ik vind deze vraag een beetje subjectief.
Als u een webtoepassing maakt waarin elke gebruiker rond de site moet lopen met informatie die uniek is voor zijn sessie, zoals bijvoorbeeld zijn voornaam, achternaam, laatste login en andere leuke dingen, dan ja, ik denk dat je een reden hebt om een sessie te gebruiken.
Maar als je iets aan het bouwen bent dat alleen maar authenticatie vereist voordat je informatie uit een database kunt genereren, dan zou ik me afvragen of je wel of niet een sessie moet implementeren.
Dit alles om te zeggen: het hangt af van de aard van uw project.
Op dit moment zijn we klaar om verder te gaan naar het volgende algemene onderdeel van webtoepassingen: e-mail.
In plaats van te vertrouwen op PHP en deze te verbinden met de levenscyclus van WordPress, maakt de WordPress API het werken met e-mail relatief triviaal en echt krachtig. En daarmee zullen we het in het volgende artikel bespreken.
