Share
In deze reeks hebben we bekeken hoe WordPress kan dienen als een basis voor de ontwikkeling van webtoepassingen.
Het punt is dat we tot nu toe niet echt hebben gekeken naar de functies van WordPress die echt bijdragen naar webapplicaties bouwen. In plaats daarvan hebben we tijd besteed aan het kijken naar hoe WordPress fungeert als een fundament in plaats van een raamwerk, en we hebben gekeken naar hoe WordPress is georganiseerd in vergelijking met veel van de moderne frameworks die beschikbaar zijn.
In het bijzonder hebben we een kijkje genomen naar het gebeurtenisgestuurde ontwerppatroon in tegenstelling tot het populaire ontwerppatroon van de modelweergave-controller (en varianten daarvan) en hoe dit eruitziet in de context van WordPress..
Daarom hebben we de toepassingsarchitectuur en de structuur ervan in de context van WordPress opnieuw bekeken om ons te helpen een beter conceptueel model te krijgen voor hoe dingen bij elkaar passen in WordPress en hoe we kunnen profiteren van het haaksysteem - dat wil zeggen acties en filters - en hoe ze verschillende punten beïnvloeden tijdens de levenscyclus van de WordPress-pagina.
Hoewel dit een beetje meer discussie verdient, moeten we de faciliteiten bekijken die WordPress out-of-the-box aanbiedt om de functies en API's waarmee we moeten werken volledig te begrijpen voordat we daadwerkelijk een kijkje nemen op hoe om met hen te werken.
In de volgende paar artikelen gaan we precies dat doen.
Wanneer je denkt aan de componenten van een webapplicatie, denk je waarschijnlijk aan een aantal dingen. Dat wil zeggen dat er naast de gebruikelijke architectuur van de database, middleware en presentatielaag ook de volgende functies zijn:
Hoewel deze lijst lang niet allesomvattend is, treft het de hoge noten van wat er bij het bouwen van een standaard webtoepassing gaat (natuurlijk, als er punten zijn die worden gemist, aarzel dan niet om ze in de commentaren te vermelden).
En nee - dit is niet prescriptief. Soms hebben webtoepassingen geen gebruikersbeheer, soms hebben gebruikers geen rollen, misschien hebt u geen behoefte aan caching, enzovoort.
Maar het gaat er niet om voor te pleiten allemaal de dingen die je nodig hebt. In plaats daarvan gaat het om het verdedigen van de dingen die beschikbaar zijn moeten je hebt ze nodig.
Laten we daarom eens kijken naar wat WordPress biedt op het gebied van gebruikersbeheer, machtigingen, e-mailfunctionaliteit en sessiebeheer..
Iedereen die WordPress heeft gebruikt - ook al is het alleen voor bloggen of eenvoudig contentbeheer - is bekend met het standaardgebruikerssysteem. Dat wil zeggen, u maakt een gebruikersnaam, een wachtwoord en vult vervolgens uw profiel zo vaak in als u wilt.
Bovendien zijn meer ervaren ontwikkelaars bekend met de ideeën over rollen en mogelijkheden. Ik zou zelfs durven zeggen dat degenen die WordPress gebruiken bekend zijn met het systeem, zelfs als ze nooit echt naar de Codex hebben gekeken of geknoeid met het schrijven van een op gebruikers gebaseerde code.
Maar het algemene idee is heel simpel: gebruikers vertegenwoordigen een individueel profiel voor een account in WordPress. Hun rol wordt aangegeven door wat ze zijn toegewezen tijdens het maken van een account.
Deze rollen omvatten:
Nogmaals, de meesten van ons die met WordPress hebben gewerkt, zijn bekend met deze rollen, toch? Maar hoe passen capaciteiten in de afbeelding?
Simpel gezegd, mogelijkheden zijn wat gebruikers bepaalde machtigingen verleent in de gehele WordPress-applicatie, evenals wat hen beperkt van bepaalde delen van de applicatie. Dit is relatief goed gedocumenteerd in de Codex.
Maar hier is het ding: als u een toepassing bouwt op WordPress, maken de beschikbare API's het mogelijk om gebruikers te blokkeren van aangepaste gebieden die u hebt gemaakt op basis van hun rollen en mogelijkheden.
Laten we eerst zeggen dat u op een gegeven moment tijdens het werken aan uw webtoepassing de gebruiker de mogelijkheid wilt bieden om zich te registreren of aan te melden vanuit een aangepast aanmeldingsformulier (in tegenstelling tot de standaardmethode voor het maken van het gebruikersaccount in de backend zoals hierboven getoond).
Dit kan worden gedaan door een sjabloon met een formulier te maken en vervolgens de berichtgegevens te lezen.
In feite kan het echt zo simpel zijn als het vastleggen van het e-mailadres van de gebruiker. Ik noem dit omdat, hoewel gebruikersnamen leuk en leuk zijn, e-mails vaak uniek zijn voor een individu, dus het maakt het controleren van fouten eenvoudiger.
Dus de stappen om dit te doen zijn:
Relatief ongecompliceerd, toch? Dit betekent natuurlijk wel dat u bij het maken van hun account een wachtwoord voor de gebruiker kunt genereren. Gelukkig is daar een API voor.
Dus hier is een voorbeeld van hoe u programmatisch een gebruiker kunt maken op basis van een opgegeven e-mailadres (terwijl u een wachtwoord automatisch genereert).
Accentsconagua
if (null == username_exists ($ email_address)) $ password = wp_generate_password (12, false); $ user_id = wp_create_user ($ email_address, $ password, $ email_address); wp_update_user (array ('ID' => $ user_id, 'nickname' => $ email_address);); else // De gebruikersnaam bestaat al, dus behandel deze dienovereenkomstig ... Hierna moet je eigenlijk een nieuw exemplaar maken van WP_User.
$ user = nieuwe WP_User ($ user_id);
Dit is wat ons in staat stelt om rollen in te stellen voor de gegeven gebruiker.
Ten slotte is het tijd om te bepalen welke rol en reeks functies u aan de gebruiker wilt toewijzen.
Aan de ene kant kun je deze waarden hard coderen op basis van de opties die WordPress biedt. De waarheid is dat je zelfs aangepaste rollen en mogelijkheden kunt creëren. Voor nu valt dat buiten de reikwijdte van het artikel; we kunnen het echter in een toekomstige reeks bezoeken.
Dus laten we zeggen dat we willen dat alle gebruikers die momenteel zijn aangemeld de abonnee rol. U kunt zien welke set mogelijkheden zij zullen krijgen in dit Codex-artikel.
Een rol instellen is triviaal:
$ user-> set_role ('contributor'); Op dit punt hebt u met succes een nieuwe gebruiker in de WordPress-applicatie programmatisch aangemaakt zonder gebruik te hoeven maken van de standaard administratieve functionaliteit.
Sluit dit simpelweg aan op uw eigen sjabloon, valideer, zuiver en controleer de binnenkomende berichten $ _POST data, en je bent klaar om te gaan.
De volledige code ziet er als volgt uit:
if (null == username_exists ($ email_address)) // Genereer het wachtwoord en maak de gebruiker $ wachtwoord = wp_generate_password (12, false); $ user_id = wp_create_user ($ email_address, $ password, $ email_address); // Stel de bijnaam wp_update_user in (array ('ID' => $ user_id, 'nickname' => $ email_address);); // Stel de rol $ user = new WP_User ($ user_id) in; $ user-> set_role ('contributor'); else // De gebruiker bestaat al // einde if / else Niet slecht, toch??
Maar een gebruiker aanmaken en dan hun informatie in de database eigenlijk maar in de helft opslaan, toch??
Zodra de gebruiker inlogt en is geverifieerd, wilt u waarschijnlijk de inhoud beperken op basis van hun rol. Dit roept dus de vraag op: wanneer een gebruiker is ingelogd, hoe kunnen we de rol van een gebruiker opvragen?
Gelukkig maakt de API van WordPress dit relatief eenvoudig:
We zullen moeten profiteren van de wp_get_current_user () functie, en dan moeten we een instantie van de WP_User object met de ID van de huidige gebruiker, waarna we de mogelijkheden van de gebruiker kunnen bekijken.
Bekijk de onderstaande code:
// Krijg een exemplaar van de huidige gebruiker $ user_id = wp_get_current_user () -> ID; $ user = nieuwe WP_User ($ user_id);
Niet slecht, toch??
Dit maakt het heel gemakkelijk om voorwaardelijke code te schrijven, zoals:
// Hiermee drukt u de gebruikersmogelijkheden print_r ($ user-> wp_capabilities) af; // Op zijn beurt kunt u een dergelijke controle uitvoeren: if ('1' === $ user-> wp_capabilities ['subscriber']) // We hebben een abonnee Er is een alternatieve manier om dit te doen, hoewel:
global $ current_user; get_currentuserinfo (); if (0 === $ current_user-> user_level) // We hebben een abonnee
Maar dit roept de vraag op waar kwam die nul vandaan? Bekijk precies dat.
De verschillen tussen de twee benaderingen zijn afhankelijk van hoe objectgericht u wilt dat uw code is.
Ik ben minder fan van het gebruik globaal wanneer er een objectgerichte benadering beschikbaar is (zoals in het eerste voorbeeld); het tweede voorbeeld biedt echter ook een relatief eenvoudige oplossing. Uw keuze.
Hoe dan ook, als u eenmaal in staat bent om de rol van het account van een gebruiker voorwaardelijk te controleren, kunt u deze beperken tot specifieke delen van de toepassing.
Je hebt gelijk: op zijn minst de behoefte van gebruikers om e-mails te ontvangen voor wanneer hun accounts zijn aangemaakt en ze moeten e-mails kunnen ontvangen als iets over hun account is veranderd.
Nogmaals, WordPress biedt een API die dit heel gemakkelijk maakt, maar het kan uitgebreid worden voorbij eenvoudige acties zoals wanneer de profielinformatie van een gebruiker veranderd is.
In feite, gezien het feit dat WordPress een rijk evenementensysteem heeft, kun je potentieel inhaken op een willekeurig aantal evenementen en e-mails verzenden wanneer iets gebeurt. Dat is duidelijk overdreven, maar het laat zien hoe krachtig de API echt is.
Dus in de volgende sectie gaan we kijken naar de e-mail API van WordPress en hoe deze kan worden gebruikt om berichten over bepaalde activiteiten te verzenden, evenals hoe deze kan worden gekoppeld aan andere functies in de applicatie..
