Come quasi tutti i web designer mi è capitato molto spesso di avere a che fare con famosi e diffusissimi CMS, da Joomla a WordPress, da PHPNuke a Movable Type. L’incontro con questi prodotti è sempre più frequente: sono facili da trovare ed orami anche molto semplici da installare ed usare. Traduzioni in italiano non è difficile individuarne, anche per quelli più misconosciuti e strani. Con o senza database, scritti in PHP, ASP, Perl, Ruby o quant’altro. Portali, blog, forum, e-commerce e gestionali.

L’aspetto che li distingue non è solo nel tipo di contenuto gestito o nel modo di gestirlo, ma soprattutto nell’amministrare la grafica e nelle reali possibilità di personalizzazione. Possono essere divisi in CMS con motore grafico o senza, con template integro o splittato, con stili in linea od esterni.
E’ opinione molto diffusa che per cambiare la veste grafica ad un sito web sia sufficiente sostituire qua e là qualche file d’immagine come il logo aziendale oppure un fondalino e poi con un paio di ritocchi ai CSS cambiare il colore ai bordi delle tabelle ed ai testi.
E se volessimo qualcosa di diverso? Impostare la sola homepage a quattro colonne e non a due o tre? Oppure avere un template liquido, cioè table-less? E se dovessimo adattare il blog alla Legge Stanca?

Quali sono le caratteristiche che li distinguono e che si dovrebbero analizzare e conoscere?

Motore grafico
Si chiama così in un CMS una parte dei listati preposti specificatamente alla creazione delle stampe a monitor in linguaggio HTML e sue varianti: in sostanza questi listati sfruttano uno o più file per “pescare” il codice con cui i contenuti, richiamati nel database dalle query, verranno formattati. I file che contengono le sole stampe potranno essere facilmente modificati per dare al sito una differente impaginazione dei contenuti. Averlo o non averlo rende il CMS più o meno facile da modificare nel suo aspetto esteriore: ci basterà modificare un file o uno specidico gruppo di file per cambiare completamente tutte le stampe a monitor del nostro sito web.

Splitting
L’idea di dividere la pagina HTML in più listati in linguaggio client/server, nasce come soluzione primitiva di accelerazione dei tempi di modifica delle pagine di un progetto. Facciamo un esempio pratico: abbiamo creato un piccolo sito web di appena cinque pagine e dobbiamo inserire il codice di partita IVA della nostra azienda in tutte quante e decidiamo di posizionarlo a pié di pagina. Nel caso di un tipico sito in HTML dobbiamo aprire i cinque file e modificarli uno per uno, se invece avessimo impiegato un qualunque sistema client/server avremmo avuto nelle cinque pagine un richiamo ad un unico file che si occupava di conservare il codice HTML del piede: modificando solo quest’ultimo, apporteremo la modifica contempornaemente a tutte le pagine del nostro sito. Nei CMS moderni, a questo principio si è anche affiancata una motivazione di sicurezza: ripristinare una pagina con richiami, dopo un caso di defacciamento, è più rapido ed indolore che dover ripristinare un listato contenente tutte le stampe a monitor. La divisione riduce anche il rischio di intercettazione.

Stili in linea ed attributi dei TAG
I TAG dell’HTML possono essere “descritti” e quindi modificati esteticamente sia tramite i classici attributi in linea, specifici per ogni TAG, sia tramite l’uso di CSS: è però possibile usare la proprietà STYLE come attributo interno di un qualunque TAG HTML ed inserire in essa comandi CSS. Per un web design questa soluzione è una delle peggiori adottabili da un CMS, perché comporta un problema gerarchico non indifferente che prevede nella maggior parte dei casi che lo stile in linea sia prioritario rispetto al link hidden dello stile su CSS esterno. Il risultato è quello di obbligare il web designer a ricercare lo specifico TAG e modificarlo. Se a questa pratica si dovesse unire la tecnica dello splitting delle stampe e l’assenza di un motore grafico, il lavoro sarebbe enorme.

