Podatkovna baza spletne trgovine se v nekaj mesecih podvoji, čeprav se „ni nič spremenilo”, spredaj pa je stran hitra. Takrat so pogosto krive tabele Action Scheduler: več sto tisoč neuspešnih ali čakajočih opravil vtičnika, ki so ga že zdavnaj odstranili in ga sistem znova in znova poskuša izvesti.

V WordPressu vzporedno delujeta dva sistema opravil v ozadju, in če se kaj zatakne, je vredno pogledati oba:

• WP-Cron: vgrajeni razporejevalnik WordPress. Ne ravna se po uri strežnika, temveč po obiskih: ob vsakem nalaganju strani pogleda, ali je kakšno opravilo zapadlo.
• Action Scheduler: vrsta opravil, ki pride z WooCommerce in jo uporabljajo tudi številni drugi vtičniki (na primer Yoast SEO, MailPoet, vtičniki za naročnine in pošiljanje e-pošte). Njegova opravila čakajo v tabeli actionscheduler_actions, njegov dnevnik pride v tabelo actionscheduler_logs, izvajanje pa privzeto sproži WP-Cron.

Spodnje ukaze smo izvedli na testnem spletnem mestu z nameščenim WooCommerce v Terminalu gostovanja cPanel; osnove WP-CLI opisuje članek o uporabi WP-CLI.

Stanje Action Scheduler

Brez SSH ga lahko pogledaš tudi v skrbniškem vmesniku WordPress: na strani WooCommerce › Stanje lahko na zavihku načrtovanih dejanj (Scheduled Actions) filtriraš po stanju (čakajoče, neuspešno, končano) in imenu opravila (hook). Iz ukazne vrstice je hitreje:

cd ~/public_html
wp action-scheduler status

Data store: ActionScheduler_HybridStore
Runner: ActionScheduler_QueueRunner
Version: 4.1.0
status    count  oldest                      newest
complete  1      2026-10-27 19:56:51 +0000   2026-10-27 19:56:51 +0000
pending   2      2026-10-27 19:57:51 +0000   2026-10-28 03:00:00 +0000

Na zdravem spletnem mestu je število opravil pending (čakajoča) majhno, najstarejše pa čaka le nekaj minut; opravil failed (neuspešna) je malo in njihov vzrok je znan. Če čakajoča opravila čakajo že ure, se je zataknilo izvajanje; če je neuspešnih več tisoč, vtičnik ponavljajoče napaka.

Katero opravilo čaka ali je spodletelo v koliko izvodih?

wp action-scheduler action list --status=pending --fields=id,hook,group,scheduled_date --per_page=20
wp action-scheduler action list --status=failed --format=count
wp action-scheduler action logs 1234

Zadnji ukaz pokaže dnevnik opravila, z vzrokom napake. Pri večji množici je povzetek po imenih opravil hitrejši v SQL. Na strežnikih cPanel aWh wp db query ne deluje, zato uporabi ukaz mysql (nastavitev ~/.my.cnf z geslom opisuje članek o WP-CLI) ali poizvedbo zaženi v phpMyAdmin, s svojo predpono tabel:

P=$(wp db prefix)
mysql "$(wp config get DB_NAME)" -e "SELECT hook, status, COUNT(*) AS db FROM ${P}actionscheduler_actions GROUP BY hook, status ORDER BY db DESC LIMIT 20"

Stanje WP-Cron

wp cron event list --fields=hook,next_run_relative,recurrence
wp cron event list --due-now

Če je veliko opravil že zapadlih (--due-now), a se ne izvedejo, se WP-Cron ne zažene pravilno: na primer ker je obiskovalcev malo ali ker je DISABLE_WP_CRON vklopljen, namesto njega pa ni strežniškega časovnika.

Osirotela opravila WP-Cron (ki spadajo k odstranjenemu vtičniku in na njihov hook nič več ne posluša):

wp eval 'foreach ( _get_cron_array() as $ts => $events ) { foreach ( $events as $hook => $x ) { if ( ! has_action( $hook ) ) echo "brez lastnika: $hook\n"; } }'

Tako opravilo izbrišeš takole: wp cron event delete <hook>.

Čiščenje

