DISABLE_WP_CRON = true sluit het wp-cron.php-endpoint niet af; het zorgt er alleen voor dat WordPress stopt met het uitvoeren van zijn eigen loopback-verzoek. Het bestand blijft bereikbaar via het web, dus iedereen kan het nog steeds aanroepen en een volledige WordPress bootstrap forceren.

Dat verborgen toegangspunt kan CPU, geheugen en PHP-workers verspillen, vooral op drukke sites. Als je dacht dat je de deur had dichtgedaan, dan is dat nog niet het geval.

Waarom deze instelling vaak verkeerd wordt begrepen

Wanneer WordPress een geplande taak uitvoert, probeert het eerst een snel HTTP-verzoek naar het eigen wp-cron.php-bestand te doen. Door DISABLE_WP_CRON op true te zetten, krijgt de core het signaal om dat interne verzoek over te slaan. De core verandert niet de webserverconfiguratie en voegt ook geen authenticatielaag toe aan wp-cron.php. Het script blijft een publieke URL die een 200-status retourneert, zelfs als het PHP-proces voortijdig wordt afgebroken.

Een aanvaller die de URL ontdekt, kan deze herhaaldelijk aanroepen (pingen), waardoor WordPress telkens alle plugins, thema's en de database moet laden. Op een shared host of een site met beperkte PHP-workers kan dit enkele endpoint een denial-of-service-vector worden.

Wat er echt moet gebeuren

Om geplande taken over te zetten naar een scheduler op systeemniveau (cron, systemd-timer, etc.) en de publieke deur te sluiten, volg je deze vijf stappen.

1. Schakel de interne loopback uit

Voeg de regel 

define( 'DISABLE_WP_CRON', true );

toe aan wp-config.php. Dit voorkomt dat WordPress zijn eigen HTTP-verzoek probeert te doen, maar het stopt externe aanroepen niet.

2. Blokkeer wp-cron.php op de webserver

Voeg bij Nginx bijvoorbeeld een location-block toe die 403 Forbidden retourneert:

location = /wp-cron.php {
    return 403;
}

De server wijst het verzoek nu af voordat PHP zelfs maar opstart, waardoor de bootstrap-kosten worden geëlimineerd.

3. Voeg een mu-plugin toe als vangnet

Maak een must-use plugin (geplaatst in wp-content/mu-plugins) die elk verzoek dat wp-cron.php bereikt logt en afsluit met een 403. Dit vangt verzoeken op die op de een of andere manier de serverregel omzeilen—bijvoorbeeld via een andere hostname of een CDN edge-regel.

4. Onderdruk Action Scheduler async-aanroepen

Veel plugins gebruiken de Action Scheduler-bibliotheek, die zijn eigen loopback-verzoeken kan genereren. Gebruik een hook op action_scheduler_queue_runner en keer vroegtijdig terug voor verzoeken die niet via de CLI verlopen, om te voorkomen dat de bibliotheek probeert zijn eigen deuren te openen.

5. Ontkoppel de queue runner van de WP-Cron hook

Verwijder de standaard Action Scheduler queue runner die is gekoppeld aan de wp cron hook. Dit zorgt ervoor dat de wachtrij alleen wordt uitgevoerd wanneer je deze expliciet vanaf de command line aanroept.

Taken op de juiste manier uitvoeren

Nu het publieke endpoint is afgesloten, kun je de systeem-scheduler gebruiken om WordPress één keer per minuut aan te roepen (of welke frequentie je ook nodig hebt) via WP-CLI:

wp cron event run --due-now

Dat enkele commando verwerkt zowel de core cron-events als de Action Scheduler-wachtrij in een gecontroleerde omgeving, gebruikmakend van hetzelfde PHP-proces dat je voor elke andere CLI-taak zou gebruiken.

Voordelen die je kunt meten

  • Beveiliging – Geen ongeauthenticeerde gebruiker kan zware achtergrondtaken starten.
  • Prestaties – PHP-workers blijven beschikbaar voor echte bezoekers; geheugenpieken door willekeurige cron-aanroepen verdwijnen.
  • Betrouwbaarheid – Planning wordt proactief; je weet precies wanneer een taak wordt uitgevoerd omdat deze wordt aangestuurd door de cron van het systeem, en niet door het laden van een pagina door een bezoeker.

Waar je op moet letten na de wijziging

Vertrouw niet op de HTTP-statuscode van wp-cron.php; deze kan nog steeds 200 retourneren, zelfs als deze door PHP wordt geblokkeerd. Doe in plaats daarvan het volgende:

  • Monitor de grootte van de Action Scheduler-wachtrij. Een groeiende wachtrij is vaak een teken van gemiste runs.
  • Controleer de serverlogs op "403"-vermeldingen vanuit de wp-cron.php location-block.
  • Observeer de PHP-FPM of FastCGI-procesaantallen tijdens piekverkeer om te bevestigen dat de belasting is gedaald.

Een waarschuwing

Sommige beheerders laten DISABLE_WP_CRON op false staan omdat ze vertrouwen op websites met weinig verkeer om cron op natuurlijke wijze te triggeren. De bovenstaande aanpak neemt die afhankelijkheid volledig weg, maar voegt wel een onderhoudstap toe: je moet ervoor zorgen dat de systeem-scheduler betrouwbaar draait. Als de cron-daemon van de server faalt, stoppen de geplande taken. Combineer deze configuratie met monitoring van de systeem-cron-service om deze valkuil te vermijden.

Conclusie: het instellen van DISABLE_WP_CRON op true zorgt er alleen voor dat WordPress stopt met zichzelf te pingen; het sluit het publieke wp-cron.php-endpoint niet af. Blokkeer het bestand op de webserver, voeg een mu-plugin fallback toe en stuur alle geplande taken via een systeem-scheduler via WP-CLI. Hiermee beveilig je de site, verminder je onnodig PHP-werk en krijg je nauwkeurige controle over wanneer achtergrondtaken worden uitgevoerd.