"De link die je hebt gevolgd is verlopen" in WordPress

Je probeert een plugin-ZIP te uploaden, een thema te activeren of een grote afbeelding naar de mediabibliotheek te slepen, en WordPress stopt je met een wit scherm dat zegt:

De link die je hebt gevolgd is verlopen. Probeer het opnieuw.

Geen stacktrace, geen bestandspad, geen hint over wat er mis is gegaan. De HTTP-statuscode is 403. De melding klinkt alsof je sessie is verlopen, maar opnieuw inloggen en het nogmaals proberen helpt niet. De fout komt uit wp_nonce_ays(), die WordPress aanroept wanneer een formulierinzending de beveiligingsnonce niet doorkomt. Het misleidende is dat een ontbrekende nonce en een verlopen nonce precies dezelfde melding opleveren, en de meest voorkomende reden dat de nonce ontbreekt heeft niets met verlopen te maken.

Wat de fout werkelijk betekent (en waarom de melding misleidend is)

Elk formulier in het WordPress-adminpaneel bevat een verborgen _wpnonce-veld, gegenereerd door wp_nonce_field(). Bij het verzenden leest check_admin_referer() dat veld en valideert het. Ontbreekt het veld of is het ongeldig, dan roept WordPress wp_nonce_ays() aan, die de pagina afbreekt met een 403 en de tekst "de link die je hebt gevolgd is verlopen".

Het woord "verlopen" impliceert dat de tijd om was. Dat klopt soms, maar in de praktijk is de meest voorkomende trigger dat het nonce-veld nooit bij WordPress is aangekomen, omdat PHP de volledige POST-body stilletjes heeft weggegooid voordat WordPress de kans kreeg om 'm te lezen. De fouttekst is nooit aangepast. Hij stamt uit WordPress 2.0.4 en is sindsdien ongewijzigd gebleven.

Oorzaken, op volgorde van waarschijnlijkheid

1. PHP-uploadlimieten te laag (veruit het vaakst)

Wanneer een bestandsupload de POST-body voorbij PHP's post_max_size duwt, geeft PHP geen foutmelding. Het maakt zowel de $_POST- als $_FILES-superglobals stilletjes leeg en overhandigt het verzoek aan WordPress zonder data. De PHP-handleiding over veelvoorkomende uploadproblemen documenteert dit gedrag expliciet: als de POST-data groter is dan post_max_size, zijn $_POST en $_FILES leeg.

WordPress ontvangt de lege $_POST, vindt geen _wpnonce-veld, en check_admin_referer() faalt. Het resultaat is de "link is verlopen"-melding, terwijl de werkelijke oorzaak een te groot bestand en een te lage PHP-limiet is.

Twee PHP-instellingen regelen dit:

Veel shared hosts laten deze op of vlak bij de PHP-standaarden staan. Een plugin-ZIP van 10 MB, een thema-ZIP van 15 MB of een batch productfoto's kan post_max_size overschrijden zonder dat je doorhebt dat die limiet bestaat.

2. Daadwerkelijk verlopen nonce (pagina te lang open)

WordPress-nonces zijn geldig voor 12 tot 24 uur, afhankelijk van waar in de tick-cyclus de nonce is aangemaakt. De standaard nonce_life is DAY_IN_SECONDS (86.400 seconden), verdeeld in twee ticks van 12 uur. Een nonce is geldig voor de huidige tick en de vorige tick, wat een venster oplevert van 12 tot 24 uur.

Als je de plugin-uploadpagina maandagochtend opent en dinsdag pas op "Installeren" klikt, is de nonce in het formulier verlopen. Herlaad de pagina. De nieuwe pagina bevat een verse nonce en de upload werkt gewoon.

Een subtielere variant: een cachingplugin die verouderde admin-HTML serveert. De meeste cachingplugins sluiten /wp-admin/ standaard uit, maar misconfiguraties komen voor. Als WP Rocket, W3 Total Cache, LiteSpeed Cache of WP Super Cache een gecachte kopie serveert van een pagina met een nonce erin, veroudert die nonce in de cache. De documentatie van WP Rocket raadt een cachelevensduur van 10 uur of minder aan, precies om dit te voorkomen. Staat je cachelevensduur op 24 uur of meer, dan bevatten gecachte formulieren verlopen nonces tegen de tijd dat ze geserveerd worden. Voor een bredere blik op cacheproblemen, zie het artikel over waarom je WordPress-cache niet werkt.

