Geen toegang tot wp-admin zonder foutmelding

"Geen toegang tot wp-admin zonder foutmelding" is een heel specifiek symptoom, en het eerste wat ik wil vaststellen is waarom dit een apart artikel is naast "ik kan niet inloggen". Er staat geen foutmelding op je scherm. Geen 403. Geen "wachtwoord onjuist". Geen "je hebt geen toestemming". Je probeert bij het dashboard te komen en je komt er gewoon niet.

Die stilte is het hele probleem. Zodra WordPress een foutmelding laat zien, kun je de tekst zoeken en land je bij een gerichte oplossing. Gebeurt dat niet, dan ziet elke categorie oorzaken er vanuit de browser hetzelfde uit en raken mensen urenlang op de verkeerde zoektocht.

Wat de stille variant eigenlijk is

Concreet: je vult je inloggegevens in en belandt op de voorkant in plaats van in het dashboard, je gaat naar wp-admin/ en komt stilletjes terug op wp-login.php, of de dashboard-URL geeft 200 OK met een lege pagina (of alleen de bovenbalk). Zie je "wachtwoord onjuist", een 403 Forbidden-pagina, een "Sorry, je hebt geen toestemming"-melding, of een "te veel redirects"-fout, dan zit je niet in dit artikel. Dat soort symptomen is luid en elk heeft z'n eigen pagina onderaan gelinkt.

Hoe WordPress bepaalt wat je in wp-admin mag zien

Twee mechanismen bepalen of een request naar wp-admin/ je ook iets laat zien: de authenticatiesessie die meekomt op cookies uit de login-pipeline, en de capability-check die bij elk admin-scherm draait.

Bij elke request binnen wp-admin/ roept WordPress is_admin() aan om te herkennen dat het de admin rendert, en laadt daarna de huidige gebruiker met wp_set_current_user(). Die gebruiker heeft een rol, die rol mapt naar capabilities, en het scherm dat de URL opvroeg draait een current_user_can()-check op de capability die daarbij hoort. De mapping is beschreven op developer.wordpress.org: administrator heeft de volledige set, editor verliest onder andere activate_plugins en de instellingen-capabilities, en subscriber heeft bijna niks. Gaat een van die stappen stilletjes mis in plaats van met een foutmelding, dan zit je in een van de drie onderstaande categorieën.

De drie categorieën achter een stille wp-admin-lockout

Deze opdeling spiegelt bewust de umbrella waarom je niet kunt inloggen in WordPress: account, sessie, omgeving. Elk van de drie leidt tot hetzelfde zichtbare resultaat (geen dashboard, geen foutmelding) via een ander mechanisme, en elk wijst naar een ander vervolgartikel.

Account

Accountproblemen zijn de gevallen waarin login en sessie allebei prima werken, maar je gebruiker niet meer de capability heeft waarmee het admin-scherm voor jou rendert. WordPress stuurt je dan stilletjes door naar de voorkant óf laadt een bijna leeg admin-scherm, afhankelijk van welke capability mist.

• Je rol is stilletjes gedegradeerd. Een plugin, een staging-sync, of een teruggezette database-backup heeft je gebruiker teruggezet van administrator naar subscriber of author. Inloggen kan nog, maar er is gewoon niks in de admin om je te tonen.
• Een capability is weggehaald door een plugin. Membership-, LMS- en custom-role-plugins herschrijven rol-definities bij activering. Haal read of edit_dashboard weg en het dashboard verdwijnt stilletjes.
• Je super-admin-status op multisite is ingetrokken. Netwerkschermen vereisen de super-admin-vlag, en die staat los van je rol per site. Raak je die kwijt, dan verdwijnen hele menu's zonder foutmelding.

Het duidelijkste teken is dat er niks aan de infrastructuur is veranderd: geen migratie, geen nieuwe host, geen aanpassing in wp-config.php. Wat wél is veranderd, is je gebruikersrecord. Voor het aangrenzende geval waar WordPress wél een melding toont, lees Sorry, you are not allowed to access this page in WordPress oplossen.

Sessie

