@harrasteblogi JUURI NYT
--:--

Tilaa uutiskirje

Saat tuoreimmat 10 uusinta artikkelia kerran viikossa sähköpostiisi.

Tilaa uutiskirje

WordPressin custom scheduler -ratkaisut ilman WP-CroniaWP-Cron on WordPressin oletusajastusjärjestelmä, mutta se ei ole oikea cron. Se käynnistyy vain sivulatausten yhteydessä, mikä tekee siitä epäluotettavan suurissa tai vähäliikenteisissä järjestelmissä.

Tiivistelmä
Miksi WP-Cron ei riitä

WP-Cronin ongelmat:...

1. Oikea server cron (suositus baseline-ratkaisu)

Yksinkertaisin ja yleisin korvaaja:...

3. Custom scheduler + database queue

Yksinkertainen oma järjestelmä:...

4. Cron + queue hybrid (paras käytännön malli)

Server Cron ↓ Fetch due jobs ↓ Push to queue ↓ Workers process Tämä erottaa:...

5. Action Scheduler (de facto WordPress standard)

Paras valmis ratkaisu ilman WP-Cron-riippuvuutta....

8. Event-driven scheduler (moderni malli)

Event → Queue → Workers Esimerkki:...

9. Rate limiting scheduler

Tärkeä suurissa järjestelmissä:...

11. Priority-based scheduler

Jobit priorisoidaan:...

13. WP-CLI worker (suositeltu production-malli)

wp myplugin process-jobs Cron:...

14. Multi-worker scaling

cron → spawn multiple workers → parallel processing 15. Monitoring scheduler Seuraa:...

16. Retry & backoff

fail → retry in 1m → 5m → 30m → dead letter 17. Dead letter queue Jobit jotka epäonnistuvat:...

17. Dead letter queue

Jobit jotka epäonnistuvat:...

19. Yleisimmät virheet

Server Cron ↓ Scheduler Service ↓ Queue (DB/Redis) ↓ Workers ↓ Retry + Logging + Monitoring Yhteenveto WordPressin WP-Cron ei riitä vakaviin tuotantoympäristöihin, koska se...

20. Paras moderni scheduler-arkkitehtuuri

Server Cron ↓ Scheduler Service ↓ Queue (DB/Redis) ↓ Workers ↓ Retry + Logging + Monitoring Yhteenveto WordPressin WP-Cron ei riitä vakaviin tuotantoympäristöihin, koska se...

Yhteenveto

WordPressin WP-Cron ei riitä vakaviin tuotantoympäristöihin, koska se on liikenteeseen sidottu ja epädeterministinen. Paras ratkaisu on korvata se server cronilla ja rakentaa sen päälle joko...

Skaalautuvissa WordPress-ympäristöissä WP-Cron korvataan usein custom scheduler -ratkaisuilla, jotka perustuvat oikeaan server cron -ajoon tai erilliseen job queue -järjestelmään.

Tavoite on yksinkertainen:

  • ennustettava ajastus
  • ei riippuvuutta liikenteestä
  • parempi suorituskyky
  • kontrolloitu kuormitus

Miksi WP-Cron ei riitä

WP-Cronin ongelmat:

  • ei ajeta ilman liikennettä
  • voi kasaantua useita jobeja samaan requestiin
  • epädeterministinen ajastus
  • huono skaalautuvuus
  • vaikea monitorointi

Tyypillinen ongelmatilanne:

User request
↓
5 cron jobia käynnistyy
↓
TTFB kasvaa
↓
sivu hidastuu

1. Oikea server cron (suositus baseline-ratkaisu)

Yksinkertaisin ja yleisin korvaaja:

*/1 * * * * php /var/www/html/wp-cron.php

Tai WP-CLI:

wp cron event run --due-now

Hyödyt

  • tarkka ajastus
  • ei riippuvuutta liikenteestä
  • helppo debugata

Haitat

  • ei queue-logiikkaa
  • ei retry-mekanismia ilman lisärakennetta

2. WP-Cron pois käytöstä + server scheduler

wp-config.php:

define('DISABLE_WP_CRON', true);

Tämän jälkeen kaikki ajastus siirtyy serverille.

