Cos'è WP-Cron?

WordPress ha il suo pianificatore di attività integrato chiamato WP-Cron. Si occupa di tutto ciò che deve accadere secondo un programma: pubblicare articoli a un orario impostato, controllare gli aggiornamenti, inviare notifiche email, ripulire i sovraccarichi del database, eseguire attività in background dei plugin. Sembra ragionevole — finché non ti rendi conto di come funziona effettivamente. A differenza di un vero sistema cron che gira su un timer fisso, WP-Cron viene attivato solo quando qualcuno visita il tuo sito. Niente visitatori, niente cron. E quella scelta progettuale porta a tutta una serie di problemi.

Come viene attivato WP-Cron

Ogni volta che una pagina sul tuo sito WordPress viene caricata, WordPress controlla un elenco di eventi pianificati. Se uno è in ritardo, viene attivato durante quel caricamento della pagina. Il visitatore che ha attivato il controllo non vede nulla di diverso — le attività cron vengono eseguite (più o meno) in background. Ma è importante capire: non c'è un processo indipendente che continua a ticchettare. L'intero sistema di pianificazione fa l'autostop sul traffico HTTP in entrata.

Questa era una scelta pragmatica. WordPress è stato progettato per girare su hosting condiviso economico, dove non puoi installare servizi di sistema o accedere a crontab. L'approccio basato sul traffico ha garantito che le attività pianificate funzionassero immediatamente, su qualsiasi host, senza configurazione del server.

Dove questo va storto

Il design dipendente dal traffico presenta evidenti problemi che diventano più dolorosi man mano che il tuo sito cresce — o, paradossalmente, se non cresce abbastanza:

• I siti con poco traffico mancano la loro pianificazione. Se il tuo sito riceve 10 visite al giorno, gli articoli pianificati possono essere pubblicati con ore di ritardo. Un articolo impostato per le 8:00 andrà in onda solo dopo che qualcuno visiterà il sito dopo le 8:00 — che potrebbe essere nel pomeriggio se il tuo pubblico è in un fuso orario diverso. L'elaborazione degli ordini WooCommerce, le pianificazioni dei backup e i digest email subiscono la stessa sorte.
• I siti ad alto traffico sprecano risorse. Su un sito trafficato, WP-Cron viene attivato praticamente a ogni caricamento di pagina. WordPress controlla l'elenco degli eventi, valuta i timestamp e — la maggior parte delle volte — non trova nulla da fare. Questa è potenza di calcolo sprecata a ogni richiesta. Peggio: più visitatori simultanei possono attivare lo stesso controllo cron contemporaneamente, portando a race condition in cui la stessa attività viene eseguita due volte.
• Le attività di lunga durata rallentano i caricamenti delle pagine. Quando WP-Cron si attiva, le attività vengono eseguite come parte della richiesta di pagina. WordPress cerca di avviare una richiesta in background separata per il lavoro cron effettivo, ma su alcune configurazioni server questo fallisce silenziosamente e le attività vengono eseguite inline. Un plugin di backup che genera un dump del database da 500 MB può bloccare il caricamento della pagina di un visitatore se la connessione di loopback non funziona correttamente.
• La deriva del cron si accumula. Poiché gli eventi vengono eseguiti solo quando attivati dal traffico, la tempistica è nel migliore dei casi approssimativa. Un'attività pianificata ogni ora può essere eseguita alle 1:00, 2:17, 3:02, 4:45 — quando si verifica la prossima visita dopo l'orario pianificato.

Cosa gestisce effettivamente WP-Cron

Potresti rimanere sorpreso da quanto dipenda da questo sistema:

