Quando non scegliere WordPress

WordPress è il CMS più amato e utilizzato: viene impiegato nel 21% dei siti.

Ha certamente grandi meriti, primo tra tutti quello di aver permesso a migliaia di persone di creare siti internet senza sapere una riga di HTML. Il suo maggiore punto di forza è la facilità di utilizzo e la possibilità di personalizzare velocemente i siti con l'uso di temi e plug-in a costi molto bassi.

WordPress potrebbe uccidere il tuo sito internet
Lavoro spesso con persone del marketing e mi sono reso conto che quasi sempre scelgono WordPress perché ne hanno già esperienza o perché “si dice in giro che sia il migliore”, ma raramente conoscono i suoi punti deboli e sanno valutare se nel loro progetto potrebbero essere critici.


L’incompletezza

Appena installato, WordPress è praticamente inutile. Quello che mette nativamente a disposizione è un sistema molto semplice basato su pagine e notizie. Tutti quelli che l’hanno utilizzato sanno che per ogni minima implementazione c’è il suo plug-in: ce n’è uno per poter gestire le tabelle all’interno dei testi, uno per poter rendere non cliccabili i primi livelli del menù, uno per le statistiche Google Analytics, uno per creare slideshow, uno per fare i backup, uno per aumentarne la velocità, uno per la sicurezza, uno per la pulizia periodica, uno per il SEO, uno per l’antispam, etc etc.
Ci si ritroverà velocemente con decine di plug-in installati: è un male? Vediamo.

I problemi del modello a plug-in

Il peso

Installando anche solamente i plug-in base, WordPress non è più quel CMS leggero che avevamo installato: spesso i plug-in includono funzionalità molto complesse, con decine di opzioni inutili che interagiscono con WP tramite una sand-box che ne controlla le azioni ma ne appesantisce ulteriormente il funzionamento. Non è un elemento critico su progetti web di piccola portata (non sempre: ho visto anche siti piccoli caricarsi in 27 secondi grazie a due-tre plug-in lenti), ma lo diventa su progetti di ampia portata.

WordPress può essere molto lento, per vari motivi

La qualità e la sicurezza

Se è vero che WordPress viene sviluppato da programmatori di grande esperienza, non è altrettanto vero che chi sviluppa plug-in sia allo stesso livello, anzi è ben noto che i più grandi problemi di sicurezza vengono proprio dai plug-in. Se infatti un plug-in esegue delle query SQL senza averle adeguatamente sanitarizzate, spalanca una porta su tutto il sito agli attacchi di MySQL-injection; se un plug-in scrive dei file senza verificare che il percorso sia valido, consente di sovrascrivere e compromettere qualsiasi parte di WordPress...
In che misura? 10 dei 50 plug-in più diffusi e 7 dei 10 plugin-in di e-commerce più usati presentano vulnerabilità (leggi l’analisi).

Inoltre, per come è stato concepito WordPress, ogni plug-in andrà ad aggiungere elementi, CSS, meta-dati, Javascript, webfont, in maniera disordinata alle pagine del nostro sito, creando dei veri mostri privi della minima ottimizzazione.

Il decadimento

Ho sentito dire una volta “scegliamo WordPress perché è un’azienda solida e ci garantisce continuità di sviluppo”. È un falso. WordPress difficilmente chiuderà tra qualche anno, ma le decine di plug-in indispensabili al funzionamento del tuo sito sono sviluppati da piccole aziende o a volte addirittura da appassionati a tempo perso. Quando questi smetteranno di sviluppare il loro plug-in tu dovrai o cambiare plug-in, ma non potrai convertire i contenuti dei vecchi per i nuovi, o pagare profumatamente qualcuno perché porti avanti i plug-in che già utilizzi.

Non è un caso raro, a me è già capitato due volte: una volta con un plug-in per il monitoraggio del WP-cron e un’altra volta, ben più grave, con il plug-in per il multilingua che quando l’ho installato aveva un voto alto ed era consigliato da quasi tutti i blogger. Non potendolo più aggiornare ho dovuto sceglierne un altro ma ho dovuto ricreare a mano tutte le pagine in inglese e francese, non essendoci una procedura automatica di migrazione.

