L’incubo che è wp-cron.php

Una grande lamentela che ho con WordPress è l’implementazione predefinita di wp-cron.php. Se avete familiarità con il modo in cui WordPress utilizza wp-cron.php per impostazione predefinita, potreste voler passare alla prossima sezione di questo articolo.

Il file wp-cron.php è la parte di WordPress che gestisce gli eventi programmati all’interno di un sito WordPress. Tutto ciò che ha a che fare con la programmazione di post o pubblicazioni e davvero tutto ciò che è orientato alla data/ora è governato dal file wp-cron.php.

Perché wp-cron.php funzioni correttamente, deve essere eseguito frequentemente, ma non più di una volta al minuto. Tuttavia, il comportamento predefinito non richiede di impostare un vero cron job a livello di sistema sul tuo server. Invece, usa un metodo piggyback su ogni richiesta in arrivo. Quando una richiesta entra nel sito, WordPress genererà un’ulteriore richiesta da se stesso al file wp-cron.php su HTTP(S). Sembra abbastanza innocuo, vero?

Perché il comportamento predefinito di wp-cron.php è un incubo?

Il metodo predefinito funziona perfettamente su un piccolo sito con pochi visitatori all’ora. Tuttavia, quando viene implementato su un sito medio o grande o anche su un sito che viene analizzato dai bot (che è molto comune in questi giorni), questo significa che si ottiene il doppio del traffico che si sta gestendo attualmente. Diventa un rudimentale attacco DDoS contro voi stessi. Questo perché il cron viene eseguito più volte al minuto utilizzando una richiesta HTTP. La richiesta HTTP genera un overhead aggiuntivo dovendo generare, negoziare e stabilire la connessione su un socket di rete. Ha anche un impatto sulla capacità effettiva del vostro server web sottostante. Questa soluzione non va bene nella maggior parte delle situazioni, e onestamente, dovrebbe essere rimossa come comportamento predefinito a causa della sua propensione ad essere abusata o trasformata in un vettore di attacco su un server solo dal traffico regolare.

Bene, quali sono le alternative?

L’unica vera alternativa e la soluzione molto migliore è configurare un regolare cronjob di sistema che esegua lo script wp-cron.php direttamente attraverso PHP ogni minuto. Questo assicura che tutti i compiti programmati siano effettivamente eseguiti all’ora prevista. Inoltre non dovrebbe essere fatto tramite una richiesta HTTP ma un’esecuzione diretta di PHP per evitare di ostacolare la capacità del server web o di generare ulteriore memoria sul livello di rete.

Come faccio a disabilitare il comportamento predefinito di wp-cron.php?

Questo è abbastanza universale e semplice da fare. Devi aggiornare il tuo file wp-cronfig.php per includere la seguente impostazione:

define('DISABLE_WP_CRON', true);

• Di solito puoi trovare il tuo file wp-config.php nella directory public_html del tuo sito.
• Questa nuova impostazione dovrebbe essere messa nel file subito dopo la linea del database DB_COLLATE che assomiglia alla seguente

define('DB_COLLATE', '');

Come posso impostare un cron job di sistema?

Questo è semplice in cPanel, assumendo che il tuo fornitore di hosting abbia abilitato la funzione cron job sul tuo account. La documentazione di cPanel Cron Jobs va in maggiori dettagli, ma essenzialmente si fa:

1. Login a cPanel per il tuo dominio: yourdomain.tld/cpanel
2. Inserire “cron” nella casella di ricerca rapida vicino alla parte superiore della pagina.
3. Cliccare “Cron Jobs” icona che appare.

• Se non appare, il tuo account non ha la funzione Cron Jobs abilitata e dovrai parlare con il tuo fornitore di hosting per un aiuto per impostare il cron o passare a un pacchetto che include la funzione Cron Jobs.

1. Fai attenzione alla pagina Cron Jobs, ti fornirà la posizione esatta del tuo binario PHP. Dovrai copiare quel percorso nella casella di comando in fondo alla pagina e modificare il file che viene eseguito da PHP per essere il tuo file /home/username/public_html/wp-cron.php. Usando il percorso completo.
2. Seleziona la prima voce (“*”) per ogni parametro. Questo eseguirà il file wp-cron.php ogni minuto.
3. Clicca il pulsante add cron e hai finito.

Perché sei così duro con questa pratica, sembra ragionevole e facile da risolvere?

Credo che sia compito degli ingegneri del software che sviluppano il nostro mondo digitale imprimere a se stessi un senso di responsabilità per i loro prodotti. WordPress è onnipresente in questi giorni e con software di installazione automatica, come Softaculous, WordPress viene installato su una grande maggioranza di siti. Sono installati con il comportamento predefinito abilitato, che è essenzialmente un vettore di attacco su qualsiasi server. Ora con l’industria dell’hosting che è così prevalente nelle nostre vite, molte persone hanno siti WordPress e non sanno di questo problema fino a quando non paralizza il loro sito. L’integrazione predefinita è dolorosamente inadeguata e dovrebbe essere rimossa. Oggi su un solo server, ho trovato oltre 500 diverse installazioni di WordPress e ho visto come un bot ha colpito ogni sito sul server. Ognuno di quei siti è diventato improvvisamente una responsabilità per la stabilità del server.

Mi rendo conto che questo problema viene gestito caso per caso. Tuttavia, con così tante installazioni in tutto il mondo, sarebbe meglio affrontato da WordPress piuttosto che da ogni singolo fornitore di hosting che deve impostare condizioni speciali sul proprio server per proteggere dal buco che questo software genera. Il costo di rimuovere questo comportamento e costringere i proprietari del sito a generare un cron di sistema dovrebbe essere la linea di base e un avviso collocato all’interno dell’interfaccia di amministrazione di WordPress che le attività programmate non saranno eseguite fino a quando un lavoro cron di sistema non sarà creato correttamente. Questo rientra nelle mie capacità di programmazione, quindi so che è ben all’interno delle loro.

WordPress mira alla facilità d’uso, quindi i loro consumatori target sono quelli che in genere sanno poco di caveat di hosting. Credo che la responsabilità qui sia interamente di WordPress per risolvere e loro hanno preso la posizione contraria. Nel frattempo, gli amministratori di sistema nel settore dell’hosting devono soffrire per questa terribile “caratteristica” quando esaminano i server che sono caduti fuori controllo a causa di un bot in esecuzione su un’installazione predefinita di WordPress.