WordPress-rollen en -mogelijkheden de basisprincipes

Dit is een vierdelige tutorialserie over het onderwerp van WordPress-gebruikers, -rollen en -mogelijkheden. De serie behandelt de architectuur en het ontwerp van gebruikersrollen in WordPress; markeer de belangrijkste functies voor interactie met gebruikers en het beheren van rollen en mogelijkheden; en in de laatste zelfstudie gaan we een realistisch voorbeeld geven dat het nut van deze API aantoont.


Invoering

In dit eerste deel zullen we de basisprincipes en interne werking van het WordPress gebruikers-, rollen- en capaciteitensysteem bekijken. In dit deel worden geen functies of codes behandeld. Dus je kunt naar de volgende gaan als je alleen geïnteresseerd bent in het schrijven van code die met dit systeem samenwerkt. Ik zou echter sterk aanbevelen dat u dit eerst doorneemt om een ​​basisidee te krijgen over gebruikers en rollen in WordPress.

Na versie 2.0 introduceerde WordPress een nieuw Rollen en Capabilities-systeem dat het oudere systeem op gebruikersniveau verving. Het oudere systeem zal niet worden besproken; het is nu volledig verouderd (sinds versie 3.0) en zou niet langer moeten worden gebruikt.

Het nieuwe systeem is geavanceerder en flexibeler. Het is nu mogelijk om aangepaste machtigingen te maken en deze toe te wijzen per gebruiker. Deze update kwam om de tekortkomingen in het oude model aan te pakken en om ontwikkelaars in staat te stellen krachtigere en aangepaste plug-ins en thema's te bouwen.


Database-architectuur voor gebruikers

  1. Tabellenschema voor gebruikers

    WordPress houdt de gegevens van de gebruikers in twee tabellen: wp_users en wp_usermeta (Ik neem tijdens deze hele reeks de aanname dat je WordPress-setup de standaard gebruikt wp_ voorvoegsel). De tweede tabel is gemaakt om de eerste uit te breiden en stelt ontwikkelaars in staat extra gegevens aan elke gebruiker te koppelen.

    Als er maar één tabel was, kunt u niet meer gegevens aan gebruikers toevoegen of moet u al deze gegevens in een rij in series bewaren die niet echt goed is voor prestaties en schaalbaarheid. (Stel je het geval voor van het hebben van 50 plug-ins waarbij elke 2 of 3 velden per gebruiker toevoegt.)

    Hieronder staat een schema van het schema van de twee tabellen. De tabellen zijn gekoppeld aan een "one-to-many" relatie. In feite kunt u zoveel rijen als u wilt in de wp_usermeta met hetzelfde gebruikersnaam (dit is de externe sleutel voor deze relatie en vertegenwoordigt de kolom ID in wp_users)

  2. In de tafels

  3. Als we het schema van deze twee tabellen bekijken, kunnen we concluderen dat wp_users wordt gebruikt om een ​​beperkte en eindige hoeveelheid gegevens over elke gebruiker vast te houden. Sommigen van hen zijn vereist en worden meestal gebruikt door de WordPress-kern, thema's of plug-ins, zoals de login, wachtwoord, e-mail en mooie naam (ook bijnaam). Maar het is niet het geval voor de user_url veld, bijvoorbeeld. Dit veld zou kunnen passen in de wp_usermeta tabel omdat het niet verplicht is.

    Sommige verplichte velden worden opgeslagen in de wp_usermeta zoals de bijnaam. Nou, eigenlijk ben ik me alleen bewust van deze. Bepaalde kritieke informatie zoals de gebruikersmogelijkheden, gebruikersniveau en SSL-modus worden echter opgeslagen in de wp_usermeta tafel ook. Dit maakt het niet minder belangrijk dan de wp_users tabel (vooral als permissies en beveiliging een grote zorg zijn).

    Dat gezegd hebbende, moet je voorzichtig zijn als je met beide tafels omgaat. Ik raad u aan om bij de WordPress-functies te blijven voor interactie met het systeem voor gebruikers en mogelijkheden.


Rollen en mogelijkheden in WordPress

