WordPress DISABLE_WP_CRON configurato male

DISABLE_WP_CRON può essere corretto se esiste uno scheduler alternativo. Quando gli eventi restano scaduti, verifica prima quel meccanismo.

WordPress DISABLE_WP_CRON configurato male: significato

Non avviare tutti gli eventi di produzione senza conoscerne gli effetti.

Sintomi e cause probabili

Sintomi da verificare

• DISABLE_WP_CRON risulta impostato su true, ma gli eventi pianificati non vengono eseguiti con regolarità.
• Gli eventi dovuti si accumulano perché non esiste un cron di sistema equivalente oppure il comando configurato non viene avviato.
• Il cron di sistema utilizza un percorso WordPress errato, un utente non adatto oppure un comando che termina con errore.
• I log del cron non mostrano esecuzioni recenti oppure registrano errori nello stesso intervallo in cui gli eventi WordPress restano scaduti.

Cause probabili

• Il cron alternativo può mancare o terminare con errore.
• Percorso, utente o ambiente PHP possono non essere quelli del sito.

Diagnosi passo per passo

• Controlla il valore effettivo della costante e l’ultima esecuzione dello scheduler.
• Confronta gli eventi dovuti con il log del comando configurato.

Log e dati da controllare

• Messaggio completo e versione del componente coinvolto.
• Log del componente o di PHP nello stesso momento della prova, oscurando dati riservati.

Correzioni sicure

• Fai correggere percorso, utente e frequenza del cron previsto.
• Se torni a WP-Cron su visita, coordina la modifica con la rimozione dello scheduler equivalente.

Verifica finale

• Il valore di DISABLE_WP_CRON corrisponde al meccanismo di scheduling scelto.
• Il cron di sistema viene eseguito con il percorso WordPress, l’utente e la frequenza previsti.
• Gli eventi dovuti vengono elaborati senza continuare ad accumularsi.
• I log del cron non mostrano errori e non risultano configurati scheduler concorrenti non necessari.

Errori da evitare

• Non impostare DISABLE_WP_CRON su true prima di aver creato e verificato un meccanismo alternativo affidabile.
• Non copiare un comando cron da un altro account senza controllare percorso WordPress, binario PHP e utente di esecuzione.
• Non aggiungere più cron di sistema equivalenti per compensare eventi in ritardo: prima identificare perché quello previsto non viene eseguito.
• Non lanciare indiscriminatamente tutti gli eventi dovuti su produzione senza conoscere gli effetti dei callback applicativi.

Guide Xlogic correlate

• WordPress cron spawn failed: WP-Cron non parte
• WordPress WP-Cron: missed schedule
• WordPress WP-Cron: lock doing_wp_cron bloccato

Fonti tecniche

• Documentazione tecnica di riferimento

Domande frequenti