corpusctl vs WordPress: cosa guadagni e a cosa rinunci

corpusctl non renderizza mai una pagina. Non c'è uno strato di temi, né una gerarchia di template, né un ordine degli hook su cui ragionare. Il read client è l'interfaccia primaria, non un' aggiunta.

#Cosa succede davvero quando qualcuno legge il tuo post

WordPress: la richiesta raggiunge PHP, PHP interroga MySQL, i plugin girano, il tema renderizza. Poi metti un plugin di caching davanti, poi magari una CDN davanti a quella, e spendi tempo reale sull'invalidazione della cache — perché la pagina è calcolata e la cache è una copia di un calcolo che potrebbe cambiare in qualsiasi momento.

corpusctl: la pubblicazione esegue la pipeline di build. Il contenuto viene validato, renderizzato e scritto in un file immutabile e indirizzato tramite hash nell'object storage; il manifest viene aggiornato. Il client di un visitatore risolve lo slug in uno shard del manifest localmente, poi recupera quell'indirizzo dalla cache edge nginx.

Poiché l'indirizzo è un hash del contenuto, lo stesso indirizzo non può mai restituire contenuti diversi — quindi è memorizzabile nella cache per trenta giorni senza una strategia di invalidazione. La pubblicazione scrive un nuovo indirizzo. Non c'è nulla da purgare.

Due richieste HTTP, entrambe dalla cache. Nessuna raggiunge l'API. Nessuna raggiunge PostgreSQL.

Il numero che ne consegue: il traffico dei visitatori non carica affatto il tuo percorso di scrittura. Un editor che salva una bozza durante un picco di traffico non compete con il picco.

#La superficie dei plugin è anche la superficie di attacco

L'ecosistema di plugin è il maggior punto di forza di WordPress, ed è la stessa frase del suo maggior rischio operativo. Ogni plugin è codice di terze parti che gira nel tuo processo con accesso al database. Un sito con trenta plugin ha trenta flussi di aggiornamento e trenta potenziali CVE, e il plugin che si rompe è di solito quello che nessuno si ricorda di aver installato.

corpusctl non ha un marketplace di plugin — il che è una perdita reale, elencata onestamente qui sotto. Ciò che ha invece è un sistema di moduli con una regola imposta dalla CI:

• Ogni funzionalità è un modulo: media, ricerca, webhook, SEO, GraphQL, import, analytics.
• I moduli non possono importarsi a vicenda. Un service registry e un event bus sono gli unici canali tra di loro, e pnpm check:isolation fa fallire la build se quella regola viene infranta.
• Rimuovere un modulo non può rompere la build. È l'intero scopo della regola.

E disattivare una funzionalità non distrugge nulla: disabled preserva i dati e riprende alla riattivazione, uninstalled li cancella con una doppia conferma, e un downgrade del piano imposta i moduli solo su disabled.

#Più siti, un pannello

WordPress Multisite esiste e funziona, con le riserve che gli operatori conoscono: plugin che si comportano male sulla rete, un database condiviso, un aggiornamento che arriva su ogni sito in una volta, e un modello di permessi che non è stato progettato per "questo editor lavora sui brand uno e tre ma non deve vedere il brand due".

corpusctl è multi-tenant nel core, accanto all'auth e al registro dei moduli:

• Un pannello, spazi illimitati.
• Un utente porta con sé un ruolo separato per spazio.
• Isolamento garantito dalla row-level security di PostgreSQL — nel database, sotto lo strato applicativo dove vive un filtro dimenticato.

L'argomento a favore della RLS è ristretto: l'isolamento a livello applicativo regge fino all'unica query che ha saltato il filtro, e quella query prima o poi viene scritta, da qualcuno di fretta, in un modulo che nessuno revisiona con attenzione. La RLS rende la fuga impossibile al di sotto dell'errore.

#Contenuto strutturato, e chi possiede il design

Il contenuto di WordPress è un post o una pagina, estesi con campi personalizzati e un plugin per gestirli. Funziona, e il modello mostra le sue origini.

In corpusctl non ci sono tipi di contenuto integrati. Li definisci dal pannello o dall'API, e i campi portano ruoli — title, slug, body — così il sistema sa quale campo è il titolo senza dipendere da come l'hai chiamato. La localizzazione è per campo. Ogni record è versionato, le versioni più vecchie sono ripristinabili e la pubblicazione può essere programmata.

Sul front end, i renderer dei blocchi arrivano con zero stile predefinito. Nemmeno una riga di CSS. Ogni tipo di blocco è sovrascrivibile, e un tipo di blocco sconosciuto viene saltato con grazia invece di generare un errore. L'albero di rendering del core è indipendente dal framework; gli adattatori React, Vue e Next.js stanno sopra come sottili strati.

Confrontalo con un tema WordPress, che è una decisione di design che erediti e poi sovrascrivi.

#Tre buoni motivi per restare su WordPress

Assunzioni. Puoi trovare qualcuno che conosce WordPress in qualsiasi città, a qualsiasi budget, la settimana prossima. Non puoi farlo per corpusctl e fingere il contrario sarebbe sciocco.

L'ecosistema. Form, prenotazioni, membership, e-commerce, strumenti SEO, utilità di migrazione — un plugin esiste, è collaudato e costa 59 $. Costruire l'equivalente su un'API è un progetto.

È gratuito. Il core di WordPress non costa nulla e non lo ha mai fatto. Se il budget è il vincolo determinante, questo chiude la discussione.

Aggiungine un quarto, meno comodo: corpusctl è giovane. L'SSO e uno SLA contrattuale sono nella roadmap, che è il modo educato per dire che non esistono ancora. Non c'è marketplace né CDN globale — la cache edge è a regione singola. Se la tua checklist di approvvigionamento ha uno di questi, questo confronto finisce qui.

#Il riepilogo onesto

Resta su WordPress se un team modifica un sito, l'ecosistema sta facendo un lavoro reale per te, o il budget decide.

Passa a corpusctl se gestisci più progetti, più front end, o una superficie di plugin che non riesci più a controllare — e vuoi che il percorso di lettura smetta di essere un problema di caching.

Stai migrando? Il modulo di import legge un export WXR di WordPress: post, pagine, tag e media. I ruoli dei campi vengono mappati, e il corpo viene convertito nel modello a blocchi. Metti in conto tempo reale per tutto ciò che faceva un plugin — quella logica non si esporta.

Guarda l'architettura → · Leggi la documentazione →

corpusctl vs Directus: una piattaforma di contenuti contro un wrapper di database