3. Custom scheduler + database queue

Yksinkertainen oma järjestelmä:

Taulu:

wp_jobs

Kentät:

  • id
  • hook
  • payload
  • run_at
  • status

Scheduler runner:

$jobs = $wpdb->get_results("
    SELECT * FROM wp_jobs
    WHERE run_at <= NOW()
    AND status = 'pending'
    LIMIT 10
");

Worker:

foreach ($jobs as $job) {

    do_action($job->hook, json_decode($job->payload));

    $wpdb->update('wp_jobs', [
        'status' => 'done'
    ], ['id' => $job->id]);
}

4. Cron + queue hybrid (paras käytännön malli)

Server Cron
↓
Fetch due jobs
↓
Push to queue
↓
Workers process

Tämä erottaa:

  • scheduling
  • execution

5. Action Scheduler (de facto WordPress standard)

Paras valmis ratkaisu ilman WP-Cron-riippuvuutta.

Esimerkki:

as_schedule_single_action(
    time() + 300,
    'process_order',
    ['order_id' => 123]
);

Hyödyt:

  • retry support
  • admin UI
  • scalable
  • WooCommerce käyttää tätä

6. Redis queue scheduler (high scale)

Arkkitehtuuri:

WordPress
↓
Redis list (jobs)
↓
Worker daemon
↓
Processing cluster

Push job:

$redis->lpush('queue', json_encode($job));

Worker:

$job = $redis->rpop('queue');

7. RabbitMQ / SQS -pohjainen scheduler

Enterprise-taso:

WordPress → Message Broker → Worker Fleet

Hyödyt:

  • erittäin skaalautuva
  • retry & dead-letter queues
  • observability

8. Event-driven scheduler (moderni malli)

Event → Queue → Workers

Esimerkki:

  • post published → trigger job
  • user registered → trigger email
  • order created → trigger sync

9. Rate limiting scheduler

Tärkeä suurissa järjestelmissä:

if ($active_jobs > 50) {
    delay_next_run();
}

10. Locking (vältetään tuplarun)

Ongelma:

2 workeria sama job

Ratkaisu:

  • Redis lock
  • DB lock
  • transient lock

Esimerkki:

set_transient('job_lock_'.$id, true, 60);

11. Priority-based scheduler

Jobit priorisoidaan:

HIGH: checkout sync
MEDIUM: email send
LOW: analytics

12. Delayed jobs

Esim:

run_at = NOW() + INTERVAL 10 MINUTE

13. WP-CLI worker (suositeltu production-malli)

wp myplugin process-jobs

Cron:

*/1 * * * * wp myplugin process-jobs

14. Multi-worker scaling

cron → spawn multiple workers → parallel processing

15. Monitoring scheduler

Seuraa:

  • job queue length
  • failed jobs
  • execution time
  • retry rate
  • memory usage

16. Retry & backoff

fail → retry in 1m → 5m → 30m → dead letter

17. Dead letter queue

Jobit jotka epäonnistuvat:

wp_failed_jobs

18. Avoid WP-Cron completely (best practice)

Production-säännöt:

  • DISABLE_WP_CRON true
  • server cron hoitaa triggerin
  • queue hoitaa executionin

19. Yleisimmät virheet

  • WP-Cron edelleen käytössä
  • liian raskaat cron hookit
  • ei queue-arkkitehtuuria
  • ei lockingia
  • ei retry-logiikkaa
  • kaikki samaan requestiin

20. Paras moderni scheduler-arkkitehtuuri

Server Cron
↓
Scheduler Service
↓
Queue (DB/Redis)
↓
Workers
↓
Retry + Logging + Monitoring

Yhteenveto

WordPressin WP-Cron ei riitä vakaviin tuotantoympäristöihin, koska se on liikenteeseen sidottu ja epädeterministinen. Paras ratkaisu on korvata se server cronilla ja rakentaa sen päälle joko queue-pohjainen scheduler tai käyttää Action Scheduleria.

Kun ajastus erotetaan suorituksesta ja lisätään queue, retry ja locking-mekanismit, WordPressistä tulee aidosti skaalautuva taustaprosessointialusta.

🍪