WP-Cron ei ole päris cron – see töötab lehe laadimiste peal. Selgitame miks see probleem on ja kuidas väline cron Zone serveril seadistada.

Sisukord

WordPress sisaldab sisseehitatud ülesannete planeerijat – WP-Cron. See peaks käivitama ajastatud tegevusi: cache eelsoojendamine, e-kirjade saatmine, pluginate ajastatud toimingud, Action Scheduler järjekorrad. Teooria on hea. Praktika on problemaatiline.

WP-Cron ei ole päris cron. See on pseudo-cron, mis töötab lehe laadimiste peal – ajastatud ülesanded käivituvad ainult siis, kui keegi lehte külastab. Vaikne öine aeg, madala liiklusega sait, WP Rocket cache eelsoojendamine – kõik need eeldavad regulaarset käivitumist. WP-Cron eeldab regulaarset liiklust. Need kaks asja ei ühildu.

Mis on WP-Cron ja miks see on probleem

Iga kord kui WordPress saab lehe laadimise päringu, kontrollib see: “Kas on mõni ajastatud ülesanne, mis peaks käima?” Kui jah, käivitab selle. Kui ei ole külastajaid, ei käivitu miski.

See tekitab mitu probleemi:

Ebausaldusväärsus – ülesanne, mis on ajastatud kell 03:00 öösel, ei käivitu kui lehel ei ole sel ajal külastajaid. Madala liiklusega saidil võib ülesanne hilineda tunde.

Jõudlusprobleemid – kui cron ülesanded kogunevad (sest liiklus oli madal ja neid ei käivitatud), võivad need korraga käivituda suure liikluse hetkel – just siis, kui server on niigi koormatud.

Cache probleemid – WP Rocket ja teiste cache eelsoojendamine töötab cron-i peal. Kui cron ei käivitu regulaarselt, ei soojenda cache ette – esimene külastaja iga lehe peal genereerib lehe nullist.

Action Scheduler anomaaliad – WooCommerce, paljud pluginad ja ka näiteks Hundikuu Consent & Tracking kasutavad Action Schedulerit asünkroonsete ülesannete jaoks (sh Meta CAPI sündmused). Action Scheduler vajab regulaarset cron käivitamist. Ebaregulaarsel käivitumisel kogunevad ülesanded järjekorda – ja siis käivituvad korraga.

Lahendus 1 – väline cron, WordPress viis

Lihtsaim lahendus: keela WP-Cron ja asenda see päris välise cron-iga, mis käivitub serveri tasandil regulaarselt.

Samm 1 – keela WP-Cron wp-config.php-s:

// Lisa enne "That's all, stop editing!" rida
define('DISABLE_WP_CRON', true);

See peatab WP-Croni käivitumise lehe laadimistel – vähendab ka pisut serveri koormust.

Samm 2 – seadista väline cron Zone.eu serveril:

Zone.eu virtuaalserveri puhul CRON töid ei lisata mitte SSH kaudu vaid Perioodilised tööd (Crontab) sakis Zone halduses. Seal on üsnagi lihtne panna sobiv käsk sisse:

wp cron event run --due-now --path=[[$D2ND_A]]/htdocs/

Järgmises vaates valida iga 5 minuti tagant ning ongi korras. Server käivitab nüüd htdocs (vaikimisi lehe paigalduse koht) kaustas WordPress Cron käsu ning leht ei ole sõltuvuses lehe laadimisest. 5 minutit ning töö tehtud.

Lahendus 2 – .sh fail serveris (Elkdata meetod)

Keerulisemate keskkondade jaoks, kus on mitu saiti või spetsiifilised nõuded, on bash skript paindlikum lahendus. See on lähenemine, mida kasutame klientide serveritel mis on näiteks Elkdata (veebimajutus.ee) serverites. Seal ei ole võimalik WP CLI käivitamine otse. Saab küll PHP faili kaudu, aga see ei ole alati parim variant. Selle jaoks

Loo skriptifail:

#!/bin/sh

# Käivita ja ignoreeri kogu output
/usr/local/bin/wp cron event run --due-now --path=/www/apache/domains/www.sinudomeen.ee/htdocs >/dev/null 2>&1
EXIT_CODE=$?

# Kui error, väljasta ja käivita uuesti et näha mida läks valesti
if [ $EXIT_CODE -ne 0 ]; then
    echo "WP-CRON FAILED with exit code: $EXIT_CODE"
    echo "Running again to see error:"
    /usr/local/bin/wp cron event run --due-now --path=/www/apache/domains/www.sinudomeen.ee/htdocs 2>&1
    exit $EXIT_CODE
fi

# Muidu vaikus
exit 0

Salvesta see fail näiteks oma kodulehe juurkausta.

Tee fail käivitatavaks (käsurealt):

chmod +x /www/apache/domains/www.sinudomeen.ee/htdocs/cron.sh

Lisa Veebimajutus.ee halduses Crontab nimekirja fail ning valikuks käivitatakse süsteemselt otse. Ääremärkusena – veel mõnda aega tagasi täheldasime, et kui meiliteavitust sisse ei lülitata, siis Elkdata serverites Cron tööd ei toiminud sedasi. Järjekordselt nende veidrusi me testima ei hakka. Kui 5 minuti jooksul tööle ei hakka, siis tasub proovida variandiga – lülita teavitus sisse. PS: Seepärast on ka ülevalpool välja toodud scriptil teavitused välja lülitatud.