Prej shrani podatkovno bazo (mysqldump, glej članek o WP-CLI), ker brisanja ni mogoče razveljaviti.

1. Brisanje osirotelih opravil

Poišči čakajoča ali neuspešna opravila, h katerim ne spada več noben vtičnik:

wp eval 'global $wpdb; foreach ( $wpdb->get_col( "SELECT DISTINCT hook FROM {$wpdb->prefix}actionscheduler_actions WHERE status IN (\"pending\",\"failed\")" ) as $h ) { if ( ! has_action( $h ) ) echo $h, "\n"; }' > ~/gazdatlan-feladatok.txt
cat ~/gazdatlan-feladatok.txt

Preglej seznam; če je ime znano in njegov vtičnik še potrebuješ, ga ne briši. Čakajoča opravila prekličeš po imenu:

while IFS= read -r hook; do wp action-scheduler action cancel "$hook" --all; done < ~/gazdatlan-feladatok.txt

Preklicana (canceled) in stara neuspešna opravila počisti naslednji korak.

2. Brisanje starih opravil in dnevnikov

Action Scheduler končana in preklicana opravila privzeto izbriše po približno enem mesecu. Neuspešnih ne, in če čiščenje iz kakšnega razloga ne teče, vse ostane. Ročno, v majhnih odmerkih:

wp action-scheduler clean --status=complete,failed,canceled --before='14 days ago' --batch-size=500 --pause=1

Zaradi premora med odmerki (--pause) čiščenje ne obremeni podatkovne baze in spletno mesto ostane hitro tudi med njim. Čas hrambe lahko skrajšaš z vtičnikom must-use (wp-content/mu-plugins/action-scheduler-megorzes.php):

<?php
/**
 * Plugin Name: Action Scheduler: 14-dnevna hramba
 */
add_filter( 'action_scheduler_retention_period', function () {
    return 14 * DAY_IN_SECONDS;
} );

3. Stiskanje tabele

Brisanje sprosti vrstice, tabela pa na disku ostane enako velika. Po velikem čiščenju zaženi v phpMyAdmin (z izbiro tabel, Optimiziraj tabelo) ali:

mysql "$(wp config get DB_NAME)" -e "OPTIMIZE TABLE ${P}actionscheduler_actions, ${P}actionscheduler_logs"

Zanesljivo izvajanje

WP-Cron sprožijo obiski, zato lahko v spletni trgovini z malo nočnega prometa opravila zamujajo ure, v konici pa težko opravilo upočasni nalaganje strani obiskovalca. Izvajanje zaupaj strežniku:

• Če spletno mesto upravlja WP Toolkit, na kartici spletnega mesta v razdelku Zmogljivost vklopi možnost Prevzem datoteke wp-cron.php.
• Ročno: WP-Cron izklopi v datoteki wp-config.php (define( 'DISABLE_WP_CRON', true );) in namesto njega v cPanelu nastavi opravilo cron. Korake opisuje članek o zamenjavi WP-Cron.

Pri prometni spletni trgovini lahko vrsto Action Scheduler izvajaš tudi v ločenem opravilu cron, v omejenih odmerkih, da ne zasede vseh procesov PHP. V vmesniku Opravila cron v cPanelu (skupina Napredno) na primer vsakih pet minut:

/usr/local/bin/wp --path=/home/felhasznalonev/public_html action-scheduler run --batch-size=25 --batches=4 > /dev/null 2>&1

Opravilo v ozadju, ki teče dlje od minute in je vsakič na istem mestu, opravlja neomejeno delo: to mora popraviti razvijalec vtičnika. Tudi veliko naročil, ki prispejo nenadoma (na primer med akcijo), lahko naenkrat načrtuje več tisoč opravil; če se spletno mesto takrat upočasni, poraba virov CloudLinux pokaže, v katero omejitev se zaleti račun.

Redno preverjanje

Enkrat na mesec poglej izpis wp action-scheduler status. Če je čakajočih opravil trajno na tisoče ali se neuspešna kopičijo, je to znak napake vtičnika in bolje je to opaziti v nekaj tednih kot čez leto, ko je podatkovna baza že velika več gigabajtov. Druge tabele podatkovne baze obravnavata članka o čiščenju tabel wp_options in wp_postmeta.