U had een nieuwsbericht ingepland voor maandagochtend 08:00 uur. Om half tien kijkt u op de site en het staat er niet. In het beheer staat achter het bericht de status “Gemist” of nog steeds “Gepland”. Bij een andere ondernemer is het de back-upplugin die al vijf dagen geen back-up heeft gemaakt, terwijl die dagelijks zou moeten draaien. En bij een webshop komt de herinneringsmail voor verlaten winkelwagens gewoon niet meer aan.

Al deze klachten hebben dezelfde bron: WP-Cron werkt niet, of niet goed genoeg. WP-Cron is de taakplanner van WordPress, en die werkt anders dan de meeste mensen verwachten. In dit artikel bespreken we de symptomen, de vijf oorzaken die wij het vaakst zien, hoe u zelf controleert wat er aan de hand is en hoe u de planner betrouwbaar maakt.

Hoe u merkt dat WP-Cron niet werkt

De taakplanner werkt op de achtergrond, dus u ziet hem nooit direct. U ziet alleen de gevolgen. De meest voorkomende signalen:

  • Ingeplande berichten en pagina’s verschijnen niet, en krijgen de status “Gemist”.
  • Back-ups worden niet of onregelmatig gemaakt.
  • Geplande e-mails van WooCommerce of een nieuwsbriefplugin worden niet verstuurd.
  • Updates worden niet gemeld of niet automatisch geïnstalleerd.
  • Statistieken of voorraadsynchronisaties lopen achter.
  • Onder Gereedschap, Sitegezondheid staat een melding dat geplande taken te laat zijn of dat de cron niet kan worden aangeroepen.

Merkt u één van deze dingen, dan is de kans groot dat er meer taken stil liggen die u nog niet heeft opgemerkt.

Waarom de planner anders werkt dan u denkt

Een gewone taakplanner op een server gaat af op de klok. Die van WordPress niet. WordPress kijkt bij elke pagina die een bezoeker opvraagt of er taken zijn die inmiddels hadden moeten draaien, en voert die dan uit. Geen bezoekers betekent dus geen taken. Hoe dat precies zit en waarom het ook uw site kan vertragen, leest u in onze uitleg over WP-Cron. Voor dit artikel is het genoeg om te weten dat de planner afhankelijk is van drie dingen: bezoekers, een server die zichzelf kan bereiken, en een takenlijst die niet is vastgelopen.

Vijf oorzaken waarom WP-Cron niet werkt

1. Te weinig bezoekers op het juiste moment

Een bericht gepland om 08:00 uur wordt pas gepubliceerd bij het eerste bezoek daarna. Op een rustige bedrijfssite kan dat elf uur zijn. Het bericht verschijnt dan te laat, en als WordPress vindt dat het te lang geleden is, krijgt het de status “Gemist”. Dit is geen fout, maar een eigenschap van het systeem.

2. De server kan zichzelf niet bereiken

Om de taken uit te voeren zonder de bezoeker te laten wachten, doet WordPress een verzoek aan zijn eigen adres, een loopback. Als de firewall van de hostingpartij dat blokkeert, als de server zijn eigen domeinnaam niet kent, of als een beveiligingsplugin het verzoek tegenhoudt, mislukt de loopback en blijven de taken liggen. In Sitegezondheid ziet u dit als een mislukt loopback-verzoek, vaak met een cURL-foutcode erbij.

3. WP-Cron is uitgeschakeld zonder vervanging

In wp-config.php kan een regel staan met DISABLE_WP_CRON op true. Dat is een goede instelling, mits er een echte cronjob op de server is die de planner elke paar minuten aanroept. Soms is die regel door een vorige beheerder of hostingpartij gezet en is de bijbehorende cronjob bij een verhuizing verdwenen. Dan staat de planner gewoon uit.

4. Een vastgelopen of overvolle takenlijst