Esempio di plug-in deprecato

Nel 2011 solo il 32% dei plug-in erano stati aggiornati da meno di un anno, e l’85% presentavano degli avvisi o degli errori di PHP (leggi analisi).

L’interoperabilità

A volte due funzionalità hanno bisogno di fare squadra. Un esempio ricorrente è quando si deve usare il plug-in multilingua all’interno del plug-in di e-commerce, per poter offrire i nostri prodotti nelle varie lingue del sito. Molto spesso non è possibile farlo, perché i plug-in sono blocchi indipendenti: occorre quindi fare ricorso a trucchetti che complicano molto la gestione del sito.

I conflitti tra un plug-in e l’altro

Quando si installano decine di plug-in, alcuni possono entrare in conflitto. Succede perché magari utilizzano lo stesso tag o lo stesso nome per la tipologia di post o lo stesso nome per delle tabelle aggiuntive nel database, e quindi si sovrascrivono a vicenda smettendo di funzionare entrambi. Oppure uno aggiunge dei CSS con delle classi che poi vengono sovrascritte dall’altro, o uno ha bisogno di una certa condizione nel DOM che non va bene per l’altro… ci sono moltissime cause e la maggior parte delle volte occorre rinunciare ad alcuni plug-in.
Casi tipici sono l’uso di un plug-in di caching che blocca il funzionamento di un plug-in di banner, o l'uso di plug-in basati su tecnologia AJAX che operano insieme all'infinite-scroll.

La coerenza nell’interfaccia e nell’utilizzo

Ogni plug-in funziona un po’ a modo suo: aggiunge elementi diversi all’interfaccia, può collocarsi nel menù principale del pannello di amministrazione, oppure su un livello secondario, dentro alla voce “plug-ins” o dentro a quella “aspetto” o altrove; alcuni plug-in possono richiedere dei copia/incolla di URL di immagini, altri avere direttamente il tasto di selezione; alcuni possono includere della pubblicità, o l’invito a una donazione…

Il risultato per l’utente è che non ha a disposizione un’interfaccia coerente, in cui tutte le cose si fanno allo stesso modo ed è facile individuare delle procedure uniformi.

Il peso dei temi

Un’altra grande fortuna per WordPress sono stati i temi grafici, ovvero riuscire a creare un mercato redditizio nel quale diversi sviluppatori hanno creato centinaia di temi di qualità elevata a costi ridicoli. I costi ridicoli, parliamo di 50 euro per un tema professionale, sono ovviamente dovuti alla vastità della domanda e al fatto che centinaia di persone avranno il sito identico.

Ma i temi hanno un problema enorme: sono estremamente complessi. Spesso includono loro stessi dei plug-in (non è possibile diversamente, devono pur basarsi su qualcosa di certo), propongono un’interfaccia di gestione attraverso la quale impostare in maniera dinamica molte caratteristiche come colori, font, disposizione degli elementi… questa flessibilità ha un peso mostruoso che incide sia sulla velocità di caricamento delle pagine sia sulla pulizia del codice (tanto da renderlo spesso formalmente non valido se sottoposto ai test W3C).

Giusto per dare un’idea…

WordPress 3.8 pesa 15.9Mb ed ha 1.162 file - 219.928 linee di codice.
Mio, un tema di media complessità con supporto e-commerce, pesa 3.31Mb ed ha 428 file - 25851 linee di codice.
Il plug-in WP e-commerce, tra i più diffusi per l’e-commerce, pesa 10.9Mb ed ha 386 file - 51.719 linee di codice.

Comparazione tra il peso di WordPress, di un tema medio e del plug-in WP e-commerce

Significa che installando solo un tema di media complessità e un solo plug-in, ci affidiamo per più del 25% al codice di altri. Ovvero WordPress è meno del 75% del lavoro di programmazione di un sito. (sono ovviamente conti a spanne)

Gioie e dolori della personalizzazione

