Arbeta med WordPress Transients och autentisering
När du fortsätter med innehållet i det föregående inlägget är det också viktigt att överväga användningen av transienter och autentisering.
Eftersom det finns scenarier där användare autentiseras på en webbplats (tänk på ett område som endast är för medlemmar på en webbplats) och eller inte autentiseras på webbplatsen (som webbplatsbesökare).
Den här typen av situationer finns både på bloggar och andra webbplatser och webbapplikationer över hela linjen.
WordPress Transients och autentisering
Hur kan vi lagra användarinformation för dessa användare? Lyckligtvis ger PHP oss en del funktionalitet som ger oss möjligheten att göra det utan att behöva WordPress API:er.
I slutändan är målet som vi siktar på att uppnå att serialisera övergående data med hjälp av en nyckel som använder ID:t för en autentiserad användare eller en icke-autentiserad användare.
Och så här gör du var och en av dem.
WordPress API
Förutsatt att en användare är autentiserad med WordPress, då kan vi använda funktionen get_current_user_id. Det är enkelt också.
Från kodreferensen:
Få den aktuella användarens ID
Vi kan sedan använda den funktionen i konstruktorn för att ställa in en egenskap som lagrar användarens ID. Och jag kommer att visa koden för det ett ögonblick, men hur är det med situationen när en användare inte är inloggad?
PHP API
När det gäller att lagra information för användare som inte är autentiserade behöver vi fortfarande ett sätt att identifiera dem. Detta kan göras på en mängd olika sätt med hjälp av olika värden som underhålls av PHP för att lägga till den transienta nyckeln.
Kom ihåg att nyckeln måste vara unik, och så länge den är unik för användaren på webbplatsen ska den vara bra.
Två funktioner som PHP erbjuder är:
När det gäller den andra kommer den inte att fungera med IIS eller några Windows-baserade servrar. Men jag nämner det här som ett annat alternativ för värdar som är *nix-baserade (eftersom så många är det, särskilt när det gäller WordPress).
Get_current_user – funktionen är tillräckligt tydlig:
Hämtar namnet på ägaren av det aktuella PHP-skriptet
Det finns något annat att lägga märke till i manualen. Det står uttryckligen detta "[returnerar] namnet på ägaren av det nuvarande PHP-skriptet." Och jag kommer att ta upp detta innan slutet av inlägget.
Dessutom kanske get_current_user inte heller är vad du letar efter beroende på hur servern är konfigurerad och vilken användare som är "ägare" till PHP-skriptet som körs på servern.
Men det räcker med att säga att för detta exempel fungerar det. Och här är varför: Poängen jag försöker visa är hur man använder värden som är unika för en besökare som inte är autentiserad på en webbplats för att generera en nyckel från vilken vi kan hämta information.
Hur nyckeln genereras är sekundärt till den faktiska koden.
Att kombinera allt tillsammans
Så hur ser koden ut om vi ska utnyttja ovanstående funktioner? Det vill säga om vi upprätthåller en egenskap som innehar användarens ID och sedan gör det för både autentiserade och icke-autentiserade användare?
Och det ger dig den funktionalitet som krävs för att skapa ett unikt användar-ID för både autentiserade användare och icke-autentiserade användare.
Hur är det med transienta nycklar?
Ja – en del av poängen med det vi diskuterar är också att skapa unika transienta nycklar.
För att göra detta har jag tyckt att det är lätt nog att sammanfoga användarens ID som vi har genererat ovan och lägga till det till nyckeln som används vid serialisering av en transient.
Sedan, med värdet som denna funktion returnerar, kan vi använda det för att spara data som en transient med unika nycklar.
Fortfarande andra alternativ
Som nämnts kanske det inte är rätt väg att gå att använda funktioner som är inbyggda i PHP. Men det betyder inte att det inte finns andra värden som ger ett unikt värde till det du behöver.
I sådana fall är det viktigt att identifiera hur du vill identifiera din användare, vilket operativsystem de använder och vilket användarkonto som äger applikationen.
Om det inte ger en tillräckligt unik inställning (och det är mycket troligt att det inte gör det under vissa förhållanden), så gäller principen fortfarande – du behöver bara byta ut det funktionella anropet get_current_user() till något som fungerar bäst för du.