U vult uw gebruikersnaam en wachtwoord in, drukt op inloggen, de pagina knippert even en u staat weer op hetzelfde scherm. Geen melding dat het wachtwoord verkeerd is, geen foutcode, gewoon opnieuw het inlogformulier. Dit is de klassieke WordPress login cookie fout, en hij is bijna altijd op te lossen zonder dat er iemand in de code hoeft te duiken.

Soms staat er wel een tekst bij: “Cookies zijn geblokkeerd door onverwachte uitvoer” of “Cookies zijn geblokkeerd of worden niet ondersteund door uw browser”. Meestal blijft het bij die stille lus. Hieronder leest u waarom dit gebeurt en in welke volgorde u het aanpakt.

WordPress controleert uw wachtwoord en zet daarna een cookie in uw browser. Dat cookie is uw polsbandje: bij elke volgende pagina laat u het zien en wordt u herkend als ingelogde gebruiker. Lukt dat plaatsen niet, of past het bandje bij een ander adres dan waar u bent, dan ziet WordPress u als bezoeker en stuurt het u terug naar de deur. Het inloggen is dus geslaagd, alleen het onthouden gaat mis.

Dat verklaart meteen waarom u geen wachtwoordfout ziet. De site heeft niets tegen u; hij weet alleen een halve seconde later niet meer wie u bent.

De zes gebruikelijke oorzaken

1. Uw browser blokkeert of bewaart het cookie niet

Strenge privacy-instellingen, een uitgebreide cookieblokkering of een browserprofiel dat vol zit met verlopen cookies voor hetzelfde domein. Dit is de meest voorkomende oorzaak en tegelijk de makkelijkst te testen.

2. Het adres van de site komt niet overeen

Logt u in op de versie met www terwijl WordPress zichzelf zonder www kent, dan wordt het cookie voor het ene adres gezet en op het andere gezocht. Hetzelfde gebeurt bij http tegenover https. Vaak zichtbaar doordat u na het inloggen op een net iets ander adres in de balk staat.

3. Er wordt iets afgedrukt vóór de cookie

Een cookie moet worden verstuurd voordat er ook maar één teken naar het scherm gaat. Staat er in een thema- of pluginbestand een spatie of lege regel voor de openingstag, of drukt een plugin een waarschuwing af, dan is de cookie te laat. Dit is de variant met de melding over onverwachte uitvoer.

4. Een plugin bemoeit zich ermee

Beveiligingsplugins die de inlogpagina verplaatsen, cookie-toestemmingsbanners die alles blokkeren tot er is geklikt, en caching-plugins die de inlogpagina per ongeluk opslaan. Die laatste is berucht: u krijgt dan een opgeslagen kopie van het uitgelogde scherm te zien.

5. De klok van de server loopt niet gelijk

Cookies hebben een vervaldatum. Staat de servertijd uren verkeerd, dan is het cookie al verlopen op het moment dat het wordt gezet. Zeldzaam, maar het komt voor na een serververhuizing.

6. De beveiligingssleutels zijn gewijzigd of ontbreken

In het configuratiebestand van WordPress staan sleutels waarmee de inlogcookies worden ondertekend. Ontbreken ze of zijn ze zojuist vervangen, dan zijn alle bestaande sessies ongeldig. Dat hoort zo na een hack, maar het verklaart wel waarom iedereen opeens niet meer binnenkomt.

Oplossen in vaste volgorde

Werk deze lijst af en stop zodra u binnen bent. De eerste drie stappen kosten samen geen vijf minuten en helpen in de meeste gevallen.

  1. Open een incognitovenster en probeer het opnieuw. Lukt het daar wel, dan zit het probleem in uw gewone browserprofiel en kunt u verder bij stap 2.
  2. Verwijder de cookies van uw eigen domein en herlaad de pagina. Niet uw hele browsergeschiedenis wissen; alleen de cookies voor deze site.
  3. Controleer het adres in de balk. Tik bewust de andere variant in, met of zonder www, en probeer daar in te loggen.
  4. Probeer een andere browser of een ander apparaat. Werkt het daar wel, dan is de site in orde.
  5. Zet de cache van de site leeg. Kunt u niet inloggen, dan kan dat meestal ook via het bedieningspaneel van uw hosting, of door de cachemap te legen.
  6. Schakel plugins tijdelijk uit. Zonder toegang tot het dashboard doet u dat via het uitschakelen van een plugin via FTP. Hernoem de pluginmap, probeer opnieuw in te loggen, en zet daarna alles terug.
  7. Kijk naar de site-url in de instellingen. Staat daar een adres dat niet klopt, dan is dat de oorzaak. Dat rechtzetten kan via het configuratiebestand, zonder dat u uzelf verder buitensluit.
  8. Controleer of de site zichzelf naar een ander adres stuurt. Ziet u het adres in de balk telkens veranderen, dan is er een omleiding actief die het cookie onderweg kwijtraakt.

Wanneer het niet aan u ligt

Meldt meer dan één collega hetzelfde, dan hoeft niemand meer aan zijn browser te sleutelen. Dan is er iets veranderd aan de site: een update, een nieuwe beveiligingsplugin, een gewijzigd certificaat of een verhuizing. Kijk als eerste naar wat er in de laatste dagen is aangepast; dat scheelt uren zoeken.

Let ook op het verschil met het probleem waarbij u wél binnenkomt maar er telkens uit vliegt. Dat is een ander mechanisme: daar wordt het cookie wél gezet maar te snel ongeldig verklaard.

Voorkomen dat het terugkomt

Drie maatregelen halen deze fout structureel weg. Kies één vaste variant van uw webadres en laat alle andere varianten daarheen doorsturen, zodat er nooit twee versies naast elkaar bestaan. Zorg dat uw caching-plugin de inlogpagina en het beheerscherm uitsluit, want die horen nooit uit een opgeslagen kopie te komen. En houd bij welke beveiligingsplugin de inlogpagina aanpast, zodat u bij een storing weet waar u moet kijken.

Komt u er niet uit en heeft u geen toegang meer tot uw eigen beheerscherm, dan is dat het moment om er iemand bij te halen die via FTP en de database kan kijken. Dat valt onder het verhelpen van storingen aan een WordPress-site, en bij WebMaintor is een inlogprobleem standaard een melding met voorrang, simpelweg omdat u zonder toegang ook niets anders kunt oplossen.

Concrete volgende stap: probeer het inloggen eerst in een incognitovenster. Lukt het daar wel, dan hoeft u aan de site zelf niets te veranderen.