Marzo 2026, sala da circa cinquanta persone, quasi tutti dev e sysadmin. WordPress Meetup Marzo 2026 è stato uno dei pochi appuntamenti in cui ho preso appunti tutto il tempo invece di stare al telefono. Il taglio della giornata era esplicitamente operativo: niente keynote, niente sponsor che parlavano di AI in astratto, solo case studies da chi sta in produzione con WordPress su scala medio-grande. Negli altri post di Fieldwork racconto progetti specifici di Romiltec: qui invece sono nei panni del partecipante, e il valore è in quello che tornavo a casa con appunti pieni.
Il taglio del meetup: WP come piattaforma editoriale, non come blog
Il filo conduttore degli interventi era netto. WordPress nel 2026 non è più il CMS del blog personale: è la spina dorsale di redazioni che producono centinaia di articoli al giorno, di gruppi multi-testata che gestiscono asset cross-brand, di piattaforme che integrano AI generativa nel workflow autoriale. Il meetup ha messo sul tavolo la realtà operativa di chi quel passaggio l’ha già fatto: non startup in pitch mode, ma squadre tecniche che ogni mattina aprono Grafana e guardano alert reali.
Sulla mia parte: ho parlato per circa trentacinque minuti dell’esperienza con AI Multisite e dell’homelab che uso come laboratorio R&D, lasciando una sessione di live coding con Claude Code in coda. Il talk vero di questo post è però quello degli altri, perché è da loro che sono arrivati i pattern più interessanti. I dettagli del mio intervento sono in coda al meetup ufficiale: qui sintetizzo i pattern trasversali, anonimizzando le testate citate per rispetto degli speaker.
Pattern uno: scaling di CMS write-heavy
Il primo intervento operativo veniva da un team che gestisce un network editoriale con picchi di pubblicazione di sette-ottocento articoli al giorno cumulati su una decina di testate. La parte interessante non era il read scaling (problema risolto da anni con FastCGI cache, edge cache su Cloudflare e una buona regola di invalidazione), ma il write scaling.
Tre cose da loro che ho preso in nota.
Database write hot path. L’autosalvataggio nativo di WordPress, di default ogni 60 secondi, su una redazione con sessanta autori contemporanei in editing genera carico significativo sulla tabella wp_posts e sulle revisioni. La loro mitigazione è stata triplice: alzare l’intervallo di autosave da 60 a 180 secondi (AUTOSAVE_INTERVAL in wp-config.php), limitare il numero di revisioni con WP_POST_REVISIONS a 10 invece dell’illimitato, e spostare le query di scrittura su un nodo MariaDB dedicato in scrittura via MaxScale o ProxySQL. Niente di sofisticato, ma fatto in modo coerente e misurato.
Object cache come prima linea di difesa. Redis come object cache (plugin di tipo Redis Object Cache) in modalità persistente, non sui default. La differenza non è nei numeri di benchmark sintetici, è nel comportamento sotto burst di pubblicazione: l’invalidazione mirata sulle metakey più scritte (_edit_lock, _edit_last, custom fields ricorrenti) abbassa la pressione sulla tabella wp_options quando esplode una notizia di breaking news.
Job queue separata da WordPress. Per i task secondari della pubblicazione (push notification, sync social, generazione embedding stilometrici, alert interni) hanno spostato l’esecuzione fuori da WP-Cron, su una coda Redis con worker dedicati Laravel o Bull-MQ. WP-Cron è notoriamente fragile sotto carico: girare in modalità system cron aiuta, ma non basta su questi volumi.
Pattern due: multi-tenant su infrastruttura condivisa
Il secondo case study è arrivato da chi gestisce decine di siti WP per clienti finali (modello agency tecnica), con un’infrastruttura condivisa basata su WordPress Multisite più alcuni siti standalone. Il loro problema dichiarato era la neighbor noise: un sito che ha un picco improvviso (articolo virale, scraping di un bot) sottrae risorse a tutti gli altri sullo stesso pool PHP-FPM.
La loro soluzione, raccontata con onestà tecnica, era un mix. Pool PHP-FPM separati per gruppi di siti omogenei (basso traffico raggruppati, medio-alto isolati), Cloudflare cache su tutto con regole di bypass per cookie di login, e fail2ban con regole specifiche su wp-login.php e xmlrpc.php per chiudere i bot di brute force che ti consumano i worker prima ancora di servire una pagina utile.
Il dettaglio operativo che mi ha colpito di più: non hanno scelto la strada del WordPress Multisite per tutti i clienti. Per i siti più importanti, con plugin specifici e tema custom, sono rimasti su installazioni singole. Multisite è comodo finché lo stack è omogeneo: appena un cliente vuole una versione diversa di un plugin commerciale, si rompe. La regola che hanno enunciato è secca: Multisite è un’ottimizzazione di gestione, non un dogma di architettura. Lo sottoscrivo. In Romiltec, per AI Multisite, abbiamo preso una strada diversa (siti WP indipendenti, hub centrale Laravel che parla via REST), proprio per non dipendere da quel vincolo.
Pattern tre: cache invalidation cross-site
Il terzo intervento ha affrontato un problema che a chi non lavora multi-testata sembra accademico, e a chi ci lavora è il problema più rognoso del mestiere: l’invalidazione di cache cross-site.
Lo scenario: un articolo pubblicato su Testata A viene clonato (con riscrittura AI o redazionale) su Testata B. La modifica del clone su B richiede un’invalidazione della home di B, dell’archivio della categoria su B, dei feed RSS di B. Nessuna interferenza con A. Finché lavori su un singolo sito, è banale. Quando ne hai venti collegati da una pipeline editoriale, ogni publish event genera una catena di invalidation che, se non è disegnata bene, o lascia stale (peggio per gli utenti) o purga troppo (peggio per il database).
La pattern che ha vinto in sala, raccontata da chi gira con un volume serio:
- Cache key namespaced per sito (prefisso
tenant_<id>_) in Redis e su Cloudflare via cache tag header - Webhook di publish dal CMS centrale verso ciascun sito target, con payload firmato HMAC, che triggera la purge mirata
- Purge a tag (su Cloudflare Enterprise, con
Cache-Tagheader) quando disponibile, fallback a purge per URL su piano Pro - Audit log delle invalidation, separato dai log applicativi, per tracciare chi ha purgato cosa quando
Il punto culturale: nessuno ha proposto la soluzione purgo tutto a ogni publish. Tutti hanno parlato di purge selettivo come scelta di disegno. È la maturità che ti aspetti da chi sta in produzione, non in tutorial.
Pattern quattro: AI editorial workflow
Quarto e ultimo blocco di pattern, in cui rientra anche il mio intervento. Qui le opinioni in sala erano più variegate, e mi è servito molto.
Il consenso tecnico, distillato dagli interventi:
Generazione AI come bozza, non come prodotto finale. Su questo, sorprendentemente, non c’erano voci dissonanti. Tutti gli speaker che hanno parlato di workflow AI hanno enfatizzato che il modello produce un draft (status: draft o equivalente) che richiede review umano prima della pubblicazione. La pipeline tecnica può essere sofisticata quanto vuoi, ma il commit alla pubblicazione è umano.
Stilometria autoriale come differenziatore. Tre speaker su quattro hanno menzionato la conservazione dello stile autoriale come problema centrale. È esattamente il taglio che noi su AI Multisite abbiamo formalizzato come metodologia (stilometria computazionale a 10 parametri come istruzioni per LLM): è confortante vedere che il problema viene riconosciuto come reale anche da chi affronta architetture diverse.
Costo per articolo, tracciato. Tutti i team mature loggano il costo per articolo (token in/out per provider, tariffa, totale in euro per pezzo). Chi non lo fa, prima o poi prende uno schiaffo dalla bolletta. La buona notizia è che con un wrapper sopra le SDK ufficiali (Prism PHP per Laravel, llm.openai per Python, simili) si fa in mezza giornata.
Provider routing. Tutti i team avevano almeno due provider disponibili in fallback, con regole di routing per costo, latenza e capability. La diversità di provider riportata in sala: OpenAI come primario in più della metà dei casi, Anthropic come secondario forte, Google Gemini come opzione su workload massivi a costo contenuto. Modelli locali (Ollama, LocalAI) erano presenti come option, raramente come primario in produzione editoriale.
Cosa mi sono portato a casa dal meetup
Tre cose, in ordine di urgenza operativa per Romiltec.
Una. L’idea della separazione wp-cron come system cron + job pesanti su queue Redis dedicata fuori WP è già implementata da noi su AI Multisite, ma ho preso nota di un dettaglio sul timeout dei worker che voglio rivedere settimana prossima. Se la job queue ha worker che vivono per ore, occupano connessioni DB con statement cache cresciuti: il restart soft ogni N job è un’igiene che a noi manca.
Due. Il pattern di purge a tag su Cloudflare lo stiamo usando, ma non lo abbiamo audit log separato. Vado a metterlo. Quando la prossima volta una purge di troppo butta giù la home di una testata in chiusura, voglio poter vedere chi l’ha triggerata in dieci secondi, non in dieci minuti di tail dei log applicativi.
Tre. Il punto sul costo per articolo è ben coperto da noi (lo logghiamo per tenant, modello, token e euro nella nostra pipeline AI). Ho però capito che dovremmo esporlo come dashboard pubblica al cliente finale, non solo come metrica interna. Se il cliente vede in tempo reale quanto sta spendendo in AI sulle sue testate, le conversazioni di rinnovo sono diverse.
Cosa NON è uscito dal meetup, e me lo segno
Niente sul disaster recovery cross-tenant. Tutti gli speaker hanno parlato di backup (Backblaze B2, Wasabi, S3 Glacier sono ricorsi più volte), ma nessuno ha aperto il capitolo un tenant viene compromesso, come isoli e ripristini senza toccare gli altri. Per chi gestisce decine di siti su infrastruttura condivisa è un buco. Su questo Romiltec ha lavorato seriamente nell’ultimo anno (migrazione backup B2 da region US a EU per compliance GDPR, con testing del restore per tenant), e mi sembra una conversazione che vale la pena portare a un prossimo meetup.
Niente di approfondito sull’accessibilità a livello di piattaforma. Quando hai cinquanta autori e una piattaforma di publishing, costringere ogni autore a rispettare AA è un problema architetturale, non culturale. Una sezione del meetup futuro su questo punto la pagherei volentieri.
Il meetup come laboratorio di confronto
L’osservazione di chiusura del meetup l’ha fatta uno degli organizzatori: qui non si vende, si confronta. Chi è venuto a vendere, lo abbiamo riconosciuto, e non torna. È la frase che riassume meglio perché torno a questi appuntamenti. Tre ore di confronto operativo, in cui un dev senior racconta come ha risolto un problema reale, valgono più di una settimana di letture su blog tecnici stranieri. Il valore è nel dettaglio italiano: i vincoli di banda dei provider locali, il taglio editoriale italiano, le aspettative dei clienti SMB nostrani. Su questi dettagli i case studies internazionali raramente parlano.
Il prossimo meetup su WordPress lo seguo. Se posso, parlo. Se non posso, prendo appunti. Tre ore di sala con cinquanta persone che fanno il mio mestiere sono il miglior R&D non strutturato che mi sia capitato di trovare in Toscana, e finora nessun corso a pagamento mi ha restituito quel tipo di valore.