TYPO3 è di livello enterprise, collaudato sul campo e costruito per un’altra era del web.

La parte headless è un’aggiunta posticcia

TYPO3 è stato progettato come un CMS tradizionale server-side. Il suo output nativo è HTML renderizzato da template Fluid. L’estensione EXT:headless — mantenuta dalla community TYPO3 Headless, non da TYPO3 GmbH — trasforma questo output in una API JSON.

Funziona, e per i team che hanno investito in TYPO3 e devono esporre i contenuti come API è una strada ragionevole. Ma è un’estensione della community con il proprio ciclo di release, il proprio perimetro di compatibilità con le versioni core di TYPO3 e la propria documentazione. Non c’è SLA, non c’è un contratto API versionato da TYPO3 GmbH e non c’è uno SDK TypeScript.

b10cks è stato progettato come CMS headless fin dal primo giorno. L’API è il prodotto. Ogni decisione di design — architettura a blocchi, localizzazione, versioning, webhook — è stata presa per servire chi consuma l’API, non chi renderizza template.

L’interfaccia editoriale

L’interfaccia backend di TYPO3 (il “Backend”) è potente e altamente configurabile, ma ha una curva di apprendimento che la maggior parte dei team riconosce con onestà. Il paradigma dei content element (tt_content, configurazione TypoScript, FlexForm per contenuti strutturati) non è intuitivo per editor non tecnici. L’onboarding richiede in genere una formazione strutturata.

Le versioni TYPO3 v12 e v13 hanno introdotto miglioramenti al backend e una UI rinnovata: i progressi sono reali. Ma il modello mentale di fondo — albero di pagine, colonne di contenuto, TypoScript — resta diverso dal modo in cui lavorano i team content moderni.

Il visual editor di b10cks vive dentro il sito reale del team. Gli editor cliccano sugli elementi che vogliono modificare e li editano sul posto. L’onboarding è minimo perché l’interfaccia è il prodotto che gli editor usano ogni giorno.

Localizzazione: il vero punto di forza di TYPO3

Qui TYPO3 è davvero davanti. Il suo sistema di localizzazione — traduzione a livello di campo, catene di fallback per locale, alberi di pagine per lingua, tracciamento dello stato delle traduzioni — è tra i più maturi in assoluto in qualsiasi CMS. Le organizzazioni che gestiscono oltre 20 lingue su strutture di sito complesse vi fanno affidamento da decenni.

La localizzazione di b10cks è solida per la maggior parte delle esigenze reali: traduzione a livello di campo, ereditarietà locale, workflow di pubblicazione per locale, integrazione con strumenti professionali di traduzione (Lokalise, Phrase, DeepL). Per i team che ripartono da zero, copre l’intero set di funzionalità senza complessità legacy.

Per le organizzazioni che gestiscono già workflow di traduzione TYPO3 molto complessi, il divario di maturità va valutato con onestà.

Workspaces: l’altra forza di TYPO3

Il modulo Workspaces di TYPO3 è uno dei sistemi di content staging più potenti sul mercato CMS. Gli editor possono preparare versioni complete di un sito in uno workspace isolato, confrontarle con il contenuto live, fare anteprima e rilasciarle in blocco — su più pagine, elementi di contenuto e lingue allo stesso tempo.

b10cks offre cronologia delle versioni stile git, branching e release atomiche: puoi raggruppare più modifiche di contenuto in un’unica distribuzione programmata. Per la maggior parte dei team di contenuti di prodotto, è più che sufficiente.

Per grandi realtà editoriali che gestiscono release complete del sito come eventi atomici — pensa a portali della pubblica amministrazione, grandi siti media in periodo elettorale — il sistema Workspaces di TYPO3 è uno strumento specializzato che b10cks non eguaglia in profondità.

L’esperienza per gli sviluppatori

Mettere in piedi uno stack TYPO3 headless moderno richiede un investimento concreto: core TYPO3, configurazione EXT:headless, TypoScript per il mapping dei campi API, integrazione con un framework frontend (Nuxt-TYPO3 è l’opzione principale) e configurazione per FAL (File Abstraction Layer), caching e CDN.

Deploy self-hosted di b10cks:

git clone https://github.com/b10cks/cms
cd cms && docker compose up

Ed eccoti un CMS in esecuzione. Aggiungi un dominio. Collega il frontend tramite lo SDK TypeScript.

L’API è documentata con una specifica OpenAPI. Esistono adapter per Next.js, Nuxt, Astro e Vue. Il modello dei contenuti è definito sull’infinite canvas e si riflette subito nell’API.

Modellazione dei contenuti: alberi di pagine vs blocchi

TYPO3 organizza i contenuti in un albero di pagine: le pagine sono l’entità primaria e gli elementi di contenuto vivono all’interno delle regioni di colonna della pagina. Questo modello si adatta bene ai siti web tradizionali, ma richiede ulteriori decisioni architetturali per scenari content-as-a-service (contenuti condivisi su più pagine o canali).

b10cks organizza i contenuti in blocchi: ogni tipo di contenuto è un blocco componibile e riutilizzabile. I blocchi possono essere referenziati su pagine e canali diversi senza duplicazione. Il modello dei contenuti è definito visivamente e riflette un approccio API-first: il contenuto non è vincolato a una posizione nella pagina, è una risorsa.