Share
Under hela serien har vi tittat på hur WordPress kan fungera som grund för webbapplikationsutveckling.
Saken är, fram till nu har vi inte riktigt tittat på funktionerna i WordPress som verkligen bidrar till bygga webbapplikationer. Istället har vi spenderat tid på hur WordPress fungerar som en grund snarare än en ram, och vi har tittat på hur WordPress är organiserat i jämförelse med många av de moderna ramarna som är tillgängliga.
I synnerhet har vi tittat på det händelsesdrivna designmönstret i motsats till det moderna modellvynskontrollmönstret (och varianter av det) och hur det ser ut inom ramen för WordPress.
Därför har vi arbetat för att ompröva applikationsarkitekturen och hur dess struktur inom ramen för WordPress hjälper oss att få en bättre konceptuell modell för hur saker och ting passar ihop i WordPress, och hur man utnyttjar kroksystemet - det vill säga åtgärder och filter - och hur de påverkar olika punkter under WordPresss livscykel.
Även om detta förtjänar en lite mer diskussion, behöver vi titta på de faciliteter som WordPress erbjuder för att inte förstå de funktioner och API-er som vi måste arbeta innan vi tar en titt på på vilket sätt att arbeta med dem.
Under de kommande par artiklarna ska vi bara göra det.
När du tänker på komponenterna i en webbapplikation kommer ett antal saker troligt att komma i åtanke. Det vill säga att bortsett från den vanliga arkitekturen i databasen, middleware och presentationsskiktet finns också följande funktioner:
Även om denna lista inte alls är omfattande, träffar den höga anteckningar om vad som går att bygga en vanlig webbapplikation (naturligtvis, om det finns poäng som saknas, tveka inte att nämna dem i kommentarerna).
Och nej - det här är inte receptbelagt. Ibland har webapplikationer inte användarhantering, ibland kan användarna inte ha roller, kanske har du inte behov av cachning och så vidare.
Men poängen är inte att göra ett ärende för Allt de saker du behöver I stället handlar det om att göra ett fall för de saker som är tillgängliga skall du behöver dem.
Så med det sagt, låt oss ta en titt på vad WordPress erbjuder i vägen för användarhantering, behörigheter, e-postfunktionalitet och sessionhantering.
Den som har använt WordPress - även om det bara är för bloggar eller grundläggande innehållshantering - är bekant med det grundläggande användarsystemet. Det vill säga, du skapar ett användarnamn, ett lösenord, och fyll sedan i din profil så mycket du vill.
Dessutom är mer erfarna utvecklare bekanta med idéerna om roller och förmågor. Jag vågar ens att säga att de som använder WordPress är bekanta med systemet, även om de aldrig har tittat på Codex eller förstört med att skriva någon användarbaserad kod.
Men den allmänna idén är väldigt enkel: Användare representerar en enskild profil för ett konto i WordPress. Deras roll indikeras av vad de har tilldelats vid skapandet av konton.
Dessa roller innefattar:
Återigen, de flesta av oss som har arbetat med WordPress är bekanta med dessa roller, eller hur? Men hur passar kapaciteten in i bilden?
Enkelt uttryckt är funktioner som ger användarna vissa behörigheter under WordPress-programmet, liksom vad som begränsar dem från vissa områden i applikationen. Detta är relativt väl dokumenterat i Codex.
Men här är det: Om du bygger en applikation på WordPress, gör de tillgängliga API: erna det möjligt att låsa användare av egna områden som du har skapat baserat på deras roller och funktioner.
Låt oss först säga att någon gång du arbetar med din webbapplikation vill du kunna ge användaren möjlighet att registrera eller registrera sig från en anpassad registreringsblankett (i motsats till standardmetoden för att skapa användarkontot i baksidan som visas ovan).
Detta kan göras genom att skapa en mall med en blankett och sedan läsa in postdata.
Faktum är att det verkligen kan vara så enkelt som att fånga användarens e-postadress. Jag nämner detta eftersom, trots att användarnamnen är trevliga och roliga, tenderar e-postmeddelanden att vara unika för en individ, så det gör det enklare att felsöka.
Så stegen för att göra det skulle vara:
Relativt rakt fram, eller hur? Det innebär givetvis att du kan skapa ett lösenord för användaren när du skapar ditt konto. Lyckligtvis finns det ett API för det.
Så här är ett exempel hur man programmerar en användare baserat på en angiven e-postadress (samtidigt som ett automatiskt lösenord skapas).
Accentsconagua
om (null == användarnamn_existerar ($ email_address)) $ password = wp_generate_password (12, false); $ user_id = wp_create_user ($ email_address, $ lösenord, $ email_address); wp_update_user (array ('ID' => $ user_id, 'smeknamn' => $ email_address);); else // Användarnamnet finns redan, så hantera detta i enlighet med detta ... Därefter måste du faktiskt skapa en ny instans av WP_User.
$ user = ny WP_User ($ user_id);
Det här gör det möjligt för oss att ställa in roller för den givna användaren.
Slutligen är det dags att bestämma vilken roll och uppsättning funktioner du ska tilldela användaren.
Å ena sidan kan du svårt koda dessa värden baserat på de alternativ som WordPress erbjuder. Sanningen är att du även kan skapa egna roller och funktioner. För nu ligger det utanför artikelns räckvidd. Vi kan dock besöka den i en framtida serie.
Så låt oss säga att vi vill att alla användare som är registrerade för närvarande ska få den abonnent roll. Du kan se vilka uppsättningar funktioner de kommer att beviljas i denna Codexartikel.
Att ställa in en roll är trivial:
$ user-> set_role ('bidragare'); På den här tiden har du framgångsrikt skapat en ny användare inom WordPress-programmet utan att behöva använda någon av de administrativa standardfunktionerna.
Koppla bara upp det här till din egen mall, validera, sanera och kontrollera inkommande $ _POST data, och du är redo att gå.
Den fullständiga koden ser så här ut:
om (null == användarnamn_existerar ($ email_address)) // Skapa lösenordet och skapa användaren $ password = wp_generate_password (12, false); $ user_id = wp_create_user ($ email_address, $ lösenord, $ email_address); // Ange smeknamnet wp_update_user (array ('ID' => $ user_id, 'smeknamn' => $ email_address);); // Ställ in rollen $ user = ny WP_User ($ user_id); $ user-> set_role ('bidragare'); else // Användaren finns redan // slutet om / annars Inte dåligt, rätt?
Men skapa en användare och spara faktiskt deras information i databasen på bara hälften av det, rätt?
När användaren loggar in och är autentiserad kommer du sannolikt att vilja begränsa innehåll baserat på deras roll. Så detta väcker frågan: När en användare är inloggad, hur hämtar vi en användares roll?
Lyckligtvis gör WordPress API det här relativt enkelt:
Vi kommer att behöva dra nytta av wp_get_current_user () funktion, och då måste vi få en förekomst av WP_User objekt med den nuvarande användarens ID, varefter vi kan ta en titt på användarens möjligheter.
Ta en titt på koden nedan:
// Få en instans av den nuvarande användaren $ user_id = wp_get_current_user () -> ID; $ user = ny WP_User ($ user_id);
Inte dåligt, rätt?
Det gör det väldigt enkelt att skriva villkorlig kod, till exempel:
// Detta kommer att skriva ut användarfunktionerna print_r ($ user-> wp_capabilities); // som i sin tur tillåter dig att göra en check så här: om ('1' === $ användare-> wp_capabilities ['abonnent']) // Vi har en abonnent där är ett alternativt sätt att göra detta, men:
global $ current_user; get_currentuserinfo (); om (0 === $ current_user-> user_level) // Vi har en abonnent
Men det här ställer frågan om var kom noll från? Kolla in exakt det.
Skillnaderna mellan de två metoderna beror på hur objektorienterad du vill att din kod ska vara.
Jag tenderar att vara mindre av ett fan av att använda global när det finns ett objektorienterat tillvägagångssätt tillgängligt (som i det första exemplet); emellertid ger det andra exemplet en relativt enkel lösning också. Ditt val.
Hur som helst, när du väl kan kontrollera villkoret för användarens konto kan du sedan begränsa dem till specifika områden i ansökan.
Du har rätt: Minst måste användarens behov av att få e-post för när deras konton har skapats, och de måste kunna ta emot e-post när någonting om deras konto har ändrats.
Igen ger WordPress ett API som gör det här väldigt enkelt, men det kan utökas utöver enkla åtgärder, t.ex. när en användares profilinformation ändras.
I själva verket, med tanke på att WordPress har ett rikt händelsessystem, kan du eventuellt koppla in till ett antal händelser och skicka e-post när något händer. Det är uppenbarligen overkill, men det går för att visa hur kraftfull API verkligen är.
Så i nästa avsnitt ska vi ta en titt på WordPress e-post API och hur det kan användas för att skicka meddelanden om viss aktivitet, liksom hur det kan anslutas till andra funktioner i ansökan.
