AVVERTENZE: Questo post non parla solo di roba da nerd ma anche di editoria online e Web development in generale, quindi è indirizzato un po’ a tutti.

Questo è un post che volevo fare da molto tempo ma ogni volta che cominciavo c’era sempre qualcosa che mi diceva “aspetta, non sai ancora tutta la storia” e quindi io aspettavo di saperla. Tra le varie cose c’erano anche una quantità di scogli psicologici e pratici che ho dovuto superare, quindi adesso sono pronto per le premesse.

È in realtà un punto controverso ed estremamente soggettivo, quindi prendetelo così. Ci sono tanti bei linguaggi e framework per programmare nel Web lato server — per esempio Ruby on Rails è molto bello, come pure mi sembra che Django (Python) sia diffuso e apprezzato, e poi ce ne sono altri tipo Perl e via andando. Nella mia esperienza, però, quando si parla di sviluppare un sito per un privato o un’azienda — cioè parliamo di un sito vetrina, al massimo con qualche semplice extra, e-commerce et similia — la scelta cade praticamente sempre su PHP. C’è pieno di soluzioni già pronte, WordPress per citarne una, basate su PHP. Inoltre secondo Google, PHP si colloca quasi sempre nei primi quattro posti delle classifiche di popolarità e diffusione, assieme a C, C++ e Java, per solo uno dei quali mi è nota una certa diffusione in ambito Web. Inoltre praticamente ogni hosting provider che si rispetti ad oggi, se non esplicitamente votato a qualche altra chiesa, fornisce anche PHP oltre allo spazio, il che è un incentivo. Senza considerare comunque che in qualsiasi momento il cliente tipico può lanciare la bomba “che ne dici di aggiungere anche questa $feature_assurda?“, e nel 90% dei casi c’è qualcuno che quella feature l’ha sviluppata. In PHP. A questo punto è chiaro che andrò a parare su PHP, quindi passiamo oltre.

Quando si viene a creare il tipico sito per il tipico piccolo cliente “femo in nero, me racomando, fame ben” [1] il progetto di norma coinvolge

• alcune pagine semplici, tipo chi siamo, da dove veniamo, dove andiamo, perché dovresti venire a fondo con noi;
• una sezione blog/news/spettacoli/aperitivi o simili attraverso cui il cliente informa il suo pubblico su come e dove intende frodare il fisco la prossima volta (o forse no, quelli onesti);
• e l’evergreen chiamaci subito e avrai uno sconto speciale.

Facile facile, semplice semplice, estetica carina-un-po’-già-vista-ma-non-troppo, tempo di sviluppo medio due mesi, compenso equivalente a due settimane.

Capita però a volte di trovare anche qualche cliente più interessante, con esigenze un po’ evolute e che, soprattutto, non farà gestire il sito al nipotino, quello che di PC ne capisce, bensì da qualcuno affetto da orticaria informatico-compulsiva — tipo me con GiMP, per dire. La cosa divertente di lavorare con questi clienti, a parte l’ovvio che in genere tendono a non voler frodare il fisco [2], sta proprio nelle esigenze. Per esempio

• devono pubblicare contestualmente una serie di contenuti concettualmente legati a scadenze regolari (aka: rivista);
• hanno un’organizzazione strutturata che comprende chi decide e assegna gli articoli, chi li scrive, chi li corregge e chi ne approva la pubblicazione;
• come se tutto ciò non fosse già abbastanza interessante, hanno persone addette per cui la Lettera 22 è già un’esagerata ingerenza tecnocratica nel loro lavoro.

Non so quanti di voi a questo punto avranno già capito tutto e quindi possono anche smettere di leggere. Per gli altri sarà più chiaro tra poco.

Il punto l’ha recentemente sottolineato mia sorella mentre mi guardava lavorare ad un sito:

Com’è che è tutto così bello, facile e integrato? Ma una volta i siti non si facevano con l’HTML?

Eeeh, sì. Il fatto è che oggi ci vogliono i Web CMS per fare i siti senza dare di matto. Altrimenti uno può anche farseli in HTML, nessun problema. Le spese dell’ospedale psichiatrico non gliele pago io, però.

