WordPress gebruikersrollen en rechten: wat elke rol daadwerkelijk kan

Scope en versies. Dit artikel beschrijft het WordPress-rollen- en capabilitysysteem zoals dat werkt in WordPress 5.5 en nieuwer, gecheckt tegen de huidige Roles and Capabilities-pagina uit de officiële documentatie (laatst herzien in september 2024) en de developer reference voor get_role() en de WP_Roles-klasse. De lijst met ingebouwde capabilities is al jaren stabiel, maar WooCommerce en andere plugins brengen hun eigen capabilities mee en worden apart benoemd.

Eerst even de logica, want die is belangrijker dan de tabel. WordPress geeft geen rechten rechtstreeks aan gebruikers. Het kent capabilities toe aan rollen, wijst rollen toe aan gebruikers en checkt capabilities tijdens elk request met current_user_can() en user_can(). Rollen zijn gewoon een handig bundeltje. Capabilities zijn wat echt telt. Zodra je die scheiding snapt, is de rest van dit artikel vooral een naslag.

De zes ingebouwde rollen en hun capability-tabel

WordPress levert vijf rollen op een single-site installatie en voegt een zesde toe op Multisite. De tabel hieronder bevat de volledige set primitieve capabilities, gegroepeerd vanaf de laagste rol die ze heeft. "ja" betekent dat de rol de capability standaard bezit, "nee" betekent niet en "(single)" betekent dat de capability wel aanwezig is bij Administrators op een single-site installatie maar op Multisite alleen bij Super Admin.

Eén capability ontbreekt bewust bij elke rol: unfiltered_upload. Die wordt standaard aan niemand toegekend, zelfs Super Admin niet. Je krijgt hem pas als je define( 'ALLOW_UNFILTERED_UPLOADS', true ); in wp-config.php zet, en zelfs dan alleen voor Administrators op single-site of Super Admins op Multisite. Dat is meteen ook de reden waarom WordPress SVG-uploads out of the box weigert.

Super Admin (alleen Multisite)

Super Admin is technisch gezien geen rol in de databasezin. Het is een aparte vlag die bewaard wordt in de site_admins-netwerkoptie, niet een rij in de user_roles-optie. Op een single-site installatie bestaat Super Admin simpelweg niet. Administrators op single-site vervullen daar dezelfde functie.

Op Multisite is Super Admin het enige type gebruiker dat het netwerk zelf kan beheren. Dat betekent subsites aanmaken, bewerken of verwijderen, plugins en themes netwerk-breed installeren of updaten, netwerk-gebruikers beheren en de netwerkopties aanpassen. Site-Administrators op een subsite houden controle over hun eigen posts, pages, categorieën en subsite-instellingen, maar verliezen de mogelijkheid om plugins of themes te installeren, gebruikers te verwijderen of theme- en plugin-bestanden te bewerken. Die capabilities schuiven omhoog naar Super Admin.

De praktische vuistregel op Multisite: een Administrator runt een site. Een Super Admin runt het netwerk. Draai je single-site? Dan kun je Super Admin verder negeren.

Van Subscriber tot Administrator: waar elke rol eigenlijk voor is

De tabel is precies maar abstract. Hieronder wat de rollen in de praktijk doen, van laag naar hoog, met de beslissingen die ze mogelijk maken.

Subscriber

Een Subscriber heeft precies één capability: read. Dat is genoeg om in te loggen, de admin bar te zien en het eigen profiel te bewerken. Hij kan niet schrijven, niet uploaden, geen reacties modereren en ziet verder niks zinvols in het dashboard. Subscriber is er voor membership-achtige sites waar front-end toegang het enige is wat een gebruiker nodig heeft: paywalled content, leden-downloads of een forum waar de forum-plugin zelf de toegangscontrole doet. Gebruik je zo'n patroon niet? Dan is Subscriber gewoon de juiste default voor nieuwe aanmeldingen, en is Settings > General > New User Default Role op Subscriber laten staan de veiligste keuze.

Contributor

Een Contributor heeft edit_posts en delete_posts erbij, bovenop Subscriber. Dat betekent drafts schrijven en opslaan, maar specifiek geen publish_posts en geen upload_files. Met andere woorden: een Contributor mag een post schrijven maar niet publiceren en kan geen eigen afbeeldingen toevoegen. Drafts gaan naar "In afwachting van review" en een Editor of Administrator moet ze goedkeuren. Zodra hun eigen post live staat, verliezen ze ook het recht om hem nog te bewerken, want edit_published_posts ontbreekt.

