WP-Cron eller riktig cron: när ska du använda vad?

WP-Cron räcker för en vanlig företagssajt. Driver du en WooCommerce-butik, skickar nyhetsbrev från WordPress eller har inlägg som måste publiceras på minuten, byt till systemets cron. Det tar tio minuter: en rad i wp-config.php och ett cronjobb hos webbhotellet. Sätt upp cronjobbet först och stäng av WP-Cron sedan, annars står sajten utan schemaläggning däremellan.

Raden läggs i wp-config.php, ovanför kommentaren ”That’s all, stop editing!”.

PHP<?php
// Place this in wp-config.php above "That's all, stop editing!".
// Stops WordPress from spawning wp-cron.php on page views; the system cron takes over.
if ( ! defined( 'DISABLE_WP_CRON' ) ) {
	define( 'DISABLE_WP_CRON', true );
}

Cronjobbet kör de händelser som förfallit, var femte minut. Finns WP-CLI på servern använder du den första raden, annars den andra.

Terminal# Every 5 minutes: run every due WP-Cron event with WP-CLI. Adjust the path to your install.
*/5 * * * * cd /var/www/exempel.se/public_html && /usr/local/bin/wp cron event run --due-now > /dev/null 2>&1

# Without WP-CLI: fetch wp-cron.php over HTTP instead.
*/5 * * * * curl -s https://exempel.se/wp-cron.php > /dev/null 2>&1

Så fungerar WP-Cron

WordPress har ingen egen klocka. Vid varje sidvisning kontrollerar WordPress om någon schemalagd händelse har förfallit, och skickar i så fall ett anrop till wp-cron.php i bakgrunden. Besökaren märker inget, men jobbet körs alltså bara när någon tittar in.

Det ger tre problem som alla beror på trafiken.

• På en sajt med få besök körs ett inlägg schemalagt till 07:00 vid första besöket, kanske 09:30.
• Med sidcache på servern körs PHP inte ens vid de flesta besök, så chanserna blir ännu färre.
• Låset doing_cron gäller i 60 sekunder (WP_CRON_LOCK_TIMEOUT). Tar ett jobb längre tid kan nästa sidvisning starta en ny omgång medan den första fortfarande kör.

Dubbelkörningen är den som gör mest skada. Jag har sett den i en butik där en export till bokföringen tog ett par minuter, och samma ordrar skickades två gånger.

När WP-Cron räcker

Broschyrsajter, bloggar och de flesta företagssajter klarar sig utan riktig cron. Det som ligger i kön där är uppdateringskontroller, radering av gamla exportfiler och ett städjobb eller två. Ingen märker om de körs klockan nio i stället för sju. Ett cronjobb som ingen underhåller är sämre än WP-Cron, så låt det vara om sajten inte har något tidskritiskt.

Vad du vinner på riktig cron

Med DISABLE_WP_CRON slutar WordPress starta wp-cron.php från sidvisningar. Systemets cron anropar i stället sajten på fasta tider, oavsett trafik. wp cron event run --due-now kör alla förfallna händelser och respekterar samma lås som sidvisningarna gjorde, så den krockar inte med sig själv. Anropet via curl hamnar i samma lås i wp-cron.php.

I crontab skriver jag hela sökvägen till wp, eftersom cron inte har samma PATH som ditt inloggade skal. Cronjobbet ska köras som samma användare som webbservern, annars får cachefiler och loggar fel ägare.

Cronjobb hos svenska webbhotell

Hur du lägger upp jobbet beror på panelen. Här är de tre jag oftast möter.

Hos Loopia ligger funktionen i Kundzon under Lägg till / skapa… > Cron-jobb. Tjänsten anropar en webbadress med valt intervall och mejlar resultatet till dig. Det finns ingen crontab att redigera, så du anger adressen till wp-cron.php och väljer fem minuter. Hjälpsidan använder just fem minuter som exempel.

