WordPress programmazione saltata indica che l’evento previsto per pubblicare un articolo non è stato eseguito nel momento programmato. WordPress usa WP-Cron, un sistema attivato normalmente dalle visite, e non un demone cron continuo.
Questa guida approfondisce WordPress programmazione saltata con verifiche progressive e reversibili. Non inviare password, cookie, token, chiavi private, codici 2FA o file di configurazione completi nei ticket.
Che cosa significa
Su siti con poco traffico l’evento può partire in ritardo. Loopback falliti, `DISABLE_WP_CRON`, cache, plugin e processi già in esecuzione possono impedire il trigger.
La timezone di WordPress determina l’orario editoriale. Una differenza tra timezone del sito, server e utente può far sembrare saltata una pubblicazione che è stata pianificata per un altro orario.
Come riconoscere il problema
- Il post resta programmato dopo l’ora prevista.
- Site Health segnala eventi cron in ritardo.
- Visitando il sito la pubblicazione parte.
- WP-Cron è disabilitato senza cron reale.
- Il loopback request failed compare nello stato del sito.
Cause più frequenti
1. Traffico insufficiente
Nessuna visita avvia WP-Cron vicino all’orario. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
2. Loopback non funzionante
WordPress non riesce a chiamare sé stesso. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
3. WP-Cron disabilitato
La costante è attiva ma manca un cron cPanel. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
4. Evento o lock cron
Un processo lungo impedisce nuove esecuzioni. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
5. Timezone errata
Il post è programmato in un orario diverso da quello atteso. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
6. Plugin o cache
Componenti di pubblicazione e ottimizzazione interferiscono. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
Diagnosi passo per passo
- Controlla timezone WordPress. Impostazioni → Generali. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Verifica eventi in Site Health. Cerca ritardi e loopback. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Leggi wp-config.php. Controlla `DISABLE_WP_CRON` senza modificarlo alla cieca. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Esamina cron cPanel. Verifica comando, frequenza e log. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Controlla eventi con WP-CLI. Elenca e avvia l’evento in ambiente controllato. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Analizza plugin e log. Cerca fatal error durante il cron. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Confronta più post. Stabilisci se il problema è generale o relativo a un contenuto. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
Metodo sicuro di diagnosi
Prima di modificare la configurazione, registra URL o servizio coinvolto, messaggio completo, data e ora, ultima modifica nota, client o rete e risultato ottenuto con un secondo strumento. Questa fotografia iniziale permette di confrontare i test e di tornare alla configurazione precedente quando una modifica non produce il risultato atteso.
Applica una sola correzione alla volta. Dopo ogni intervento ripeti esattamente la stessa operazione e controlla i log dello stesso intervallo temporale. Modificare contemporaneamente DNS, cache, PHP, plugin, proxy e firewall elimina la possibilità di attribuire il risultato a una causa precisa.
Controllo incrociato
Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin, Site Health e WP-CLI; per DNS interroga nameserver autoritativi e resolver pubblici; per la posta confronta Webmail, intestazioni originali e Track Delivery. Cache, TTL e code possono mostrare stati differenti per alcuni minuti.
Quando il problema sembra risolto, esegui una seconda prova con una nuova sessione, un secondo utente o una seconda rete quando applicabile. Verifica inoltre che TLS, autenticazione, WAF, permessi e controlli antispam restino attivi: una correzione che disabilita stabilmente le protezioni non è una soluzione definitiva.
Verifica prolungata dopo la correzione
Conserva temporaneamente backup, valori precedenti ed estratti dei log. Ripeti il controllo dopo il normale ciclo di cache, cron, coda o TTL. Se l’anomalia ricompare a intervalli regolari, confronta l’orario con backup, aggiornamenti, rinnovi SSL, rotazioni DNS, processi pianificati e servizi esterni.
Documenta il risultato finale con data, comando o schermata utilizzata e condizione verificata. Questa nota evita interventi duplicati e rende più rapida una futura analisi da parte dell’assistenza.
Procedura di risoluzione
- Configura un cron reale. Quando WP-Cron è disabilitato, usa cPanel con frequenza adeguata. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Ripristina loopback. Correggi DNS, HTTPS, autenticazione e WAF. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Correggi timezone. Usa una città o offset coerente. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Riduci eventi pesanti. Evita che backup e importazioni blocchino la coda. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Aggiorna plugin. Correggi componenti che alterano cron o pubblicazione. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Pubblica manualmente il post urgente. Dopo aver verificato contenuto e data. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Monitora gli eventi successivi. Conferma che nuovi post vengano pubblicati in orario. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
Come raccogliere prove utili
Quando riproduci il problema, conserva soltanto i dati tecnici necessari: codice di risposta, URL priva di token, orario con fuso, request ID, nome del client, dimensione del file o del messaggio e una breve descrizione dell’operazione. Evita screenshot parziali quando puoi esportare il testo originale, perché header, log e messaggi completi permettono una diagnosi più precisa.
Prima di chiudere il controllo, confronta il comportamento con una configurazione nota e funzionante. Per una API usa un payload minimo; per WordPress prova una funzione core senza plugin aggiuntivi; per DNS interroga direttamente i nameserver; per la posta usa Webmail e conserva il file `.eml`. Questo confronto riduce le ipotesi e impedisce modifiche inutili.
Controlli finali
- Post programmati pubblicati.
- Eventi cron non in ritardo.
- Loopback funzionante.
- Timezone corretta.
- Cron cPanel eseguito.
Prevenzione
- Cron reale per siti critici.
- Monitoraggio Site Health.
- Timezone documentata.
- Processi pesanti separati.
- Plugin aggiornati.
Errori da evitare
- Non impostare cron ogni minuto senza necessità.
- Non disabilitare WP-Cron senza alternativa.
- Non modificare date direttamente nel database.
- Non ignorare loopback failed.
- Non eseguire più cron concorrenti.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:
- URL o ID post
- orario previsto e timezone
- stato WP-Cron
- cron cPanel
- log e Site Health
Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.
Fonti tecniche ufficiali
Domande frequenti su WordPress programmazione saltata
WP-Cron è un cron reale?
No, normalmente viene attivato dalle visite al sito.
Un sito con poco traffico può pubblicare in ritardo?
Sì, se nessuna richiesta avvia WP-Cron.
Posso usare cPanel Cron Jobs?
Sì, soprattutto quando disabiliti WP-Cron e configuri un trigger reale.
La timezone influisce?
Sì, determina l’orario mostrato e programmato in WordPress.
Perché visitando il sito il post si pubblica?
La visita può avviare gli eventi WP-Cron scaduti.