Dovrei disabilitare WP_CRON e attivare wp-cron.php dal server?

Non ci sono svantaggi nell'eseguire WP CRON utilizzando i cron job del server. In effetti, questa è la pratica raccomandata.

Secondo il Documento Ufficiale di Sviluppo Plugin WordPress:

WP-Cron non viene eseguito continuamente, il che può rappresentare un problema se ci sono attività critiche che devono essere eseguite in tempo. C'è una soluzione semplice per questo. Basta configurare il programmatore di attività del sistema per eseguire negli intervalli desiderati (o all'orario specifico necessario).

Per farlo, devi prima disabilitare il comportamento predefinito del cron in wp-config.php:

define('DISABLE_WP_CRON', true);

Quindi, programma wp-cron.php dal tuo server. Per Linux, significa:

crontab -e

Tuttavia, invece di eseguirlo nella riga di comando (CLI), eseguilo come una richiesta HTTP. Per questo puoi usare wget:

*/5 * * * * wget -q -O - https://your-domain.com/wp-cron.php?doing_wp_cron

WordPress carica tutti i file core necessari, i Plugin ecc. in wp-cron.php con il seguente CODICE:

if ( !defined('ABSPATH') ) {
    /** Configura l'ambiente WordPress */
    require_once( dirname( __FILE__ ) . '/wp-load.php' );
}

Quindi non preoccuparti che WordPress non carichi funzionalità importanti.

Ci sono un paio di svantaggi: Innanzitutto, quando si utilizza wp-cron.php come CLI, variabili come $_SERVER non sono impostate. Le persone superano questa limitazione utilizzando una richiesta curl a wp-cron.php invece.

In secondo luogo, poiché WP stesso non viene caricato con wp-cron.php; se si utilizza un plugin SMTP per le email, questo non verrà caricato quando si chiama wp-cron. Ancora una volta, utilizzare una chiamata curl supera questo problema. Curl sembra essere il metodo più frequentemente utilizzato.

Tuttavia; preferisco utilizzare wp-cli dopo aver impostato correttamente le impostazioni di postfix e (per nginx) la configurazione di php-fpm e aver impostato un crontab come il seguente:

*/5    *   *   *   *  wp cron event list --skip-plugins --skip-themes --path="/var/www/vhosts/example.com/httpdocs/wp" --fields=hook,next_run_relative --format=csv | awk -F, '$2=="now" {print $1}' | xargs -r wp --path="/var/www/vhosts/example.com/httpdocs/wp" cron event run $1

(Elenca tutti i cron con campi specifici in formato csv - hook è il nome del cron, next_run_relative è il tempo. Filtra quelli che mostrano 'now' come prossima esecuzione (quelli in scadenza ora) usando AWK, passa quella lista a xargs per chiamare wp cron event run $HOOK su ogni cron.) Utilizzare wp-cli carica WordPress correttamente (scelgo di saltare i plugin quando elenco i cron, poiché errori di codice e avvisi php potrebbero compromettere l'output dello script; ma non di saltarli quando eseguo il cron con xargs, poiché il cron potrebbe aver bisogno che i plugin siano caricati)

Spero che questo ti dia alcuni spunti su cosa prestare attenzione.

Non ho ancora trovato un vero svantaggio nell'esternalizzare wp-cron a un servizio esterno. Lo faccio da molti anni ormai.

Soprattutto nel mondo di oggi dove puoi eseguire applicazioni come microservizi.

Uso container Docker separati per ogni componente di WordPress - php, web, db, crontab, redis e così via). Avere crontab come container separato, che chiama wp-cron via http usando la rete locale, eseguendolo solo quando necessario.

Questo riduce lo stress sui nodi backend e migliora la sicurezza avendo una superficie di attacco più ridotta.

Se uno sviluppatore non riesce a capire come fare le cose senza dover chiamare wp-cron ad ogni caricamento di pagina, beh, questo parla solo della sua inesperienza. "Lasciarlo così", perché non si capisce come funzionano le cose, non è una buona ragione per mantenerlo.

Ci sono molte ragioni per non disabilitare il wp-cron. In effetti, è quasi impossibile trovare un caso d'uso valido per farlo. Non rallenta il tuo sito e viene utilizzato per funzionalità di cui potresti non essere a conoscenza.

Molti plugin utilizzano il WP-Cron per programmare azioni. Potrebbero comportarsi in modo anomalo se disattivi lo scheduler.

Ci sono numerosi tutorial su questo argomento perché crea confusione e perché disabilitarlo non ha un impatto immediato evidente sul sito. Ciò che farà, invece, è creare un mal di testa allo sviluppatore che dovrà risolvere il misterioso problema che causerà tra sei mesi.

Inoltre, il WP Heartbeat viene attivato ogni 15 secondi nell'area di amministrazione, risolvendo questo problema per il 99% delle persone che pensano di averne bisogno.