E qui finiamo le premesse e arriviamo all’argomento del post, cioè quale CMS scegliere? Se uno mette “php cms” su Google, esce una quantità indecente di risultati, esistono talmente tanti CMS in PHP che uno non può proprio pensare di provare tutti e trovare quello definitivo. Purtroppo PHP è un linguaggio estremamente popolare, ed essendo un linguaggio facile è anche il primo con cui uno si avvicina alla programmazione sul Web. Risultato: tutti, prima o poi, si sentono in dovere di scrivere un CMS, con risultati spesso imbarazzanti. E quindi bisogna un po’ scremare.

Per esempio per cominciare possiamo eliminare quelli che contengono nel nome o nella descrizione le parole nerd, geek, easy, simple, community e roba così, e già ne abbiamo esclusi metà. Poi possiamo procedere a vaporizzare quelli che contengono nuke e php, e così se ne vanno un altro po’. A questo punto siamo rimasti con una discreta quantità di progetti dai nomi estremamente fantasiosi, alcuni anche molto carini e che potrebbero invogliarci, ed è qui che lo stolto cade. Noi che non siamo stolti facciamo una lista delle feature desiderabili.

• Open Source. Questo non è un requisito stringentissimo. In effetti tronca sì e no cinque o sei progetti, ma purtroppo a volte sono progetti maledettamente buoni.
• Workflow flessibile. Già solo con questo decimiamo la lista. Per workflow flessibile intendo la possibilità di personalizzare la sequenza di operazioni che producono un qualsiasi tipo di contenuto, sia un articolo, un podcast, una galleria di immagini… l’idea minima è che qualcuno assegna o crea il contenuto, lo sottopone per revisione, qualcuno lo revisiona, lo corregge, eventualmente lo rimanda indietro finché non è soddisfatto e può sottoporlo per il timbro finale che lo spara negli intertubi in tutta la sua gloria. Per esempio io, che sono uno sadico, potrei volere che ci siano due grandi capi che hanno il compito di assegnare la produzione di un contenuto ad una persona (o più di una) e che questi capi possano infine porre il sigillo solo se almeno due di tre revisori designati hanno approvato la bozza e un altro contenuto da cui questo dipende è già pronto per l’approvazione contestuale. Per dire, eh. Non mi è noto alcun caso in cui questo succede, di certo non succede nei siti dei quotidiani, ma è per dare l’idea.
• Tipi di contenuti flessibili, aka gestione integrata del flusso produttivo del contenuto. E anche con questo abbattiamo una buona quantità di candidati. Il punto interessante qui non è solo l’idea che un contenuto può essere sia una pagina semplice che una recensione a cui sono associati vari metadati tipo il voto o la data di uscita dell’album recensito. Un contenuto è un’insieme di informazioni di processo che concorrono a produrre l’istanza finale del contenuto. Per esempio un podcast non è solo un file audio, è anche una sceneggiatura composta di monologhi, dialoghi, stacchi audio e via dicendo, compreso un eventuale storico delle revisioni successive. E tutte queste informazioni devono viaggiare insieme ed essere potenzialmente (o no, a seconda) accessibili ad ogni persona coinvolta nella produzione di quel particolare podcast.
• Presentazione separata dalla logica. Qui andiamo un po’ meglio, dato che molti WCMS hanno capitolato in favore dei poveracci che devono integrare la presentazione dei contenuti con la loro elaborazione. A me non capita spesso perché in genere mi occupo di entrambe le cose, ma non è affatto raro che allo stesso progetto lavorino grafici e programmatori i quali non hanno quasi alcuna esperienza dei reciproci campi. Non è quindi fattibile chiedere ad un grafico di districarsi nei meandri dell’integrazione dei dati grezzi in un template HTML attraverso PHP — che sarà pure semplice ma è comunque un linguaggio di programmazione, mica frittelle e caffelatte. C’è un altro aspetto. Se noi programmatori abbiamo predisposto la logica che riempie il template e un bel giorno il cliente decide che quel $piccolo_insignificante_particolare va lievissimamente modificato — risultato: tre giorni di stridore di denti e bestemmie — è molto più facile se un grafico può modificare solo la presentazione sapendo che comunque i dati gli vengono forniti già elaborati in un certo modo. Così il grafico può lavorare felice sul suo Mac e il programmatore sulla sua Linux box, e infine tutti e due convergono sul server di sviluppo dove tutto per magia si mette a funzionare. Sì, più o meno funziona così.
• Human factor. Sembra una stupidaggine — e in effetti è un tantino in contrasto con i numeri che fanno Facebook e Twitter — ma le cose facili da usare attirano utenti. Il guaio — in cui risiede anche il mistero Facebook — è la quantità di utenti potenziali che vanno in panico per il più banale messaggio di avvertimento, o che si stufano prima di cominciare di fronte ad un’interfaccia eccessivamente convoluta e poco lineare. Insomma: meno bottoni per tutti, e un’occhio a cosa può fare chi e come. Per esempio, un recensore potrebbe non aver alcun interesse — e in genere dovrebbe essergli strettamente vietato — a modificare il menu di navigazione principale. Però magari, per qualche motivo, quello della sezione libri, in cui recensisce, sì. Inoltre è inutile presentare ad un addetto stampa un modulone pieno di campi tipo alias url o peso nella sitemap se poi non li può modificare. Quello che a lui interessa è bottone crea comunicato, campi titolo e corpo, bottone invia per la revisione. Fine.
• I18N e L10N. Ebbene sì. A noi i siti ci piacciono multi lingua e cultura. Sia per avere gli stessi contenuti tradotti in più lingue, sia per avere contenuti diversi a seconda della lingua o della cultura di destinazione. Come pure le date nel formato corretto, la valuta, la direzione di scrittura e chi ne sa più di me, più ne metta.
• Estendibilità. Vabè, già che ci siamo…

