Sorry, you are not allowed to access this page in WordPress oplossen

Je logt in op WordPress, het formulier accepteert je wachtwoord, de dashboard-URL laadt en in plaats van een scherm zie je een vrijwel lege pagina met één regel tekst: Sorry, you are not allowed to access this page. De login werkte. Iets anders heeft je een fractie van een seconde later afgewezen.

Wat deze melding eigenlijk betekent

De tekst komt uit wp_die(), aangeroepen door een admin-scherm nadat current_user_can() false teruggaf voor de capability die dat scherm vereist. WordPress zegt niet dat het je niet kent. Het zegt dat het je kent, je rol heeft opgezocht, die rol heeft uitgewerkt naar een set capabilities, en dat jouw account de capability die voor deze URL nodig is gewoon niet heeft. Het mechanisme is bewust zo gebouwd en staat in de officiële WordPress roles and capabilities reference: elk admin-scherm heeft een vereiste capability en elk account heeft een rol die die wel of niet bevat.

Even in gewone taal: je account mocht door de voordeur, de plattegrond is gecheckt, en de deur naar de kamer waar je naartoe wilde is voor jou de verkeerde kamer. De site is niet stuk. De capability-check doet precies waar hij voor gemaakt is, en daarom is dit ook een ander probleem dan "ik kan niet inloggen": de login-pipeline is geslaagd, de cookies zijn aangekomen, WordPress weet wie je bent, en de blokkade zit één stap verder, bij de capability-check.

Hoe het WordPress-capability-systeem echt werkt

WordPress scheidt twee dingen die er van buitenaf hetzelfde uitzien, maar van binnen heel anders werken: rollen en capabilities. De officiële roles and capabilities reference is de canonieke beschrijving, en de grove vorm kennen is wat de rest van dit artikel logisch maakt.

Een rol is een label dat aan een gebruikersaccount hangt: administrator, editor, author, contributor, subscriber, plus super_admin op multisite. WordPress levert standaard zes vooraf gedefinieerde rollen en laat plugins er meer registreren. De rol op zichzelf doet bijna niets.

Een capability is de eenheid waar de applicatie daadwerkelijk op checkt. Namen als manage_options, activate_plugins, edit_others_posts en read zijn capabilities. Elk admin-scherm, elke REST endpoint en elke beveiligde actie verklaart welke capability nodig is, en WordPress beslist of het serveert door simpelweg te vragen: heeft deze gebruiker deze capability, ja of nee? De koppeling van rol naar capability-set staat in de database, in de optie <prefix>user_roles, en op elke gebruiker in de <prefix>capabilities-rij van wp_usermeta.

Als code current_user_can('manage_options') aanroept, vraagt WordPress dus niet "is deze gebruiker een administrator". Het vraagt "heeft deze gebruiker, los van zijn label, deze specifieke capability". De officiële documentatie is daar expliciet over: rechtstreeks op rollen checken "is discouraged as it may produce unreliable results", omdat twee accounts met dezelfde rol verschillende capabilities kunnen hebben zodra een plugin eraan heeft gezeten. Een subscriber kan door een plugin manage_options toegekend krijgen en meteen het Settings-scherm bereiken. Een administrator kan manage_options kwijtraken en het meteen niet meer kunnen openen.

Die ontkoppeling is de hele reden dat de melding bestaat als een eigen reactie. WordPress hoeft niet te weten wáárom een capability mist om het verzoek te weigeren. Het weigert, zegt het, en stopt. Expliciet weigeren is auditbaar: een stille redirect zou er identiek uitzien als een sessie-bug en je urenlang op het verkeerde been zetten, en precies daarom bestaat het artikel geen toegang tot wp-admin zonder foutmelding voor de stille variant van dit probleem.

Wat deze melding NIET is

Dit is het routeringsblok dat de meeste verspilde diagnose-tijd voorkomt.

