WP-Cron non funziona: risolvere articoli programmati, email e attività WooCommerce bloccate

Un articolo programmato che non viene pubblicato, attività WooCommerce in ritardo o azioni scadute possono segnalare un problema di WP-Cron. Non sono però prove definitive: il blocco può essere nella richiesta loopback, nel runner configurato sul server, nella coda Action Scheduler o nel codice di un singolo plugin.

Prima di modificare configurazioni o rilanciare eventi, individua il punto in cui il processo si interrompe. È essenziale per rinnovi, pagamenti e webhook: un’attività apparentemente ferma potrebbe avere già prodotto un effetto nel gateway di pagamento o in un servizio esterno.

Diagnosi rapida in 4 passaggi

1. Controlla se DISABLE_WP_CRON è attivo e se esiste già un runner alternativo.
2. Leggi il risultato di Strumenti → Salute del sito → Stato, soprattutto gli errori di loopback.
3. Distingui gli eventi WP-Cron dalle azioni di Action Scheduler usate da WooCommerce e da molte estensioni.
4. Se serve un runner esterno, configurane uno, testalo e solo dopo disabilita l’avvio di WP-Cron dalle richieste web.

1. Prima di intervenire

Verifica backup, ultimo evento riuscito e modifiche recenti

Assicurati di avere un backup ripristinabile. Annota l’ora dell’ultimo articolo pubblicato, dell’ultima email generata o dell’ultima attività completata correttamente e confrontala con le modifiche recenti: aggiornamenti di plugin, tema o PHP, migrazione dell’hosting, variazioni DNS, CDN, reverse proxy, firewall e regole di sicurezza.

Se il problema è iniziato subito dopo l’attivazione di Basic Auth in staging, la verifica da eseguire sarà diversa da quella necessaria dopo un aumento del carico del server o un cambio di piano hosting.

WP-Cron, loopback e Action Scheduler: cosa cambia

WP-Cron è il sistema con cui WordPress registra ed esegue eventi pianificati. Non è un processo sempre attivo come il cron di sistema: senza un runner esterno, gli eventi possono dipendere dalle richieste ricevute dal sito e quindi subire ritardi sui siti poco visitati.

Per avviare gli eventi dovuti WordPress può effettuare una richiesta HTTP interna tramite spawn_cron(). Questa è comunemente chiamata richiesta loopback. Con configurazioni particolari, incluso ALTERNATE_WP_CRON, il flusso può essere diverso: per la diagnosi conta verificare se gli eventi pianificati vengono realmente eseguiti.

Action Scheduler è invece una libreria per code asincrone usata da WooCommerce e da molte estensioni. WP-Cron può contribuire ad avviarla, ma i due sistemi non coincidono: un errore in una singola azione WooCommerce non prova che WP-Cron sia fermo, e un runner WP-Cron funzionante non corregge un callback difettoso.

2. Controlla configurazione, loopback ed eventi WP-Cron

Verifica DISABLE_WP_CRON

Cerca in wp-config.php questa costante:

define( 'DISABLE_WP_CRON', true );

Quando è impostata a true, WordPress non tenta di avviare WP-Cron durante le normali richieste web. È una configurazione corretta soltanto se un cron di sistema, WP-CLI o un runner fornito dall’hosting esegue già gli eventi.

Non rimuoverla automaticamente: può essere definita da variabili d’ambiente, bootstrap o configurazioni del provider. Verifica prima se esiste un task server-side e se viene eseguito con regolarità. La documentazione di WordPress descrive le costanti disponibili in wp-config.php.

Leggi l’errore completo in Salute del sito

Apri Strumenti → Salute del sito → Stato e conserva il testo completo dell’eventuale avviso, inclusi codice HTTP e messaggio cURL. Un errore di loopback è un indizio utile, ma non dimostra che ogni plugin, callback o servizio esterno sia guasto.

Un errore 403 porta a controllare WAF, ModSecurity, autenticazione HTTP e policy del proxy. Un timeout può dipendere da risorse insufficienti, da una chiamata che non riceve risposta o da un blocco di rete. Errori DNS e SSL richiedono verifiche sulla risoluzione del dominio dal server e sul certificato TLS.

Isola la causa della loopback

1. Riproduci il problema in staging oppure usa una modalità di troubleshooting che non disattivi le estensioni per i visitatori.
2. Controlla plugin, tema, mu-plugins e drop-in: gli ultimi due possono restare attivi anche disabilitando i normali plugin.
3. Verifica Basic Auth, restrizioni dell’ambiente, WAF e ModSecurity.
4. Controlla CDN, reverse proxy, DNS e risoluzione del dominio dal server.
5. Esamina access log del web server, error log PHP e log dell’applicazione.

Non attribuire il problema all’hosting senza evidenze: una protezione temporanea dell’ambiente o un plugin di sicurezza può bloccare la richiesta interna nello stesso modo.

Verifica gli eventi con WP-CLI

Se hai accesso SSH, WP-CLI aiuta a separare un problema di avvio automatico da un errore dell’evento. Per elencare gli hook registrati e le relative scadenze:

wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence

Per eseguire gli eventi già dovuti:

wp cron event run --due-now

