Cache Redis in WordPress mostra dati vecchi: diagnosi dell'object cache
- Wordpress
- 4 settembre 2026
Indice dei contenuti
Un prezzo viene aggiornato nel database ma il sito continua a mostrare quello precedente. Una configurazione modificata nel backoffice non arriva al frontend, oppure i dati tornano corretti solo dopo aver svuotato Redis. In questi casi si parla spesso genericamente di “cache”, ma WordPress può avere più livelli indipendenti: browser, CDN, page cache, object cache, transients e cache applicative dei plugin.
Redis usato come object cache persistente conserva oggetti fra richieste diverse. Se un componente aggiorna il dato originale senza invalidare la chiave corrispondente, WordPress può continuare a leggere una copia non aggiornata. Svuotare tutta la cache elimina temporaneamente il sintomo, ma non spiega perché la copia sia rimasta valida.
Come funziona l’object cache persistente di WordPress
La documentazione di WP_Object_Cache spiega che l’object cache riduce gli accessi al database conservando risultati costosi da rigenerare. Per impostazione predefinita la cache vive soltanto durante la richiesta; un backend persistente, come Redis, permette invece di riutilizzare i dati nelle richieste successive.
WordPress e i plugin salvano valori associandoli a una chiave e a un gruppo. Quando il dato cambia, il codice dovrebbe aggiornare o eliminare la voce pertinente. Se l’invalidazione manca, usa un gruppo errato o avviene soltanto in alcuni percorsi di aggiornamento, la cache può restituire un valore precedente.
Redis non è quindi necessariamente la causa. Può rendere visibile un difetto che con la cache non persistente scompariva alla fine di ogni richiesta.
Object cache, page cache e CDN non sono la stessa cosa
La page cache conserva una risposta HTML già costruita. L’object cache conserva oggetti e risultati usati da PHP durante la costruzione della pagina. Una CDN può memorizzare la risposta in un nodo esterno, mentre il browser può conservarla sul dispositivo dell’utente.
Per localizzare il livello responsabile conviene confrontare:
- risposta da utente autenticato e anonimo;
- pagina completa e dato recuperato direttamente dall’applicazione;
- richieste con bypass controllato della CDN o page cache;
- comportamento con object cache temporaneamente esclusa in staging;
- valore nel database e valore restituito dalle API WordPress;
- chiavi e gruppi coinvolti, quando gli strumenti lo consentono.
Se il sorgente HTML contiene già il dato vecchio, il problema precede il browser. Se una richiesta non memorizzata restituisce il valore corretto ma la pagina pubblica no, il livello da indagare può essere page cache o CDN. La diagnosi richiede prove controllate, non lo svuotamento simultaneo di ogni cache.
Perché Redis può restituire dati non aggiornati
Le cause più comuni dipendono dall’integrazione applicativa:
- una chiave non viene cancellata dopo l’aggiornamento;
- un’importazione scrive direttamente nel database evitando le API e i relativi hook;
- due percorsi aggiornano lo stesso dato ma solo uno invalida la cache;
- il codice usa chiavi non sufficientemente specifiche;
- una rete Multisite non separa correttamente dati locali e globali;
- ambienti diversi condividono involontariamente lo stesso database Redis o prefisso;
- un plugin conserva anche una propria cache oltre all’object cache;
- un processo asincrono ricrea la chiave con un valore precedente.
La sequenza temporale conta. Un valore che ricompare dopo pochi secondi può essere riscritto da un job; un dato vecchio presente solo su alcune pagine può dipendere da più livelli di cache; un problema limitato a una funzione custom può indicare una chiave applicativa gestita male.
Come diagnosticare una mancata invalidazione
La prova più utile è riprodurre un singolo aggiornamento osservando database, hook e cache. Bisogna annotare il valore prima e dopo, il percorso usato per modificarlo e il momento in cui il frontend torna incoerente.
Una procedura può includere:
- scegliere un dato non sensibile e riproducibile;
- verificare il valore originale nel database;
- modificare il dato attraverso il flusso che genera il problema;
- controllare quale codice dovrebbe invalidare la cache;
- confrontare una lettura con cache e una senza, in ambiente controllato;
- verificare se un task successivo riscrive il valore;
- correggere l’invalidazione e ripetere il test.
Nei plugin custom le API wp_cache_get, wp_cache_set e wp_cache_delete devono usare chiavi e gruppi coerenti. Per funzionalità recenti come lo svuotamento di un gruppo, WordPress raccomanda di controllare il supporto del backend tramite wp_cache_supports(), perché non tutti i drop-in implementano le stesse capacità.
Perché svuotare tutta Redis può essere rischioso
Il comando wp cache flush svuota l’object cache. La documentazione WP-CLI avverte che in un Multisite con cache persistente l’operazione può normalmente coinvolgere tutti i siti e avere un impatto sulle prestazioni.
Dopo un flush, molte informazioni devono essere rigenerate dal database. Su un sito trafficato questo può produrre un picco di query proprio mentre si cerca di risolvere il problema. Inoltre, se l’invalidazione è difettosa, il dato obsoleto tornerà non appena il percorso problematico ricrea la chiave.
Quando il backend lo supporta, eliminare una chiave o un gruppo mirato è più preciso. Anche questa operazione richiede però di conoscere ownership e dipendenze: cancellare un gruppo condiviso può influire su altre funzioni.
Redis e WordPress Multisite
In una rete Multisite alcune informazioni sono specifiche del singolo sito, altre sono globali. Il backend deve rispettare questa distinzione e usare prefissi che impediscano collisioni fra installazioni. Condividere la stessa istanza Redis non significa dover condividere tutte le chiavi.
Prima di migrare, clonare o creare uno staging bisogna verificare configurazione e prefissi. Un ambiente di test che legge o cancella chiavi della produzione può causare dati incoerenti e rendere la diagnosi molto più difficile.
I problemi di accesso Multisite richiedono invece un’analisi diversa: l’articolo sul login loop in WordPress Multisite tratta cookie, domini e HTTPS, che non vanno confusi con l’object cache.
Quando correggere il codice invece della configurazione Redis
Se il dato diventa corretto eliminando una chiave precisa ma torna obsoleto dopo lo stesso aggiornamento, la correzione probabilmente appartiene al flusso applicativo. Può servire usare le API WordPress invece di scritture dirette, collegare l’invalidazione all’hook corretto o riprogettare chiave e durata.
La configurazione Redis va esaminata quando esistono collisioni, connessioni intermittenti, prefissi errati o ambienti condivisi. Il plugin di object cache va inoltre verificato rispetto a versione di WordPress, server Redis e modalità di connessione realmente disponibili.
Quando serve una diagnosi della cache WordPress
Un flush occasionale dopo una modifica strutturale può essere previsto. Non è normale doverlo ripetere per rendere visibili prezzi, contenuti o impostazioni aggiornati. In quel caso serve individuare il livello che conserva il dato e il percorso che avrebbe dovuto invalidarlo.
Se WordPress continua a mostrare dati vecchi con Redis, posso analizzare object cache, page cache, CDN, transients, codice e processi asincroni per correggere la causa senza affidarsi a svuotamenti globali. Per approfondire il rapporto fra cache, query e plugin puoi leggere anche l’analisi sul database dei plugin WordPress.