HTML incluso
Una delle caratteristiche che accomunano tutti i linguaggi client/server è che possono invariantemente esistere sia listati che includono stampe a monitor dell’HTML, sia listati HTML che includono porzioni di linguaggio di programmazione. E’ facile comprendere come sia più semplice per un web designer mettere le mani sul secondo tipo di listati: in questo caso l’HTML è puro e le parti di PHP, ASP o Ruby sono ben identificabili ed individuabili. Per un programmatore però potrebbe essere più sensato il primo tipo di listato, dove l’HTML occupa un ruolo marginale: è solo il risultato “pratico” di questa o quella funzione, classe o ciclo. Nei CMS si possono trovare o l’uno o l’altro approccio, ma anche entrambi contemporaneamente: il principio del motore grafico offre proprio proprio la possibilità di avere CMS basati su un prosupposto programmativo, ma con una gestione dell’HTML più indirizzata alla grafica.

I puntatori
Si presentano in vario modo, generalmente come semplici chiamate a variabili globali, ma possono avere anche la forma di chiamate inclusive o veri e propri TAG speciali: lo scopo dei puntatori è quello di segnalare all’interno del template il punto dove si vuole che specifiche componenti del CMS stampino il risultato delle query al database nelle loro varie forme. Il vantaggio dei puntatori è nella possibilità di ridurre al minimo l’intervento sul codice client/server da parte del designer che invece si concentrerà sulla realizzazione di listati HTML.

E’ indubbio che in tutti i casi può capitare che determinate componenti del CMS stampino dei propri TAG HTML, ma se il progetto è ben realizzato, l’impatto che tali porzioni di codice avranno sull’economia della veste grafica sarà ininfluete. In alcuni casi i progettisti vengono incontro ai grafici progettando dei veri e propri frameworks CSS, creando dei riferimenti certi, relativamente ricorsivi e/o ridondanti che permettono di modificare anche quei TAG non filtrati dal motore grafico.

Vediamo alcuni dei più diffusi CMS in circolazione ed il loro comportamento con le stampe a monitor HTML e la loro gestione dei templates.

Template nei CMS

WordPress
WordPress è una delle più diffuse piattaforme di blogging scritta integralmente in PHP ed appoggiata su un database MySQL: questo CMS, arrivato alla sua versione 2.9.1, nel corso degli anni si è potenziato e migliorato sotto un po’ tutti i punti di vista. Alcune aziende hanno creato veri e propri bussiness entrando nell’indotto di questo gestore, com’è successo anche per altri prodotti di altrettanto alto profilo: tra di esse molte si sono specializzate nella realizzazione proprio di template per WordPress. L’ambiente possiede un motore grafico che permette di apportare non solo modifiche alle stampe, ma anche di introdurre features e tool nei template stessi. WordPress divide il codice in vari file che corrispondono ai vari elementi che compongono le pagine: testata, piede, corpo centrale, colonne laterali, CSS, ma anche i commenti ed i feed fanno parte del “tema” (così viene chiamato un template in questo gestore di contenuti). Questa soluzione permette di arricchire i temi con funzioni speciali semplicemente aggiungendo altri listati in PHP e richiamandoli con delle semplici funzioni include() nel punto che si desidera. Anche alcune plugin possono richiedere l’inclusione nel template. Il tutto può essere gestito ed amministrato tramite l’editor di codice interno a WordPress stesso, oppure è possibile anche crare dei veri e propri pannelli di controllo per la personalizzazione del tema stesso.

