Share
I denna serie tittar vi på hur det är möjligt att bygga webbapplikationer med WordPress.
Hittills har vi pratat om hur WordPress är en grund (snarare än en ram), dess arkitektur, hur vi behöver begreppsmässigt tänka på det när vi närmar oss det speciellt kommer från andra språk, och sedan började vi prata om de komponenter som utgör en grundläggande webbapplikation.
Som en påminnelse nämnde vi:
Och började i det senaste inlägget täckte vi både användarhantering och behörigheter.
I det här inlägget ska vi titta på hur man införlivar sessioner inom en WordPress-baserad applikation; Vi kommer dock att anta att du - eller andra läsare - inte känner till sessioner alls.
Så vi börjar på en hög nivå av sessioner, prata om förhållandet mellan sessioner och WordPress, och sedan börja med att integrera sessioner i ditt WordPress-baserade program.
För er som inte känner till sessionsbegreppet är det relativt enkelt att förstå (men det kan vara svårt att genomföra beroende på vilken ram eller grund du använder).
Kort sagt är sessioner ett sätt att behålla tillståndet för en applikation över sidladdningar.
Men här är saken: Det kan implementeras på ett antal sätt. I ett scenario kan du helt enkelt skriva data till databasen på en sida och sedan hämta den på nästa sida.
Det här är inte precis det effektivaste sättet att ställa in en session speciellt om du har många aktiva användare, men det gör tillåter dig att behålla staten.
Då är det inte vad vi pratar om när vi hänvisar till sessioner. Istället pratar vi om att hålla en uppsättning information som är kvar i minnet - bokstavligen, i RAM - hela tiden användaren är aktiv på webbplatsen.
Med risken att bli mer teknisk än jag skulle vilja i den här serien av artiklar, där är sätt på vilka sessioner hanteras lite annorlunda så att du kan lämna en webbplats, komma tillbaka och fortfarande ha din aktiva session underhållen.
Tänk på tjänster som Twitter när du inte behöver logga in varje tid du besöker webbplatsen. Oavsett detaljerna i den där genomförandet ligger utanför ramen för denna serie.
Låt oss istället överväga hur en session skulle se ut från den tid en användare landade på en applikations hemsida, loggade in, inrättade en session och loggade sedan ut.
Så här är vad en typisk databas-backad applikation ser ut ur perspektivet av inte upprätthålla eventuell sessioninformation. Istället är allt statiskt tillhandahållet på sidor och / eller det laddas från databasen:
Ganska lätt att förstå, är det inte?
I grund och botten varje gång en sida laddas - eller varje gång en användare navigerar till en ny sida - hämtar sidan den nödvändiga informationen från databasen och presenterar den sedan för användaren.
Om det ovanstående diagrammet visar hur en databasbaserad webbapplikation ser ut utan någon typ av sessionsmekanism, hur ser det ut när den är gör erbjuda stöd för sessioner?
Innan vi tittar på ett diagram över hur det är, låt oss ange följande parametrar:
Kort sagt innebär det att en gång användaren är inloggad kommer någon information att visas från statisk information, information i databasen och information som lagras i sessionen.
Inget fruktansvärt komplicerat, va?
Kort sagt, information laddas i en session som lagras i minnet och hämtas därifrån när det behövs. Annan information som inte är i session men som är relevant för sidan som visas kommer hämtas från data.
Att tillåta detta är implementerat korrekt, du kan verkligen pressa mycket prestanda ur ett program och göra den övergripande användarupplevelsen lite bättre. Men detaljerna i det är bortom denna artikel.
Den viktigaste ta bort från det här avsnittet är hur sessioner fungerar och vilka fördelar de erbjuder.
För alla som har arbetat med att bygga webbapplikationer i andra ramar, är du troligt bekant med sessioner och hur de fungerar inom ramen för de givna verktygen som du använde.
I själva verket, om du har gjort något tidigare arbete med PHP, är du troligen bekant med hur sessionerna fungerar också.
Men här är ett intressant faktum (åtminstone, jag tycker det är intressant!):
Kärnan WordPress-programmet använder inte sessioner.
Faktum är att den enda gången det kommer nära att behålla någon typ av tillstånd är genom att använda en cookie som genereras när du loggar in på ansökan.
När det gäller att implementera sessioner i WordPress, handlar det mer om att förstå hur man genomför en session i PHP och se till att du gör rätt inredning när det behövs.
Specifikt betyder det att du vet hur man:
Låter enkelt nog, eller hur? För det mesta är det bara, som med de flesta saker i utveckling, det finns saker som vi måste överväga.
Det första du behöver notera är att sessioner måste startas. Detta görs genom att ringa till PHP session_start () fungera.
Det finns två saker att notera om att starta en session i PHP:
För att göra detta kan du definiera en funktion med en lämplig krok men den måste vara tillräckligt tidigt i WordPresss livscykel.
I exemplet med den här artikeln ska jag börja en session om En användare är inloggad. Om en användare är inloggad lagrar vi den tid då de loggade in. annars kommer vi inte göra någonting.
Fall i punkt: I koden nedan börjar jag en session under WordPress ' i det verkan.
Accentsconagua
funktion example_login () if (! session_id () && is_user_logged_in ()) session_start (); add_action ('init', 'example_login'); Nu med en session startad kan vi faktiskt börja lagra information.
Att arbeta med sessionsdata liknar mycket att arbeta med data lagrad i $ _GET, $ _POST, eller till och med i en normal associativ grupp. Kort sagt, PHP erbjuder $ _SESSION samling som tillåter oss att lagra information via nyckel / värdepar.
När vi fortsätter med exemplet ovan lagrar vi den aktuella tiden då användaren loggade in. Observera dock att vi måste Kontrollera först om värdet är inställt i samlingen; Annars kommer vi skriva över det varje gång.
funktion example_login () if (! session_id () && is_user_logged_in ()) session_start (); om (! isset ($ _SESSION ['time'])) $ _SESSION ['time'] = tid (); add_action ('init', 'example_login'); Enkelt nog - först kontrollerar jag för att se om a session_id () är inställd och jag kontrollerar om användaren är inloggad. Om så är fallet, spara tid.
Men nu måste vi faktiskt hämta informationen från sessionen någon annanstans i kodbasen.
Precis som vid lagring av information i arrays kan vi hämta informationen på samma sätt, men det finns ett tillvägagångssätt: vi måste se till att värdet är inställt i matrisen och att det inte är tomt.
Vi kan göra detta med en enkel förutsättning:
om (isset ($ _SESSION ['time']) &&! tomt ($ _SESSION ['time'])) print_r ($ _SESSION ['time']);
Antag att värdet är närvarande i $ _SESSION samling, då borde vi vara bra att gå.
Detta kan göras vid utloggning. Med den angivna koden bör du se skillnad på din webbplats baserat på om du är inloggad eller inte.
Slutligen, eftersom vi etablerar en session när användaren är inloggad vill vi förstöra sessionen när användaren loggar ut. Detta är relativt enkelt med hjälp av PHP session_destroy () fungera; Det finns dock några finare nyanser som måste förstås.
Direkt från PHP-manualen:
session_destroy () förstör all data som är associerad med den aktuella sessionen. Det avstänger inte någon av de globala variablerna som är associerade med sessionen, eller avaktiverar sessionskakan
Kort sagt innebär det att mekanismen för fortlöpande sessionsinformation förstörs, men värdena som hålls i samlingssamlingen hålls fortfarande.
funktion example_logout () if (session_id ()) session_destroy (); add_action ('wp_logout', 'example_logout'); Men igen, som med andra associativa arrays och samlingar i PHP, kan du återställa dessa värden (eller skriva över dem). Oavsett, det går utöver omfattningen av den här serien.
Vad skulle en artikel om programmering vara utan någon typ av gotchas, rätt?
För det första har vi redan etablerat att själva WordPress-kärnan är statslös. Inte bara det, men det upprätthåller också en funktion som används för att återställa globals (du kan hitta denna funktion i wp-includes / load.php - leta efter wp_unregister_GLOBALS).
När du tittar på källkoden märker du följande rader:
$ input = array_merge ($ _GET, $ _POST, $ _COOKIE, $ _SERVER, $ _ENV, $ _FILES, isset ($ _SESSION) && is_array ($ _SESSION)? $ _SESSION: array ()); foreach ($ input som $ k => $ v) om (! in_array ($ k, $ no_unset) && isset ($ GLOBALS [$ k])) unset ($ GLOBALS [$ k]);
Detta gäller för att avaktivera värden i sessionen, så, på ett visst sätt, kan WordPress faktiskt försöka avaktivera din session.
För det andra stöder inte alla webbhotell PHP-sessioner eller $ _SESSION samling. För det ändamålet måste du se till att miljön där du använder ditt arbete erbjuder den nödvändiga konfigurationen och supporten för det du släpper ut.
Så om du är orolig för att du måste hantera mycket kod för att säkerställa att sessioner fungerar inom WordPress (och inte sönder) samtidigt som du inte vill hantera de olika värdmiljöerna och deras olika konfigurationer , då rekommenderar jag starkt att kolla Eric Manns arbete på WP_Session.
Det här projektet ligger utanför ramen för det som vi försöker täcka här i den här artikeln. Detta plugin är dock värt att kolla in som det ger en bra session management lag för WordPress utan mycket av det överhuvudtaget som vi har täckt här.
Först minns att sessioner inte är unika för WordPress. De är en funktion av PHP som vi kan implementera inom sammanhang av WordPress. För det ändamålet kan vi introducera några riktigt coola funktionaliteter baserade på användarnas behov.
Men det här ställer frågan: sessioner spelar roll?
Jag tycker att denna fråga är lite subjektiv.
Om du bygger en webbapplikation där varje användare måste gå runt på webbplatsen med information som är unik för sin session - till exempel, deras förnamn, efternamn, sista inloggningsdatum och andra roliga saker - Ja, jag tror att du har ett fall för att använda en session.
Men om du bygger något som kräver inget annat än autentisering innan du lämnar information från en databas, då skulle jag fråga om du behöver implementera en session.
Allt detta att säga: Det beror på vilken typ av projekt du har.
Vid denna tidpunkt är vi redo att gå vidare till nästa gemensamma komponent i webbapplikationer: e-post.
I stället för att förlita sig på PHP och leda det i WordPress-livscykeln, gör WordPress API-arbetet med e-post relativt trivialt och verkligen kraftfullt. Och med det ska vi granska det i nästa artikel.