Passando la lista superstite attraverso questi requisiti, improvvisamente questa si svuota. È evidente che abbiamo sbagliato qualcosa. Il linguaggio di programmazione? Il modello di sviluppo? La nostra esistenza su questa Terra? Può essere. Sgomento e disperazione.

Deciso comunque a trovare qualcosa, alla fine mi sono fatto una lista dei mali minori ed è uscito Drupal. Che ha un workflow a senso unico. Che i tipi di contenuti flessibili sono un plug-in neanche nel core [3] che permette appena di aggiungere qualche campo. La cui idea di separazione tra logica e presentazione risale al 1989, con alcune esilaranti performance di HTML hard wired “perché non c’è sistema di template più potente di PHP stesso”. In cui lo Human è considerato alla stregua di una pezza da piedi con un QI di 300, i permessi degli utenti se non c’erano proprio mi sentivo più tranquillo, e la cui unica cosa forse fatta un po’ bene, ma neanche troppo, è la parte di internazionalizzazione. Per non parlare della quantità di estensioni.

Quello che mi stupisce sempre di Drupal è proprio come sia diventato uno dei più diffusi e sviluppati gestionali per applicazioni web, usato perfino dal sito della Casa Bianca in persona. Il punto vero è che Drupal non è un CMS, è un brutto ibrido tra un gestore di contenuti e un framework per applicazioni web, col risultato che non fa bene nessuna delle due cose. L’unica spiegazione razionale è che tutti ti dicono che Drupal è il meglio, allora tu lo provi, investi un mese della tua vita a capirci qualcosa, e alla fine ti ritrovi assorbito in una comunità Borg-like in cui anche tu inizi a ripetere il mantra per cui Drupal è il meglio.

Al momento qualche sito con Drupal l’ho fatto, e non sono nemmeno del tutto insoddisfatto. Ci sono meccanismi in cui è necessario entrare a forza e decine di motivi per cui turarsi il naso, non è affatto il migliore dei mondi e, anzi, fa pure un po’ schifo a guardarlo; però, badando ai requisiti, è il male minore. Ecco qua. Avevo una mezza idea di fare una serie su come avventurarsi in Drupal senza soccombere troppo ma non saprei nemmeno da dove iniziare. Se qualcuno di voi lo usa e ha qualche idea, io ascolto volentieri.

Fine del post. Ora viene il momento sbrocco. Mandate a letto i bambini e cambiate canale se siete di stomaco debole. Ora io dico, [bestemmia], perché [volgarità] c’è al mondo una mandria di [insulto] che si fanno pagare compensi a cinque cifre significative per produrre montagne di [scarto organico] che chiamano CMS, senza alcuna cognizione minima di buona programmazione e usabilità, quando non addirittura di coscienza professionale?!

Ma [bestemmia di distruzione di massa].

1. È per inquadrare il budget, più che il tipo di cliente, anche se a volte anche il cliente vorrebbe essere inquadrato in questo modo, ma di solito finisce inchiodato al muro da un’occhiataccia che non lascia margini di interpretazione.[↑]
2. Lo so che lo ripeto di continuo, ma la cronaca è con me.[↑]
3. Ok, forse in Drupal 7 sì.[↑]