Cinque approcci errati alle personalizzazioni di WordPress

businesswoman working in the officeImmagine originale tratta da Fotolia
Tempo stimato di lettura: 5 minuti, 36 secondi
Pubblicato il 1 dicembre 2014

Lo scenario in cui si deve personalizzare un sito web non dovrebbe essere nuovo a nessuno: potrebbe essere dovuto alle richieste di un cliente (per il quale decidiamo di “appoggiarci” a WP), oppure alle rinnovate necessità della nostra azienda, che desidera avere “qualcosa di più di un blog”.

Ecco, WordPress a mio modo di vedere corrisponde molto fedelmente a questa definizione appena formulata: “qualcosa di più di un blog”. Ed è proprio per questo, e per via del suo essere open source, che si presta facilmente ad essere utilizzato per gli usi più svariati, dai quotidiani online ai siti di annunci, di fatto. Numerosi, pero’, sono gli errori che si commettono durante suddette personalizzazioni: ed in questo articolo andremo a spulciarne cinque tra i più diffusi.

Per comodità di lettura, farò riferimenti ad alcuni (neanche troppo ipotetici) “tipi”.

#1 : il modificatore di plugin

Sbrigativo, semplicistico ed essenziale nei propri ragionamenti, ha fretta di consegnare la modifica al cliente: gli hanno appena richiesto di variare leggermente il comportamento di un plugin di WordPress preesistente. Il nostro eroe cosa fa? È presto detto: modifica il codice del plugin.

Peccato che la modifica che ha fatto si perderà definitivamente al prossimo aggiornamento del plugin stesso.

#2 : l’installatore compulsivo di plugin

Assolutamente ignaro dell’esistenza di ulteriori possibilità, e terrorizzato dalle modifiche al codice del template peggio di Shelley Alexis Duvall in Shining, ha deciso di non darsi ulteriori possibilità: per lui, qualsiasi modifica anche minimale al comportamento standard di WordPress va fatta obbligatoriamente tramite plugin. Plugin per qualsiasi cosa, anche solo per creare una pagina autori o un link nel footer.

Ricordiamoci che i plugin di WordPress vanno installati il meno possibile, e questo non solo perchè tendono ad appesantirlo, ma anche (e forse soprattutto) qualora creino dipendenze nel comportamento del sito. Se, per capirci, un plugin viene inserito lato codice nel theme (in modo hardcoded), qualora decidiate in futuro di cambiare theme il plugin smetterà di funzionare. In certa misura, inoltre, a differenza delle modifiche manuali ben fatte, il comportamento dei plugin è spesso controllabile solo in parte.

#3 : il “modificatore folle” di theme

Inizia a modificare il theme che sta usando: del resto lui ed il PHP sono una cosa sola! C’è confidenza, feeling, produttività: il nostro eroe inizia a sentirsi onnipotente, non si aspettava che cambiare l’aspetto di un sito in WordPress fosse così semplice! Ed ecco che arriva alla versione desiderata: il suo WP è personalizzato, guarda che bello, lo mostra in giro, tutti felici, pacche sulla spalla… ma dopo qualche giorno, qualcosa non quadra. Il suo rapporto con PHP sembra essersi incrinato, hanno preso le distanze che neanche Felona e Sorona (“Le orme” – chi seguiva o segue il progressive rock italiano … capirà!).

Le modifiche effettuate da un giorno all’altro sono sparite, ed il theme è tornato al suo aspetto originario. Il nostro eroe, in altri termini, ha dimenticato che le modifiche al theme vanno fatte sempre seguendo il criterio dei theme child, una cosa di cui si parla troppo poco e che, invece, è vitale per lavorare bene, e soprattutto non dipendere dagli update che il theme quasi certamente effettuerà nel tempo.

#4 : il miscelatore di plugin

Piccola variante dell’installatore compulsivo di plugin, tende a sovraccaricare il proprio sito in WordPress di elementi che, almeno in teoria, dovrebbero servire ad ottimizzarlo, estenderlo e chissà che altro, in quella fantasia vagamente perversa. Dal suo punto di vista, anche qui, fare siti in WordPress è un gioco di combinazioni di plugin che, a ben vedere, è più angusto e restrittivo di quanto possa sembrare. Peccato che il nostro amico non consideri che tanti plugin di WordPress vanno spesso in conflitto, e finiscono (se usati assieme) per creare solo problemi. È il caso di due plugin che modifichino i title delle pagine oppure, peggio ancora, di due plugin di cache.