De takenlijst staat in de database. Een plugin die bij elke aanroep een nieuwe taak toevoegt zonder de oude op te ruimen, kan die lijst laten uitgroeien tot tienduizenden regels. Het uitvoeren duurt dan zo lang dat het proces afbreekt, en er wordt niets meer afgewerkt. Ook een taak die een fout geeft kan de rest ophouden.

5. Caching die de aanroep tegenhoudt

Als elke pagina uit de cache komt, wordt WordPress zelf niet meer aangeroepen, en dus ook de planner niet. Goede cacheplugins houden daar rekening mee, maar servercaching bij de hostingpartij of een CDN dat alles opslaat, kan de planner grotendeels uitschakelen. Dit zien wij vooral bij sites die na een snelheidsoptimalisatie opeens problemen krijgen met geplande berichten.

Zelf controleren in vier stappen

  1. Kijk in Sitegezondheid. Meldingen over geplande taken, loopback of de REST API wijzen de richting.
  2. Installeer tijdelijk een cron-beheerplugin, zoals WP Crontrol. Die toont de hele takenlijst met de tijd waarop elke taak had moeten draaien. Staan daar taken van dagen geleden, dan is de planner inactief. Staan er duizenden regels van dezelfde plugin, dan is de lijst overvol.
  3. Open wp-config.php (of laat dat doen) en zoek naar DISABLE_WP_CRON. Staat die op true, vraag dan uw hostingpartij of er een cronjob is ingesteld.
  4. Roep de planner handmatig aan door in de browser uwdomein.nl/wp-cron.php te openen. Verschijnt het gemiste bericht daarna alsnog, dan werkt de planner op zich, maar wordt hij niet vaak genoeg aangeroepen.

De oplossing die bijna altijd werkt: een echte cronjob

De betrouwbaarste oplossing is de planner losmaken van bezoekers. U schakelt de ingebouwde aanroep uit in wp-config.php en laat de server zelf elke vijf minuten wp-cron.php aanroepen. Vrijwel elke hostingpartij biedt dat in het controlepaneel onder “cronjobs” of “geplande taken”; bij managed hosting is het vaak al standaard geregeld. Het resultaat is dat taken op tijd draaien, ook ‘s nachts, en dat bezoekers er nooit op hoeven te wachten.

Ruim daarnaast de takenlijst op. Verwijder plugins die u niet gebruikt maar die nog taken inplannen, en laat een specialist de tabel met opties nakijken als de lijst uit de hand is gelopen. Controleer tot slot bij uw cacheplugin dat de aanroep van wp-cron.php niet wordt gecachet.

Praktijkvoorbeeld: een accountantskantoor in Eindhoven

Een accountantskantoor in Eindhoven plaatste elke maandag een blog over fiscale actualiteiten, ingepland op zondagavond. Drie weken op rij bleef het bericht op “Gemist” staan. De marketingmedewerker publiceerde het dan maandag handmatig, wat op zich geen ramp was, tot bleek dat ook de wekelijkse back-up al zes weken niet was gemaakt.

De oorzaak was een combinatie. De site was recent naar een andere host verhuisd, waar een cronjob van de vorige host niet was meegekomen, terwijl DISABLE_WP_CRON nog wel op true stond. De planner was daardoor volledig uit. Na het instellen van een cronjob bij de nieuwe host liepen alle taken weer, en de back-up van die nacht was de eerste in anderhalve maand. Het kantoor controleert nu maandelijks in het onderhoudsrapport of de laatste back-up recent is. Wie zelf geen zin heeft in dat soort controles, kan dit meenemen in een storing laten oplossen of in een onderhoudsabonnement waar de planner standaard wordt bewaakt.

Samengevat

Gemiste berichten en uitgebleven back-ups zijn zelden toeval. Controleer eerst Sitegezondheid en de takenlijst, kijk dan naar wp-config.php en de cache, en stel een echte cronjob in als die er nog niet is. Daarna hoeft u nooit meer op maandagochtend te kijken of het bericht wel is verschenen.