U heeft waarschijnlijk nog nooit bewust iets met WP-Cron gedaan. Toch draait hij op uw website, elke dag, en regelt hij zaken waar u op vertrouwt: het publiceren van een ingepland bericht, het versturen van een back-up, het controleren op nieuwe updates. Meestal gaat dat geruisloos goed. Maar zo nu en dan komt er een ondernemer bij ons met een site die “af en toe traag is, zonder aanwijsbare reden”. Vaker dan u zou verwachten blijkt de taakplanner de boosdoener.
In dit artikel leggen we uit wat de taakplanner precies doet, waarom hij anders werkt dan een echte taakplanner en hoe u kunt zien of hij bij u voor problemen zorgt. Geen diepgaande techniek, wel genoeg om een goed gesprek met uw hostingpartij of beheerder te voeren.
Wat is WP-Cron eigenlijk?
Op een gewone server bestaat een systeem dat cron heet: een taakplanner die op vaste tijden opdrachten uitvoert, of er nu iemand kijkt of niet. WordPress heeft daar geen toegang toe, omdat het op allerlei soorten hosting moet kunnen draaien. Daarom hebben de makers een eigen variant gebouwd, en die heet WP-Cron.
Het verschil zit in de aansturing. De echte cron gaat af op de klok. De WordPress-variant gaat af op bezoekers. Bij elke pagina die wordt opgevraagd, kijkt WordPress even of er taken zijn die inmiddels hadden moeten draaien. Zo ja, dan worden die tijdens dat bezoek gestart. Dat is een slimme oplossing voor een lastig probleem, maar het heeft twee gevolgen waar u rekening mee moet houden.
Gevolg één: zonder bezoek gebeurt er niets
Heeft uw site ‘s nachts geen bezoekers, dan draait er ‘s nachts ook geen enkele taak. Een bericht dat om 07:00 uur gepland staat, verschijnt pas als de eerste bezoeker om 08:14 uur langskomt. Voor een blog is dat een schoonheidsfoutje. Voor een webshop die ‘s nachts voorraad wil bijwerken of een back-up wil draaien, is het vervelender.
Gevolg twee: een bezoeker betaalt de rekening
Andersom geldt: als er wél veel taken klaarstaan, moet er iemand zijn die ze in gang zet. Dat is die ene bezoeker die net op het verkeerde moment uw homepage opent. Zijn pagina laadt trager, omdat op de achtergrond opeens een reeks taken wordt afgewerkt. WordPress probeert dit zo veel mogelijk los van de pagina te doen, maar op drukke of zwakke hosting merkt u het.
Welke taken staan er in de wachtrij?
WordPress zelf plant een handjevol taken in: controleren op updates, oude concepten opruimen, verlopen transients wissen. Dat is bescheiden. Het probleem ontstaat door plugins. Elke plugin mag zijn eigen taken toevoegen, en veel doen dat gretig:
- Back-upplugins die elke dag of elk uur een kopie willen maken.
- Beveiligingsplugins die scans inplannen en logboeken opruimen.
- Cacheplugins die de cache willen voorverwarmen.
- Koppelingen met nieuwsbrief-, boekhoud- of verzendsystemen die elke paar minuten willen synchroniseren.
- Statistiekplugins die bezoekgegevens verwerken.
- WooCommerce, dat via de Action Scheduler een eigen, uitgebreide wachtrij bijhoudt.
Op een site die een paar jaar meegaat, zien we regelmatig tientallen geplande taken. Een deel daarvan hoort bij plugins die allang zijn verwijderd. De taak blijft in de database staan, wordt elke keer opgepakt, faalt of doet niets, en komt de volgende ronde weer terug. Dat kost cycli, en op den duur merkt u dat.
Hoe merkt u dat WP-Cron uw site vertraagt?
De klachten zijn meestal vaag, en dat maakt de oorzaak lastig te vinden. Herkent u een van deze situaties?
- De site is meestal snel, maar zo nu en dan duurt één pagina opeens vier of vijf seconden. De volgende keer is het weer normaal.
- Ingeplande berichten verschijnen te laat of helemaal niet, of uw back-up van 03:00 uur is pas om 09:30 uur gemaakt.
- Uw hostingpartij meldt dat de site regelmatig de CPU-limiet raakt, terwijl het bezoek niet is toegenomen.
- In het foutenlog staan meldingen over wp-cron.php die te lang duurt of een time-out geeft.
Wilt u zelf kijken, dan is er een gratis plugin met de naam WP Crontrol. Die toont alle geplande taken, wanneer ze voor het laatst draaiden en hoe vaak ze terugkomen. Alleen al de lijst bekijken is leerzaam. U ziet dan bijvoorbeeld een taak van een plugin die u in 2022 heeft verwijderd, die nog elke tien minuten probeert iets te doen. Verwijderen is verstandig, maar wees zorgvuldig: verwijder alleen taken waarvan u zeker weet bij welke plugin ze hoorden.
Werkt de planner helemaal niet meer, dan is dat een ander verhaal met andere oorzaken. Daarover leest u meer in dit artikel over WP-Cron die niet afgaat.
De nette oplossing: een echte cron laten aansturen
De structurele oplossing is om de koppeling met bezoekers los te laten. U schakelt de ingebouwde trigger uit en laat de server zelf, op de klok, elke paar minuten de wachtrij afwerken. Bezoekers merken er dan niets meer van en taken draaien ook als er niemand op de site is.
In grote lijnen gaat dat zo:
- In wp-config.php voegt u de regel toe die de automatische aanroep uitschakelt (DISABLE_WP_CRON op true).
- In het beheerpaneel van uw hosting (Plesk, DirectAdmin, cPanel) maakt u een cron-taak aan die bijvoorbeeld elke vijf minuten wp-cron.php aanroept.
- U controleert een dag later in WP Crontrol of de taken netjes op tijd zijn gedraaid.
Dit is werk van een kwartier, mits u toegang heeft tot de hosting en de bestanden. Veel managed WordPress-hosters hebben dit standaard al zo ingericht. Twijfelt u, stel de vraag dan gewoon aan uw hostingpartij: “Draait de WordPress-taakplanner bij jullie via een systeemcron?” Een goede hoster weet meteen wat u bedoelt.
Wat u zelf kunt doen en wanneer u hulp inschakelt
Zelf kunt u zonder risico WP Crontrol installeren, de lijst bekijken en noteren welke taken u niet thuis kunt brengen. Ook het opschonen van ongebruikte plugins helpt vaak al: minder plugins betekent minder taken. Wees wel terughoudend met het handmatig verwijderen van taken en met wijzigingen in wp-config.php. Eén typefout daar en de site is even niet bereikbaar.
Hulp inschakelen is verstandig als de vertraging aanhoudt terwijl de lijst er schoon uitziet, als u een webshop draait waarin de Action Scheduler duizenden acties in de wachtrij heeft, of als u simpelweg niet aan bestanden op de server wilt zitten. Wie de site toch al periodiek laat nakijken via een onderhoudsabonnement voor uw website, kan dit rustig als aandachtspunt meegeven. Het hoort bij de dingen die een beheerder standaard controleert, net als de PHP-versie en de staat van de database.
Een voorbeeld uit de praktijk
Een installatiebedrijf uit Apeldoorn had een informatieve site met een klein offerteformulier. Ze klaagden dat de site “op maandagochtend altijd traag” was. Bezoek was er nauwelijks in het weekend, dus de eerste bezoeker op maandag trok een wachtrij van twee dagen aan taken in gang: drie mislukte back-uppogingen, een malwarescan en een synchronisatie van een nieuwsbriefplugin die niet meer werd gebruikt. Na het verwijderen van de dode taken en het overzetten naar een systeemcron was het probleem weg. Geen nieuwe hosting, geen nieuwe plugins, gewoon opruimen en anders aansturen.
Conclusie
De taakplanner van WordPress is geen fout, maar een compromis dat u moet kennen. Zolang de wachtrij kort is en uw site regelmatig bezoek krijgt, merkt u er niets van. Groeit de lijst of daalt het bezoek, dan wordt de planner een bron van onverklaarbare traagheid en gemiste taken. Bekijk deze week eens de lijst met geplande taken op uw site. Duurt het langer dan een minuut om de lijst te lezen, dan is het tijd om op te ruimen en de aansturing over te zetten naar de server. Dat past goed bij een bredere opruimronde, zoals beschreven in onze uitleg over het opruimen van plugins.