3. Pluginconflict

Beveiligingsplugins, firewallplugins en WooCommerce-extensies die inhaken op formulierverwerking kunnen $_POST-data strippen of wijzigen voordat WordPress de nonce leest. Het symptoom is identiek: nonce ontbreekt, 403, "link verlopen". Als de fout begon na het installeren of updaten van een specifieke plugin, is die plugin de eerste verdachte.

4. MIME-type afwijzing bij bestandsupload

Op sommige WordPress-configuraties wijst wp_check_filetype_and_ext() het MIME-type van een geupload bestand af, en komt die afwijzing naar boven als de "link verlopen"-melding in plaats van het duidelijkere "dit bestandstype is niet toegestaan". Dit komt het vaakst voor bij niet-standaard bestandstypen als SVG, HEIC op oudere WordPress-versies, of aangepaste formaten. Het artikel over beperkingen bij het uploaden van bestandstypen behandelt de fix per formaat.

Zo stel je de oorzaak vast

Loop deze checks op volgorde af. Stop bij de eerste treffer.

Stap 1: gebeurde de fout tijdens een bestandsupload? Als je een plugin, thema of mediabestand aan het uploaden was, begin dan met oorzaak 1. Ga naar Gereedschap > Sitediagnose > Info > Server en controleer Upload max filesize en Post max size. Vergelijk die waarden met de grootte van het bestand dat je probeerde te uploaden. Is het bestand groter dan een van beide limieten? Dan heb je je oorzaak gevonden.

De mediabibliotheek toont het plafond ook onderaan het Media > Nieuw bestand-scherm: "Maximale uploadgrootte: X MB."

Stap 2: stond de pagina lang open voordat je het formulier verstuurde? Als je de adminpagina uren geleden opende, of een tab open liet staan overnight, kan de nonce echt verlopen zijn. Herlaad de pagina en probeer het opnieuw. Verdwijnt de fout? Dan was het oorzaak 2 en hoef je niets te veranderen.

Stap 3: is er een cachingplugin actief? Deactiveer de cachingplugin tijdelijk en probeer de actie opnieuw. Als de fout verdwijnt, serveerde de cache verouderde nonces. Leeg de volledige paginacache, zet de cachelevensduur op 10 uur of minder, en controleer of /wp-admin/ is uitgesloten van paginacaching.

Stap 4: begon de fout na een pluginwijziging? Deactiveer de laatst geinstalleerde of bijgewerkte plugin en probeer opnieuw. Verdwijnt de fout? Dan heb je het conflict gevonden. Lukt het niet direct, deactiveer dan alle plugins en activeer ze een voor een opnieuw.

Stap 5: probeerde je een ongebruikelijk bestandstype te uploaden? Was het bestand een SVG, HEIC, een aangepast lettertype of een leveranciersspecifiek formaat, dan is oorzaak 4 (MIME-afwijzing) waarschijnlijk. Kijk in het artikel over bestandstypebeperkingen voor de fix per formaat.

Fix voor uploadlimieten (oorzaak 1)

Verhoog upload_max_filesize en post_max_size samen. post_max_size moet gelijk aan of groter zijn dan upload_max_filesize, altijd. Verhoog je er maar een, dan wint de lagere waarde nog steeds.

De snelste route hangt af van je hostingsetup:

• Hostingcontrolepaneel (cPanel, Plesk, DirectAdmin, hPanel): open de PHP-instellingeneditor en verhoog beide waarden naar 64M of hoger. Dit is de schoonste methode en werkt bij het volgende verzoek.
• .htaccess (alleen Apache met mod_php): voeg php_value upload_max_filesize 64M en php_value post_max_size 64M toe. Werkt niet op nginx of Apache met PHP-FPM.
• .user.ini (PHP-FPM zonder paneeltoegang): maak een .user.ini in de WordPress-root met upload_max_filesize = 64M en post_max_size = 64M. Het kan tot vijf minuten duren voordat PHP de wijziging oppikt vanwege de .user.ini cache-TTL.