• Pubblicare articoli e pagine pianificati alla data e ora impostate
• Controllare gli aggiornamenti del core WordPress, dei plugin e dei temi
• Elaborare attività in background di WooCommerce (modifiche dello stato degli ordini, vendite pianificate, gestione dell'inventario)
• Eseguire plugin di backup automatici (UpdraftPlus, BackWPup, BlogVault)
• Inviare campagne email pianificate o digest
• Ripulire transient scaduti, articoli nel cestino e cronologia delle revisioni
• Elaborare attività in coda da plugin di moduli, plugin di abbonamento e plugin LMS
• Rinnovare i certificati SSL Let's Encrypt (su host che gestiscono questo tramite WordPress)

Se WP-Cron è inaffidabile, tutto questo diventa inaffidabile.

La soluzione: sostituire WP-Cron con un vero cron di sistema

La raccomandazione standard per qualsiasi sito che prenda sul serio la pianificazione è disabilitare il trigger basato sul traffico e sostituirlo con un vero job cron di sistema. È un processo in due fasi:

Passo 1: Aggiungi questa riga al tuo wp-config.php per impedire a WordPress di attivare cron a ogni caricamento di pagina:

define('DISABLE_WP_CRON', true);

Passo 2: Imposta un job cron di sistema per chiamare wp-cron.php a un intervallo fisso. La maggior parte dei pannelli di controllo dell'hosting (cPanel, Plesk) ha un gestore di job cron, oppure puoi usare crontab -e su un server che gestisci:

# Chiama WP-Cron ogni 5 minuti tramite wget
*/5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

# Alternativa con curl
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

# Alternativa con WP-CLI (consigliata per invocazioni locali, evita l'overhead HTTP)
*/5 * * * * cd /var/www/html && wp cron event run --due-now >/dev/null 2>&1

L'approccio WP-CLI è il più pulito perché non coinvolge una richiesta HTTP. Esegue gli eventi cron direttamente tramite PHP, evitando problemi con le connessioni di loopback, i timeout HTTP e l'autenticazione (ad es. HTTP basic auth sui siti di staging).

Hosting gestito e WP-Cron

Molti host WordPress gestiti (Kinsta, WP Engine, Cloudways, SiteGround) disabilitano il comportamento predefinito di WP-Cron e lo sostituiscono automaticamente con un cron lato server. Se utilizzi un hosting gestito, consulta la loro documentazione — potresti non dover fare nulla. Ma verifica che funzioni effettivamente, perché alcuni host impostano un intervallo molto lungo (ogni 30 minuti o anche ogni ora) che può essere troppo raro per le tue esigenze.

Sicurezza: l'endpoint wp-cron.php

Il file wp-cron.php è pubblicamente accessibile per impostazione predefinita. Visitarlo in un browser attiva manualmente il controllo cron. Sebbene non esponga dati sensibili, può essere abusato: un aggressore che inonda l'endpoint di richieste può far eseguire ripetutamente attività cron ad alta intensità di risorse, risultando in una condizione di denial-of-service.

Se sei passato a un cron di sistema, non c'è motivo per cui wp-cron.php sia raggiungibile pubblicamente. Puoi bloccare l'accesso esterno tramite la configurazione del tuo server web, mentre il cron di sistema può ancora invocarlo localmente.

Risolvere i problemi di WP-Cron

Se le attività pianificate non vengono eseguite come previsto, il plugin WP Crontrol è inestimabile. Aggiunge una pagina all'admin di WordPress che mostra tutti gli eventi cron registrati, la loro prossima ora di esecuzione pianificata e la loro frequenza. Puoi attivare manualmente qualsiasi evento, eliminare eventi bloccati o aggiungere nuove pianificazioni personalizzate. È il primo strumento da installare quando si diagnosticano problemi cron.

Come aiuta InspectWP

InspectWP verifica se il tuo file wp-cron.php è pubblicamente accessibile. Se sei passato a un cron di sistema e hai disabilitato WP-Cron integrato, l'endpoint non dovrebbe essere raggiungibile dall'esterno. Il report ti aiuta a confermare che la tua configurazione cron sia impostata correttamente e che tu non esponga un endpoint non necessario.