Dat maakt Contributor de juiste rol voor gastbloggers, externe reviewers of situaties waar een redactionele poort niet-onderhandelbaar is. Het is de verkeerde rol voor iemand die je vertrouwt om zonder review te publiceren, want dan ben je de hele week bezig met "Publiceren" klikken op drafts.

Author

Een Author is een Contributor plus publish_posts, edit_published_posts, delete_published_posts en upload_files. Een Author kan eigen posts schrijven, publiceren, herzien en offline halen. Hij kan ook media uploaden naar de library. Hij kan niet aan andermans posts komen, kan geen pages maken of bewerken, kan geen categorieën beheren en kan geen reacties modereren.

De beperking waar mensen steevast tegenaan lopen: een Author kan out of the box niet aan specifieke categorieën worden vastgeklikt. Er is geen core capability die zegt "deze gebruiker mag alleen in Nieuws publiceren, niet in Reviews". Authors mogen elke bestaande categorie aan hun eigen posts hangen, en Editors mogen nieuwe categorieën vrijelijk aanmaken. Wil je die beperking toch? Dan heb je een plugin nodig: PublishPress Permissions is de krachtigste optie, en Members dekt eenvoudiger gevallen. Hetzelfde geldt trouwens voor taxonomie-beperkingen op Editors; het core capabilitysysteem modelleert dat gewoon niet.

Editor

Een Editor is de eerste rol met echte redactionele macht. Hij kan elke post en page bewerken, publiceren en verwijderen, categorieën en links beheren, reacties modereren en privé-posts zien. Hij kan geen plugins installeren, themes wisselen, bestanden bewerken, site-instellingen wijzigen of gebruikers beheren. Op single-site heeft hij ook unfiltered_html, wat betekent dat hij rauwe <script>- en <iframe>-markup in postcontent mag opslaan. Op Multisite wordt unfiltered_html beperkt tot Super Admin alleen, en dat is een bewuste veiligheidsgrens: een Editor op één subsite zou geen willekeurige JavaScript moeten kunnen injecteren op een netwerk dat hij niet bezit.

Editor is dus de juiste rol voor iemand die de content-kant van de site runt maar niet de site zelf mag slopen. Mentaal model: "content lead".

Administrator

Een Administrator heeft de volledige set single-site capabilities: plugins, themes en core installeren en updaten, theme- en plugin-bestanden bewerken via de dashboard-editor, gebruikers aanmaken en verwijderen en elke instelling aanpassen. Op single-site is Administrator het hoogste privilege-niveau. Op Multisite verliest Administrator install_plugins, install_themes, update_core, delete_users, create_users, edit_users, edit_plugins, edit_themes en edit_files. Die schuiven allemaal omhoog naar Super Admin.

Er is een hardnekkig misverstand dat het waard is om recht te zetten: Administrator geeft geen servertoegang. De WordPress Administrator-rol stuurt uitsluitend de WordPress-applicatielaag. Hij geeft geen SSH, geen SFTP, geen toegang tot het filesystem. De prompt "WordPress has to access your web server" die je soms ziet bij updates komt voort uit bestandseigenaar en OS-permissies, niet uit WordPress-rollen.

De nuance is wel dat single-site Administrators edit_plugins en edit_themes hebben, wat betekent dat ze PHP-bestanden kunnen bewerken via de Theme- en Plugin File Editor in het dashboard. Dat is een code-execution-route binnen de WordPress-laag. Het is geen shell-toegang op de server, maar wel genoeg om willekeurige PHP uit te voeren. Op elke geharde installatie die ik draai zet ik define( 'DISALLOW_FILE_EDIT', true ); in wp-config.php, wat de editor-schermen en de onderliggende capabilities volledig verwijdert. Die aanpassing hoort bij elke WordPress-installatie die ik opzet en komt uitgebreider aan bod in mijn WordPress security hardening checklist.

WooCommerce Customer en Shop Manager

WooCommerce voegt twee rollen toe bovenop de vijf core-rollen. Ze volgen hetzelfde capabilitymodel, ze voegen alleen WooCommerce-specifieke capabilities toe. Gecheckt tegen de WooCommerce roles and capabilities documentation.