Het volledige stappenplan met verificatie per methode, nginx-specifieke stappen, de wp-config.php-valkuil (waarom ini_set() hier niet werkt) en het aparte Multisite-plafond staat in het artikel over de uploadlimiet verhogen in WordPress.

Je weet dat de fix werkt wanneer Gereedschap > Sitediagnose > Info > Server de nieuwe waarden toont voor Upload max filesize en Post max size, en de upload die eerder de "link verlopen"-fout veroorzaakte nu zonder probleem slaagt.

Fix voor verlopen nonces (oorzaak 2)

Als de oorzaak een daadwerkelijk verlopen nonce is (pagina te lang open, of gecachte formulieren), hangt de fix af van de variant.

Pagina te lang open: herlaad de pagina voor je het formulier verstuurt. Dat is de volledige fix. De nieuwe pagina bevat een verse nonce, geldig voor de komende 12 tot 24 uur.

Cachingplugin serveert verouderde nonces:

1. Leeg de volledige paginacache vanuit het dashboard van de cachingplugin.
2. Zet de cachelevensduur op 10 uur of minder. In WP Rocket is dit onder Instellingen > WP Rocket > Cache > Cachelevensduur.
3. Controleer of /wp-admin/-pagina's zijn uitgesloten van paginacaching. Elke serieuze cachingplugin doet dit standaard, maar check even of iemand de uitsluiting heeft uitgeschakeld.

nonce_life aanpassen als laatste redmiddel. Het nonce_life-filter laat je het geldigheidsvenster van nonces aanpassen. Dit is bijna nooit de juiste fix. Een langere nonce-levensduur vergroot het CSRF-aanvalsvenster op elk formulier in WordPress. Overweeg het alleen als je hebt bevestigd dat echte nonce-verloping de oorzaak is, alle caching correct is geconfigureerd, en er geen andere optie bestaat. Ga ook dan niet boven 48 uur.

// Laatste redmiddel. Vermindert beveiliging. Gebruik alleen na bevestiging van oorzaak 2.
add_filter( 'nonce_life', function () {
    return 48 * HOUR_IN_SECONDS;
} );

Wanneer hulp inschakelen

Als je de uploadlimieten hebt gecontroleerd, bevestigd hebt dat de nonce niet verlopen is, de cache hebt geleegd en plugins hebt gedeactiveerd, en de fout nog steeds verschijnt, verzamel dan dit voordat je een supportticket opent:

• De exacte actie die de fout triggert (welke adminpagina, welke knop, of er een bestandsupload bij zat, de bestandsgrootte).
• De waarden voor Upload max filesize, Post max size en PHP SAPI onder Gereedschap > Sitediagnose > Info > Server.
• Je WordPress-versie, PHP-versie en de naam van je actieve thema.
• Een volledige lijst van actieve plugins.
• Of de site single-site of multisite is.
• Of er een cachingplugin actief is en wat de cachelevensduur is.
• De inhoud van het PHP-foutenlog rond het tijdstip van de fout (als je daar toegang toe hebt). Het log kan extra context bevatten die het witte 403-scherm niet toont.

Zo voorkom je het in de toekomst

• Stem je uploadlimieten af op de bestanden waarmee je werkt. Als je workflow plugin-ZIPs van 20 MB en mediabestanden van 50 MB omvat, voorkomt een post_max_size van 64M de meest voorkomende trigger van deze fout. De standaard 8M is te laag voor de meeste WordPress-sites die meer doen dan tekst bewerken.
• Houd de cachelevensduur onder 12 uur. Zo voorkom je dat gecachte nonces verlopen voordat de gecachte pagina wordt ververst. De meeste cachingplugins raden 10 uur aan.
• Laat adminpagina's niet overnight open staan. Als je de neiging hebt om browsertabs dagenlang open te laten, herlaad de pagina dan even voordat je een formulier verstuurt. De nonce in het formulier veroudert ook als je er niet naar kijkt.