Uno dei test più onesti per un CMS multi-sito non è la demo: è aprire due siti veri, costruiti sullo stesso codice, e vedere se si assomigliano per le ragioni sbagliate. caffeinapura.it e viviagriturismo.com girano entrambi sul motore di rendering di DynamicShare, e a parte la struttura delle pagine — homepage, sezioni, un footer con i link — non hanno praticamente nulla in comune a vista. Colori diversi, contenuti diversi, un eshop nell'uno e non nell'altro. Il codice condiviso sta un livello più sotto, dove l'utente finale non guarda mai.
Ogni sito è un "tema": una cartella con dentro le pagine (homepage, blog, una scheda prodotto, quel che serve), e ogni pagina è a sua volta una lista di widget dichiarata in un file di configurazione, non un unico template monolitico. La homepage di un sito è "intestazione, poi hero, poi una sezione con i servizi, poi il blog, poi i contatti"; quella di un altro sito ha una lista diversa, magari con un widget in più o in meno. Cambiare l'ordine delle sezioni di una pagina, per noi, è modificare una lista in un JSON — non toccare un file PHP di 400 righe sperando di non rompere qualcos'altro più in basso.
La parte che vale la pena chiarire, perché è quella che confonde più spesso, è la differenza tra progetto e sito. Un progetto non è un sito: è un contenitore che può averne più di uno — più domini, più temi, più contenuti — appoggiati sullo stesso database e sullo stesso pannello di amministrazione. Quando un cliente ci chiede "posso avere un sito per il pubblico e uno per i rivenditori", la risposta tecnica è: sono due temi diversi nello stesso progetto, non due progetti separati. Condividono i contatti, gli utenti, gli accessi; cambia solo cosa viene mostrato e a chi. Nel pannello, chi segue quel cliente sceglie quale sito sta gestendo da un menu in alto, non con un login diverso per ciascuno.
Cosa guadagna davvero un cliente da questa architettura? Che "un progetto può avere più siti" non è una frase di marketing ma una cosa che succede spesso nella pratica: un'azienda con un sito istituzionale e un eshop su domini separati, o — caso concreto — un cliente con un sito e un applicativo di gestione rete vendita sotto lo stesso progetto. Stesso pannello, stessi accessi, stesso database di base per i contatti. Zero sviluppatori duplicati per gestire "il secondo sito", che in tanti altri stack vuol dire semplicemente un secondo contratto di manutenzione.