Customer is een Subscriber met accountcontext. Vanuit core gezien heeft de rol read en verder niks, maar WooCommerce herkent hem als de rol die automatisch wordt toegekend aan iedereen die zich registreert bij het afrekenen. Een Customer kan zijn eigen bestelgeschiedenis zien en zijn factuur- en verzendgegevens aanpassen op de Mijn Account-pagina. Andermans bestellingen ziet hij niet en backend-instellingen komt hij ook niet binnen.

Shop Manager is de rol die WooCommerce specifiek heeft ontworpen zodat winkelpersoneel niet per se Administrator hoeft te zijn. Hij heeft de volledige Editor-capability-set plus manage_woocommerce (wat de WooCommerce-instellingen, productbeheer en bestelafhandeling ontgrendelt) en view_woocommerce_reports. Hij heeft geen install_plugins, geen update_core en geen gebruikersbeheer-capabilities die Administrator wel heeft. Een Shop Manager kan de winkel van A tot Z draaien, bestellingen verwerken, producten bewerken en rapportages trekken, maar kan geen nieuwe betaal-plugin installeren en geen algemene WordPress-instelling aanraken. Dit is dus de juiste rol voor een winkelmanager of customer-service lead; Administrator is eigenlijk altijd te veel.

Gebruikers toevoegen, wijzigen en overdragen

Een gebruiker toevoegen gaat op single-site rechtstreeks via Gebruikers > Nieuwe toevoegen. Je vult een gebruikersnaam, e-mail en rol in, en WordPress schrijft de rij in wp_users en zet de capabilities in wp_usermeta onder de wp_capabilities-meta key. De rol wordt daar opgeslagen als geserialiseerde array van rol-slugs, en dat is precies de reden dat een gebruiker in principe meer dan één rol tegelijk kan dragen (core wijst er maar één toe, maar WP_User::add_role() en sommige plugins gebruiken dit wel).

Op Multisite verandert de flow. Een site-Administrator kan geen create_users op het netwerk, alleen add_users op zijn eigen subsite vanuit de pool van gebruikers die al op het netwerk bestaan. Bestaat de gebruiker nog niet? Dan kan alleen een Super Admin hem aanmaken. Dat is een bewuste integriteitsregel voor het hele netwerk, want een gebruiker kan lid zijn van meerdere subsites en één subsite-admin moet geen globale identiteit kunnen aanmaken.

De rol van een gebruiker wijzigen via Gebruikers > Alle gebruikers werkt wp_capabilities in wp_usermeta meteen bij. Een demotie is bij de volgende pagina-load actief. Iemand promoveren naar Administrator op single-site is vanuit de ontvanger gezien in feite onomkeerbaar: zodra hij die rol heeft, kan hij iedereens rol wijzigen, inclusief die van de persoon die hem net promoveerde. Neem promoties dus serieus.

Deletion-gedrag: admin UI vs wp_delete_user vs WP-CLI

Gebruikers verwijderen is waar het meeste onbedoelde dataverlies in WordPress ontstaat, want het gedrag verschilt tussen de admin UI, de functie wp_delete_user(), en WP-CLI. De defaults zijn niet gelijk tussen die drie, en aannemen dat ze dat wel zijn is een snelle manier om posts te wissen die je had willen behouden.

Via de admin UI (Gebruikers > Verwijderen). WordPress presenteert altijd een keuze: alle content van de gebruiker verwijderen, of alle content toewijzen aan een andere gebruiker. Er is geen stille default. De admin moet expliciet één van de twee kiezen. Dit is de veilige route voor handmatig werk.

Via wp_delete_user( $user_id, $reassign ) in PHP. De tweede parameter heeft null als default. Laat je hem weg of geef je null mee, dan wordt elke post van die gebruiker verwijderd samen met de gebruiker zelf. Geef je een geldig gebruikers-ID mee, dan wordt het auteurschap overgedragen aan die gebruiker. Dit is dus de valkuil: een half afgeschreven opschoonscript dat wp_delete_user( $id ) aanroept zonder reassign-argument wist stilletjes content. Geef altijd een expliciet reassign-ID mee, tenzij je echt verwijdering wil.