Joomla
Nato come fork di Mambo è cambiato nel tempo, differenziandosi e potenziandosi. Alcune cose però rimangono invariate tra la vecchia versione 1.0.x e la nuova 1.5.x. Il principio della prima versione di Joomla è quello di un motore grafico che gestisce il template filtrando i contenuti tramite un unico file PHP 4 che contiene tutto il costrutto della pagina HMTL con l’inclusione dei soli puntatori alle componenti ed ai moduli del CMS. La gestione dei moduli aggiuntivi e la possibilità di indirizzarli su un alto numero di puntatori rende Joomla molto versatile e configurabile. Anche nella nuova versione le cose non sono sostanzialmente cambiate, ma quello che è cambiato è il fatto che Joomla 1.5 ha abbandonato definitivamente gli elementi che lo accomunavano al suo progetto madre, Mambo, e si è dotato di un nuovo motore grafico che permette, al pari di WordPress, una più potente gestione dei template come se fossero delle vere e proprie plugin.

Mambo
E’ il progetto da cui è nato il più diffuso Joomla. La sua è una community ancora vivissima che continua lungo la propria strada. Se per un certo periodo, ciò che poteva essere fatto su Mambo andava bene anche per il suo fork e viceversa, oggi non è più così: la gestione dei template di questo CMS è praticamente identica alla prima versione di Joomla e per chi non vuole cimentarsi in ardite programmazioni di template altamente dinamici, oppure per chi aspira ancora ad un bacino di utenza per una tipologia classica di template per Joomla, Mambo fa proprio al caso.

MovableType
E’ il progetto di punta della SixApart, azienda famosa anche per il light-blog TypePad. MovableType non è solo commerciale, ma è da poco divenuto anche Open Source a distribuzione gratuita: ovviamente chi acquista una licenza ottiene assistenza diretta da parte dell’azienda (sebbene recentemente in Internet non è difficile trovare feedback negativi su questo argomento con vere e proprie migrazioni eccellenti). MovableType ha una sua peculiarità che per certi versi lo può limitare in un uso estemporaneo per neofiti: è scritto integralmente in Perl. Di fatto questa soluzione necessita di avere un serio controllo sui moduli Perl del server, soprattutto se si vogliono installare componenti aggiuntive che facciano richiamo a librerie non standard.
MovableType ha un suo motore grafico: diversamente dagli altri CMS, genera però pagine statiche e quindi usa i template solo per “raccogliere” le informazioni necessarie per costruire il codice HTML che materialmente salva sul server in cartelle apposite sotto forma di file *.shtml. Tutta la gestione del CMS ruota attorno a questo principio, voluto per ottenre contemporaneamente una grande velocità nel downloads sul browser delle pagine in fase di consultazione e delle URI razionali per migliorare il SEO.
MovableType non ha i template “dinamici” come WordPress o Joomla 1.5, ne divide la struttura su più file: dovendo creae pagine sia per articoli che per liste di articoli, la soluzione trovata è stata quella di creare tanti template ognuno per ogni tipologia di file da generare: uno per la homepage, uno per l’archivio temporale, uno per le pagine dei singoli articoli ed uno per le pagine delle rubriche, e così via, compresi i commenti ed i feed. Se si apporta una modifica ad un template però non la si vedrà subito applicata al salvataggio del modello, ma si dovranno rigenerare tutti i file elaborati sulla base di quello specifico template: se cambiamo quello dei singoli articoli, li dovremo ricreare tutti aspettando che MovableType lo faccia per noi. Ovviamente più file si devono ricreare e più tempo impiegherà. La scelta di usare file SHTML permette a MovableType di dotarsi di una ricca schiera di puntatori disegnati come TAG personalizzato del CMS o come variabili Perl. Molto interessante l’editor interno dei template dotato di tutti i comfort, dalle righe numerate, alla colorazione del codice, alla possibilità d’inserire nuovi puntatori mantenendo corretta la sintassi.

Simple Machine Forum
E’ uno dei CMS più diffusi per la creazione di forum on-line: scritto nell’immancabile PHP ed appoggiato sul classico database MySQL, SMF è relativamente snello e fornito. Il template è basato su una serie di file che riuniti insieme da un indice a chiamate stampano a monitor tutto il codice HTML. La struttura non fa uso di stili in linea, ma non impiega neanche chiamate modulari: tutte le variabili per il caricamento degli elementi costitutivi il forum, le colonne laterali e le informazioni a pié di pagina sono incluse come codice nel template stesso, costringendo ad individuare le stampe a monitor tra i vari echo e print presenti nei listati. Ricostruire idealmente così una ipotetica pagina HTML diventa ostico.

