Indice dei contenuti
Programmi un articolo per le 9:00, ma alle 9:20 non è ancora online. Oppure un plugin dovrebbe inviare una notifica, aggiornare una cache o completare un’elaborazione in background, ma lo fa soltanto quando qualcuno visita il sito. ⏰ Se ti è successo, potresti aver incontrato una particolarità di WordPress: WP-Cron non funziona come il cron di Linux.
La differenza sembra piccola, ma diventa importante quando gestisci un sito poco visitato, un eCommerce o più progetti ospitati sulla stessa VPS.
Come funziona WP-Cron davvero?
WordPress mantiene un elenco di eventi pianificati. Per impostazione predefinita, quando arrivano richieste al sito controlla se ci sono attività da eseguire e tenta di avviarle. Questo approccio funziona senza richiedere l’accesso allo scheduler del sistema operativo, ed è uno dei motivi per cui WordPress può girare anche su hosting condivisi.
Il limite è evidente: se non arrivano visite o richieste in un determinato intervallo, un’attività può partire più tardi del previsto. Il problema non riguarda soltanto la pubblicazione programmata, ma anche plugin che dipendono dalle attività periodiche.
La documentazione ufficiale di WordPress sul sistema cron descrive proprio questa differenza.
Il cron di sistema lavora in modo diverso 🐧
Il cron di Linux è un servizio che avvia comandi secondo una pianificazione definita, indipendentemente dal traffico del sito. Puoi chiedergli di eseguire un’operazione ogni cinque minuti e, finché il servizio e l’ambiente funzionano, tenterà di avviarla agli orari stabiliti.
Questo non significa che garantisca il successo dell’attività: il comando può fallire, il server può essere spento e possono verificarsi sovrapposizioni. Significa però che la partenza non dipende da una visita al sito.
Quando ha senso passare a un cron di sistema?
Su un piccolo blog con traffico regolare, WP-Cron può essere sufficiente. Su un sito con poche visite, un portale con pubblicazioni programmate o un’applicazione che richiede maggiore prevedibilità, preferisco valutare un trigger esterno.
In un ambiente VPS, una soluzione comune consiste nel disabilitare l’avvio automatico di WP-Cron dalle richieste web e farlo eseguire periodicamente dal cron del server. Ma l’ordine delle operazioni è fondamentale: prima si configura e si verifica il nuovo trigger, poi si disabilita quello predefinito.
Un esempio con WP-CLI 🛠️
Se WP-CLI è installato e configurato per il sito, un comando utile è:
wp cron event run --due-now --path=/percorso/wordpressIl percorso è un esempio da sostituire. Il comando va eseguito con l’utente corretto del sito, non automaticamente come root. Puoi inserirlo in una voce crontab con una frequenza adeguata alle necessità dell’applicazione e registrare gli errori in un file di log protetto.
Solo dopo aver verificato che l’esecuzione funziona, puoi impostare nel file wp-config.php:
define( 'DISABLE_WP_CRON', true );Questa costante impedisce l’avvio automatico del sistema cron di WordPress: non crea da sola una pianificazione alternativa. Se la imposti senza aver predisposto un trigger funzionante, rischi di lasciare ferme le attività programmate.
Un’alternativa: richiamare wp-cron.php
In alcune configurazioni il cron di sistema richiama periodicamente wp-cron.php tramite HTTP. È un’opzione diffusa, ma va valutata rispetto alle regole di accesso, al firewall, alla cache e all’eventuale protezione dell’endpoint. Quando ho accesso a WP-CLI, preferisco spesso eseguire direttamente gli eventi dovuti, evitando di dipendere da una richiesta web esterna.
Non esiste però un’unica configurazione valida per tutti: l’importante è che lo scheduler sia osservabile, affidabile e compatibile con l’ambiente.
Come capire se qualcosa non funziona 🔍
Un controllo iniziale può essere effettuato con:
wp cron event list --path=/percorso/wordpressVerifico quali eventi sono in programma, se alcuni risultano scaduti e se ci sono errori applicativi. Nei siti con molti plugin possono esserci eventi frequenti o operazioni pesanti: non tutte devono necessariamente essere lanciate a intervalli molto brevi.
Per approfondire l’uso dei cron job lato Linux, ho scritto anche una guida su come automatizzare attività senza creare problemi. Il monitoraggio dei log resta altrettanto importante: ne parlo nell’articolo sul logging e monitoraggio di una VPS.
Attenzione alle esecuzioni sovrapposte ⚠️
Se un’attività dura più dell’intervallo previsto, una nuova esecuzione potrebbe partire mentre la precedente è ancora attiva. Per processi lunghi, come importazioni o sincronizzazioni, conviene verificare i meccanismi di locking e l’idempotenza delle operazioni.
Questo vale soprattutto per integrazioni che inviano email, creano ordini o chiamano API: una ripetizione involontaria può generare effetti reali. Una pianificazione affidabile richiede quindi sia un trigger regolare sia attività progettate per gestire gli errori.
La checklist prima di cambiare configurazione ✅
- Individuare gli eventi WP-Cron attivi e la loro frequenza.
- Verificare che WP-CLI o il metodo scelto funzionino con l’utente corretto.
- Configurare un cron di sistema e controllarne i log.
- Disabilitare WP-Cron sulle richieste web solo dopo il collaudo.
- Verificare pubblicazioni programmate, email e attività dei plugin.
- Controllare sovrapposizioni, errori e processi bloccati.
La scelta non è tra un sistema “buono” e uno “cattivo”. WP-Cron privilegia la compatibilità con tanti hosting; il cron di sistema offre maggiore controllo operativo. Su una VPS gestita direttamente, conoscere entrambi permette di scegliere la soluzione più adatta invece di intervenire soltanto quando un articolo resta in attesa. 🚀