Gebruikersrollen en rechten maken het binnen WordPress mogelijk om te beheren wat andere gebruikers wel en niet kunnen doen op jouw site. Je kan ze gebruiken om de acties van gebruikers te managen, zoals het schrijven en bewerken van artikelen, maken van nieuwe pagina’s, beheren van reacties, installeren van plugins, toevoegen van nieuwe gebruikers, en ga zo maar door.
Om een WordPress website goed te kunnen beheren is het van essentieel belang om gebruikersrollen en rechten goed te begrijpen. Ben je bijvoorbeeld een website aan het bouwen voor een klant, dan wil je niet dat ze het geïnstalleerde thema kunnen veranderen of bewerken. Net zoals dat het ook onverstandig is om schrijvers op een blog plugins te laten verwijderen of installeren.
Door WordPress gebruikersrollen zo slim mogelijk te beheren kun je je workflow stroomlijnen, je website veilig houden, en heb je je website volledig onder controle.
In deze uitgebreide gids zul je alles leren over WordPress gebruikersrollen, de verschillende mogelijkheden die WordPress biedt, hoe je bestaande gebruikersrollen bewerkt, hoe je gebruikers binnen een multisite beheert en hoe je nieuwe gebruikersrollen maakt met een nieuwe set rechten.
Al nieuwsgierig? Laten er dan meteen induiken!
Wat zijn gebruikersrollen en rechten binnen WordPress?
Gebruikersrollen en rechten zijn dagelijkse kost binnen het beheren van gebruikers in WordPress. Om te begrijpen wat gebruikersrollen binnen WordPress zijn, moet je eerst weten wat gebruikersrechten zijn.
WordPress definieert elke actie die een gebruiker kan uitvoeren als een Capability. Hier zijn enkele voorbeelden van rechten die beschikbaar zijn binnen WordPress, en hoe hieraan gerefereerd wordt binnen de WordPress code:
- Het lezen van artikelen (read)
- Schrijven en bewerken van artikelen (edit_posts)
- Publiceren van artikelen (publish_posts)
- Installeren van plugins (install_plugins)
- Verwijderen van thema’s (delete_themes)
- Aanmaken van gebruikers (create_users)
- Beheren van reacties (moderate_comments)
De meeste gebruikersrechten zijn vrij eenvoudig te begrijpen. WordPress heeft meer dan 70 rechten ingebouwde in de kern.
Een Role oftewel rol is een verzameling Capability’s, oftewel rechten, die je kan toewijzen aan een gebruiker. Elke WordPress gebruiker moet een rol hebben toegewezen. Een gebruiker kan alleen die acties ondernemen die toegestaan zijn binnen hun rol.
In de afbeelding hierboven kun je zien dat elke gebruiker met Role 1 artikelen kan lezen, maar niet bewerken. Gebruikers met Role 2 kunnen artikelen zowel lezen als bewerken, maar weer niet publiceren. Elke gebruiker met Role 3 kan artikelen lezen, bewerken en publiceren, maar niet verwijderen, terwijl gebruikers met Role 4 dat wel kunnen.
WordPress maakt gebruik van de ingebouwde capability’s om de standaard gebruikersrollen te definiëren. Zo geeft het bijvoorbeeld standaard het recht publish_pages aan Administrators (Beheerder) en Editors (Redacteur), maar niet aan Subscribers (Abonnee) en Contributors (Schrijver).
Elke WordPress gebruiker heeft altijd minimaal een gebruikersnaam, wachtwoord, emailadres en een gebruikersrol.
WordPress slaat alle rolgebaseerde rechten op in de database binnen de wp_options tabel onder de wp_user_roles optie. De WP_Roles core class wordt gebruikt voor het beheren van rollen en rechten binnen de database.
De WP_Roles class
WordPress implementeert de rollen en rechten via de User Roles API, die vooral draait op de WP_Roles core class. Je kan de bron hiervoor vinden in het bestand wp-includes/class-wp-roles.php.
Wanneer je de database bekijkt, zie je dat de rollen worden gedefinieerd binnen een array, samen met de naam voor de rol. De rolename key slaat de naam voor de gebruikersrol op als een waarde van de name key en alle rechten in een aparte array als een waarde voor de capability key.
array (
'rolename' => array (
'name' => 'rolename',
'capabilities' => array()
)
)De WP_Roles class definieert allerlei methods. Je kan ze overal in je code oproepen om met de User Roles API te werken.
Let op: WordPress bevat nog een andere core class met de naam WP_Role (het verschil is dus enkelvoud Role versus meervoudig RoleS). Dit wordt gebruikt om de User Roles API verder uit te breiden.
Wanneer je de key values van wp_user_roles uitschrijft, ziet het er ongeveer zo uit:
array (
'administrator' =>
array (
'name' => 'Administrator',
'capabilities' =>
array (
'switch_themes' => true,
'edit_themes' => true,
'activate_plugins' => true,
// [...rest of the lines cut off for brevity...]
),
),
'editor' =>
array (
'name' => 'Editor',
'capabilities' =>
array (
'moderate_comments' => true,
'manage_categories' => true,
'manage_links' => true,
// [...rest of the lines cut off for brevity...]
),
),
'author' =>
array (
'name' => 'Author',
'capabilities' =>
array (
'upload_files' => true,
'edit_posts' => true,
'edit_published_posts' => true,
// [...rest of the lines cut off for brevity...]
),
),
'contributor' =>
array (
'name' => 'Contributor',
'capabilities' =>
array (
'edit_posts' => true,
'read' => true,
// [...rest of the lines cut off for brevity...]
),
),
'subscriber' =>
array (
'name' => 'Subscriber',
'capabilities' =>
array (
'read' => true,
'level_0' => true,
),
),
)Dit is een multidimensionale array waarbij elke rol een naam en set rechten krijgt toegewezen. Zo slaat WordPress ook rechten per gebruiker op in de wp_usermeta tabel via de wp_capabilityies meta key name.
Let op: Het voorvoegsel wp_ kan anders zijn in jouw installatie. Dat is afhankelijk van de global variable $table_prefix binnen het wp-config.php bestand van je site.
Grafiek met rollen vs rechten
De WordPress Codex bevat een eenvoudige Capability vs Role Table, alhoewel je wel even twee keer moet kijken voordat je de grafiek doorhebt. Het vat alle acties die standaard gebruikersrollen kunnen uitvoeren samen voor zowel enkelvoudige sites als multisites. Er is een break na elke set rechten om het eenvoudiger te maken om onderscheid te maken tussen high-level en low-level rechten.
Voor een betere visualisatie van alle WordPress gebruikersrollen en rechten, kun je ook deze handige tabel van Exygy bekijken.
Rechten gerelateerd aan Gutenberg herbruikbare blokken
De Gutenberg blok-editor van WordPress introduceerde een handige feature met de naam Herbruikbare blokken. Hiermee kun je een heel blok (of diverse blokken) opslaan als template en ergens anders op je website hergebruiken.
Daarom heeft WordPress ook de volgende nieuwe rechten toegevoegd voor de herbruikbare blokken:
- Herbruikbare blokken aanmaken
- Herbruikbare blokken wijzigen
- Herbruikbare blokken lezen
- Herbruikbare blokken verwijderen
De rechten hierboven werken op dezelfde manier als de rechten voor berichten. Een Admin of Editor heeft toegang tot alle blokrechten, terwijl een Author alleen herbruikbare blokken kan bewerken of verwijderen die ze zelf hebben aangemaakt. Contributors kunnen alleen herbruikbare blokken lezen.
Speciaal recht: Ongefilterde uploads
Ongefilterde uploads is een speciaal recht die niet standaard aan een gebruikersrol is toegewezen, zelfs niet aan Administrator of Super Admin. Het maakt het mogelijk dat een gebruiker bestanden uploadt met elk format (bijv .svg of .psd), dus niet alleen die formats die WordPress heeft goedgekeurd.
Let op: Je kan een lijst met mime types en bestandsformats die ondersteund worden door WordPress opvragen via de wp_get_mime_types() function.
Om deze capaciteit in te schakelen, zul je het volgende stukje code moeten toevoegen aan je wp-config.php bestand: Definieer de constant voor de regel die je verzoekt om verder geen code te bewerken.
define( 'ALLOW_UNFILTERED_UPLOADS', true );Nadat je deze constant hebt gedefinieerd, kun je elke gebruikersrol binnen een WordPress single-site de Ongefilterde upload mogelijkheid toewijzen. Bij een multisite installatie zal alleen een Super Admin deze capaciteit hebben.
Als je bijvoorbeeld de unfiltered_upload mogelijkheid wil toewijzen aan een Editor, zul je het volgende stukje code ergens moeten toevoegen (idealiter binnen de activering van je thema of plugin).
<?php
$role = get_role( 'editor' );
$role->add_cap( 'unfiltered_upload' );
?>We zullen verderop beter bekijken hoe je rechten van gebruikersrollen of specifieke gebruikers kunt aanpassen of toevoegen.
Primitive vs meta
Er zijn twee verschillende hoofdsoorten gebruikersrechten bij WordPress.
- Primitive capability’s: Dit zijn rechten die toegekend worden aan specifieke rollen. Gebruikers met deze rollen krijgen automatisch deze primitieve rechten.
- Meta capability’s: Deze rechten worden niet automatisch toegekend aan een rol. WordPress zoekt naar een bepaald object binnen de code en de database, zoals een artikel, pagina, gebruiker of taxonomie, en als er aan de voorwaarden voldoen wordt, wordt een meta-recht op één of meerdere primitieve rechten “gemapt”.
Zo wijst WordPress Authors bijvoorbeeld het recht edit_posts toe voor hun eigen artikelen zodat ze deze artikelen kunnen bewerken. Maar daarmee kunnen ze nog niet de artikelen van andere gebruikers bewerken. Hier komen meta-rechten dus om de hoek kijken.
WordPress gebruikt de functie map_meta_cap() om een array van primitieve rechten op te halen die aan een specifiek object is verbonden. Die worden vervolgens vergeleken met het gebruikersobject om te bepalen of een gebruiker het artikel mag bewerken.
Enkele andere voorbeelden van meta-rechten zijn read_post, delete_post, remove_user en read_post. We zullen hier verder op ingaan in het deel over aangepaste rechten.
De zes standaard WordPress gebruikersrollen
WordPress bevat zes vooraf gedefinieerde gebruikersrollen. De eerste gebruiker van een WordPress installatie krijgt standaard de Administrator rol (of de Super Admin rol bij een WordPress Multisite). In het Nederlands is dit de Beheerder.
Aangezien WordPress begonnen is als blogplatform voor het een compleet CMS werd, zijn de meeste gebruikersrollen gebouwd rond het publiceren van content op het web. De andere vooraf gedefinieerde gebruikersrollen zijn dan ook Editor, Author, Contributor en Subscriber. In een Nederlandse versie van WordPress zijn dit respectievelijk Redacteur, Auteur, Schrijver en Abonnee.
Stel je de standaard WordPress gebruikersrollen voor als een verzameling van gestapelde cilinders, die de verschillende rechten voorstellen. De grootste cilinder heeft de meeste rechten en de kleinste de minste.
Je moet de ene rol niet zien als ‘beter’ dan de andere. Zie het vooral als niet meer dan het definiëren van de verantwoordelijkheden van een gebruiker binnen de site.
Een gebruikersrol is nooit beter of slechter, het definieert alleen precies waar een rol voor bedoeld is.
Tijd om dieper in de vooraf gedefinieerde rollen binnen WordPress te duiken.
Administrator
WordPress wijst de eerste gebruiker van een installatie de Administrator rol toe. Deze rol bevindt zich boven alle andere gebruikersrollen en heeft toegang tot alle rechten die WordPress gedefinieerd heeft. Gebruikers met de Administrator rol kunnen dus acties uitvoeren zoal:
- Het maken en verwijderen van andere gebruikers
- Installeren en beheren van plugins en thema’s
- Bewerken van plugins, thema’s, bestanden en code
Aangezien de Administrator de rol is met de meeste rechten, moet je het alleen toewijzen aan mensen die je volledig vertrouwt. Idealiter is er ook maar één admin per site.
De rol van Administrator binnen een WordPress Multisite netwerk is net iets anders gedefinieerd, al heeft het dezelfde naam. Binnen een Multisite netwerk mist de Administrator rol enkele rechten die het binnen een single-site wel heeft, bijvoorbeeld het installeren van thema’s en plugins. WordPress heeft die rechten namelijk gereserveerd voor de Super Admin rol.
Editor
Een Editor regelt het beheren van content binnen een WordPress website. Ze kunnen artikelen en pagina’s maken, bewerken, publiceren of verwijderen, ook als ze door andere gebruikers zijn gemaakt. De bijbehorende rechten zijn onder meer:
- Het verwijderen van gepubliceerde artikelen en pagina’s
- Beheren van reacties
- Beheren van links en categorieën
- Bewerken van de artikelen en pagina’s van andere gebruikers
Editors kunnen geen Admin bewerkingen voor de site uitvoeren, zoals het installeren van plugins en thema’s. Hun belangrijkste verantwoordelijkheid is het werk van andere auteurs controleren en beheren – of ze zijn natuurlijk een contentteam bestaande uit slechts een persoon.
Tip: Als je in je eentje een WordPress website beheert, kan je ook een alternatieve gebruiker voor jezelf maken met de rol van Editor. Daardoor kun je je taken als Admin en als schrijver scheiden. Je adminaccount is op die manier beschermd tegen hackers, zelfs als je Editor account gehackt wordt.
Author
Zoals de naam al doet vermoeden, kan een gebruiker met de rol van Author artikelen schrijven, bewerken en publiceren. Ze kunnen ook mediabestanden uploaden en hun eigen artikelen verwijderen, maar ze kunnen geen pagina’s aanmaken of de artikelen van andere auteurs bewerken.
Authors kunnen tags aan hun artikelen toevoegen en ze toewijzen aan bestaande categorieën, maar ze kunnen zelf geen nieuwe categorieën aanmaken. Net als bij Editors hebben ze geen toegang tot administratieve zaken zoals instellingen, plugins en thema’s.
Let op: Een Author kan eigen artikelen verwijderen, ook nadat ze gepubliceerd zijn. Als je iemand de rol van auteur toewijst, zorg er dan voor dat je er helemaal oké mee bent dat ze de volledige controle over hun eigen artikelen hebben, inclusief het verwijderen van artikelen.
Contributor
De rol van Contributor is een afgeslankte versie van de Author. Een gebruiker met de Contributor rol kan eigen artikelen maken, concepten van hun artikelen verwijderen, maar niet hun eigen artikelen publiceren.
Ze kunnen concepten van hun artikelen opslaan of ze naar een Editor of Administrator sturen zodat die ze kan goedkeuren en publiceren. Nadat een artikel gepubliceerd is, kan een Contributor een eigen artikel niet verwijderen. Dit is dus anders dan bij Authors, die dat wel kunnen.
De rol van Contributor is ideaal voor nieuwe auteurs of voor gastbijdragen.
Subscriber
De rol van Subscriber bevindt zich helemaal onderaan qua aantal rechten. Een gebruiker met de Subscriber rol kan een eigen profiel beheren, en kan alle artikelen op een website lezen. En dat is het wel zo’n beetje.
In principe heeft iedereen de mogelijkheid om de content van een WordPress website te lezen. Maar bij websites met abonnementen of lidmaatschappen kunnen alleen ingelogde gebruikers (bepaalde delen van) de content bekijken. Een gebruiker met de rol van Subscriber kan in zo’n situatie de artikelen lezen.
Super Admin
De rol van Super Admin is alleen beschikbaar binnen een WordPress Multisite netwerk. Deze rol staat hiërarchisch gezien boven de Admins van de individuele site, en geeft toegang tot alle high-level Admin rechten.
Sommige Multisite rechten die alleen toegankelijk zijn voor Super Admins zijn:
- Het maken, beheren en verwijderen van sites binnen het netwerk
- Beheren van netwerkgebruikers, plugins, thema’s en instellingen
- Upgraden van alle sites binnen het Multisite netwerk
- Opzetten van een Multisite netwerk
- Toewijzen van Admins aan de individuele sites binnen het netwerk
Binnen een Multisite netwerk kan alleen een Super Admin thema’s installeren en ze beschikbaar maken voor sites binnen het netwerk. Admins van individuele sites kunnen alleen thema’s zien en activeren die al geïnstalleerd zijn door de Super Admin.
Zo heb ik bijvoorbeeld het gratis Astra thema geïnstalleerd op mijn netwerk, maar niet beschikbaar gemaakt voor subsites. Daardoor kunnen Administrators van individuele sites dit thema niet zien binnen hun Thema’s.
In het screenshot hierboven kun je ook zien dat het Plugins menu niet toegankelijk is voor de site Admins. Anders dan bij thema’s kan een Super Admin de instellingen binnen het netwerk zo veranderen dat site Admins zelf plugins kunnen installeren en activeren op hun sites.
Een Super Admin kan ook een Network Activate uitvoeren voor plugins waardoor ze voor alle sites binnen het netwerk geactiveerd worden. Site Administrators kunnen plugins die op deze manier geactiveerd zijn door de Super Admin niet zelf deactiveren. Deze instelling is vooral ideaal als je essentiële plugins wilt installeren voor het hele netwerk.
Het Network Admin scherm
Het Network Admin dashboard dient als centrale hub voor de Super Admin waar ze de netwerkrechten binnen een WordPress Multisite kunnen beheren. Het is ook alleen toegankelijk voor gebruikers met de rol van Super Admin nadat ze een netwerk hebben gemaakt.
1. Dashboard
Het Network Admin Dashboard is de centrale hub voor gedetailleerde informatie over je netwerk. Het geeft je ook toegang tot alle netwerkinstellingen.
2. Sites
Je kan het Sites paneel gebruiken om de verschillende sites binnen het Multisite netwerk te beheren. De websites die hier staan zullen een subdirectory of subdomein zijn, afhankelijk van hoe je het WordPress Multisite netwerk opgezet hebt.
Vanuit hier kun je ook nieuwe sites toevoegen of bestaande sites verwijderen binnen het netwerk.
Je ziet verder informatie over sites, gebruikers, thema’s en algemene netwerkinstellingen. De eerste site die je maakt is de primaire website binnen het netwerk. Het netwerk neemt alle instellingen over van deze eerste site.
Door op Add New Site te klikken ga je naar het scherm hierboven waarvandaan je een nieuwe website kunt toevoegen aan je Multisite netwerk. Ook kun je hier de Admin van de nieuwe site aanwijzen.
3. Users
Het scherm Users binnen het Network Admin dashboard helpt je bij het beheren van gebruikers en het toevoegen van nieuwe gebruikers via Add New Users. Alleen de Super Admin kan gebruikers toevoegen aan het hele netwerk, maar de Super Admin kan ook de instellingen zo veranderen dat Site Administrators wel nieuwe gebruikers toe kunnen voegen aan hun eigen individuele sites.
4. Themes
Het scherm Themes maakt het mogelijk om thema’s te beheren waar je site Administrators toegang toe hebben. Je kan hieruit niet thema’s voor een specifieke site activeren of deactiveren, alleen de mogelijke thema’s beheren.
Als je een thema niet-toegankelijk maakt terwijl een site binnen het netwerk dat thema gebruikt, zal het thema actief blijven op de site. Maar voor de sites die een ander thema gebruiken zal het uitgeschakelde thema niet meer verschijnen in het ‘Themes’ panel.
Je kan meer leren in het WordPress Multisite artikel van Kinsta als je meer wil weten over thema’s en plugins binnen je netwerk. Je kan ook de Theme Editor gebruiken om je thema bestanden te bewerken, direct binnen het dashboard.
5. Plugins
Het scherm Plugins maakt het mogelijk om plugins toe te voegen of te verwijderen. Nadat een plugin is toegevoegd voor het netwerk, kan je ze activeren vanuit het dashboard van de site. Je kan ook Network Activate gebruiken voor plugins zodat het gebruik van een plugin afgedwongen wordt voor alle sites binnen het netwerk.
Standaard heeft een site Administrator geen toegang tot het Plugin menu binnen het dashboard. Maar een Super Admin kan dit toegankelijk maken door de netwerkinstellingen aan te passen.
Let op: Niet alle WordPress plugins ondersteunen Multisite netwerken. Controleer de documentatie van de plugin om te zien of ze zullen werken binnen een Multisite.
6. Settings
Je kan de instellingen voor het hele netwerk veranderen binnen het scherm Network Settings. De standaardinstellingen van het netwerk zijn gebaseerd op de eerste website die je maakt bij het aanmaken van het netwerk. Enkele netwerkinstellingen die je hier kan veranderen zijn:
- Operationele instellingen
- Registratie-instellingen
- Instellingen voor nieuwe sites
- Uploadinstellingen
- Taalinstellingen
- Menu-instellingen
Je kan ook de informatie over de Network Setup bekijken. Deze heb je gebruikt bij het aanmaken van het netwerk. Zie verder de WordPress Codex over de instellingenpagina’s voor admins voor gedetailleerde informatie over alle instellingen.
7. Updates
Je kan de updates voor het hele netwerk of individuele sites beheren vanuit het scherm Updates. Updates zal laten zien of er updates zijn voor de WordPress Core, thema’s en plugins. Nadat je de nieuwste versie van WordPress hebt geïnstalleerd, kan je deze toepassen op alle sites binnen het netwerk via Upgrade Network.
Let op: Bij een WordPress single-site is de Administrator in feite een Super Admin, aangezien ze toegang hebben tot al deze adminrechten.
Je kan gebruikersrollen aanpassen of je eigen aangepaste rollen maken door de standaardrechten binnen WordPress te gebruiken.
Voordelen van gebruikersrollen en rechten
Het systeem van rollen en rechten van gebruikers is de ruggengraat van het gebruikersbeheer binnen WordPress. Enkele van de vele voordelen zijn:
- Gebruikersrollen helpen je bij het beter en efficiënter beheren van gebruikers binnen je site. Zelfs als tientallen gebruikers van over de hele wereld aan je website werken, kan je ze alsnog eenvoudig aansturen door de juiste gebruikersrollen te geven.
- Door gebruikers te beperken tot alleen bepaalde rechten, blijft je website veiliger. Zo kunnen Authors niet de artikelen van anderen verwijderen, Editors geen thema’s wijzigen of plugins installeren, en hebben Subscribers alleen toegang tot hun eigen profielen.
- WordPress plugins kunnen controleren of een gebruiker bepaalde rechten heeft, en of ze op basis daarvan een bepaalde actie mogen uitvoeren. De WordPress functie current_user_can() helpt bij het uitvoeren van deze controle. Zo kan een beveiligingsplugin het instellingenscherm uitsluitend aan de admin laten zien, en toch beveiligingsmeldingen voor alle gebruikers weergeven.
- Je kan gebruikersrollen aanpassen om een selectie van jouw verantwoordelijkheden aan andere gebruikers toe te wijzen, waardoor jij tijd voor andere dingen hebt. Stel bijvoorbeeld dat je website veel reacties krijgt. In zo’n geval kan je regelen dat een Author die je vertrouwt ook alle reacties kan gaan modereren. Je houdt als admin nog steeds de uiteindelijke controle, maar je kan wel je verantwoordelijkheden delen wanneer dat nodig is.
- Je kan rechten ook gebruiken om te bepalen welke gebruikersrollen welke pagina’s en artikelen mogen zien. Dit is uiteindelijk de basis van ledenwebsites.
- Je kan front-end elementen weergeven of juist verbergen (zoals menu-items, widgets etc.) op basis van de gebruikersrol.
- Je kan aangepaste berichttypes maken met aangepaste rechten en aangeven welke gebruikersrollen die rechten hebben. Op dezelfde manier kan je aangepaste rechten gebruiken om te bepalen welke rollen toegang hebben tot de instellingen van je plugin of thema.
Het effectief beheren van WordPress gebruikersrollen
Het kennen van de mogelijkheden van rollen en rechten is essentieel, maar het is ook belangrijk te weten hoe je ze efficiënt kan beheren binnen je sites. Er zijn geen twee WordPress websites die hetzelfde zijn, maar een aantal basisregels helpen op elke website om maximaal nut te halen uit gebruikersrollen en rechten.
Geef elke gebruiker minimale toegang
Wijs elke gebruiker alleen precies de toegang toe die ze nodig hebben, meer niet. Het is altijd beter te weinig rechten te verstrekken dan te veel. Het veilig gebruik maken van gebruikersrollen is essentieel voor het veilig houden van je WordPress website en je content.
Beperk het aantal Administrators en Editors
Als algemene regel moet elke website maar één Administrator hebben die de belangrijkste veranderingen voor de website doorvoert. WordPress beveelt iedereen aan om zich te houden aan het “principe van de minste rechten”. Dat betekent dat je elke gebruiker alleen die rechten moet geven die absoluut noodzakelijk zijn om hun gewenste bezigheden uit te voeren.
Zo is het bijvoorbeeld beter om een gebruiker met een rol als Editor je content te laten beheren dan een Administrator. Als je meer dan één Editor binnen je site hebt, moet je zeker weten dat je ze volledig vertrouwt met die extra toegang.
Wijs de rol van Author toe aan content creators die je kan vertrouwen, aangezien ze hun eigen artikelen kunnen publiceren én verwijderen. De rol van Contributor is vooral goed geschikt voor nieuwe content creators en gastschrijvers.
Pas gebruikersrollen aan wanneer nodig
De standaard gebruikersrollen van WordPress zijn handig en goed bedacht, maar passen niet perfect bij elke usecase. Zo kan het zijn dat je wil dat Authors de mogelijkheid hebben om reacties te modereren, of juist niet.
Gelukkig maakt WordPress het mogelijk om gebruikersrollen aan te passen of nieuwe te maken wanneer dat beter bij jouw site past. Die kan je handmatig doen via de code of via plugins voor gebruikersrollen. We behandelen beide methoden in dit artikel.
Het beheren van gebruikers binnen een WordPress Multisite netwerk
WordPress Multisite biedt unieke mogelijkheden voor het beheren van gebruikers. Sommige hiervan zijn eenvoudig te begrijpen, en andere wat lastiger.
We bekijken ze allemaal in detail.
Multisite netwerk registratie-instellingen
Standaard kan alleen een Super Admin nieuwe gebruikers en sites binnen het netwerk maken. Maar ze kunnen het wel toestaan dat gebruikers een account als Subscriber registreren binnen subsites in het netwerk.
Om dit toe te staan ga je naar Network Admin > Network Settings > Registration Settings > Allow new registrations en activeer je de optie “User accounts may be registered”.
Op deze pagina kan je ook toestaan dat ingelogde gebruikers nieuwe sites binnen je netwerk aanmaken. Je kan deze optie aanvinken als je deze mogelijkheid wil beperken tot gebruikers die je zelf hebt aangemaakt.
De laatste mogelijkheid laat gebruikers zowel een account als een site aanmaken. Een gebruiker die een site binnen je netwerk maakt krijgt automatisch de rol van Administrator voor die subsite.
Eén gebruikersaccount voor het hele netwerk
Wanneer je een gebruikersaccount op je netwerk aanmaakt of een gebruiker zelf een account op één van de sites registreert, kunnen ze bij alle sites binnen het netwerk. Stel je dit voor zoals een sociaal netwerk zoals Facebook of Reddit, waarbij je een account aanmaakt en vervolgens bij alle groepen of subreddits kunt met dat ene account.
Dit is één van de grote voordelen van WordPress Multisite. Je gebruikers krijgen toegang tot al je sites vanaf slechts één account.
Extra privileges toewijzen aan Site Administrators
Je kan toestaan dat Site Administrators zelf gebruikers kunnen toevoegen aan hun website door de optie Add New Users aan te vinken.
Zoals eerder gezegd kan je Site Administrators toegang geven om de plugins op hun eigen subsite te beheren, via Network Settings > Menu Settings waar je de optie Enable administration menus > Plugins inschakelt.
Subsite level gebruikersregistratie
WordPress Multisite installaties staan standaard gebruikersregistratie voor het hele netwerk toe. Er is geen mogelijkheid om gebruikersregistratie maar voor één site in te schakelen. Je kan dit veranderen door de plugin Network Subsite User Registration te gebruiken.
Deze plugin maakt het mogelijk voor Site Administrators om lokale gebruikersregistratie in te schakelen, waarmee nieuwe gebruikers alleen toegang krijgen tot die ene site. Nieuwe gebruikers krijgen standaard de rol van Subscriber, maar ook dit kun je veranderen via de instellingen van de plugin.
Dezelfde gebruiker toewijzen aan meerdere subsites
Je kan één gebruiker aan verschillende subsites in je netwerk toewijzen, met voor elke site verschillende rollen. Wanneer de gebruiker inlogt bij het dashboard van één van de sites, hebben ze toegang tot het dashboard voor alle websites via het scherm My Sites.
Andere gebruikers Super Admin rechten geven
Een Super Admin kan de bijbehorende rechten delen met andere gebruikers. Wees voorzichtig met deze optie en deel deze privileges alleen met gebruikers die je volledig kan vertrouwen.
Door de instellingen voor gebruikers binnen WordPress Multisite te begrijpen, kun je je netwerk beter beheren. Om andere handige plugins voor WordPress Multisite te vinden, kun je in de WordPress pluginbibliotheek kijken, of lees ons artikel met aanbevolen WordPress Multisite plugins.
Zo bewerk je bestaande gebruikersrollen binnen WordPress
Je kan rechten toevoegen aan je bestaande gebruikersrollen om ze meer toegang te geven. Zo kan je bijvoorbeeld Editors de ruimte geven om plugins te beheren. Of wellicht wil je dat Contributors de reacties op hun eigen artikelen kunnen beheren. Laten we kijken hoe je dat doet.
Let op: Als je niet graag met code werkt, sla dan de handmatige methode over en ga meteen naar het gedeelte over plugins hieronder. Of huur een WordPress developer in.
Zo voeg je rechten toe aan een gebruikersrol
Je kan rechten toevoegen aan een gebruikersrol of specifieke gebruiker door de WordPress functie add_cap() te gebruiken. Ik zal een custom plugin gebruiken met de naam Customize User Role om te laten zien hoe je deze functie kan gebruiken om een Editor de mogelijkheid te geven plugins te beheren.
<?php
/*
Plugin Name: Customize User Role
Version: 1.0
Description: Demonstrating how to customize WordPress User Roles.
Author: Salman Ravoof
Author URI: https://www.salmanravoof.com/
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
Text Domain: customize-user-role
*/WordPress doet de aanbeveling om deze functie te koppelen aan een thema of plugin aangezien de instellingen die het toevoegt aan de database, opgeslagen worden in de wp_options tabel in het wp_user_roles veld. Het is inefficiënt om deze functie elke keer dat je een pagina laadt uit te voeren, aangezien de tabellen in je database dan bij elke pagina die geladen wordt overschreven worden.
Aangezien ik een plugin gebruik, zal ik de register_activation_hook() functie gebruiken als hook in de action die draait wanneer je een plugin activeert. Er zijn veel verschillende manieren om dit te doen, maar ik gebruik een robuuste class-based implementatie om er zeker van te zijn dat er geen conflicten ontstaan.
// this code runs only during plugin activation and never again
function sal_customize_user_role() {
require_once plugin_dir_path( __FILE__ ).'includes/class-sal-customize-user-role.php';
Sal_Customize_User_Role::activate();
}
register_activation_hook( __FILE__, 'sal_customize_user_role' );De code hierboven wordt eenmalig uitgevoerd bij het activeren van de plugin. De gehookte functie sal_customize_user_role maakt een referentie naar de custom class Sal_Customize_User_role.
Ik heb deze class gedefinieerd in een apart bestand dat class-sal-customize-user-role.php heet en zich bevindt in de rootmap van mijn plugin binnen een submap met de naam includes, maar je kan het ook een andere naam geven.
<?php
class Sal_Customize_User_Role {
public static function activate() {
// get the Editor role's object from WP_Role class
$editor = get_role( 'editor' );
// a list of plugin-related capabilities to add to the Editor role
$caps = array(
'install_plugins',
'activate_plugins',
'edit_plugins',
'delete_plugins'
);
// add all the capabilities by looping through them
foreach ( $caps as $cap ) {
$editor->add_cap( $cap );
}
}
}We bekijken de code van hierboven in detail:
- We beginnen met het definiëren van de class en functie waar je aan refereert in het hoofdbestand van de plugin.
- De functie get_role(‘editor’) haalt het Editor role object op van de
WP_Rolecore class en wijst het toe aan de$editorvariabele. - Het beheren van plugins vereist vier specifieke permissies:
install_plugins,activate_plugins,edit_plugins, endelete_plugins. Maar deadd_cap()functie kan maar één parameter accepteren. Daarom moeten we alle rechten in een array zetten. Definieer de$capsarray zo dat alle benodigde rechten daarin zitten. Als we slechts één permissie zouden toevoegen, is er geen array nodig. - De
add_cap( $cap )functie voegt alle rechten in de$capsarray toe door een ‘loop’ opdracht in de foreach() PHP-functie.
Sla al je pluginbestanden op en activeer de plugin vanuit het Administrator dashboard. Nu loggen we in het op Editor dashboard om de veranderingen te zien.
Na het toevoegen van de rechten voor plugins, kunnen Editors nu het menu voor Plugins zien in hun admin menu.
Je kan de rechten die toegekend zijn aan elke gebruikersrol zien via de wp_user_roles key value zoals deze is opgeslagen in de wp_options tabel van je WordPress database.
Dit zijn de rechten die toegewezen waren aan de Editor rol bij mijn site:
'editor' =>
array (
'name' => 'Editor',
'capabilities' =>
array (
'moderate_comments' => true,
'manage_categories' => true,
// [...lines cut off for brevity...]
'install_plugins' => true,
'activate_plugins' => true,
'edit_plugins' => true,
),
),In de laatste drie regels zie je dat Editors het recht hebben om plugins te beheren.
Wil je deze rechten verwijderen, dan kun je hooken aan de register_deactivation_hook() functie en de functie remove_cap() gebruiken om de gewenste rechten te verwijderen zodra de plugin gedeactiveerd wordt, net zoals dat ging bij het toevoegen tijdens het activeren.
Nu je weet hoe je rechten kan toevoegen aan een gebruikersrol, is het tijd om te leren hoe je ze weer kunt verwijderen.
Let op: Je kan ook hooken aan de after_switch_theme action om deze code te activeren wanneer je een thema (of child-thema) activeert. Dan moet je de code wel opnemen in je thema’s (of zoals aanbevolen in je child-thema’s) functions.php bestand.
Zo verwijder je rechten van een gebruikersrol
Soms wil je rechten weghalen bij een gebruikersrol. Je kan de functie remove_cap() gebruiken om een recht van een rol of specifieke gebruiker te verwijderen. Het is bijvoorbeeld een goed idee om het privilege delete_published_posts weg te halen bij de rol van Author.
Dat doen we zo.
Ik maak een nieuwe plugin met de naam Customize Author Role. Net als eerder laat ik deze code maar één keer uitvoeren door te hooken aan de register_activation_hook() functie.
<?php
/*
Plugin Name: Customize Author Role
Version: 1.0
Description: Demonstrating how to customize WordPress Author Role.
Author: Salman Ravoof
Author URI: https://www.salmanravoof.com/
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
Text Domain: customize-author-role
*/
// this code runs only during plugin activation and never again
function sal_customize_author_role() {
require_once plugin_dir_path( __FILE__ ).'includes/class-sal-customize-author-role.php';
Sal_Customize_Author_Role::activate();
}
register_activation_hook( __FILE__, 'sal_customize_author_role' );Hierna definieer ik de Sal_Customize_Author_Role class binnen het bestand class-sal-customize-author-role.php. Ik refereer aan beide resources in het pluginbestand hierboven.
<?php
class Sal_Customize_Author_Role {
public static function activate() {
// get the Editor role's object from WP_Role class
$author = get_role( 'author' );
// remove the capability to delete published posts from an Author role
$author->remove_cap( 'delete_published_posts' );
}
}De functie remove_cap('delete_published_posts') zal het recht om gepubliceerde artikelen te verwijderen weghalen bij de Author rol.
Tijd om de bestanden van de plugin op te slaan en de plugin te activeren. Nu loggen we in het op Author dashboard op de veranderingen te zien.
De Trash optie is niet langer zichtbaar voor gepubliceerde artikelen. Maar ze kunnen wel nog altijd niet-gepubliceerde artikelen met de status Draft of Pending verwijderen.
Wil je zelfs deze mogelijkheid verwijderen, dan moet je ook de delete_posts capability verwijderen bij de rol van Author.
Toevoegen of verwijderen van rechten voor specifieke gebruikers
Wil je rechten toevoegen voor een specifieke gebruiker (dus niet voor alle gebruikers met een bepaalde rol), dan kun je hiervoor de WP_User::add_cap() class functie voor gebruiken.
// get the user object by their ID
$user = new WP_User( $user_id );
// add the capability to the specific user
$user->add_cap( $cap );Je kan de get_user_by() functie gebruiken om het ID van een gebruiker te vinden via hun emailadres, inlognaam of slug.
Op ongeveer dezelfde manier haal je rechten bij een specifieke gebruiker weg via de WP_User::remove_cap() class functie.
// get the user object by their ID
$user = new WP_User( $user_id );
// add the capability to the specific user
$user->add_cap( $cap );Net als eerder worden deze functies alleen uitgevoerd bij het activeren van een plugin of thema.
Let op: Zowel add_cap() als remove_cap() zijn object methods van de WP_Role class. Je kan ze dus niet direct oproepen in je code. Je moet er toegang toe krijgen via de get_role() functie of de $wp_roles global variabele.
Dupliceren van een gebruikersrol
Je kan een nieuwe gebruikersrol maken door alle rechten van een reeds bestaande gebruikersrol te klonen. Dat doe je zo:
add_role( 'clone', 'Clone', get_role( 'administrator' )->capabilities );In het voorbeeld hierboven maak ik een nieuwe rol met de naam Clone die dezelfde rechten heeft als een Administrator. Door deze code alleen uit te voeren bij het activeren van een thema of plugin zorgen we ervoor dat deze nieuwe rol maar één keer wordt toegevoegd.
Zo maak je aangepaste gebruikersrollen binnen WordPress
Het aanpassen van de rechten van standaard gebruikersrollen is een snelle manier om ze beter bij jouw site te laten passen. Maar als je van plan bent veel rechten van een rol aan te passen, kun je beter een complete nieuwe custom rol maken. Op die manier kan je precies de rechten toewijzen die je voor de nieuwe rol wil.
Om een custom gebruikersrol te maken, kun je de add_role() functie gebruiken. Deze accepteert drie parameters.
add_role( $role, $display_name, $capabilities );De eerste twee parameters moeten strings zijn en zijn vereist. Deze definiëren respectievelijk de naam van de nieuwe rol en de display name. De laatste parameter is optioneel en is een array. Deze kan je gebruiken om alle specifieke rechten toe te wijzen aan de rol.
Laten we een custom gebruikersrol maken met de naam Community Manager, die reacties kan modereren en artikelen kan bewerken. Dat doe je zo:
<?php
/*
Plugin Name: Add Community Manager Role
Version: 1.0
Description: Add a Custom User Role called 'Community Manager'
Author: Salman Ravoof
Author URI: https://www.salmanravoof.com/
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
Text Domain: add-community-manager-role
*/
// this code will run only once on plugin activation and never again
function add_community_manager_role() {
add_role(
'community_manager',
__('Community Manager', 'add-community-manager-role'),
array(
'read' => true,
'moderate_comments' => true,
'edit_posts' => true,
'edit_other_posts' => true,
'edit_published_posts' => true
)
);
}
register_activation_hook( __FILE__, 'add_community_manager_role' );Net zoals eerder wordt de add_role() functie slechts uitgevoerd bij het activeren van de plugin, en daarna nooit weer. Sla het bestand op en activeer de plugin binnen je Administrator dashboard. Je zou nu de Community Manager rol moeten kunnen toewijzen aan zowel nieuwe als bestaande gebruikers.
Je kan ook de rechten die deze nieuwe rol heeft controleren door de waarde van het wp_user_roles veld te controleren binnen de wp_options tabel in je database. Dit vond ik in mijn database:
array (
'administrator' =>
// [...]
'editor' =>
// [...]
'author' =>
// [...]
'contributor' =>
// [...]
'subscriber' =>
// [...]
'community_manager' =>
array (
'name' => 'Community Manager',
'capabilities' =>
array (
'read' => true,
'moderate_comments' => true,
'edit_posts' => true,
'edit_other_posts' => true,
'edit_published_posts' => true,
),
),
) Helemaal aan het einde staat de nieuwe rol die we net hebben toegevoegd, met alle rechten van de rol. Je kan deze rol nog verder bewerken door rechten toe te voegen of te verwijderen.
Testen van een nieuwe gebruikersrol
Voordat je de nieuwe gebruikersrol toewijst aan een echte gebruiker, is het verstandig te testen of alles goed werkt. Je kan daarbij deze checklist gebruiken om alles te testen:
- Maak een nieuwe testaccount en wijs de nieuwe gebruikersrol aan dit account toe.
- Log in met de testgebruiker en controleer dat alle rechten werken zoals bedoeld. Heb je bijvoorbeeld het recht om gepubliceerde artikelen te bewerken toegekend aan de rol, ga dan naar een gepubliceerd artikel en controleer of je het kan bewerken. Hoe meer rechten je hebt toegekend, hoe meer je dus ook moet testen.
- Ga vervolgens binnen je browser direct naar een higher-level admin link. Ik heb dit getest door direct naar het venster voor de WordPress Settings te gaan, en zoals de bedoeling is geeft WordPress me geen toegang.
De melding ‘access denied’ bij WordPress - Verwijder de testgebruiker na het testen.
En dat is het wel zo’n beetje. Nu kan je de nieuwe rol toewijzen aan gebruikers op je site.
Je kan de plugins User Switch of View Admin As gebruiker om sneller tussen gebruikers te wisselen. Dit is superhandig bij het testen van de rechten van verschillende gebruikers(rollen). Ik bespreek ze uitgebreid verderop in dit artikel.
Aanmaken van custom gebruikersrollen in WordPress Multisite
WordPress Multisite gaat wat anders om met gebruikersrollen dan single-sites. Alhoewel je nog altijd de add_role() functie kan gebruiken om een eigen gebruikersrol toe te voegen zoals we dat eerder ook deden, zal deze nieuwe rol dan alleen op de primaire site van het netwerk werken (de eerste site die je gemaakt hebt). Het zal dus niet toegevoegd worden aan alle subsites binnen het netwerk.
Om ervoor te zorgen dat de code binnen je callback functie op elke site in je netwerk uitgevoerd wordt, moet je de uitvoering herhalen voor elke site binnen het netwerk door een ‘loop’. In dit voorbeeld maak ik een nieuwe gebruikersrol die Plugin Manager heet, die het recht zal hebben om plugins te beheren.
<?php
/*
Plugin Name: Add Plugin Manager Role
Version: 1.0
Description: Add a custom user role named Plugin Manager in a WordPress Multisite Installation
Author: Salman Ravoof
Author URI: https://www.salmanravoof.com/
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
Text Domain: add-plugin-manager-role
*/
/*
make the code run on every site in the network
when the plugin is Network Activated
*/
function add_plugin_manager_role( $network_wide ) {
if ( is_multisite() && $network_wide ) {
// run the code for all sites in a Multisite network
foreach ( get_sites(['fields'=>'ids']) as $blog_id ) {
switch_to_blog( $blog_id );
add_role(
'plugin_manager',
__('Plugin Manager', 'add-plugin-manager-role'),
array(
'install_plugins' => true,
'activate_plugins' => true,
'edit_plugins' => true,
'delete_plugins' => true
)
);
}
restore_current_blog();
}
else {
add_role(
'plugin_manager',
__('Plugin Manager', 'add-plugin-manager-role'),
array(
'install_plugins' => true,
'activate_plugins' => true,
'edit_plugins' => true,
'delete_plugins' => true
)
);
}
}
register_activation_hook( __FILE__, 'add_plugin_manager_role' );Laten we de bovenstaande code even doornemen:
- Eerst hook je aan de action voor het activeren van de plugin via de
register_activation_hook()functie en voer je die in bij je callback functie. Hier is de callback functieadd_plugin_manager_role(). - Vervolgens definieer je de callback functie en voer je één argument in dat
$network_wideheet. - De parameter
$network_wideis een booleaanse waarde die optruestaat als je de plugin voor het hele netwerk hebt geactiveerd. Is het alleen ingeschakeld voor de huidige site dan geeft dezefalseterug. Dit is dus alleen van toepassing voor Multisites en de standaardwaarde staat daarom opfalse. - De voorwaarde
is_multisite() && $network_widecontroleert of de plugin voor het hele netwerk is geactiveerd binnen de Multisite via een ‘Network Activate’. Is dat zo, dustrue, dan wordt de code in hetIfstatement uitgevoerd. Is dat niet zo, dusfalsedan wordt de code in hetelsestatement uitgevoerd. - De functie
get_sites(['fields'=>'ids'])geeft een lijst met alle site ID’s in het netwerk. Via deforeach()PHP functie wordt er een ‘loop’ gemaakt om de code op elke individuele site in het netwerk uit te voeren. - De functie switch_to_blog( $blog_id ) zorgt ervoor dat de volgende regels code uitgevoerd worden voor de subsite met ID
$blog_id. Aangezien WordPress ooit begonnen is als blogplatform, kan je het woord ‘blog’ beter lezen als ‘site’ om het wat logischer te maken. - Daarna gebruik je de functie
add_role()om een custom gebruikersrol te maken met de gewenste rechten. Hierbij gebruik je min of meer dezelfde code als dat we eerder in dit artikel al bespraken. - Voordat je de ‘loop’ beëindigd, moet je de restore_current_blog() functie definiëren om ervoor te zorgen dat je de veranderde site terugzet in de originele staat.
- De code in het
elsestatement is om ervoor te zorgen dat de plugin geen problemen veroorzaakt in een single-site installatie.
Sla het bestand op en ga naar Network Admin > Plugins en gebruik ‘Network Activate’ voor je custom plugin. Daarna ga je naar het tabblad Users binnen het Edit Site scherm van één van je sites om te zien of de nieuwe rol van Plugin Manager nu inderdaad beschikbaar is.
Ik heb ook gecontroleerd dat de nieuwe gebruikersrol beschikbaar is op de andere subsites. Het werkt perfect.
Je kan de nieuwe gebruikersrol en de bijbehorende rechten verifiëren door in de database van je site te kijken. Maar anders dan bij single-site installaties maakt WordPress Multisite een aparte wp_options tabel aan voor elke subsite.
Je kan de tabellen per subsite vinden als wp_2_options, wp_3_options, en wp_4_options. Volgens dezelfde methode vind je de rollen en rechten in de respectievelijke velden onder wp_2_user_roles, wp_3_user_roles, en wp_4_user_roles.
Je hebt gedefinieerd hoe je een custom gebruikersrol kan maken voor alle sites binnen je netwerk, maar wat kun je met sites die je in de toekomst gaat toevoegen? Om ervoor te zorgen dat deze custom gebruikersrol wordt toegevoegd aan elke nieuwe site binnen je netwerk, kan je de volgende code toevoegen aan de plugin:
// run the code once again when a new site is created
function add_custom_user_role_new_site( $blog_id ) {
// check whether the plugin is active for the network
if ( is_plugin_active_for_network( 'add-custom-user-role/add-custom-user-role.php' ) ) {
switch_to_blog( $blog_id );
add_role(
'plugin_manager',
__('Plugin Manager', 'add-plugin-manager-role'),
array(
'install_plugins' => true,
'activate_plugins' => true,
'edit_plugins' => true,
'delete_plugins' => true
)
);
restore_current_blog();
}
}
add_action( 'wpmu_new_blog', 'add_custom_user_role_new_site' );- De action wpmu_new_blog wordt geactiveerd wanneer iemand een nieuwe site maakt in een Multisite netwerk. Je kan aan deze action hooken met je callback functie om de custom gebruikersrol toe te voegen.
- De is_plugin_active_for_network() functie controleert of de plugin actief is op het hele netwerk en retourneert een booleaanse waarde. Het accepteert het bestandspad van de plugin als argument
- De rest van de code lijkt sterk op wat we eerder al gebruikten. Je kan naar de nieuwe site gaan via de
$blog_idparameter, je eigen custom rol maken via deadd_role()functie en teruggaan naar de huidige site via derestore_current_blog()functie.
Zo verwijder je gebruikersrollen bij WordPress
Je kan gebruikersrollen verwijderen bij WordPress via de functie remove_role(). Het accepteert één argument, namelijk de naam van de rol. Zo kan je de Contributor rol verwijderen door de volgende code ergens in je site uit te voeren:
remove_role( 'contributor' );Anders dan bij de functie add_role() die de database aldoor blijft bewerken, tenzij je het aan de activering van een plugin of thema koppelt, wordt de remove_role() functie alleen uitgevoerd wanneer de gebruikersrol daadwerkelijk bestaat, Aangezien de rol die je opgegeven hebt verwijderd wordt bij de eerste uitvoering, maakt het niet uit waar je deze functie uitvoert.
Maar om in de toekomst conflicten te voorkomen, kun je het beste de code verwijderen nadat de gebruikersrol verwijderd is uit de database.
Zo maak je speciale gebruiksrechten binnen WordPress
Het bewerken van bestaande gebruikersrollen en maken van nieuwe custom rollen via de ingebouwde gebruiksrechten van WordPress is genoeg voor de meeste use-cases. Toch zijn er ook situaties waarbij je nieuwe rechten wilt definiëren, bijvoorbeeld bij features die ontstaan door het toevoegen van custom code (via een plugin of thema).
Je kan deze speciale rechten gebruiken om nieuwe rollen te definiëren of ze toevoegen aan al bestaande gebruikersrollen.
Zo voegt WooCommerce bijvoorbeeld rechten en rollen toe voor gebruikers, die samengaan met hun uitgebreide ecommerce features. WooCommerce voegt onder meer de volgende rechten toe:
- Toestaan van beheren van WooCommerce instellingen
- Maken en bewerken van producten
- Bekijken van WooCommerce rapportages
Aan de hand van deze rechten worden twee nieuwe gebruikersrollen toegevoegd: Customer en Shop Manager.
De rol van Customer lijkt eigenlijk altijd heel sterk op die van Subscriber, behalve dat de Customer rol ook de informatie in hun eigen account kunnen aanpassen en huidige of oude bestellingen kunnen bekijken. De rol van Shop Manager bevat alle rechten die de Editor ook heeft, en daarnaast ook alle rechten die met WooCommerce samenhangen.
Andere plugins introduceren ook speciale rechten of rollen, zoals The Events Calendar, Visual Portfolio, WPML en WP ERP.
Wanneer je goed kijkt in de documentatie van deze plugins, zul je zien dat ze haast altijd hun speciale gebruiksrechten meteen verbinden aan de aangepaste berichttypes die ze ook zelf definiëren. In het geval van WooCommerce geldt dit voor de aangepaste berichttypes Products en Orders, en bij de andere plugins zijn dit onder meer Events, Portfolios, Translations en Customers .
Laten we kijken hoe je custom gebruiksrechten kunt maken die aan een aangepast berichttype zijn verbonden.
Allereerst maak je een plugin, en registreer je het aangepast berichttype dat je wilt hebben. In het voorbeeld hieronder registreer ik een aangepast berichttype met de naam Stories.
<?php
/*
Plugin Name: Custom Post Type and Capabilities
Version: 1.0
Description: Register a custom post type and define custom capabilities tied into it.
Author: Salman Ravoof
Author URI: https://www.salmanravoof.com/
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
Text Domain: custom-post-type-capabilities
*/
// register a custom post type, in this case it's called "story" //
function cpt_story_init() {
$labels = array(
'name' => _x( 'Stories', 'custom-post-type-capabilities' ),
'singular_name' => _x( 'Story', 'custom-post-type-capabilities' ),
'menu_name' => _x( 'Stories', 'Admin Menu text', 'custom-post-type-capabilities' ),
'name_admin_bar' => _x( 'Story', 'Add New on Toolbar', 'custom-post-type-capabilities' ),
'add_new' => __( 'Add New', 'custom-post-type-capabilities' ),
'add_new_item' => __( 'Add New Story', 'custom-post-type-capabilities' ),
'new_item' => __( 'New Story', 'custom-post-type-capabilities' ),
'edit_item' => __( 'Edit Story', 'custom-post-type-capabilities' ),
'view_item' => __( 'View Story', 'custom-post-type-capabilities' ),
'all_items' => __( 'All Stories', 'custom-post-type-capabilities' ),
'search_items' => __( 'Search Stories', 'custom-post-type-capabilities' ),
'parent_item_colon' => __( 'Parent Stories:', 'custom-post-type-capabilities' ),
'not_found' => __( 'No stories found.', 'custom-post-type-capabilities' ),
'not_found_in_trash' => __( 'No stories found in Trash.', 'custom-post-type-capabilities' ),
'featured_image' => _x( 'Story Cover Image', 'custom-post-type-capabilities' ),
'set_featured_image' => _x( 'Set cover image', 'custom-post-type-capabilities' ),
'remove_featured_image' => _x( 'Remove cover image', 'custom-post-type-capabilities' ),
'use_featured_image' => _x( 'Use as cover image', 'custom-post-type-capabilities' ),
'archives' => _x( 'Story archives', 'custom-post-type-capabilities' ),
'insert_into_item' => _x( 'Insert into story', 'custom-post-type-capabilities' ),
'uploaded_to_this_item' => _x( 'Uploaded to this story', 'custom-post-type-capabilities' ),
'filter_items_list' => _x( 'Filter stories list', 'custom-post-type-capabilities' ),
'items_list_navigation' => _x( 'Stories list navigation', 'custom-post-type-capabilities' ),
'items_list' => _x( 'Stories list', 'custom-post-type-capabilities' ),
);
$args = array(
'labels' => $labels,
'public' => true,
'menu_icon' => 'dashicons-book',
'publicly_queryable' => true,
'show_ui' => true,
'show_in_menu' => true,
'query_var' => true,
'rewrite' => array( 'slug' => 'story' ),
'capability_type' => array ( 'story', 'stories' ),
'map_meta_cap' => true,
'has_archive' => true,
'hierarchical' => false,
'menu_position' => 6,
'supports' => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' ),
'show_in_rest' => true,
);
register_post_type( 'story', $args );
}
add_action( 'init', 'cpt_story_init' );We bekijken het script hierboven per element:
- Gebruik de functie register_post_type() om je aangepast berichttype te registreren. Je kan de
initaction als hook gebruiken om deze functie uit te voeren. - De functie
register_post_type()kan twee argumenten gebruiken. Het eerste argument is de naam van het aangepast berichttype en het tweede is een array met alle argumenten voor het registreren van het berichttype. - De
$argsvariabele bevat alle argumenten die je doorgeeft aan deregister_post_type()functie. Eén van de argumenten (‘labels’) is zelf ook weer een array die apart gedefinieerd wordt als de$labelvariabele. - Let op het
'capability_type' => 'post'argument. Dit is het standaard rechtentype dat WordPress gebruikt voor de rechten van het lezen, bewerken en verwijderen van het aangepast berichttype. - Om je eigen custom rechten te maken, moet je de waarde van het
capability_typeargument vervangen door de naam die je je eigen custom capability’s wilt geven. Dit kan zowel een string als een array zijn. De array is vooral handig als het (Engelse) meervoud van je custom rechten niet het standaard achtervoegsel s krijgen (dus bijvoorbeeld story/stories ipv book/books). - Je kan het
capabilitiesargument ook gebruiken om de nieuwe rechten een andere naam te geven dan WordPress automatisch zou doen. - Je moet de custom rechten wel mappen op de primitieve of primaire rechten van WordPress. Zet het
map_meta_capargument optruezodat WordPress weet dat het de custom rechten moeten mappen zoals jij het wil.
Daarna kun je de custom rechten toevoegen aan de rollen die je toegang wil geven aan het aangepast berichttype Stories. In dit voorbeeld geef ik de rollen van Administrator en Editor die rechten.
// add the custom capabilities to the desired user roles
$roles = array( 'editor','administrator' );
foreach( $roles as $the_role ) {
$role = get_role($the_role);
$role->add_cap( 'read' );
$role->add_cap( 'read_story');
$role->add_cap( 'read_private_stories' );
$role->add_cap( 'edit_story' );
$role->add_cap( 'edit_stories' );
$role->add_cap( 'edit_others_stories' );
$role->add_cap( 'edit_published_stories' );
$role->add_cap( 'publish_stories' );
$role->add_cap( 'delete_others_stories' );
$role->add_cap( 'delete_private_stories' );
$role->add_cap( 'delete_published_stories' );
}Sla het bestand op en activeer de plugin. Je zou nu de link voor Stories moeten zien in je dashboard van de Administrator of de Editor.
Wanneer je de rechten bekijkt die je kunt gebruiken binnen je site, zul je ook alle rechten zien die betrekking hebben op de ‘Stories’, zoals we die hebben toegevoegd. Hier gebruik ik de plugin View Admin As om de rechten te controleren.
Je kan de uitgebreidere versie van deze plugin downloaden via deze Gist. Het registreert een apart berichttype dat Projects heeft met een set custom rechten. Vervolgens worden die toegewezen aan twee custom rollen, namelijk Students en Teachers om je te helpen een educatieve website te bouwen.
Er is ook een manier om custom rechten te definiëren waarmee gebruikers toegang krijgen tot de instellingen van je plugin, afhankelijk van hun rol. Deze manier gaat echter wat te ver voor dit artikel, maar kijk eens naar deze informatieve thread op StackExchange voor meer informatie.
De beste plugins voor WordPress gebruikersrollen en rechten
Het kunnen bewerken van gebruikersrollen en rechten via code is natuurlijk prachtig, maar niet voor iedereen weggelegd. Er zijn een hoop dingen die mis kunnen gaan als je niet precies weet wat je doet. Maar goed begrijpen hoe rechten en rollen werken binnen WordPress helpt een hoop, zelfs als je ‘slechts’ een plugin gebruikt om dit te implementeren.
We bekijken enkele van de populairste WordPress plugins voor het eenvoudig aanpassen van de gebruikersrollen en rechten binnen WordPress. Ik zal ook enkele handige plugins noemen waarmee je features die betrekking hebben op rollen en rechten snel kunt testen.
User Role Editor (door Vladimir Garagulia)
User Role Editor is de populairste plugin in de WordPress pluginbibliotheek voor het beheren van gebruikersrollen en rechten. Je krijgt een eenvoudige interface waarmee je rechten en rollen met een enkele klik kunt bewerken.
Na het installeren en activeren van de plugin, kun je binnen je admin dashboard naar Users > User Role Editor gaan om de interface te vinden.
Hier is een gedetailleerd overzicht van de dashboarden hierboven:
- Selecteer de rol die je wilt aanpassen in het dropdown-menu. Hierbij krijg je alle rollen te zien die momenteel bestaan binnen je database. Je kan ook kiezen om de rechten weer te geven in een beter leesbaar format in plaats van de constanten. Een andere optie geeft de oudere rechten weer die niet langer ondersteund worden in de laatste versie van WordPress.
- User Role Editor groepeert alle rechten in specifieke categorieën aan de linkerkant. De categorie ‘Core’ bevat alle ingebouwde rechten. Aangezien ik op deze website ook WooCommerce heb geïnstalleerd zie je ook de rechten voor aangepast berichttypes. De User Role Editor plugin zelf voegt ook een set met speciale rechten toe.
- Rechts zie je een lijst van alle rechten. Aangezien ik de groep All heb geselecteerd, zie ik alle rechten. Maar je kan dit ook filteren door op een groep te klikken aan de linkerkant. Verder kan je de optie Granted Only aanvinken om alle ongebruikte rechten te verbergen.
- Hier kun je ook de opties Add Role, Rename Role, Add Capability, en Delete Role gebruiken. Helemaal onderaan zie je een extra optie Hide admin bar waarmee je de adminbalk voor die gebruikersrol verbergt.
Om een gebruikersrol aan te passen kun je de rechten die je wilt toevoegen of verwijderen aanklikken en vervolgens op de knop Update drukken om je bewerkingen op te slaan. Simpel genoeg dus.
Door te klikken op Add Role voeg je een nieuwe gebruikersrol toe. Je kan zelf een helemaal nieuwe rol samenstellen, of een bestaande rol kopiëren door op de optie Make copy of te klikken.
Je kan de Role Display Name veranderen door op de knop Rename Role te klikken. Maar je kan niet de Role ID (of Role Name) veranderen. Je kan dit omzeilen door de rol waarvan je het ID wilt wijzigen te kopiëren en vervolgens de originele rol verwijderen.
Je kan nieuwe rechten toevoegen door op de knop Add Capability te klikken.
Door op de knop Delete Roles te klikken verwijder je custom rollen die je niet hebt toegewezen aan gebruikers.
Let op: User Role Editor staat het niet toe dat je ingebouwde rollen of rechten van WordPress verwijdert. Ook kun je geen custom rollen verwijderen die toegewezen zijn aan een gebruiker, of custom rechten als ze zijn toegewezen aan een rol anders dan de Admin rol.
Je zult zien dat de knop Delete Capability alleen verschijnt als een gebruiksrecht niet is toegewezen aan (non-admin) rollen. Anders zal het verborgen zijn.
Je kan verschillende rollen toewijzen aan een gebruiker, of ze juist helemaal geen rol toewijzen.
Om een gebruiker meerdere rollen te geven ga je naar het panel Users in je dashboard, waar je klikt op Capabilities, wat je zult zien wanneer je de muis boven een gebruikersnaam laat zweven.
Als je naar Settings > User Role Editor gaat binnen je admin dashboard, zul je nog extra opties vinden voor de User Role Editor plugin.
Hier kun je de standaardinstellingen van de plugin wijzigen, extra modules installeren, de standaardrol die nieuwe gebruikers krijgen toegewezen veranderen, en zelfs de rechten en rollen terugzetten naar de standaardwaarden.
Alhoewel de gratis versie van User Role Editor meer dan genoeg is voor de meeste use cases, bevat de premium versie extra features, waaronder ondersteuning voor het beheren van rollen en rechten in een WordPress Multisite netwerk.
Members van MemberPress
Members is een plugin voor het beheren van gebruikersrollen en rechten met een focus op ledenwebsites, zoals de naam al doet vermoeden. Het is ooit gestart als eenvoudige plugin voor het beheren van rechten en rollen, maar is daarna veel meer gaan focussen op features rondom lidmaatschappen.
Na het installeren en activeren van de plugin kun je alle beschikbare rollen binnen je site bekijken door binnen je dashboard naar Members > Roles te gaan.
Members maakt het mogelijk om alle rollen te verwijderen, inclusief de ingebouwde WordPress rollen, behalve de Administrator en de Default rollen. Je kan ook rollen bewerken met Edit of klonen met Clone, en je kan een lijst maken met alle gebruikers die momenteel aan een bepaalde rol zijn toegewezen.
Binnen het panel Edit Role, kan je specifieke rechten toewijzen of verwijderen bij een specifieke rol door de relevante vakjes aan of uit te vinken. Je kan hier ook een custom capability toevoegen aan een rol.
Door op de link Add New Role te klikken ga je naar een scherm waar je nieuwe rollen kan maken door een naam, ID en set met rechten toe te wijzen.
Net als bij User Role Editor, kan je Members gebruiken om gebruikers meerdere rollen toe te wijzen. Je kan ook de contentpermissies instellen om de toegang tot content te beperken tot alleen gebruikers met een specifieke rol.
Hiermee maak je de website en de feed privé. Daarnaast kan je de toegang tot de REST API afschermen door inloggen te verplichten.
Members onderscheidt zichzelf van andere plugins voor rechten en rollen door de geweldige add-ons. Hiermee kun je een lading extra features aan je website toevoegen, zoals privacy voor gebruikers en persoonlijk datamanagement (GDPR), rechten toevoegen voor tags en categorieën, een hiërarchie voor rollen vaststellen, en nog meer.
Je kan Members perfect laten integreren met diverse populaire WordPress plugins. Zo kan je custom rechten maken en beheren voor de Advanced Custom Fields (ACF) plugin. Verder integreert het met bijvoorbeeld Easy Digital Downloads, GiveWP, Meta Box en WooCommerce.
De add-ons van Members die zich richten op leden (Payments, Subscriptions, Email Marketing, en Advanced Content Protection) zijn alleen beschikbaar in de premium versie.
WPFront User Role Editor
WPFront User Role Editor helpt je bij het maken, bewerken en verwijderen van gebruikersrollen en rechten binnen je WordPress website. De features lijken verder sterk op de andere plugin, op twee features na.
Nadat je WPFront User Role Editor hebt geïnstalleerd en geactiveerd, kun je binnen je admin dashboard naar Users > Assign / Migrate gaan en daar alle gebruikers die een bepaalde rol hebben toegewezen gekregen migreren naar een andere rol. Je kan zelfs secundaire rollen toewijzen aan je gebruikers.
Deze feature is dus erg handig wanneer je de gebruikers rol van veel gebruikers binnen je website moet veranderen.
Een andere handige feature van WPFront User Role Editor is de rolgebaseerde Login Redirect. Hiermee kun je bijvoorbeeld alle gebruikers met de Editor rol automatisch doorsturen naar de pagina Posts nadat ze inloggen. Je hebt ook de mogelijkheid om ze de toegang tot /wp-admin te ontzeggen en ervoor te zorgen dat ze de toolbar aan de front-end niet zien.
Advanced Access Manager
Advanced Access Manager(AAM) is een krachtige WordPress plugin waarmee je bijna elk aspect van je website kunt controleren. Het bevat meer dan 200 verschillende features en is ontworpen voor gevorderde WordPress gebruikers die goed begrijpen hoe rollen en rechten werken.
Vergeleken met de plugins hierboven heeft AAM veel meer features. Maar doordat het wel echt gericht is op developers, is het wat lastige voor beginners om deze plugin te gebruiken.
Je kan het dashboard van AAM in vier hoofdgebieden opdelen. Ik heb ze hierboven genummerd, met een overzichtje hieronder.
- Het bovenste gebied geeft aan welke ‘subject’ momenteel behandeld wordt. In dit geval is dat Role: Administrator, maar dit kan een specifieke gebruiker zijn, een anonieme bezoeker, of een standaardinstellingen voor iedereen.
- Het deel onder het onderwerp is het belangrijkste gebied, waar alle instellingen te vinden zijn voor het beheren van de verschillende zaken op je website.
- Het derde gebied is de Users/Roles Manager. Via de tabbladen kun je selecteren wat je wil bewerken. Is dat een gebruikersrol, een specifieke gebruiker, een anonieme gebruiker of standaardtoegang voor iedereen?
- Met het vierde deel kun je de instellingen van AAM zelf beheren, premium add-ons toevoegen, of contact opnemen met de ondersteuning.
AAM organiseert de instellingen in 5 groepen op basis van gedrag en gebruik.
- De instellingen voor Services laten alle modules van AAM zien die je kunt in- of uitschakelen. Door alleen de modules te laden die je nodig hebt, kun je je website wat lichter houden.
- In het gebied Core Settings kun je een aantal kernfeatures van zowel AAM als WordPress in- of uitschakelen.
- De Content Settings gaan over de content van je site (dus artikelen, pagina’s, custom artikeltypen, etc).
- Het stuk Security Settings bevat instellingen voor het veilig inloggen bij AAM. Op het moment van schrijven zijn er slechts twee instellingen mogelijk: Brute Force Lockout en One Session Per User.
- ConfigPress is een interessante feature waarmee je de configuratie van de AAM plugin kunt wijzigen via INI code.
AAM is een plugin gericht op developers, en gaat verder dan alleen het beheren van gebruikersrollen en rechten. Het geeft je tot in de details controle over wat elke rol wel of niet kan doen op je website.
Je kan AAM gebruiken om een Access & Security Policy uit te rollen op je website. Dit toegangsbeleid definieert onder welke voorwaarden welke rol bij de verschillende resources van je website kan. Als je dit direct wil toepassen, kan je een kant-en-klaar toegangsbeleid installeren vanaf de AAM Access Policy Hub.
Met AAM kan je tijdelijke accounts en rollen maken. Dit is een veilige manier om je account te delen met externe bronnen. Tijdelijke gebruikersaccounts verdwijnen na de ingestelde datum. Bij tijdelijke rollen zal de gebruiker de rol kwijtraken na de ingestelde datum.
Om alle features van AAM in dit artikel te behandelen gaat te ver. Je kan het beste de documentatie van Advanced Access Manager bekijken om al hun features te zien.
Tip: User Access Manager is een goed alternatief voor Advanced Access Manager, alhoewel het wel minder features heeft en minder vaak bijgewerkt wordt.
User Switching
User Switching maakt het mogelijk om tussen verschillende WordPress gebruikersaccounts te wisselen met een enkele klik op de knop. Als je allerlei rollen en rechten aan het testen bent, maakt deze plugin je leven een stuk makkelijker. User Switching gebruikt het ingebouwde cookie-verificatiesysteem van WordPress om de accounts op te slaan waar je vandaan geswitcht bent, zodat je makkelijk weer terug kunt.
Na het installeren en activeren van de plugins ga je naar het Users menu in je dashboard. Daar zul je bij elke gebruiker een Switch To link zien. Door hierop te klikken ga je meteen naar de gewenste gebruiker.
Je kan teruggaan naar je originele account door op de link Switch back to te klikken in je dashboard of in je gebruikersprofiel.
Je kan ook je Administrator account tijdelijk uitzetten via Switch Off om te zien hoe de front-end van je website eruitziet voor bezoekers.
Als beveiligingsmaatregel kunnen alleen gebruikers die het recht hebben om andere gebruikers te bewerken van account wisselen. Standaard hebben alleen Administrators dit recht binnen een WordPress single-site, terwijl op een Multisite netwerk alleen Super Admins dit kunnen doen.
Om het switchen tussen gebruikers nog makkelijker te maken, kan je de Admin Bar User Switching extensie installeren waardoor de Switch to User link weergegeven wordt in je adminbalk.
View Admin As
View Admin As is een geavanceerde plugin voor het wisselen van gebruikersaccounts, waarmee je ook rollen en rechten kunt beheren. Anders dan bij de User Switch plugin hoef je geen aparte extensie te installeren om direct vanuit je adminbalk te kunnen wisselen van gebruiker. De View Admin As plugin voegt alle belangrijkste menu-items standaard toe aan de adminbalk.
Je kan tussen bestaande gebruikers of rollen switchen, zelfs als er geen gebruikers bestaan met die rollen. Door op de link Site visitor te klikken zul je naar de front-end van je website gaan als bezoeker, zodat je de functionaliteit van je website kunt testen.
View Admin As maakt het ook mogelijk om tijdelijk je eigen rechten te wijzigen. Doordat dit niet-destructief gedaan wordt, zul je niet definitief de toegang tot je belangrijkste rechten verliezen.
Na het switchen naar een gebruikersaccount kun je hun instellingen voor weergave veranderen, direct vanuit het menu. Je kan ook de taal of locatie wijzigen voor de front-end, onafhankelijk van de back-end.
Je kan meerdere typen weergave gebruiken door de verschillende opties te combineren en allemaal tegelijk toe te passen.
View Admin As biedt twee optionele modules die je kan inschakelen indien nodig.
De eerste module voegt de feature Role Defaults toe waarmee je de standaardweergave voor alle rollen kan instellen. Je kan deze standaard toepassen op een rol, een individuele gebruiker, of toekomstige nieuwe gebruikers.
De tweede module maakt de Role Manager functie mogelijk. Alle veranderingen die je via deze module doorvoert aan de rollen en rechten zijn permanent. Anders dan bij andere plugins voor rolbeheer, kan je via deze module een rol verwijderen die is toegewezen aan een gebruiker, doordat de plugin ze automatisch migreert naar een andere rol.
Je kan meer lezen over alle features in de documentatie van View Admin As.
MyKinsta gebruikersrollen
De multi-user feature van MyKinsta maakt het mogelijk om diverse gebruikers te maken en beheren binnen hetzelfde account door ze toegang te geven tot unieke aspecten van je Kinsta account, of specifieke websites van dat Kinsta account.
Er zijn verschillende rollen waarvan je de precieze toegang kan instellen.
De eerste gebruiker krijgt standaard de Company Owner rol. Dit is de krachtigste rol en heeft ook alle rechten die de Company Administrator heeft.
Er kan slechts één Company Owner zijn, maar je kan de rol wel overzetten naar een andere Company Administrator indien nodig. Door dit te doen zet je ook het eigendom van het Kinsta account over naar de nieuwe Company Owner.
Alleen de Company Owner kan een verzoek naar Kinsta sturen om het account te verwijderen.
Je kan de andere rollen opsplitsen in twee hoofdcategorieën.
- Company Level
- Site Level
Rollen op het niveau van het bedrijf (Company Level) geven gebruikers toegang tot de gegevens van het bedrijf in het Kinsta account, terwijl rollen op het site-niveau (Site Level) gebruikers alleen toegang geeft tot specifieke websites. Wanneer je een nieuwe gebruik wil uitnodigen of een bestaande gebruiker wil aanpassen, zul je eerst moeten kiezen of je ze toegang wil geven voor specifieke websites of voor alle websites van het bedrijf.
Company Level rollen
Company Administrator
De Company Administrator rol geeft het hoogste toegangsniveau in MyKinsta. Hiermee heeft de gebruiker de volledige controle over het Kinsta account en alle sites. Deze rol moet je dus alleen geven aan gebruikers die je volledig vertrouwt.
Company Developer
De Company Developer rol geeft toegang tot het beheren van alles websites, waaronder dus ook het verwijderen van sites. Aangezien gebruikersrollen binnen Kinsta hiërarchisch zijn, kan een Company Developer ook gebruikers op het niveau van de site beheren. Maar een Company Developer heeft geen toegang tot instellingen voor het hele bedrijf of tot factuurgegevens.
Company Billing
De Company Billing rol geeft alleen toegang tot gegevens over de facturatie en bedrijfsinstellingen. Deze rol heeft dus geen toegang tot sites. Gebruikers met de Company Billing rol kunnen facturen controleren, e-mails voor automatisch incasso inschakelen en bedrijfsgegevens wijzigen, zoals adres of contactgegevens.
Site Level rollen
Site Administrator
De Site Administrator rol heeft volledige toegang tot een specifieke website, inclusief alle omgevingen die bij die site horen. Maar ze kunnen een website niet verwijderen uit het bedrijfsaccount. Je kan dezelfde gebruiker Site Administrator maken voor meerdere websites.
Site Developer
De Site Developer heeft alleen toegang tot de testomgeving van de aan hun toegewezen website. Ze kunnen alles doen binnen de testomgeving, maar ze kunnen de testomgeving niet verwijderen en ook geen veranderingen live maken. Net als bij Site Administrators kun je één gebruiker Site Developer maken voor meerdere sites.
Je zal ook zien dat Site Developers geen toegang hebben tot analytics, gebruikersbeheer en de activity log features binnen het MyKinsta dashboard.
MyKinsta gebruikersrollen vs WordPress gebruikersrollen
Er is geen overlap tussen gebruikersrollen bij MyKinsta en gebruikersrollen van WordPress. Je kan ze volledig onafhankelijk van elkaar gebruiken.
De verschillende gebruikersrollen binnen MyKinsta helpen de eigenaar van een Kinsta account bij het beheren van een team van managers, developers en accountants. Het maakt het supermakkelijk voor webdevelopmentbureaus om alle websites van hun klanten te beheren vanuit één krachtig dashboard.
Samenvatting
WordPress gebruikersrollen en rechten zijn fundamentele concepten voor het beheren van de toegang van gebruikers. Ze helpen je te beheren welke acties alle gebruikers op je site kunnen uitvoeren. Ze worden ook veel gebruikt door plugins en thema’s om handige features toe te voegen aan de WordPress kern.
WordPress heeft een eigen set rollen en rechten, maar als je meer flexibiliteit nodig hebt, kan je die zelf bewerken of eigen rollen en rechten aanmaken. Dit doe je via je eigen code of een externe plugin.
Wil je echt goed worden met WordPress, dan is het begrijpen van rechten en rollen en hoe je die beheert een belangrijke stap. Begin er vandaag nog mee!
Salman Ravoof is een autodidactische webdeveloper, schrijver, creator en een groot bewonderaar van Free and Open Source Software (FOSS). Naast techniek is hij enthousiast over wetenschap, filosofie, fotografie, kunst, katten en eten. Lees meer over hem op zijn website en kom in contact met Salman op X.
Laat een reactie achter