phpBB
Questo CMS per la realizzazione di forum è molto noto e molto solido essendo una delle soluzioni gratuite più complete in circolazione. Curiosa la gestione dei template: divisi anch’essi in vari file, hanno una sorta di estensione “proprietaria” *.tmpl che in realtà non nasconde altro che un banale file PHP.

PHPNuke
Se non il primo, è sicuramente uno dei più vecchi e l’età si fa sentire. PHPNuke ha dato origine a miriadi di fork e varianti anche in linguaggi differenti dal PHP. Ha creato uno stile di progettazione ed un approccio al web che ha portato alla moderna diffusione dei CMS: in un periodo (quasi dieci anni fa!) in cui possedere un sito web dinamico significava investire grandi somme di denaro, questo progetto Open Source è stato il primo a fornire una valida alternativa. Oggi però subisce un po’ il peso degli anni e sebbene ancora vivo ed aggiornato, le soluzioni adottate non sono elastiche e moderne come quelle di altri concorrenti. Un po’ portale, un po’ blog, apportare modifiche alla grafica spesso si riduce davvero solo a poter cambiare i file di immagine e modificare il CSS. Rigido, pieno di stili in linea o di attributi ai TAG che ne rendono difficoltosa la modifica, diventa ancora più complesso da modificare a causa della pratica dello splitting delle stampe su più file e dell’approccio inclusivo dell’HTML.

ASPNuke
Definirla una versione in ASP di PHPNuke non è corretto: questo CMS, tutto italiano, nasce da un progetto spagnolo, in seguito abbandonato, che effettivamente consisteva in una vera e propria “traduzione” del blasonato CMS in PHP. Oggi giunto alla sua versione 2.0.8, è qualcosa di diverso, anche se conserva ancora tutto l’approccio *Nuke: tema costituito da pochi file d’immagine ed alcuni listati CSS (ben tre), stili in linea, stampe splittate, DTD HTML 4.0 Transitional, una gestione un po’ primitiva dei CSS che non può certo definirsi un framework.
Se però si dispone di un hosting su Windows Server, è indubbiamente una delle soluzioni freeware più complete: la community è vivissima ed il team è ben disposto a perder un po’ di tempo a spiegare dove dover metter le mani. E poi è tutto in italiano e non è un aiuto da poco.

dBlog
Altro progetto di casa nostra scritto in ASP (cosa non rara a causa della nostrana abitudine di riferirzi a servizi low-cost basati su Windows Server per poter avere database senza costi aggiuntivi). dBlog è uno snello CMS progettato per creare una piccola piattaforma di blogging: dispone di un semplice motore grafico che richiama un unico file scritto direttamente in XHTML che contiene la maggior parte delle stampe: la soluzione è piuttosto semplice e permette di apportare anche modifiche sostanziali senza troppo sforzo. Non sono presenti stili in linea e questo permette di avere subito modifiche ai CSS toccando un unico listato. Sfrutta una serie di puntatori dalla sintassi semplice ed intuitiva. Dal sito dello sviluppatore, Daniele Vietri, è possibile accede ad una bella community tutta in italiano.

Snitz Forum
Questo board in ASP ha caratteristiche in comune con i CMS in stile *Nuke: non è molto semplice metter le mani sulla grafica di Snitz Forum, ma è possibile integrarlo con altre soluzioni in ASP: proprio per ASPNuke esiste un porting che permette di farlo convivere all’interno della root in alternativa alla board di default. Snitz, come CMS per forum, è un po’ limitato, piuttosto spartano, ma ha un po’ tutti i servizi necessari, dalle black-list di utenti in base all’IP al filtro per le parole da censurare.