Lisaks. Sõltumata sellest, millise teenuspakkujaga on tegu – sellise lähenemisega on võimalik käivitada mitut käsku korraga. Näiteks praegust on hundikuu.ee, hundikuu.com, docs.hundikuu.com ning paar halduslehte sama virtuaalmajutuse peal. Selle asemel, et mitmeid CRON töid lisada, haldab seda kõike üksainuke shell script.

BASE="/data01/virt158923/domeenid/www.hundikuu.ee"
WP="wp --quiet"
LOG="$BASE/logs/wp-cron.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
MINUTE=$(date '+%M')

mkdir -p "$BASE/logs"

log() {
    echo "[$TIMESTAMP] $1" >> "$LOG"
}

log "--- WP Cron start (min: $MINUTE) ---"

# ee, com, docs — iga 5 minuti tagant (alati)
$WP cron event run --due-now --path="$BASE/htdocs/" >> "$LOG" 2>&1 &
PID_EE=$!

$WP cron event run --due-now --path="$BASE/com/"    >> "$LOG" 2>&1 &
PID_COM=$!

$WP cron event run --due-now --path="$BASE/docs/"   >> "$LOG" 2>&1 &
PID_DOCS=$!

# haldus — ainult iga 15 min (minutid 0, 15, 30, 45)
PID_LISALEHT=""
if [ $((10#$MINUTE % 15)) -eq 0 ]; then
    log "Haldus: 15 min tsükkel käivitub"
    $WP cron event run --due-now --path="$BASE/veelyksleht/" >> "$LOG" 2>&1 &
    PID_HALDUS=$!
fi

# Oota
for pid_var in $PID_EE $PID_COM $PID_DOCS $PID_LISALEHT; do
    wait "$pid_var" 2>/dev/null
done

log "--- WP Cron done ---"

# Hoia logi kompaktsena (max 500 rida)
tail -500 "$LOG" > "$LOG.tmp" && mv "$LOG.tmp" "$LOG"

See lähenemine on kasulik kui:

Ühe serveriga haldad mitut saiti
Tahad lisada logimist (lisa >> /var/log/wp-cron.log 2>&1)
Tahad lisada tõrkekäsitlust
Elkdata või sarnase haldussüsteemi kaudu käivitamine on vajalik

Action Scheduler – miks see eriti oluline on

Action Scheduler on WooCommerce’i ja paljude pluginate kasutatav järjekorrasüsteem asünkroonsete ülesannete jaoks. Hundikuu Consent & Tracking kasutab seda Meta CAPI sündmuste serveripoolseks saatmiseks.

Probleem WP-Cron-iga Action Scheduleri kontekstis:

Kui WP-Cron käivitub ebakorrapäraselt, kogunevad Action Scheduleri järjekorras olevad ülesanded. Näiteks: 50 CAPI sündmust on järjekorras. Esimene külastaja päeva esimesel külastusel käivitab WP-Croni, mis proovib kõik 50 ülesannet korraga käivitada. Server läheb aeglaseks, mõned ülesanded aeguvad, Meta saab ebatäpsed andmed.

Välise croniga käivitub Action Scheduler regulaarselt iga 5 minuti järel – ülesanded töödeldakse väikeste partiidena kohe kui need tekivad, mitte kogunenud hunniku kaupa hiljem.

Võimalus on ka Action Scheduler käivitada WP Cron käsust tihedamini. Meie tavalähenemine on keskmiste ja suuremate lehtede puhul käivitada AS iga 1 või 2 minuti tagant. Selle jaoks näiteks Zone keskkonnas lisame järgneva käsu Crontabi:

wp action-scheduler run --path=[[$D2ND_A]]/htdocs/ --quiet

Action Scheduleri seisundi kontroll:

WordPress admin → Tools → Scheduled Actions (WooCommerce peab olema installitud) või installi “Action Scheduler” plugin eraldi.

Vaata “Pending” ja “Failed” ülesandeid. Kui “Pending” kogub pidevalt ülesandeid ja need ei töötle, on cron probleem tõenäoliselt põhjus.

Kuidas kontrollida kas cron töötab

WP Crontrol plugin – tasuta, näitab kõiki ajastatud ülesandeid ja millal need viimati käivitusid. Hea diagnostikatööriist – näitab kohe kas mõni ülesanne on hilinenud.

Cron logi – kui kasutad .sh skripti logimisega:

*/5 * * * * /home/kasutaja/scripts/wp-cron-runner.sh >> /var/log/wp-cron.log 2>&1

Vaata logi:

tail -f /var/log/wp-cron.log

Action Scheduleri statistika – Tools → Scheduled Actions → näitab töödeldud, ootel ja ebaõnnestunud ülesandeid. Kui töödeldud ülesannete arv kasvab regulaarselt iga 5 minuti järel, töötab cron õigesti.

Kokkuvõte

WP-Cron on mugav vaikimisi lahendus, mis töötab enamikul väikestel saitidel piisavalt hästi. Aga niipea kui saidil on cache, Action Scheduler ülesanded, WooCommerce või muu ajastatud töötlus – muutub välise croni kasutamine oluliseks.

Zone virtuaalserveri puhul on seadistamine 10 minutit tööd. Tulemus: regulaarne ja usaldusväärne ülesannete käivitamine, parem cache eelsoojendamine, Action Scheduler töötab korrektselt ja server ei koge ootamatuid koormusnäppe.