Come ho imparato a smettere di preoccuparmi e ad odiare Drupal

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ì.[]

14 commenti

pikkio dice:

È da un po’ di tempo che mi sono allontanato dallo sviluppo dei siti dinamici, per cui non ho molto da dire dal punto di vista tecnico. Però ti appoggio, a quanto pare la situazione non è migliorata molto da quando ero “into it”…

Ah, permettimi di sottolineare… “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.”
:-P

Per il resto, è proprio vero che Drupal è una delle poche soluzioni, se non l’unica. Anche se non è comunque significativo, pure io conosco un amico che lavora in un’azienda di sviluppo siti per aziende, ed usano esclusivamente quello.

Tuttavia, se dovessi reiniziare ad interessarmi di queste cose, come probabilmente farò, sarà esclusivamente nella direzione di un onanismo per sviluppatori come Django… Ecco, Django mi intriga parecchio.

Purtroppo, di hosting accessibili con supporto python e accesso ssh (necessario per l’installazione, mi sembra) ce ne sono veramente pochini. Fammi sapere se ne trovi qualcuno meritevole :D

Luigi dice:

Io non condivido per niente le tue idee, cioè oltre a criticare il lavoro di tutti gli sviluppatori di CMS non dici niente di costruttivo.Fai il tuo CMS se sei così bravo.Io trovo drupal un ottimo prodotto, flessibile e programmabile, magari un po’ ostico all’ inizio ma è il prezzo della sua flessibilità. Poi ognuno ha le sue idee …

In un mondo ideale avrei tutto il tempo necessario per fare il mio CMS, purtroppo non ce l’ho, e non ce l’ho nemmeno per aiutare lo sviluppo di Drupal. Mi rendo conto di criticare a vuoto, ma ritengo sia meglio dire chiaro e tondo cosa non va piuttosto che tacere e continuare ad accontentarsi.

Luigi dice:

Va bene che non apprezzi il sistema ma alcune frasi come “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. ” secondo me sono esagerate e comunque ogni tanto ci vorrebbe un po’ di umiltà e scrivere “secondo me”, visto il gran lavoro che la gente fa per creare un prodotto così vasto. E poi per esempio alcune cose sono proprio sbagliate, tipo “Che i tipi di contenuti flessibili sono un plug-in neanche nel core [3] che permette appena di aggiungere qualche campo.” non è vero, con CCK puoi inserire ogni tipo di campo, date, immagini, numeri, files etc … quindi almeno di le cose come stanno, c’è gente che c’ha faticato.

Primo, è ridicolo prendersela se manca un “secondo me”. È un blog, il “secondo me” è implicito.

Secondo, CCK non è nel Core. È un modulo essenziale, ma non è nel Core di Drupal 6, quindi io ho detto le cose come stanno.

Terzo, questo è l’atteggiamento tipico di quando ci si trova di fronte ad un lavoro monumentale: ci si prostra incondizionatamente, ringraziando gli Dei. Non ho difficoltà a riconoscere che si tratti di un lavoro monumentale, ma non ho difficoltà nemmeno a raccontare i difetti che ha, pur conoscendo bene i pregi, anche perché non sto parlando perché ci ho giocato cinque minuti e poi l’ho cancellato preso dalla frustrazione. Piuttosto ho fatto un certo numero di siti nonostante la frustrazione… e perché? Perché di meglio non c’è, a livello di php + open source. Mi spiace: Drupal avrà anche dei pregi, ma ha tanti difetti congeniti che non sembra voler abbandonare.

Quarto: pucchiacche.

Quinto: quando parlavo di “contenuti flessibili” non mi riferivo certo a CCK nella sua incarnazione attuale, ma questo è chiaro a chi ha letto il post invece di farsi annebbiare la vista da rabbia e fanboyesimo.

Luigi dice:

Ma chiaro per te, non è così chiaro,comunque il tuo post è da FanBoy al contrario, un insieme di critiche immotivate, con parti inventate. Io non sono un fanBoy non l’ho sviluppato io Drupal e non mi interessa che venga criticato, ma non mi piace vedere in giro gente che sputa sul piatto su cui poi mangia sparando a zero senza giustificazioni di ciò che dice o inventandosi in parte le cose. “non mi riferivo certo a CCK nella sua incarnazione attuale” questo post è recente non puoi criticare una versione di 10 anni fa o che non esiste, parla di quello che c’è adesso senza inventarti le cose.

1) È chiaro dal momento che è un blog personale.

2) Non mi sembra di non aver giustificato le mie affermazioni. Non aver proposto alternative non significa non giustificare.

3) CCK non è nel Core né oggi né 10 anni fa. Questo è un fatto che non mi sono inventato io. Resta il fatto che o non hai letto il post o non hai capito di cosa parlavo, perché io non parlavo di CCK e basta. Per “contenuti flessibili” intendo tutt’altra cosa, di cui CCK è una piccola parte.

franco dice:

Sono d’accordo con l’autore. Anche io lo uso. Ho iniziato a “farmi” perché considerato il migliore. Ho perso una area di tempo sui manuali (pessimi) e sulla documentazione (comprensibile solo quando hai già capito tutto e cioè quando non serve più a nulla) solo per iniziare ad utilizzarlo decentemente. Ora continuo ad utilizzarlo solo per dare un senso all’oceano di tempo perso, ma semplicemente non ha logica e sembra avere un senso solo per chi non ha intenzione di scrivere una linea di codice ma solo installare temi e moduli su moduli sperando che funzionino e non si pestino i piedi vicendevolmente. Questa è la mia opinione. Saluti

Cico dice:

“È in realtà un punto controverso ed estremamente soggettivo, quindi prendetelo così”