• Het is geen login-fout. Je bent ingelogd. De login-pipeline is netjes afgerond, je wachtwoord is geaccepteerd en de cookies zijn uitgegeven. Waren je credentials fout geweest, dan had je wp-admin/ nooit bereikt. Voor login-fouten met zichtbare error-tekst begin je bij waarom je niet kunt inloggen op WordPress.
• Het is geen 403 Forbidden. Een 403 is een weigering door de webserver, en die gebeurt vóórdat WordPress draait. De Sorry, you are not allowed to access this page-melding wordt door WordPress zelf gegenereerd, nadat het is geladen en je heeft herkend. De mechanismen zijn totaal verschillend en de oplossingen ook. Geeft het dashboard of de login-URL een 403 terug van de server zonder WordPress-branding? Lees 403 Forbidden op wp-admin.
• Het is geen wachtwoordprobleem. De capability-check draait lang nadat de wachtwoordcheck is gedaan. Was je wachtwoord fout geweest, dan had het inlogformulier je geweigerd. Op het moment dat je deze tekst kunt zien, heeft de wachtwoordlaag je allang goedgekeurd.
• Het is geen cookie- of sessieprobleem. Een kapotte cookie of sessie stuurt je terug naar het inlogscherm zónder melding. Dat is de stille variant uit geen toegang tot wp-admin zonder foutmelding. De capability-melding betekent juist dat de cookies wél zijn aangekomen, dat WordPress ze heeft gebruikt om je account te laden, en dat het scherm pas dáárna is geweigerd.
• Het is geen WordPress-bug. De fout is het systeem zoals het bedoeld is. De bug, áls er een is, zit in de roldefinitie, in de plugin die hem heeft herschreven, in de migratie die de lookup heeft kapotgemaakt, of in de cache-laag die je de verkeerde sessie heeft gegeven. Dat zijn de vijf oorzaken die hieronder aan bod komen.

Veelvoorkomende oorzaken, op volgorde van waarschijnlijkheid

Vijf mechanismen verklaren bijna elke instantie van deze melding op een WordPress 6.7 site. De volgorde hieronder is wat ik in de praktijk het vaakst zie.

1. Je gebruikersrol is gedegradeerd of de capability is verwijderd. Een staging-sync, een teruggezette database-backup, of een handmatige aanpassing heeft je account van administrator naar een lagere rol gezet, of de specifieke capability weggehaald die het scherm nodig heeft. WordPress accepteert je wachtwoord prima en weigert daarna het scherm.
2. Een plugin heeft je rol bij activatie herschreven. Membership-, LMS- en custom-role plugins roepen add_role() en remove_cap() aan tijdens activatie en updates. Een verkeerde upgrade of een misgeconfigureerde plugin kan de administrator-rol zelf herschrijven, waardoor elke admin op de site capabilities kwijtraakt.
3. De table prefix in wp-config.php komt niet overeen met de prefix op de databasetabellen. WordPress leest rollen uit de optie <prefix>user_roles en capabilities uit <prefix>capabilities in wp_usermeta. Na een migratie waarbij prefixes wijzigen, geeft de lookup niets terug en heeft je account effectief geen capabilities meer. Het mechanisme staat in de WP_Roles class reference.
4. De auth-cookie wordt aan het verkeerde account geserveerd. Een page cache of een reverse proxy die niet variëert op de wordpress_logged_in_[hash] cookie kan je een gecachet admin-scherm geven dat hoort bij iemand met een lagere rol, en je daarna midden in het verzoek doorsturen naar een scherm dat je echte account niet mag zien.
5. Een thema of plugin roept current_user_can() aan tegen een capability die niet meer bestaat. Een custom capability is verwijderd (vaak door een plugin-update), maar een andere plugin checkt er nog wel op het scherm dat je bezoekt. De check geeft false terug en WordPress beëindigt het verzoek.

Diagnose: bepalen welke oorzaak het is

Loop deze checks op volgorde af. Ze zijn niet-destructief en je weet zo welke oorzaak het is voordat je iets aanraakt.

Check 1: bevestig dat de melding uit WordPress zelf komt. Open de falende URL en kijk goed naar de pagina. Zie je Sorry, you are not allowed to access this page. op het WordPress-foutscherm (witte achtergrond, simpele tekst, geen branding van een hostingpartij), dan heeft het verzoek PHP bereikt. Zie je in plaats daarvan een Cloudflare-, Sucuri- of Wordfence-blokpagina, dan heeft de laag voor WordPress je tegengehouden en zit je in 403 Forbidden op wp-admin. Je weet dat het werkt als: je kunt vaststellen dat de pagina het WordPress wp_die()-scherm is en geen blokpagina van een derde partij.

Check 2: lees je rol uit wp_usermeta. Open phpMyAdmin (of een andere database-client) en draai:

-- Vervang wp_ door je werkelijke table prefix als die afwijkt
SELECT user_id, meta_value
FROM wp_usermeta
WHERE meta_key = 'wp_capabilities'
  AND user_id = 1;

Een werkende administrator levert de geserialiseerde string a:1:{s:13:"administrator";s:1:"1";} op. Iets anders (een lagere rol, een lege array, of helemaal geen rij) is je antwoord voor oorzaak 1. Je weet dat het werkt als: je de exacte meta_value voor je account kunt overtypen.