Per provare un hook specifico, solo dopo averne valutato l’effetto:

wp cron event run nome_hook

I comandi sono documentati da WP-CLI per l’elenco degli eventi e per la loro esecuzione. Se gli eventi funzionano da CLI ma non in automatico, verifica loopback, traffico insufficiente o runner mancante. Se il comando restituisce un fatal error, un’eccezione o un timeout, controlla il callback, il plugin o tema responsabile e le risorse del server.

3. Se il problema riguarda WooCommerce, controlla Action Scheduler

Apri WooCommerce → Stato → Azioni pianificate. Filtra per data, stato, hook e gruppo, poi apri le attività rilevanti per leggerne i log. Il nome dell’hook e il messaggio registrato sono più utili del solo numero di azioni in coda. WooCommerce spiega il significato dell’interfaccia nella documentazione sulle azioni pianificate.

Come leggere gli stati

Action Scheduler può gestire le azioni rimaste in esecuzione secondo le proprie regole di timeout e recupero. Evita quindi pulizie forzate o cancellazioni dirette delle sue tabelle: non risolvono la causa del blocco e possono eliminare dati necessari alla diagnosi.

Email, gateway e webhook

WP-Cron può attivare eventi che generano email, ma WooCommerce non usa necessariamente una coda email separata: molte email vengono inviate durante gli eventi applicativi. Se WooCommerce registra l’invio ma il messaggio non arriva, controlla il mailer o il servizio SMTP/API effettivamente in uso, i log di consegna e l’autenticazione del dominio, inclusi SPF, DKIM e DMARC quando pertinenti.

Analogamente, un’azione completata conferma che WordPress ha concluso il proprio passaggio; non garantisce che un gateway o un endpoint webhook remoto abbia accettato o completato l’operazione.

Eseguire Action Scheduler da CLI

Dopo aver letto i log e solo per una coda che non contiene operazioni critiche da rieseguire, puoi verificare se è disponibile il comando:

wp action-scheduler run

Questo comando riguarda la coda Action Scheduler; wp cron event run --due-now riguarda invece gli eventi WP-Cron. Uno non sostituisce automaticamente l’altro. Per un e-commerce che dipende da Action Scheduler, pianifica e monitora il runner appropriato alla coda effettivamente usata dal sito.

4. Scegli il runner adatto

WP-Cron standard

Il comportamento predefinito è spesso adeguato per siti con traffico sufficiente, loopback funzionante e automazioni non critiche. Se DISABLE_WP_CRON è stato attivato per errore e non esiste un runner alternativo, puoi rimuoverlo oppure impostarlo a false, dopo avere verificato la configurazione dell’hosting.

Cron di sistema o task dell’hosting

Per e-commerce, abbonamenti, membership e siti poco visitati è preferibile un task server-side, perché non dipende dalle visite. La documentazione WordPress spiega come collegare WP-Cron allo scheduler di sistema.

Se il provider offre un pannello per i cron job, usa il comando, l’intervallo e il sistema di log indicati dal provider. Un runner HTTP verso wp-cron.php resta dipendente da DNS, SSL, Basic Auth, WAF e proxy; non è quindi la scelta adatta per aggirare un problema di loopback. Configura e verifica il task prima di disabilitare l’avvio web con DISABLE_WP_CRON.

WP-CLI come runner

Su VPS, server gestiti e ambienti con SSH, WP-CLI evita la dipendenza dalla richiesta HTTP e rende più leggibili gli errori. Un esempio da adattare a percorso, binario e utente Unix è:

*/5 * * * * cd /percorso/del/sito && /usr/local/bin/wp cron event run --due-now --quiet

Se il sito usa anche Action Scheduler, verifica separatamente come viene eseguita quella coda. Un runner corretto non risolve callback difettosi, API non raggiungibili o plugin che non registrano gli hook.

ALTERNATE_WP_CRON

WordPress prevede anche un meccanismo alternativo basato su redirect:

define( 'ALTERNATE_WP_CRON', true );

Può essere utile in casi specifici, ad esempio per articoli programmati non pubblicati, ma va testato prima in staging. Non sostituisce un cron di sistema e non è una soluzione generale per code WooCommerce, loopback o errori nei callback.

5. Verifica la correzione

Aprire wp-cron.php nel browser o vedere una pagina bianca non dimostra che gli hook siano stati elaborati. Esegui invece un test controllato: crea un articolo di prova, programmano la pubblicazione a pochi minuti di distanza e verifica che venga pubblicato all’orario previsto. Controlla poi gli error log PHP e server per almeno un ciclo del runner.

Per un controllo tecnico più preciso, la guida ufficiale di WordPress sul test semplice di WP-Cron mostra come verificare l’esecuzione di un evento pianificato. In WooCommerce, controlla inoltre che nuove azioni non commerciali vengano elaborate senza accumulare ritardi.

Se il runner è sano ma una specifica azione continua a fallire, concentrati sull’hook, sul log dell’azione, sul plugin responsabile, sulla chiamata API esterna e sulle risorse del server. Per automazioni commerciali o siti con poco traffico, un runner server-side verificato e monitorato è più affidabile del solo WP-Cron basato sulle visite.