Oderland kör cPanel. Cronjobb finns under Advanced > Cron Jobs, och Oderland har en egen guide för WP-Cron som rekommenderar wget mot wp-cron.php var 5 till 15 minut. Där finns SSH, så WP-CLI-raden ovan fungerar också.

Hos Websupport väljer du domänen under Tjänster och klickar på Cron-jobb i vänstermenyn. Jobbet kan vara ett PHP-skript på kontot eller en HTTP-adress, och schemat skrivs i vanligt crontab-format ned till varje minut.

Saknar panelen cronjobb helt återstår en extern tjänst som anropar wp-cron.php på schema. Det fungerar, men då hänger sajtens schemaläggning på en tredje part.

WooCommerce och Action Scheduler

WooCommerce lägger sitt bakgrundsarbete i Action Scheduler: webhooks, analysimport och det som plugin som WooCommerce Subscriptions lägger i kö. Kön syns under WooCommerce > Status > Schemalagda åtgärder, eller med wp action-scheduler i terminalen.

Action Scheduler hänger på WP-Cron. Den registrerar händelsen action_scheduler_run_queue med intervallet every_minute, och varje körning tar högst 25 åtgärder på högst 30 sekunder. Utöver det startar den ett asynkront anrop vid sidvisningens slut, som mest en gång i minuten. Utan besök står alltså även den kön still, och det är därför butiker vinner mest på riktig cron.

Fallgropar

Det vanligaste felet är ordningen: raden i wp-config.php läggs in innan cronjobbet finns, och ingen märker det förrän en kampanj inte startar. Det näst vanligaste är ett cronjobb som anropar http:// på en sajt som omdirigerar till https://. Vissa anrop följer inte omdirigeringen, och jobbet ser ut att gå men gör inget.

Kontrollera jobbet en vecka efter bytet. wp cron event list ska visa framtida tider i kolumnen next_run_relative. Står det ”now” på flera rader körs inget. Har du inte SSH visar pluginet WP Crontrol samma lista under Verktyg, och Schemalagda åtgärder i WooCommerce ska ha en kort lista under Väntande.

Vanliga frågor

Hur ser jag om WP-Cron fungerar på min sajt?

Kör wp cron test, som försöker starta wp-cron.php och rapporterar om det gick. Kolumnen next_run_relative i wp cron event list visar ”now” för händelser som borde ha körts men inte gjort det. Saknar du SSH ger pluginet WP Crontrol samma lista under Verktyg.

Behöver en vanlig företagssajt riktig cron?

Nej. En sajt med formulär, några sidor och ett nyhetsflöde klarar sig med WP-Cron. Det enda som händer är att uppdateringskontroller och städjobb körs lite senare än planerat.

Vilket intervall ska cronjobbet ha?

Var femte minut räcker för de flesta sajter. Har du WooCommerce sätter jag varje minut, eftersom Action Scheduler själv vill köra sin kö en gång i minuten.

Kan jag köra både curl mot wp-cron.php och wp cron event run?

Det går men är onödigt. Båda respekterar låset doing_cron, så de kör inte samtidigt, men du får två saker att felsöka i stället för en. Välj WP-CLI om det finns på servern, annars curl.

Varför ligger WooCommerce-åtgärder kvar som Väntande?

Kön töms bara när action_scheduler_run_queue körs, och den hänger på WP-Cron. Står listan still över natten saknar sajten besök eller har DISABLE_WP_CRON utan cronjobb. Kör wp action-scheduler run för att tömma kön direkt.

Källor

• Hooking WP-Cron into the system task scheduler, WordPress Plugin Handbook
• wp cron event run, WP-CLI
• wp cron event list, WP-CLI
• wp-cron.php, låset doing_cron och WP_CRON_LOCK_TIMEOUT, WordPress-kärnan
• Action Scheduler, Performance (25 åtgärder per batch, 30 sekunder, en gång per minut)
• Action Scheduler, WP-CLI (wp action-scheduler run)