Il vero problema delle automazioni PHP in WordPress: troppi plugin, troppe risorse

Quando gestisci un’architettura web complessa, prima o poi ti scontri con la necessità di eseguire task in background. Che si tratti di pubblicare automaticamente articoli su un canale Telegram, aggiornare massivamente i link di affiliazione nel database o pulire vecchie revisioni, la reazione tipica del webmaster medio è cercare un plugin. Niente di più sbagliato.

Aggiungere plugin commerciali pesanti per eseguire semplici automazioni PHP in WordPress significa appesantire inutilmente il front-end, consumare RAM vitale e aumentare i tempi di caricamento (TTFB). Nell’officina di AFSI, la regola è il minimalismo estremo: i problemi si risolvono lato server, scrivendo codice pulito da inserire nella cartella mu-plugins (Must-Use Plugins). Questo approccio garantisce che le nostre automazioni vengano caricate ancor prima del tema e degli altri plugin standard, riducendo l’overhead al minimo assoluto.

Come funziona (male) il WP-Cron nativo sui server economici

Per capire come gestire correttamente le automazioni PHP in WordPress, devi prima comprendere come il CMS gestisce i task programmati. WordPress non ha un vero cron di sistema. Utilizza un sistema “finto” chiamato WP-Cron (wp-cron.php).

Ogni volta che un utente visita una pagina del tuo sito, WordPress controlla se ci sono task in sospeso. Se ci sono, tenta di lanciare una richiesta HTTP asincrona verso se stesso per eseguire lo script. Su hosting economici con piani base, questo approccio è un disastro per tre motivi:

1. Traffico irregolare: Se nessuno visita il sito alle 3 di notte, lo script di backup o di invio a Telegram non partirà mai a quell’ora, ma solo alla prima visita utile del mattino.
2. Effetto valanga: Se hai picchi di traffico improvvisi, il server spenderà cicli di CPU per controllare continuamente la coda del cron.
3. Timeout e memoria: I server condivisi di fascia bassa impongono limiti rigidi sui processi in background (es. massimo 30 secondi di esecuzione). Una query massiva sul database lanciata dal WP-Cron andrà in inesorabile Errore 500.

La soluzione custom: gestire le automazioni tramite mu-plugins e Transienti

Il modo corretto e gratuito per aggirare in parte queste limitazioni è prendere il controllo del codice. Invece di affidarti a interfacce grafiche pesanti, puoi registrare i tuoi task cron direttamente tramite uno script PHP in mu-plugins.

La chiave per far funzionare bene le automazioni PHP in WordPress senza distruggere le prestazioni è l’utilizzo dei transienti (Transients API) come meccanismo di “lock”. Questo evita che uno script di esecuzione prolungata venga lanciato due volte contemporaneamente se ricevi due visite simultanee.

Lo script PHP per l’operazione schedulata

Di seguito trovi lo scheletro di uno script PHP testato sul campo. Questo codice va salvato in un file (es. afsi-automazioni.php) e caricato via FTP nella cartella wp-content/mu-plugins/. Se la cartella non esiste, creala.

PHP

<?php
/**
 * Plugin Name: AFSI Automazioni Cron
 * Description: Gestione custom delle automazioni PHP in WordPress tramite WP Cron e Transienti.
 * Author: Antonino
 */

// Evita l'accesso diretto al file
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

// 1. Registra un intervallo personalizzato (es. ogni 10 minuti)
add_filter( 'cron_schedules', 'afsi_intervalli_cron' );
function afsi_intervalli_cron( $schedules ) {
    $schedules['dieci_minuti'] = array(
        'interval' => 600, // 600 secondi = 10 minuti
        'display'  => __( 'Ogni 10 Minuti' )
    );
    return $schedules;
}

// 2. Programma l'evento se non è già in coda
add_action( 'wp', 'afsi_attiva_automazioni' );
function afsi_attiva_automazioni() {
    if ( ! wp_next_scheduled( 'afsi_hook_automazione_primaria' ) ) {
        wp_schedule_event( time(), 'dieci_minuti', 'afsi_hook_automazione_primaria' );
    }
}