La cosa è tipica per i plugin SEO di WordPress, ed in merito a questa questione suggerisco due approfondimenti interessanti: il primo è Plugin SEO per un blog WordPress, ed il secondo è SEO e WordPress: 5 plugin che forse non conosci.

#5 : il creatore di pagine statiche ad muzzum

Creare delle pagine personalizzate è una delle cose probabilmente più importanti per non creare siti fotocopia, e WordPress ci viene incontro per questo con un meccanismo che va sotto il nome di Page Template. Il semplicione di turno, di fatto, non è consapevole di questo aspetto – che in effetti richiede un piccolo sforzo mentale extra – per cui opta per le cose più sbrigative ed aberranti che ci siano: modificare tutto via editor, inserirvi fogli di stile CSS e HTML senza un domani, oppure – reggetevi forte – installare un plugin per eseguire codice PHP. Sembra così comodo, eppure…

A parte il fatto che questi plugin sono superflui perchè gli hook ed i filter di WordPress permettono già nativamente di fare ciò che vogliamo, quella roba(ccia) rischia di spalancare falle di sicurezza che potrebbero essere sfruttate da terzi, a volte senza nemmeno fare login sul vostro sito. Non usateli, se potete.

Potrei procedere oltre con molti altri esempi in negativo, ma per ora mi fermo qui perchè, secondo me, gli spunti di riflessione sono già parecchi. Che ne pensate? Personalmente quando giocavo coi siti le prime volte, rientravo un bel po’ nei tipi 2 e 5, e solo dopo ho avuto modo di correggere il tiro. Ripensando a quei momenti ho avuto l’ispirazione per questo mio post di fine anno, che spero possa esservi utile.

Che ne pensate? Aspetto aggiunte ed osservazioni varie nei commenti, come sempre.

Le cinque lezioni che possiamo trarne, secondo me, sono le seguenti:

  1. non effettuare mai modifiche hardcoded ai plugin: non esiste alcun meccanismo di “child plugin” (per la verità ne hanno parlato, peraltro con scarso entusiasmo). Se un plugin non soddisfa appieno le vostre esigenze, fate prima a crearvene uno da soli oppure, tanto per restare fedeli al “keep it simple, stupid“, cancellare il vecchio e scaricarne uno nuovo.
  2. limitare il numero di plugin, e cercare di utilizzarli solo lo stretto necessario: molti di essi permettono di estendere le funzionalità (esempio: Magic Fields 2 permette di aggirare molti dei limiti di WordPress) e non, invece, di renderle solo più complesse.
  3. prima di effettuare qualsiasi personalizzazione ad un theme assicuratevi di aver capito il funzionamento dei child theme, in modo che le vostre modifiche siano conservative rispetto ai futuri, inevitabili aggiornamenti.
  4. assicuratevi che tutti i plugin del vostro sito non provochino effetti sovrapponibili/in conflitto, e nel caso in cui ciò avvenisse… ancora una volta, keep it simple: eliminate uno dei due senza esitazione.
  5. evitate infine di installare plugin per l’esecuzione di codice PHP arbitrario: a parte il fatto che è un modo troppo “brutale” per effettuare modifiche, è molto probabile che ci sia un modo alternativo per fare la stessa cosa o, detta diversamente, che stiate sbagliando l’approccio al problema.
  • ahha hai ragionissimo. faccio solo un appunto al punto 1. è sufficiente, nel modificare il plugin, modificare anche la versione con 99999 e non c’è il rischio che il cliente lo aggiorni erroneamente comportanto la sparizione delle modifiche 😉

    • Ciao Laura e grazie del commento, interessante appunto 🙂 l’unico problema è così facendo se il plugin fosse fallato il sito resterebbe scoperto ad eventuali attacchi informatici…

      • Altrimenti c’e’ la soluzione github o bitbucket che controllano il versionamento dei software. Io utilizzo questo metodo mantenendo le personalizzazioni e aggiornando allo stesso tempo il codice sorgente per il cliente.

  • Giancarlo Piccinini

    congratulazioni ottimo articolo

  • in realtà io faccio tutte le cose che dici, ma tutte con tanta pazienza ed analisi. Ovviamente il tutto lo faccio su un server di test e quando sono sicuro che tutto è davvero ok allora riporto il tutto sul server di produzione!

  • Interessante l’articolo: io mi sto disintossicando dall’abuso di plugin… Ma all’inizio, forse, è inevitabile ‘cascarci’….Ora li uso solo se necessario.

Shares