Via wp user delete <id> op WP-CLI. Dezelfde regel als de PHP-functie. Zonder --reassign=<user_id> worden posts verwijderd. Met --reassign=<user_id> worden ze overgedragen. Ik schrijf WP-CLI-deletes altijd met --reassign vooraan en het ID erachter, zodat de intentie gewoon zichtbaar is op de regel: wp user delete 42 --reassign=1.

Multisite voegt nog een regel toe. Op Multisite is delete_users beperkt tot Super Admin alleen. Site-Administrators op een subsite kunnen helemaal geen gebruikers verwijderen van het netwerk. Ze kunnen alleen remove_users, wat de gebruiker losmaakt van hun subsite zonder het onderliggende account aan te raken. Dat is bewust zo: een gebruiker kan bij meerdere subsites horen, en één subsite-admin mag hem niet van het hele netwerk kunnen vegen.

Mijn vaste patroon op elk project: voor ik een gebruiker verwijder, open ik het Gebruikers-scherm, sorteer op "Berichten", controleer het aantal en beslis expliciet of content overgedragen of weggegooid moet worden. Bij programmatic cleanup draag ik altijd over aan een generieke "Archief"-gebruiker in plaats van weg te gooien. Content uit een backup terughalen is lastig; een overgedragen auteur later corrigeren is makkelijk.

Wanneer je eigen rollen wil maken, en hoe

Eigen rollen zijn op hun plek wanneer de ingebouwde vijf het werk niet dekken én wanneer dat werk zich blijft herhalen. Een eenmalige capability-uitbreiding voor één gebruiker hoort op de gebruiker, niet in een nieuwe rol. Hieronder de twee typische gevallen.

Kleine, herhaalbare aanpassingen: een code snippet met add_role()

Heb je een rol nodig die "Editor min de mogelijkheid om gepubliceerde pages te verwijderen" is? Dan is een kort PHP-snippet genoeg. Dat draait eenmalig bij plugin-activatie en schrijft naar de user_roles-optie in wp_options.

// Zet dit in een mu-plugin, een kleine custom plugin of een site-
// specifieke plugin. NIET in functions.php: themes wisselen, en
// rollen zijn persistente database state die het thema moet overleven.
function myproject_register_content_manager_role() {
    // Zorg dat de rol niet bij elk request opnieuw wordt aangemaakt.
    // add_role() geeft null terug als de rol al bestaat.
    if ( null === get_role( 'content_manager' ) ) {
        add_role(
            'content_manager',
            'Content Manager',
            array(
                // De nuttige stukken van Editor overnemen...
                'read'                   => true,
                'edit_posts'             => true,
                'edit_others_posts'      => true,
                'edit_published_posts'   => true,
                'publish_posts'          => true,
                'delete_posts'           => true,
                'delete_others_posts'    => true,
                'upload_files'           => true,
                'moderate_comments'      => true,
                'manage_categories'      => true,
                // ...maar bewust geen page-capabilities en geen
                // unfiltered_html, want dat zou betekenen dat deze
                // rol willekeurige HTML in posts mag zetten.
            )
        );
    }
}
register_activation_hook( __FILE__, 'myproject_register_content_manager_role' );

// Bijbehorende cleanup: rol verwijderen bij plugin-deactivatie om de
// database schoon te houden. Zet betrokken gebruikers eerst op een
// fallback-rol terug.
function myproject_remove_content_manager_role() {
    remove_role( 'content_manager' );
}
register_deactivation_hook( __FILE__, 'myproject_remove_content_manager_role' );

Twee dingen die hier belangrijk zijn. Eén: de get_role()-guard. add_role() schrijft naar wp_options als de rol nog niet bestaat; hem bij elk request aanroepen is zonde en geeft op multi-server setups met object caching op de options-tabel soms subtiele race conditions. Twee: de activation hook. Rollen zijn persistente database state, geen runtime-configuratie. Registreer je een rol ongeguard in functions.php, dan schrijf je bij elk request naar de database, en als je ooit dat theme weggooit zonder op te ruimen, blijft de rol voor altijd in de database staan zonder dat er nog code naar verwijst.

Om een bestaande rol vanuit code aan te passen, gebruik je add_cap() en remove_cap() op een WP_Role-object. Die schrijven ook direct naar de database, dus behandel ze hetzelfde: eenmalig draaien, met een versie-check eromheen, en altijd met een terugweg.

