DISABLE_WP_CRON = true non sigilla l'endpoint wp-cron.php; interrompe solo l'invio della richiesta di loopback da parte di WordPress. Il file rimane raggiungibile dal web, quindi chiunque può ancora interrogarlo e forzare un intero bootstrap di WordPress.

Quel punto di ingresso nascosto può sprecare CPU, memoria e worker PHP, specialmente sui siti ad alto traffico. Se pensavi di aver chiuso la porta, non è ancora così.

Perché questa impostazione viene spesso fraintesa

Quando WordPress esegue un task pianificato, tenta innanzitutto una rapida richiesta HTTP al proprio file wp-cron.php. Impostare DISABLE_WP_CRON su true comunica al core di saltare quella richiesta interna. Il core non modifica la configurazione del web server, né aggiunge alcun livello di autenticazione a wp-cron.php. Lo script rimane un URL pubblico che restituisce uno stato 200 anche se il processo PHP viene interrotto prematuramente.

Un attaccante che scopre l'URL può interrogarlo ripetutamente, costringendo WordPress a caricare ogni volta tutti i plugin, i temi e il database. Su un hosting condiviso o su un sito con un numero limitato di worker PHP, quel singolo endpoint può diventare un vettore di denial-of-service (DoS).

Cosa bisogna fare realmente

Per spostare i lavori pianificati a uno scheduler a livello di sistema (cron, systemd-timer, ecc.) e chiudere la porta pubblica, segui questi cinque passaggi.

1. Disabilita il loopback interno

Aggiungi la riga 

define( 'DISABLE_WP_CRON', true );

a wp-config.php. Questo impedisce a WordPress di tentare la propria richiesta HTTP, ma non blocca le chiamate esterne.

2. Blocca wp-cron.php a livello di web server

Con Nginx, ad esempio, inserisci un blocco location che restituisca 403 Forbidden:

location = /wp-cron.php {
    return 403;
}

Il server ora rifiuta la richiesta prima ancora che PHP venga avviato, eliminando il costo del bootstrap.

3. Aggiungi un mu-plugin come rete di sicurezza

Crea un plugin "must-use" (posizionato in wp-content/mu-plugins) che registri qualsiasi richiesta che raggiunga wp-cron.php ed esca con un errore 403. Questo intercetta le richieste che in qualche modo aggirano la regola del server—magari attraverso un hostname diverso o una regola edge di una CDN.

4. Sopprimi le chiamate asincrone di Action Scheduler

Molti plugin utilizzano la libreria Action Scheduler, che può generare le proprie richieste di loopback. Utilizza l'hook action_scheduler_queue_runner e interrompi l'esecuzione per le richieste non CLI, impedendo alla libreria di tentare di aprire le proprie porte.

5. Scollega il queue runner dall'hook WP-Cron

Rimuovi il queue runner predefinito di Action Scheduler che è collegato all'hook cron wp. Ciò garantisce che la coda venga eseguita solo quando la attivi esplicitamente da riga di comando.

Eseguire i job nel modo corretto

Con l'endpoint pubblico sigillato, usa lo scheduler di sistema per invocare WordPress una volta al minuto (o con la cadenza che preferisci) tramite WP-CLI:

wp cron event run --due-now

Quel singolo comando elabora gli eventi cron del core e la coda di Action Scheduler in un ambiente controllato, utilizzando lo stesso processo PHP che useresti per qualsiasi altro task CLI.

Benefici misurabili

  • Sicurezza – Nessun utente non autenticato può avviare pesanti processi in background.
  • Performance – I worker PHP rimangono disponibili per i visitatori reali; i picchi di memoria causati dalle chiamate cron erratiche scompaiono.
  • Affidabilità – La pianificazione diventa proattiva; sai esattamente quando viene eseguito un job perché è gestito dal cron di sistema, non dal caricamento di una pagina da parte di un visitatore.

Cosa monitorare dopo la modifica

Non fare affidamento sul codice di stato HTTP di wp-cron.php; potrebbe restituire ancora 200 anche quando viene bloccato da PHP. Invece:

  • Monitora la dimensione della coda di Action Scheduler. Una coda in crescita segnala spesso esecuzioni mancate.
  • Controlla i log del server per voci "403" provenienti dal blocco location di wp-cron.php.
  • Osserva il numero di processi PHP-FPM o FastCGI durante i picchi di traffico per confermare che il carico sia diminuito.

Una nota di cautela

Alcuni amministratori mantengono DISABLE_WP_CRON su false perché si affidano ai siti a basso traffico per attivare il cron in modo naturale. L'approccio sopra descritto elimina completamente questa dipendenza, ma aggiunge un passaggio di manutenzione: devi assicurarti che lo scheduler di sistema funzioni in modo affidabile. Se il daemon cron del server fallisce, i job pianificati si fermano. Abbina questa configurazione al monitoraggio del servizio cron di sistema per evitare questo problema.

In sintesi: impostare DISABLE_WP_CRON su true interrompe solo l'auto-ping di WordPress; non chiude l'endpoint pubblico wp-cron.php. Blocca il file a livello di web server, aggiungi un fallback tramite mu-plugin e instrada tutto il lavoro pianificato attraverso uno scheduler di sistema via WP-CLI. In questo modo proteggi il sito, riduci il lavoro PHP non necessario e ottieni un controllo preciso su quando vengono eseguiti i task in background.