Check 3: bevestig dat de table prefix klopt. Open wp-config.php in de bestandsbeheerder van je hostingpaneel (of download het bestand via SFTP) en lees de regel met $table_prefix. Kijk vervolgens in phpMyAdmin naar de werkelijke tabelnamen. De prefix in het bestand moet exact overeenkomen met de prefix op de tabellen, inclusief hoofdletters. Staat er in wp-config.php wp_ maar heten de tabellen wpx7_users en wpx7_usermeta, dan is dat oorzaak 3 en geeft de role-lookup voor elke gebruiker niets terug. Je weet dat het werkt als: de waarde van $table_prefix en de tabelnamen in de database met dezelfde tekens beginnen.

Check 4: probeer een privévenster met een verse login. Open een incognitovenster, log opnieuw in en bezoek het falende scherm. Verdwijnt de melding, dan kreeg je een gecachete reactie die voor een ander account was opgeslagen, of een verlopen sessie. Dat is oorzaak 4. Is de melding identiek vanuit een verse sessie, dan zit de oorzaak in WordPress zelf en niet in de cache-laag. Je weet dat het werkt als: je kunt zeggen "het privévenster werkt" of "de fout is in elk venster hetzelfde".

Check 5: deactiveer plugins via het bestandssysteem. Hernoem via de bestandsbeheerder van je hostingpaneel (of een SFTP-client) wp-content/plugins naar wp-content/plugins_off, log in en bezoek het falende scherm. Verdwijnt de melding, dan zit de oorzaak in een plugin. Hernoem de map terug en activeer plugins één voor één weer vanuit het dashboard tot de melding terugkomt. Dit is de enige veilige manier om oorzaak 2 en oorzaak 5 te testen zonder admin-toegang. Je weet dat het werkt als: je de specifieke plugin kunt aanwijzen die bij activatie de fout reproduceert.

Oplossingen, per oorzaak

Oorzaak 1: zet de rol op het getroffen account terug

Heeft Check 2 de verkeerde waarde laten zien, schrijf dan de juiste terug. Bewerk in phpMyAdmin de rij en zet meta_value op:

a:1:{s:13:"administrator";s:1:"1";}

Heb je liever de command line en draait WP-CLI, dan is het één commando:

wp user set-role <user_id> administrator

Bestaat de rij in wp_usermeta voor jouw account helemaal niet, maak hem dan opnieuw aan. Voeg een rij toe met user_id op je gebruikers-ID, meta_key op wp_capabilities en meta_value op de geserialiseerde string hierboven. Voeg dan een tweede rij toe met meta_key op wp_user_level en meta_value op 10, het oude admin-level dat sommige plugins nog verwachten.

Verificatie: log uit, log weer in en laad het scherm dat de fout gaf. Het werkt als het dashboard normaal rendert en current_user_can('manage_options') voor je account true zou teruggeven.

Oorzaak 2: bouw de roldefinities opnieuw op

Als een plugin de administrator-rol zelf heeft herschreven, is één gebruiker fixen niet genoeg: de roldefinitie moet hersteld worden.

Hernoem via de bestandsbeheerder van je hostingpaneel (of een SFTP-client) de map van de boosdoener-plugin onder wp-content/plugins om hem te deactiveren. Log daarna in en open Tools > Site Health. De dashboard-load dwingt WordPress de roldefinities opnieuw te checken. Mist de administrator-rol helemaal, dan kun je hem opnieuw aanmaken met de standaardset capabilities die op de WordPress.org roles and capabilities reference staat.

WP-CLI-alternatief: heb je SSH-toegang, dan kan het in één commando:

wp role reset administrator

Verificatie: elke administrator op de site kan het falende scherm bezoeken zonder de melding, niet alleen jij.

Oorzaak 3: trek de table prefix recht

Heeft Check 3 een mismatch gevonden, kies dan of je de prefix in het bestand aanpast of de tabellen hernoemt. Het bestand aanpassen is veiliger als je weet dat de tabellen kloppen (bijvoorbeeld na een migratie waarbij je de database met een andere prefix hebt gekopieerd). Open wp-config.php in de bestandsbeheerder van je hostingpaneel (of download het via SFTP) en pas de prefix-regel aan:

$table_prefix = 'wpx7_';

De underscore aan het einde is verplicht en de waarde moet exact overeenkomen. Verder hoef je aan WordPress-kant niets te doen: WordPress leest de prefix op elk verzoek uit wp-config.php en bouwt de optienaam dynamisch op.

Zijn de tabellen verkeerd, hernoem ze dan in plaats daarvan zodat ze bij de prefix in het bestand passen. Dit is een schrijfoperatie op alle WordPress-tabellen tegelijk, dus maak eerst een database-backup en doe het in een onderhoudsvenster. Na het hernoemen moet je ook de twee plekken in de database updaten waar de prefix hard staat: de rij in <prefix>options met option_name = '<prefix>user_roles', en elke rij in <prefix>usermeta waar meta_key met de oude prefix begint. De WordPress Codex over het wijzigen van de table prefix geeft de exacte rijen.