// Geef de Editor-rol het recht om algemene site-instellingen te wijzigen.
// Dit is agressief; in productie zou ik dit bijna nooit doen.
$role = get_role( 'editor' );
if ( $role && ! $role->has_cap( 'manage_options' ) ) {
    $role->add_cap( 'manage_options' );
}

Overrides per gebruiker werken met WP_User::add_cap() en WP_User::remove_cap(). Die schrijven naar wp_usermeta op de specifieke gebruiker, niet naar de rol, en dat is het juiste gereedschap als één persoon een eenmalige capability nodig heeft die niet op een gedeelde rol hoort.

Grotere klussen: Members en PublishPress Permissions

Als de custom-rol-behoefte eruitziet als "zes interne rollen, elk met een eigen dashboard", dan is een code snippet niet meer te onderhouden. Twee plugins domineren hier.

Members van MemberPress is de rechttoe rechtaan rol-editor. In versie 3.2.19 (februari 2026) heeft hij een UI voor rollen aanmaken, klonen en bewerken, ondersteunt hij meerdere rollen per gebruiker, kun je capabilities naast toekennen ook expliciet ontzeggen en regelt hij contentrechten op post- en blockniveau. Alle voorheen betaalde add-ons zitten er nu gratis bij. Ongeveer 300.000 actieve installaties, getest tegen WordPress 6.9.4. Members is de juiste keuze als de klus is "maak een nieuwe rol met deze capabilities" en het ingebouwde dashboard voldoende is.

PublishPress Permissions (voorheen Press Permit Core) is een ander soort gereedschap. In versie 4.8.0 (6 april 2026) gaat hij verder dan rechten op rolniveau en modelleert hij toegangscontrole per post, per categorie en per term. Dit is de plugin die je pakt zodra de vraag is "deze Editor mag alleen in de categorie 'Nieuws' publiceren, en deze Author mag alleen posts bewerken met tag 'Europa'". Core WordPress kan dat niet uitdrukken; PublishPress Permissions wel, met een rules engine die bovenop het capabilitysysteem zit. Ongeveer 10.000 actieve installaties, wat kleiner is dan Members omdat het probleem dat hij oplost minder vaak voorkomt.

Mijn vuistregel: begin bij Members. Is het daarna nog lastig? Dan heb je PublishPress Permissions nodig. Is het nóg lastig? Dan probeer je waarschijnlijk een workflow engine te bouwen en kun je beter naar PublishPress Pro of een aparte redactietool kijken. Een klein bedrijf met één WordPress-site komt eigenlijk nooit voorbij de eerste bullet.

Custom post types en map_meta_cap

Custom post types zijn waar het capabilitysysteem stil-lelijk wordt. Registreer je een CPT met register_post_type() en zet je capability_type op bijvoorbeeld 'book', dan genereert WordPress automatisch een set capabilitynamen zoals edit_book, read_book, edit_books, edit_others_books, publish_books en read_private_books. Standaard krijgt geen enkele rol die capabilities. De CPT bestaat wel, maar niemand kan hem vanuit het dashboard bewerken.

Er zijn twee dingen die je bijna altijd naast capability_type moet zetten:

• map_meta_cap => true. Hiermee vertelt WordPress dat map_meta_cap() gebruikt moet worden om per-object-checks ("mag deze gebruiker dit specifieke boek bewerken?") te vertalen naar primitieve capability-checks ("heeft deze gebruiker edit_others_books?"). Zonder dit kan zelfs de Administrator-rol CPT-posts niet bewerken zonder dat de capabilities handmatig zijn toegekend, want WordPress zal de meta-capability-vertaling niet uitvoeren. map_meta_cap => true zetten is dus eigenlijk altijd wat je wil.
• Een blok add_cap()-aanroepen die de primitieve capabilities toekennen aan de rollen die de CPT mogen gebruiken. Zonder dit bestaat de rol-definitie "Editor mag boeken bewerken" niet en verschijnt het dashboardmenu ook niet voor die rol.

