U bent halverwege een pagina, klikt op opslaan en belandt op het inlogscherm. Uw tekst is weg, of in het beste geval bewaard als concept. Wordt u steeds uitgelogd uit WordPress, dan is dat geen kleine ergernis maar een rem op het werk: mensen gaan minder vaak iets aanpassen omdat het gedoe is.

Anders dan bij een inlogscherm dat blijft herladen, komt u hier wél binnen. Het probleem zit in het onthouden. Hieronder staan de oorzaken die we in de praktijk tegenkomen, van de meest voorkomende tot de zeldzame, plus wat u er verstandig aan doet.

Hoe lang een sessie hoort te duren

WordPress werkt met twee sessieduren. Logt u in zonder het vinkje “onthoud mijn gegevens”, dan is uw sessie twee dagen geldig. Zet u dat vinkje wel aan, dan wordt het veertien dagen. Dat is dus de standaard; wie na tien minuten of na een half uur wordt uitgelogd, heeft te maken met iets dat die sessie voortijdig ongeldig maakt.

Dat vinkje wordt trouwens massaal over het hoofd gezien. Een deel van de klachten die wij binnenkrijgen, verdwijnt zodra iemand het gewoon aanzet. Begin daar, voordat u verder zoekt.

De oorzaken op een rij

Uw ip-adres verandert tijdens het werken

Sommige beveiligingsplugins koppelen de sessie aan uw ip-adres. Verandert dat, dan wordt u uit voorzorg uitgelogd. Dat gebeurt vaker dan u denkt: bij een wisseling tussen wifi en 4G, bij een vpn die van server wisselt, of bij een internetverbinding die om de zoveel uur een nieuw adres krijgt. Werkt u in de trein, dan is dit vrijwel altijd de verklaring.

De site wisselt tussen twee adressen

Staat de ene helft van de site op het adres met www en de andere zonder, of loopt er een omleiding tussendoor van http naar https, dan raakt uw browser het cookie kwijt zodra u van de ene naar de andere variant springt. Dit merkt u doordat u op sommige schermen wel en op andere niet ingelogd bent.

Een caching-laag serveert een uitgelogde kopie

Caching hoort de beheerkant met rust te laten, maar dat gaat mis bij een verkeerd ingestelde plugin of een cache op serverniveau. U krijgt dan een opgeslagen kopie van de pagina zoals een bezoeker die ziet, inclusief de inloglink. U bént dan nog ingelogd, u ziet het alleen niet.

De beveiligingssleutels zijn vernieuwd

De sleutels in het configuratiebestand ondertekenen elke inlogcookie. Worden ze vervangen, dan vervallen alle sessies op dat moment. Gebeurt dat één keer, dan is dat een bewuste actie, bijvoorbeeld na een incident. Gebeurt het steeds, dan zet een plugin ze telkens opnieuw.

Een sessielimiet of een aanwezigheidscontrole

Plugins die het aantal gelijktijdige sessies beperken, of die u uitloggen na een periode zonder muisbeweging, doen precies wat ze beloven. Dat is bij een webshop met klantgegevens een verdedigbare keuze, maar de standaardinstelling staat vaak veel te kort.

De klok van de server loopt fout

Loopt de servertijd voor, dan is uw cookie verlopen op het moment dat het wordt aangemaakt. Zeldzaam, maar het verklaart de gevallen waarin niemand meer ingelogd blijft en er verder niets is gewijzigd.

Zo zoekt u het uit

  1. Zet het vinkje “onthoud mijn gegevens” aan en kijk of het probleem daarmee al weg is.
  2. Let op het adres in de balk op het moment dat u eruit vliegt. Verspringt daar iets, dan heeft u uw oorzaak.
  3. Vraag collega’s of zij het ook hebben. Ligt het bij één persoon, dan zit het in diens browser, netwerk of vpn.
  4. Kijk in het logboek van uw beveiligingsplugin. Daar staat vaak letterlijk waarom een sessie is beëindigd.
  5. Zet caching tijdelijk uit en werk een uur zonder. Blijft u dan wel ingelogd, dan weet u waar u moet instellen.
  6. Schakel plugins groepsgewijs uit tot het verdwijnt. Begin bij de beveiligings- en cachingplugins; die zijn samen goed voor het grootste deel van de gevallen.
  7. Controleer de servertijd in het overzicht Sitegezondheid of bij uw hosting.

Verloopt het zoeken zonder resultaat en zit u ondertussen ook nog met een scherm dat naar zichzelf blijft terugkeren, kijk dan of u eigenlijk te maken heeft met de cookiefout waarbij het inlogscherm zich herhaalt. Dat is een ander probleem met een andere oplossing.

Wat u beter niet doet

Er circuleert een aanpak waarbij de sessieduur op een jaar wordt gezet. Technisch kan dat, maar het is een slecht idee, zeker op een gedeelde laptop of bij personeelsverloop. Een gestolen of achtergelaten sessie blijft dan een jaar lang geldig.

Een verstandiger middenweg: zet de sessieduur op iets als twee weken voor redacteuren en houd hem korter voor beheerders. Combineer dat met een tweede factor bij het inloggen, dan is een langere sessie ook een stuk minder risicovol. Hoe u zo’n tweede factor kiest, staat in de afweging tussen een wachtwoordmanager en tweestapsverificatie.

Zet ook niet zomaar de ip-controle uit omdat hij lastig is. Die controle vangt echt iets af. Beter is om hem alleen soepeler te zetten voor de mensen die veel onderweg werken.

Voorkom dat u tekst kwijtraakt

Zolang de oorzaak niet gevonden is, kunt u de schade beperken. Werk lange teksten voor in een tekstverwerker en plak ze pas in als ze af zijn. Klik regelmatig op concept opslaan; WordPress bewaart daarnaast zelf automatisch versies, dus na een onverwachte uitlog is er meestal wel iets terug te halen via de revisies. En open een tweede tabblad met het dashboard erin: raakt u uitgelogd, dan ziet u dat daar meteen.

Blijft het probleem hangen terwijl u alles heeft nagelopen, dan zit het vaak in een combinatie van serverinstellingen en pluginconfiguratie die van buitenaf lastig te raden is. Dat uitzoeken is precies wat er gebeurt bij het verhelpen van terugkerende storingen in WordPress; bij WebMaintor begint zo’n melding altijd met het naast elkaar leggen van het beveiligingslogboek en de wijzigingen van de afgelopen week.

Concrete volgende stap: log opnieuw in met het vinkje voor onthouden aangevinkt en let bij de volgende keer uitloggen op wat er in de adresbalk staat. Die twee waarnemingen brengen u meestal al bij de juiste oorzaak.