Verificatie: log in, ga naar het falende scherm en bevestig dat de melding weg is. Draai daarna een query op <prefix>options voor option_name = '<prefix>user_roles' en check dat er één rij met een gevulde waarde staat.

Oorzaak 4: laat de cache ingelogde gebruikers overslaan

Werkt het privévenster uit Check 4 wel maar een normaal venster niet, dan serveert je cache een respons die voor een ander account is opgeslagen. Vrijwel elke page cache heeft een "skip cache voor logged-in users"-regel op basis van de wordpress_logged_in_[hash] cookie. Zet die aan.

Voor WP Rocket, LiteSpeed Cache, W3 Total Cache en de meeste managed-host caches staat de optie standaard aan, maar kan hij per ongeluk uit zijn gezet bij het configureren. Controleer de instellingen van je cache-plugin in wp-admin om te bevestigen dat de optie aanstaat.

Heb je SSH-toegang en gebruik je nginx FastCGI cache, dan leeft de regel in het server-block:

set $skip_cache 0;
if ($http_cookie ~* "wordpress_logged_in") {
    set $skip_cache 1;
}
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache    $skip_cache;

Purge daarna de cache volledig. Een gedeeltelijke purge laat de slechte entries staan.

Verificatie: het falende scherm laadt correct in een gewoon (niet-privé) venster, en een verzoek naar dezelfde URL met curl -I geeft geen X-Cache: HIT header meer terug op een geauthenticeerde cookie.

Oorzaak 5: zoek de ontbrekende capability

Heeft Check 5 de fout gelokaliseerd op een specifieke plugin, dan zit de snelste route in de instellingen van die plugin. Zoek naar een optie genaamd "rebuild capabilities", "reset roles" of iets in die geest. Membership-, LMS- en role-editor plugins hebben er meestal een, omdat ze weten dat hun eigen activatie rollen in een inconsistente staat kan achterlaten.

Bestaat zo'n knop niet, installeer dan tijdelijk de User Role Editor plugin op een staging-kopie en bekijk de capabilities van de rol die het falende scherm vereist. Vergelijk met de standaardset op de WordPress.org roles and capabilities reference voor die rol. De missende capability is vrijwel altijd dezelfde die het falende scherm aan current_user_can() doorgeeft. Voeg die vanuit de role editor weer toe en test.

Verificatie: het scherm laadt, en als je User Role Editor daarna weer verwijdert komt de fout niet terug, omdat de capability nu in de database staat.

Wanneer escaleren

Heb je twintig minuten gediagnosticeerd zonder de oorzaak te vinden, geef het dan door aan je host of een ontwikkelaar. Hoe sneller je de volgende lijst kunt aanleveren, hoe sneller zij kunnen handelen:

• De exacte URL die de melding geeft.
• De exacte tekst op het scherm en een screenshot waarop te zien is of het het WordPress wp_die()-scherm is of een blokpagina van een derde partij.
• De uitkomst van Check 2: de meta_value van wp_capabilities voor de getroffen gebruiker, gekopieerd.
• De uitkomst van Check 3: de waarde van $table_prefix uit wp-config.php en de werkelijke tabelnamen uit de database.
• Of een privévenster de fout reproduceert.
• Of het hernoemen van wp-content/plugins de fout laat verdwijnen.
• De lijst plugins, thema's en core-wijzigingen in de 48 uur voor het optreden van de fout.
• De WordPress-versie, PHP-versie en de hostingpartij.

Vermoed je een security-incident in plaats van een configuratieprobleem, behandel het dan ook zo. Reset alle administrator-wachtwoorden, audit <prefix>users op onbekende accounts en kijk bij het artikel over 403 Forbidden in WordPress voordat je verder iets aanraakt, omdat inbraakpogingen daar vaak als eerste opduiken.

Hoe je het in de toekomst voorkomt

Drie gewoontes houden deze melding zeldzaam op een gezonde WordPress-site:

• Test plugin-updates altijd eerst op staging als de plugin rollen of capabilities beheert. Membership-, LMS- en role-editor plugins zijn de hoogste-risico-categorie voor deze melding. Heb je geen staging, maak dan vlak voor de update een database-backup zodat de rollback één stap is.
• Verander nooit de table prefix op een live database zonder geteste rollback. Een prefix-wijziging raakt elke WordPress-tabel tegelijk en breekt de role-lookup zodra er iets misgaat. Moet het toch, doe dan de rename, de optie-rij en de usermeta-rijen in dezelfde migratie.
• Houd je page cache zo geconfigureerd dat ingelogde gebruikers overgeslagen worden. Deze ene regel voorkomt zowel de cache-versie van deze fout als een lange lijst niet-gerelateerde session-bugs. Controleer hem opnieuw na elke cache-plugin-update.