Ci tenevo a sottolinearlo perché Andrea è ingegnere dentro e quindi aveva ulteriormente specificato, malgrado non ce ne fosse bisogno, che l’idea era sua personale e non assoluta.

Detto questo, cacchio Moppo mi hai infranto un mito. Ho sempre pensato che Drupal sia fico, almeno nella top 2 assieme a Joomla.

In realtà Joomla è un po’ più in basso della seconda posizione, una volta che impari a conoscerlo :)
Drupal… beh, ma anche Drupal bisogna conoscerlo, il punto che lo situa in alto rispetto a Joomla è che prima o poi le cose le fai, epperò solo a modo suo. Se avevi imparato un modo di lavorare prima di Drupal, scordatelo :(

Dimitri dice:

Ah ah, ottimo articolo. Concordo con molte cose, ma anche con (alcune) critiche :)

Penso che la chiave di tutto stia nella frase
“Perché di meglio non c’è, a livello di php + open source” in uno dei tuoi commenti.
Pensa che anche Dries Buytaert, il papà di Drupal, ancora si chiede se abbia fatto bene a usare PHP e non Java:
http://buytaert.net/why-php-and-not-java

anche se nell’articolo fa il tranquillone, cercando di liquidare la questione con poche righe, traspare un’inquietudine di fondo, della serie “Avrò fatto bene o male? Tutti questi PHP-kiddies del [volgarità] che si mettono a realizzare moduli di [insulto] lasciati a metà, scopiazzati e pieni di bug rovineranno la mia creatura!”. Infatti la strada per far approvare un modulo è irta e piena di burocrazia…

Mi permetto di aggiungere una considerazione: ma è possibile che professionisti di gran caratura si mettano a realizzare gestionali con tanto di transazioni (monetarie) e data model fichissimi sfruttando un’applicazione che gira praticamente solo su tabelle… MyISAM!!! Mastiamoscherzando?!?

Guarda, sia l’osservazione di Buytaert che la tua sono molto sensate. Io tendo a considerare PHP in prospettiva, avendo cominciato a svilupparci quando ancora si chiamava PHP 3. Il linguaggio ha delle pecche ma nel tempo è stato fatto moltissimo lavoro, oltre ad una cosa che a me piace molto in casi drastici come questo: tagliare la retrocompatibilità.
Il punto è sempre che PHP e Java sono linguaggi, si possono scrivere gran porcate in Java e si possono scrivere raffinatezze PHP. Infatti credo che la discriminante non sia il linguaggio, bensì la base di sviluppatori. Se consideri Java, è un linguaggio molto usato in ambito enterprise e meno smanettone, quindi è facile che abbia un pool di sviluppatori di un certo livello, attenti a lavorare in un certo modo e secondo certe regole. PHP è un linguaggio snobbato dalle alte sfere e molto popolare tra gli script kiddies e altri sviluppatori magari non pessimi ma che cercano un linguaggio veloce per sviluppare piccoli prototipi (e l’ho fatto anch’io, a volte), e PHP presta facilmente il fianco a questi scopi.
Ultimamente mi sono infatuato di Ruby e di RoR con cui ho avuto il piacere di scrivere un paio di gestionali che mi servivano per scopi personali e che, anche con un buon framework dietro, in PHP avrei sviluppato in ben più della mezza giornata che mi è servita con RoR.
Trovo intelligente che l’iter per l’approvazione di un modulo non sia facile da affrontare — trovo meno intelligente però che la difficoltà sia basata spesso non su misure obiettive come unit test, integration test, e valutazioni sull’ergonomia dove appropriato, quanto sulle resistenze di alcuni sviluppatori.

La questione MyISAM… mi spiace contraddirti ma io ho almeno un sito in Drupal che gira su InnoDB :) Comunque il punto è che chi sa scrivere software, e lo sa fare bene, può farlo bene anche con PHP. Poi c’è un altro problema, che è quello degli shared hosting, ma qui siamo sul gradino “entry” della scala dell’hosting, quindi non ha molto senso discuterne. Il problema semmai è come riuscire a convincere che per avere un’applicazione di un certo livello, in questo momento, o spendi tanto e te la fai scrivere, oppure spendi tanto, prendi un server dedicato, e ci monti l’applicazione che più ti gusta. Ma “spendi tanto”, per molti clienti, è una bestemmia — soprattutto per quelli che riescono a chiederti uno sconto su un preventivo di 300 euri lordi :(

vainer dice:

come sempre, ci sono le fazioni in stile tifo da stadio, ma non è stato valutato un aspetto importante:
il codice generato.
sono non vedente e vedo troppi maledetti siti fatti coi piedi, dove il w3c manco viene letto è poi, ovvio che tanto c’è sempre da fare, ma un oggetto come drupal genera siti puliti, da navigare, ma questo, forse, è troppo settoriale.
un problema vero, però, esiste, ovvero il modo di porsi verso i neofiti da parte della comunità italiana, troppo settoriale, troppo da figo e non tiene conto del fatto che un prodotto cresce se prendi i neofiti e li fai crescere, il modus operandi stile integralista linuxaro non mi è mai piaciuto e quindi amen.
Per andrea, se legge ancora questo vecchio post, sto mettendo mano a drupal 7, mentre è già operativa la 8, rispetto alle precedenti ha integrato parecchie cose e, si spera, di vedere un interfaccia più amichevole.
apro parentesi su worpress, un pochino lo maledico perchè nasce come qualcosa blog oriented, un sito, invece, non è un blog, ma pare che la gente pensi siano la stessa cosa ed ecco personaggi che sanno installare solo plugins o estensioni di wp che vanno in giro dicendo di essere webmaster e chi continua a studiare codice o soluzioni serie, fa la figura del cioccolataio!
saluti innevati da Bologna.

Rispondi

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.