Sessieproblemen zijn de gevallen waarin de login doorkomt, je wachtwoord klopte, de authenticatiecookie is geschreven, maar de browser stuurt die bij de volgende request niet terug. WordPress ziet een anoniem bezoek en gooit je weer op wp-login.php. Het cookie-rondje komt niet rond.

• Het cookie-domein klopt niet met de URL in de adresbalk. WP_HOME staat op https://example.com maar de browser zit op https://www.example.com. De cookie wordt voor het ene domein gezet en de volgende request gaat naar het andere.
• Een full-page cache strippt de wordpress_logged_in_[hash]-cookie. Cache-lagen behandelen ingelogde gebruikers als een aparte doelgroep, en zodra die instelling een beetje uit de pas loopt, raken ze de cookie onderweg kwijt.
• Een reverse proxy termineert HTTPS en stuurt X-Forwarded-Proto niet door. WordPress ziet de request dan als http://, zet de niet-secure cookie, en de browser weigert die terug te sturen over het HTTPS-been.

De signatuur is dat je het inlogformulier elke keer gewoon kunt invullen, maar de admin blijft niet vastzitten. Je komt steeds weer terug op het inlogscherm zonder foutmelding. Het mechanisme erachter zit in WordPress login redirect loop.

Omgeving

Omgevingsproblemen zijn de gevallen waarin de login én de capability-check allebei in orde zijn, maar de admin-interface nooit afrendert zodra die in je browser staat. Vanaf de server klopt alles.

• De JavaScript van de admin initialiseert nooit. Een strenge Content Security Policy, een agressieve performance-plugin die admin-scripts defert of concateneert, of een CDN-rewriter die admin-bundles sloopt: allemaal hetzelfde resultaat. De HTML komt binnen, de bovenbalk verschijnt, en de rest blijft leeg.
• Een maintenance-mode of coming-soon-plugin heeft admins op z'n blokkadelijst. Dat soort plugins hoort ingelogde beheerders gewoon door te laten, maar een verkeerd geconfigureerde variant toont iedereen dezelfde splash, dus ook degene die naar wp-admin/ probeert.
• Een plugin die de login-URL heeft verplaatst, onderschept wp-admin/. WPS Hide Login en soortgelijke tools herschrijven requests naar een eigen slug. Ben je die slug vergeten, dan stuurt de standaard-URL je stilletjes door naar de voorkant.

De signatuur is dat de kale HTTP-response er goed uitziet (200 OK), maar het interactieve deel van de admin nooit opstart. Als het dashboard wél deels verschijnt en daarna op een spinner blijft hangen, dan zit je in een specifieker geval dat in WordPress-admin blijft laden na inloggen wordt behandeld.

Wat "geen toegang tot wp-admin" níet is

Deze sectie voorkomt het meeste verspilde zoekwerk.

• Het is niet hetzelfde als "niet kunnen inloggen in WordPress". Die umbrella dekt élk login-symptoom, inclusief de luide met een zichtbare foutmelding. Dit artikel gaat specifiek over de stille subset. Staat er wél een melding op het inlogformulier of in het dashboard, begin dan bij waarom je niet kunt inloggen in WordPress.
• Het is geen wachtwoord-probleem. Weigert het formulier je met "wachtwoord onjuist", dan werkt het inlogformulier dus en zit jij in een wachtwoord-resetsituatie. Dit artikel gaat juist over het geval waarin het formulier je accepteert en er daarna toch geen admin is.
• Het is geen 403 Forbidden. Een 403 is een luid symptoom: de server geeft een foutcode en de browser toont een foutpagina met tekst om op te zoeken. Dat is een ander mechanisme en een ander artikel: 403 Forbidden op wp-admin.
• Het is geen redirect-loop. Een loop op browserniveau eindigt met ERR_TOO_MANY_REDIRECTS. Geeft de browser zelf op, lees dan WordPress login redirect loop. De stille variant van een wp-admin-lockout triggert de redirect-detectie van de browser helemaal niet.
• Het is geen zichtbare rechten-melding. "Sorry, je hebt geen toestemming om deze pagina te bekijken" is een capability-check die mét tekst is teruggekomen, en die heeft een eigen artikel: Sorry, you are not allowed to access this page in WordPress oplossen. De stille accountvariant ziet er vergelijkbaar uit, maar produceert geen tekst.