// 3. Esecuzione della funzione associata all'hook
add_action( 'afsi_hook_automazione_primaria', 'afsi_esegui_task_pesante' );
function afsi_esegui_task_pesante() {
    
    // NOME DEL TRANSIENTE DI LOCK
    $lock_name = 'afsi_lock_automazione';
    
    // Controlla se l'operazione è già in corso
    if ( get_transient( $lock_name ) ) {
        // Un altro processo sta già lavorando, interrompi per evitare accavallamenti
        return;
    }
    
    // Imposta il lock per 5 minuti (300 secondi)
    set_transient( $lock_name, true, 300 );
    
    try {
        /* 
         * ==============================================
         * INSERISCI QUI IL TUO CODICE CUSTOM
         * Es: Chiamate cURL verso le API di Telegram per @successeoggi_it
         * Es: Query di aggiornamento DB per i link Amazon ID ilnino-21
         * ==============================================
         */
         
         // Esempio: error_log("Automazione AFSI eseguita con successo.");
         
    } catch ( Exception $e ) {
        // Registra l'errore per il debug
        error_log( 'Errore Automazione AFSI: ' . $e->getMessage() );
    } finally {
        // Rimuovi il lock una volta terminata l'operazione
        delete_transient( $lock_name );
    }
}

Proteggere l’esecuzione con i Lock Transients

Osservando il codice, noterai la presenza dei comandi set_transient e delete_transient. Questa logica è fondamentale. Immagina di aver scritto un’automazione per inviare l’ultimo articolo al tuo canale Telegram. Se il server è sotto sforzo e WP-Cron viene triggerato due volte a distanza di un secondo, rischi di inviare lo stesso messaggio due volte.

Impostando un transiente prima di iniziare il lavoro pesante, diciamo a WordPress: “Ehi, sto già elaborando questa operazione, se ricevi altre richieste nel frattempo, ignorale”. Una volta che il blocco di codice personalizzato ha terminato il lavoro, il transiente viene cancellato, liberando la strada per la successiva esecuzione schedulata.

Il limite del Workaround e l’Infrastruttura Premium

Finora abbiamo visto come gestire le automazioni PHP in WordPress limitando i danni e usando in modo intelligente l’ecosistema nativo. Tuttavia, dobbiamo guardare in faccia la realtà: stiamo pur sempre sfruttando un workaround.

Se il tuo script in mu-plugins deve aggiornare migliaia di righe nel database per sostituire i vecchi link di affiliazione, o se deve elaborare array complessi scaricati da API esterne, il limite fisiologico del tuo piano di hosting si farà sentire. I server economici strozzano la potenza della CPU e bloccano i processi lunghi (Errore 500 PHP Time-out). Soprattutto, se non hai traffico, il tuo WP-Cron non scatterà mai.

L’unica soluzione definitiva per chi sviluppa seriamente sul web e gestisce architetture automatizzate è disattivare completamente il finto WP-Cron di WordPress e passare al Cron di sistema reale del server. E per fare questo, ti serve un’infrastruttura di livello superiore.

Disabilitare WP-Cron e attivare il Cron di cPanel su Serverplan

Quando sposti i tuoi progetti su un ambiente professionale come i server NVMe di Serverplan (che garantiscono dischi ultra-veloci e isolamento delle risorse), sblocchi la possibilità di gestire le tempistiche a livello di sistema operativo (Linux Crontab).

Ecco l’architettura definitiva che implemento sui miei progetti:

1. Spegni il cron fasullo di WordPress. Apri il tuo file wp-config.php e aggiungi questa riga subito dopo i dati del database:define('DISABLE_WP_CRON', true); Da questo momento in poi, le visite degli utenti non faranno più partire i tuoi task, azzerando il carico inutile sul sito.
2. Accedi a cPanel su Serverplan. Vai nella sezione “Cron Jobs” o “Operazioni Pianificate”.
3. Crea il vero Cron Job di sistema. Imposta un’esecuzione, ad esempio, ogni 5 minuti */5 * * * * e inserisci il comando per richiamare WordPress da riga di comando (CLI) bypassando i limiti del server web Apache o Nginx:

cd /home/tuoutente/public_html; /usr/local/bin/php -q wp-cron.php

In alternativa, puoi usare WP-CLI (sempre disponibile negli ambienti Serverplan ben configurati):wp cron event run --due-now >/dev/null 2>&1

Con questo setup, le tue automazioni PHP in WordPress girano con la precisione di un orologio svizzero, non pesano sui visitatori del sito, e godono di tutta la potenza di calcolo garantita dalla CPU del tuo piano Serverplan. Questo è il passaggio da smanettone a vero amministratore di sistema.

Se i tuoi script si bloccano, non cercare un altro plugin: aggiorna la tua infrastruttura.