Il WordPress Meetup Pisa del 12 marzo 2026 era dedicato a homelab, self-hosting e AI locale. Il mio intervento partiva dal laboratorio; nel lavoro su piattaforme editoriali, le stesse prove portano a domande su cache, processi e recupero dei dati.
Il programma ufficiale documenta il tema e lo spazio dedicato alla pratica. Qui raccolgo quattro verifiche che considero utili per chi porta WordPress in un ambiente da mantenere. Sono indicazioni operative mie, non una ricostruzione di interventi altrui.
Una modifica arriva davvero al lettore?
La prima prova è pubblicare o aggiornare una pagina e controllare cosa riceve un visitatore anonimo. Guarderei articolo, home, archivio e feed coinvolti. Una risposta REST aggiornata non garantisce che il proxy stia già servendo il nuovo HTML.
In questa revisione del blog ho incontrato proprio quel caso: il contenuto e i metadati erano aggiornati in WordPress, mentre la cache nginx continuava temporaneamente a mostrare la versione precedente. La verifica sulla URL pubblica ha permesso di distinguere salvataggio riuscito e risultato ancora vecchio.
La object cache di WordPress è un livello diverso dalla cache dell’intera pagina. La persistenza tra richieste dipende dall’implementazione disponibile. Aggiungere Redis non dimostra da solo che siano corrette invalidazione e chiavi degli oggetti.
Per ogni livello annoterei cosa conserva, per quanto tempo e quale evento invalida la copia. La procedura di purge deve essere limitata al sito interessato e verificata dopo l’esecuzione.
Le attività programmate hanno un esito osservabile?
WP-Cron controlla le attività in scadenza quando viene attivato dal caricamento delle pagine. Se il sito non riceve richieste, un’attività può partire più tardi dell’orario previsto. Un richiamo tramite scheduler di sistema può rendere più regolare l’attivazione.
Questo non risolve automaticamente timeout, dipendenze o duplicazioni del singolo task. Per un’integrazione esterna controllerei anche tentativi, errori e possibilità di rieseguire senza ripetere effetti indesiderati.
Se una lavorazione è pesante, valuterei una coda dedicata in base al carico e al controllo necessario. Il test comprende un errore del provider e un nuovo tentativo: una sola esecuzione riuscita non descrive il comportamento nei giorni difficili.
Gestire più siti significa scegliere quali componenti condividere
WordPress Multisite gestisce più siti dentro un’installazione, condividendo componenti del sistema. È una possibilità da confrontare con installazioni indipendenti in base a plugin, aggiornamenti e responsabilità dei diversi siti.
AI Multisite è il nome della piattaforma editoriale Romiltec, non un sinonimo della funzione nativa WordPress. Tenere chiara la distinzione evita di dedurre l’architettura dal nome del prodotto.
Nel dimensionamento chiederei quali risorse possono essere contese: worker PHP, database, CPU e storage. Separare un pool o un guest cambia una parte del perimetro, ma non elimina tutte le dipendenze comuni. Un picco su un sito è una prova da riprodurre osservando anche gli altri.
Il ripristino comprende tutti i dati necessari?
Per WordPress controllerei database, media e configurazione, inclusi eventuali oggetti conservati fuori dal server. Un backup recente dei file non dimostra la freschezza del dump del database.
Farei un recupero in un ambiente isolato, verificando pagine, media e accessi. Disattiverei gli effetti esterni della copia prima di avviarla: email, webhook e job non devono partire in parallelo all’originale.
La guida alla migrazione dei backup restic su B2 approfondisce copertura storica e verifiche. L’articolo su WordPress tra VM, LXC e Docker aiuta invece a scegliere l’ambiente di prova.
Il laboratorio è utile quando rende queste verifiche ripetibili. Per il contesto dell’intervento e i materiali, resta disponibile il recap del talk al meetup.