Shop 2007
E’ un fork di mwOpen: nasce per fornire un CMS per l’e-commerce che fosse in grado di gestire i pagamenti tramite carta di credito attraverso gli account di PayPal, cosa che mwOpen non era in grado di fare se non installando un apposita plug-in. Shop 2007 è in ASP ed è realizzato in Italia. Sfortunatamente personalizzarlo è un’impresa ostica: la cosa fondamentale con questo CMS è quella di scaricarne la versione definitiva dal forum del progetto e poi installare subito tutte le patch, le modifiche ed i plugin che ci interessano in ordine cronologico di pubblicazione sul sito: solo in seguito e consigliato metter mano alla grafica che, comunque, costringerà a ricerche estenuanti di tratti di codice e di stili in linea. Qua e là sono presenti anche alcuni errori gravi comi TAG BODY ripetuti o TAG P aperti, ma non chiusi. Validare il codice richiede veramente tempo. Il gruppo sta adesso lavorando su un altro progetto di e-commerce, che nasce proprio dopo il lavoro fatto su Shop 2007: il suo nome è Save. Da quanto riportato sul forum, questo nuovo progetto sarà solo parzialmente basato sul precedente e sarà molto più potente.

osCommerce
E’ uno dei più noti CMS per e-commerce Open Source, distribuito sotto GNU/GPL: è ovviamente scritto in PHP ed è basato su piattaforma LAMP.
Il difetto maggiore è nell’assenza di puntatori: si fa un largo uso di HTML incluso ed i listati sono parzialmente splittati ed imparte sono invece ripetuti su più file. E’ necesario individuare bene tutti gli elementi e cercare di apportare le modifiche avendo una completa visione d’insieme del risultato finale. Già dal forum di supporto italiano ci si rende conto che la community parte da un presupposto graficamente anomalo: ogni template nel repository altro non è che una copia differente del CMS. Il lavoro da fare per una personalizzazione ad hoc è quindi enorme.

CMSimple
Questo CMS danese è l’unico che non usa un database: crea materialmente dei file HTML con un curioso sistema che prevede un’interpretazione dei TAG Header Title per creare una gerarchia tra i contenuti. Tutta la grafica è amministrata da un unico file PHP e da un solo listato CSS: in più ha dei comodi puntatori. Potrete creare l’interfaccia che più vi aggrada personalizzandola di conseguenza. Dal 1 gennaio 2010, CMSimple ha cambiato licenza passando dalla Affero’s GPL alla nuova GNU/GPL 3.0: il risultato è che non esiste più la distinzione tra licenze ad uso gratuito e quelle ad uso commerciale ed è quindi sempre possibile scaricarlo gratis ed usarlo anche ad uso commerciale, nascondendo il link al progetto madre. Francamente, vista la qualità dello strumento, lasciare il link è comunque un bel modo per riconoscere il lavoro di questa community europea.

Conclusioni
In circolazione esistono molti altri CMS, altrettanto noti come Drupal o [...], ed esistono anche molte soluzioni commerciali. Ma di base il rapporto con la grafica è per tutti inquadrabile negli esempi fatti fin qui: di fatto tutto si riduce in CMS che permettono di avere una gestione agevole e CMS che disperdono le stampe a monitor in giro per i listati. E’ l’eterno dilemma degli approcci: grafico o programmativo?
Pretendere che un programmatore dia importanza a dove si trovino le stampe per permettere al grafico di metterci le mani, è troppo: le ottiche di lavoro e gli scopi sono differenti ed una persona sola non può averle entrambe facendo contemporaneamente bene entrambi i lavori. Grafico e programmatore devono sempre lavorare insieme, perché un sito funziona se è ben programmato, ma viene indicizzato più agevolmente se scrive il codice HTML in una certa maniera ed ottiene un miglior risultato commerciale se ha una grafica più gradevole. Anche nell’ambito dei CMS freeware si dovrebbero capire queste cose.