In particolare attraverso l’uso dei widget un utente con scarse competenze può aggiungere elementi nuovi al proprio sito, alterandone il layout.
Questa funzionalità, amatissima dagli entusiasti del DIY, è forse la più odiata da qualsiasi grafico web perché altera le forme e le proporzioni della grafica del sito, così ben studiate e approvate dopo decine di bozze, includendo elementi non stilizzati che stirano, deformano, invadono spazi che non competono a loro.
Invece il cliente, lo stesso che ama scrivere “super offerta” con font rosso acceso su fondo giallo fluorescente, sarà contentissimo delle sue capacità tanto da sospettare di poter far da solo il prossimo sito.

Purtroppo questa flessibilità di gestione grafica non è onnipresente: quei webmaster che vogliono personalizzare la grafica con buona cura nei dettagli si trovano continuamente di fronte alla necessità di rimettere mano al codice dei plug-in, evidentemente non pensati per il loro bisogno specifico. Dopo enormi fatiche ne viene fuori una serie lunghissima di sovrapposizioni di CSS, Javascript e variabili hard-coded nelle pagine che, con un occhio all’estetica del codice, fanno rabbrividire gli sviluppatori.

Il multilingua

Un grande handicap di WP è di non essersi mai dotato di un sistema di gestione multilingua nativo. Certo, esistono i plug-in, ma oltre a non essere affidabili (come detto sopra) non coprono tutte le esigenze necessarie. Cioè un plug-in multilingua implementerà le traduzioni per le pagine che si appoggiano alla struttura nativa di WordPress, ovvero pagine e articoli, ma non riuscirà a fare altrettanto per i plug-in che avete deciso di installare nel vostro sito, come ad esempio quello di e-commerce, o di newsletter, o di integrazione con i social-network… oltre alle pagine generate dai plug-in, non tradurrà nemmeno i termini presenti nei relativi tasti, intestazioni, frasi di feedback tipo “ti sei iscritto con successo alla nostra newsletter”, etc etc...

Certe funzioni proprio non vanno

Infine a volte guardo certe funzionalità di WordPress e mi dico “ma che schifezza hanno combinato?”.
Ogni tanto con le nuove versioni le sistemano: ad esempio WP ha implementato con grande ritardo un sistema di gestione dei menù indipendente dalle pagine.

Quattro esempi che rendono bene l’idea e che sono ben diversi tra loro:

  • la gestione dell’ordinamento delle pagine viene fatta, ancora oggi, scrivendo un numero crescente nell’apposita casella! I numeri sono adatti a macchine e ragionieri, per tutti gli altri esiste da anni il drag&drop… ma per WP ancora no.

  • i permessi degli utenti sono: Amministratore, Redattore, Guest e qualcun altro. Sono profilati per livello, non per funzionalità. Non possiamo creare un utente che abbia accesso alla gestione delle Newsletter ma non possa modificare pagine e articoli, o uno che gestisca l’e-commerce ma non possa guardare le statistiche...

  • la pubblicazione automatica degli articoli, e altre funzionalità simili, è quanto di più terribile abbia visto: viene gestita da un finto cron (che non va confuso con i cronjob del sistema operativo). Il WP-cron funziona solo quando il sito viene visitato (è ovvio, PHP funziona così), quindi in un sito con poche visite le funzionalità legate al cron semplicemente non funzionano, pur essendo disponibili. Ti accorgi quindi al rientro delle ferie che nessun articolo pianificato è stato pubblicato.

  • Se vi cimentate nella scrittura di un tema grafico, vi accorgerete subito che molte funzioni hanno dei comportamenti poco prevedibili. Cercando poi nei forum troverete mille workaround dei quali, applicandoli a casaccio, almeno uno funzionerà ma non saprete mai bene il perché.


Conclusioni

È sconsigliabile l’uso di WordPress, quindi?

Dipende: è consigliabile in certe situazioni, ma non va adottato perché “lo conosco già” o “se ne parla così bene”: occorre fare un’analisi progettuale del sito che si deve costruire e se uno dei punti citati sopra può essere critico, o diventarlo nel tempo, bisogna adottare un altro CMS.

Ho fatto uno schemino che può aiutare ad orientarsi. Non è sempre valido, ma appunto offre un’indicazione di massima, o almeno può accendere dei campanelli d’allarme.

Flowchart: scegliere WP o no?

Quale alternativa? Non lo so, non esiste un CMS universale, occorre studiare e tenersi documentati. Buona ricerca.