// Minimale primitieve-capability-grant voor een "book"-CPT, eenmalig
// uitgevoerd bij plugin-activatie naast de register_post_type()-aanroep.
function myproject_grant_book_caps_to_editor() {
    $role = get_role( 'editor' );
    if ( ! $role ) {
        return;
    }
    $role->add_cap( 'edit_books' );
    $role->add_cap( 'edit_others_books' );
    $role->add_cap( 'edit_published_books' );
    $role->add_cap( 'publish_books' );
    $role->add_cap( 'delete_books' );
    $role->add_cap( 'delete_others_books' );
    $role->add_cap( 'delete_published_books' );
    $role->add_cap( 'read_private_books' );
}
register_activation_hook( __FILE__, 'myproject_grant_book_caps_to_editor' );

Het klassieke faalscenario: iemand registreert een CPT, zet capability_type => 'book', vergeet map_meta_cap => true en zit dan een middag te puzzelen waarom het Administrator-account het "Boeken"-menu niet ziet. De oplossing is ofwel map_meta_cap op true zetten, ofwel elke primitieve capability handmatig aan de Administrator-rol toekennen, en die eerste optie is bijna altijd de juiste.

Application Passwords beperken je rechten niet

Application Passwords zijn in WordPress 5.6 (december 2020) toegevoegd als manier voor externe applicaties om te authenticeren tegen de REST API zonder het echte wachtwoord van de gebruiker op te slaan. Ze worden per gebruiker gegenereerd vanuit het Edit User-profielscherm en kunnen alleen voor machine-to-machine-authenticatie worden gebruikt; wp-login.php weigert ze expliciet. Dat deel is een serieuze security-verbetering.

Wat niet klopt, ook al wordt het vaak aangenomen: Application Passwords beperken geen capabilities. Een token dat door een Administrator-account is aangemaakt, heeft volledige Administrator-rechten op de REST API. Er is geen ingebouwde "alleen-lezen" scope, geen per-endpoint-scope, geen "mag alleen posts bewerken" scope. Per-scope application passwords zijn wel besproken als core-verbetering, maar zijn tot en met WordPress 6.x nooit daadwerkelijk geleverd. Heb je een token met minder rechten nodig? Dan maak je een aparte gebruiker met een lagere rol en genereer je het wachtwoord op die gebruiker, of je beperkt beschikbaarheid met het filter wp_is_application_passwords_available_for_user, wat alleen toestaat of verbiedt, niet scoping.

De praktische regel: behandel een Application Password precies alsof je iemand de volledige rol van de onderliggende gebruiker geeft. Is de gebruiker een Administrator, dan kan dat token alles wat een Administrator kan. Heb je een beperkt token nodig? Maak dan eerst een beperkte gebruiker.

Least privilege is waar het allemaal om draait

Het capabilitysysteem bestaat zodat je elke gebruiker precies de macht geeft die hij nodig heeft en verder niks. In de praktijk komt dat neer op drie gewoontes.

Ken de laagste rol toe die werkt. Een schrijver die drafts maakt en review nodig heeft is een Contributor, niet een Author. Een content lead die de redactionele kalender draait is een Editor, niet een Administrator. Een winkelmanager op WooCommerce is een Shop Manager, niet een Administrator. De regel "bij twijfel één rol lager en capabilities bijgeven als het nodig is" is bijna altijd veiliger dan "begin bij Administrator en vertrouw iedereen".

Houd Administrators zeldzaam en controleer ze. Elke Administrator op een productiesite is een potentiële volledige compromittering. Ik loop de Administrator-lijst op elke site minstens per kwartaal na en haal iedereen eruit die het niet actief nodig heeft. Voor noodtoegang is er niet voor niks DISALLOW_FILE_EDIT; de dashboard file editor eruit halen neemt meteen het handigste gereedschap weg dat een gecompromitteerde Administrator in handen heeft.

Draag over voordat je verwijdert. Of je het nu vanuit de admin UI, vanuit PHP of vanuit WP-CLI doet: wijs geschreven content altijd aan een andere gebruiker toe voordat je een account weggooit. De enige uitzondering is als je de content daadwerkelijk kwijt wil, en dan moet je dat bewust beslissen en niet via een default laten gebeuren. Wil je begrijpen welke toegangsfouten verschijnen wanneer rechten niet kloppen? Het artikel sorry, you are not allowed to access this page loopt de capability-checks door die die foutmelding genereren en laat zien hoe je traceert welke capability precies ontbreekt.