Net als elk ander CMS, heeft WordPress een gebruikersrechtensysteem om privileges in te stellen en te beperken voor elke gebruiker. In deze sectie ga ik het concept achter rollen en mogelijkheden in WordPress uitleggen. Dus als je worstelt met de verklaring van de Codex, hoop ik dat deze duidelijker wordt naarmate ik het concept anders benader.

  1. Een overzicht van de mogelijkheden

    Vergeet rollen. Laten we een paar minuten aannemen dat ze niet bestaan.

    Laten we het volgende scenario bekijken: u heeft een WordPress-blog die u onlangs hebt ingesteld en u bent de beheerder. (Dus je hebt alle mogelijke stroom die er is.) Je hebt besloten om een ​​nieuwe gebruiker aan je blog toe te voegen om wat blogposts bij te dragen. U dacht ook dat het eerlijk zou zijn om hem toe te staan ​​opmerkingen te maken en zijn weergavenaam aan te passen.

    Hieronder ziet u een afbeelding van onze gebruiker met de mogelijkheden die u hem hebt toegewezen.

    Dus het is zo simpel als dat. U wijst capaciteiten toe aan gebruikers. U bent vrij om deze mogelijkheden een naam te geven. U kunt bijvoorbeeld 'write_new_post' een naam geven als naam voor het schrijven van een nieuw bericht.

    In je blog heb je een lijst met mogelijkheden waarbij iedereen een speciale en beperkte macht heeft voor de gebruikers die ze hebben. Elke gebruiker kan een beperkt aantal mogelijkheden hebben. Een gebruiker die over alle mogelijkheden beschikt, is een beheerder, omdat hij vrijwel alles kan doen. Zie het als een toestemmingssysteem en de mogelijkheden zijn machtigingen die u aan gebruikers geeft.

    Maar waarom zijn capaciteiten belangrijk? Nou, jij bent degene die daarvoor verantwoordelijk is. Als u bijvoorbeeld uw eigen plug-in (of thema) aan het bouwen bent, kunt u uw eigen plug-in maken "access_control_panel"mogelijkheid en wijs het toe aan een aantal gebruikers.

    Wanneer een gebruiker vraagt ​​om uw "Configuratiescherm", moet u controleren of de gebruiker de "access_control_panel"mogelijkheid om de pagina van het Configuratiescherm weer te geven. U kunt ook controleren op mogelijkheden voordat u een bepaald stuk code uitvoert om ervoor te zorgen dat de gebruiker de vereiste rechten heeft.

    WordPress wordt geleverd met een standaard aantal functies dat nodig is voor de werking ervan. U kunt ook gebruikmaken van deze mogelijkheden, maar pas op dat u ze niet verwijdert. Je kunt zeker je eigen en aangepaste mogelijkheden maken.

  2. Hoe rollen in het spel komen

    Dus nu weten we wat mogelijkheden zijn. Laten we een ander scenario bedenken, waar je een hoop gebruikers hebt. U wilt deze gebruikers opsplitsen in twee groepen: krachtige gebruikers en minder krachtige gebruikers. Elke groep gebruikers heeft speciale mogelijkheden.

    Om dat te doen, moet u deze mogelijkheden aan elke gebruiker toewijzen, wat een beetje frustrerend en onproductief kan zijn. Rollen zijn er precies voor gemaakt, ze zijn wat gebruikers zijn gegroepeerd.

    Dus in plaats van het toewijzen van mogelijkheden aan gebruikers, wijst u ze toe aan rollen; en vervolgens wijst u de rollen toe aan de gebruikers. Het is echter mogelijk om functies direct aan gebruikers toe te wijzen. Een rol kan voor één of voor veel gebruikers worden gemaakt; en één gebruiker kan geen, één of vele rollen hebben.

    Dus de realiteit is veel meer zo.

    Het is belangrijk om hier te noteren dat u moet controleren op een gebruikersmogelijkheid en niet op een gebruikersrol voordat u code uitvoert waarvoor toestemming is vereist. Ga er nooit vanuit dat een rol een specifieke mogelijkheid heeft, omdat deze kan worden gewijzigd door een andere plug-in of een ander thema.

  3. Meta-mogelijkheden

    Er zijn acties die meerdere mogelijkheden vereisen. Als u bijvoorbeeld een blogbericht wilt bewerken, hebt u het volgende nodig:bericht bewerken'mogelijkheid. Maar wat als deze blogpost door een andere gebruiker is gemaakt? Je hebt dan de 'edit_other_posts'mogelijkheid ook. U moet dus beide controleren voordat u de gebruiker de post kunt laten bewerken.

    Dat is waar metamogelijkheden in het spel komen. WordPress heeft een map_meta_cap () functie die een array met de vereiste mogelijkheden retourneert om een ​​bepaalde mogelijkheid uit te voeren.

    Laten we dus teruggaan naar het vorige voorbeeld. Laten we aannemen dat we een gebruiker hebben met een ID van 3 en we willen controleren of deze gebruiker een blogpost kan bewerken met een ID van 5. Deze blogpost is gepubliceerd door een andere gebruiker met een ID van 6.

    In dit geval, de map_meta_cap () functie retourneert een array met de volgende mogelijkheden: bericht bewerken, edit_published_posts, en edit_other_posts. Om die array te maken, de map_meta_cap () functie moet een aantal controles uitvoeren op basis van de gebruiker en de post.

    De standaardmogelijkheden waarnaar de functie controleert, zijn 'Verwijder gebruiker','bewerk gebruiker','remove_user','promote_user','Verwijder gepost bericht','delete_page','bericht bewerken','Pagina bewerken','read_post', of'read_page'. Het is echter mogelijk om te vergroten met uw eigen door te haken aan de 'map_meta_cap'filter.


Conclusie

Dus dat was in een notendop het WordPress-gebruikers- en machtigingensysteem. Ik heb geprobeerd het zo eenvoudig en minimalistisch mogelijk te houden; en ik vermeden om welke reden dan ook om het even welke code. In het volgende deel bekijken we een breed scala aan functies die WordPress biedt om met dit systeem te communiceren.