La filosofia della programmazione in WordPress

Nascondi

Quella che segue è una trascrizione automatica dell'episodio.

Pensieri in codice. Idee dal mondo del software, a cura di Valerio Galano. Salve a tutti e ben ritrovati per un nuovo episodio di Pensieri in Codice. Oggi parliamo di Wordpress, un software sicuramente conosciuto come il più diffuso fra i content management system per la realizzazione di siti web. Basato su tecnologie app HP e SQL, è supportato praticamente da ogni servizio di hosting, cloud, provider, eccetera. Ai più, è noto come uno dei metodi più semplici per mettere su un sito web in modo veloce, completo, efficiente, in poco tempo e con poco sforzo. Quello che però non tutti sanno è che Wordpress è un vero e proprio framework di sviluppo, con i suoi coding standard, le sue best practice ed una sua vera e propria logica di implementazione. Conoscere la filosofia che ne ha la base e applicarne correttamente i concetti permette ad uno sviluppatore di realizzare nel migliore dei modi tutte le funzionalità di cui ha bisogno. In questo episodio, dunque, vedremo come è strutturato un progetto in Wordpress e come funziona il codice al suo interno, questo per essere in grado di estenderlo nel migliore dei modi. Innanzitutto, la prima cosa da tenere a mente quando si lavora su Wordpress è che tutto nel framework è pensato per essere esteso in modo semplice. Il CMS si divide infatti in un motore centrale e due tipologie di componenti che, incastrati fra loro, danno vita al sito web con tutte le sue funzionalità. Gli elementi grafici, le aree riservate agli utenti, la gestione di archivi e cataloghi, i meccanismi di importazione e esportazione, l’interfacciamento verso sistemi esterni e qualsiasi altra cosa vi possa venire in mente. Tutto questo si ottiene appunto estendendo con dei componenti specifici un nucleo centrale di funzionalità minime che prende il nome di core. Si tratta proprio come dice il nome del core del sistema, la parte più importante della quale non si può fare a meno. In effetti, esso è il Wordpress. È la parte di software che possiamo trovare all’interno del pacchetto ufficiale scaricabile dal sito wordpress.org. Realizzato e manutenuto dal team ufficiale del progetto, il core contiene appunto il framework e le funzionalità essenziali. Già da solo permette di realizzare un sito con le caratteristiche minime standard. Con l’installazione del solo core, infatti, si può tranquillamente tirare su un sito che includa semplici pagine, e in realtà dalle ultime versioni neanche poi tanto semplici, oppure un blog, una grafica minima, la gestione degli utenti con i vari ruoli, la registrazione, un meccanismo di commenti e tanto altro. In la maggior parte dei casi, però, tutto questo non è sufficiente perché, come ben sappiamo, ogni utilizzatore ha le proprie esigenze particolari e proprio in questo si manifesta la grande forza di Wordpress. Qualunque sia la funzionalità necessaria, il core è predisposto per dare la possibilità ad uno sviluppatore di scrivere il proprio codice e modificare o aggiungere qualcosa ai comportamenti di default del software. Questo tipo di codice viene organizzato in componenti e rappresenta la prima delle tipologie a cui accennavo prima e prende il nome di plugin. Dunque, se ho bisogno di cambiare qualcosa nel mio Wordpress, posso scrivere il mio plugin, installarlo, attivarlo ed ottenere così la mia modifica facilmente. Voglio aggiungere un campo al profilo dell’utente? Ad esempio voglio che egli possa inserire il proprio codice fiscale? Scrivo un piccolo plugin. Voglio gestire tipologia di contenuti più complessi rispetto alla semplice pagina o articolo del blog? Scrivo un plugin. Voglio trasformare il mio Wordpress in un sito di e-commerce? Scrivo un plugin, e così via. Più saranno le funzionalità di cui si ha bisogno, più plugin si potranno realizzare e aggiungere alla propria installazione. E se invece le modifiche riguardassero gli aspetti grafici del sito web? Sappiamo per esperienza che i siti in Wordpress non sono tutti uguali. Beh, in questo caso entra in gioco la seconda delle tipologie di componenti a cui accennavamo prima, e cioè i temi. I temi, detto in parole molto semplici, gestiscono tutti gli aspetti grafici del nostro Wordpress. Decidono quindi quali sono i colori del testo o degli elementi grafici, dove sono posizionate le immagini e i loghi, quali caratteri vengono utilizzati per i titoli, i corpi delle pagine, ecc. A differenza dei plugin, però, per ogni installazione di Wordpress può esserci un solo tema attivo per volta. Quindi, tutte le caratteristiche grafiche di cui abbiamo bisogno devono essere implementate all’interno dello stesso tema. O quasi, più avanti ne parleremo più in dettaglio. Ad ogni modo, questa suddivisione dei compiti, diciamo così, tra i vari componenti, concede allo sviluppatore o al designer grande flessibilità nell’utilizzo della piattaforma. Sarà infatti possibile aggiungere o rimuovere funzionalità in modo molto semplice, attivando o disattivando un plugin, oppure cambiare l’intero aspetto del sito passando da un tema all’altro. I componenti, plugin o temi che siano, possono essere sviluppati da chiunque sia in grado di programmare in PHP. Oltre al fatto che ne esistono moltissimi già disponibili, più o meno potenti, gratuiti oppure commerciali, mantenuti dalla comunità o da aziende specializzate. Ovviamente, una volta capita la strategia di un progetto WordPress, la nostra mente da sviluppatori ci porta immediatamente a chiederci come possa essere praticamente realizzata una logica del genere. Beh, il core di WordPress implementa alcuni concetti di base su cui si fondano tutte le logiche di estendibilità. Questi concetti sono i filtri, le azioni, la gerarchia dei template e il tema figlio. Vediamoli uno per uno. I filtri rappresentano un meccanismo grazie al quale gran parte delle informazioni gestite all’interno del CMS vengono fatte passare attraverso delle funzioni, che, se necessario, vi apportano delle modifiche. Tali funzioni sono dette appunto filtri e in linea di principio sono strutturate in questo modo. Prendono in input il dato da filtrare ed eventuali altri dati di contesto e restituiscono in output il dato da filtrare. E dal momento che può essere necessario applicare più filtri in successione ad una stessa informazione, per ciascuna funzione è anche possibile specificare un indice di priorità. Questo per determinare un ordine di esecuzione. L’applicazione dei filtri è una cosa molto semplice, ma è molto difficile e molto complicata. L’applicazione dei filtri riguardanti un certo dato avviene in momenti strategici del flusso. Ad esempio, quando si salva una pagina nel backend di WordPress, tutti i dati inseriti dall’utente nelle varie maschere vengono filtrati prima del salvataggio, in modo che il programmatore possa applicare eventuali modifiche o correzioni. Un altro esempio potrebbe essere il form di registrazione degli utenti. Un programmatore che volesse eliminare la richiesta del nome utente potrebbe scrivere un primo filtro per eliminare il campo nome utente dalla lista di quelli mostrati nella maschera, e poi un secondo filtro per generare il username in modo casuale prima del salvataggio. Tecnicamente molto simili ai filtri, ma poi differenti a livello concettuale, sono le azioni. Esse non permettono la modifica di dati preesistenti, ma danno allo sviluppatore la possibilità di lanciare delle funzioni in determinati punti del flusso di esecuzione. Come per i filtri, possono essere eseguite più azioni negli stessi punti, e inoltre, Immaginiamo ora di voler scrivere un apposito file che contenga le username degli utenti che falliscono l’operazione di login. Per fare ciò scriveremo una funzione che salvi l’informazione nel file, e poi la segnaleremo come un’azione del filtro. Sarà quindi WordPress occuparsi di eseguire tale funzione e passare ad essa le informazioni di contesto necessarie su cui lavorare. Ora, i punti del codice che scatenano l’operazione di login. Proprio perché, a livello concettuale, rappresentano un modo di agganciare delle funzioni di modifica appropriate all’utilizzo dell’utente. Inoltre, i punti del codice che scatenano l’esecuzione di azioni o filtri, prendono il nome generico di hooks, cioè uncini. Proprio perché, a livello concettuale, rappresentano un modo di agganciare delle funzioni di modifica appropriate all’utilizzo dell’utente. Inoltre, a livello concettuale, rappresentano un modo di agganciare delle funzioni di modifica appunti specifici del flusso. Il core di WordPress implementa moltissimi hook, che sono elencati nella documentazione ufficiale. Ma allo stesso modo, ogni plugin o tema degno di questo nome, implementa i propri hook, per dare accesso ad un eventuale programmatore esterno, alle proprie parti interne. Ogni hook è identificato da un nome. Se, ad esempio, si vuole eseguire un’azione al momento della login dell’utente, si potrà dire a WordPress qualcosa di questo tipo. Aggiungi la funzione updateLoginCounter al hook user underscore login. Rispetto ai plugin, però, quando si parla di temi, oltre al discorso dei hook, c’è anche quello della gerarchia. Come è facile immaginare, infatti, per determinare l’aspetto grafico di un sito, il tema deve includere molti file contenenti codice HTML, CSS e JavaScript. Senza sottovalutare il fatto che tutti questi codici di front-end, diciamo così, conterranno a loro volta molti inserti di codice PHP, che servirà a rendere dinamici i contenuti. Anche in questi file, che modellando soprattutto la struttura grafica prendono il nome di template, deve essere possibile per uno sviluppatore applicare le proprie modifiche, anche a volte sostanziali, per poter rendere il sito rispondente alle specifiche. Per questo motivo, anche nei template vengono inclusi dei hook, ma nel caso in cui sia necessario modificare pesantemente un template, entra in gioco il concetto di gerarchia. I template, infatti, a livello di filesystem, non sono altro che dei file PHP richiamati tramite alcune particolari funzioni, e l’intera logica di recupero dei template è pensata in modo flessibile e funziona secondo un modello a cascata. Ciò vuol dire, molto semplicemente, che i file che costituiscono i template possono essere posizionati in vari percorsi all’interno del progetto. Quando è necessaria l’inclusione di uno di questi template, il sistema è in grado di esplorare tutti i percorsi, secondo un ordine prestabilito, e ricercare il file secondo tutta una serie di regole che formano una vera e propria gerarchia. Facciamo un esempio. Il plugin WooCommerce, uno dei più famosi per WordPress che permette di aggiungere al sito le funzionalità di commercio elettronico, implementa ovviamente tutta una serie di pagine aggiuntive necessarie per gestire prodotti, ordini, profili, carrello, ecc. Ognuna di queste pagine sarà composta da uno o più template che combinati insieme le danno un certo aspetto. Immaginiamo però di installare un tema nel nostro sito che modifichi pesantemente l’aspetto di tutte queste pagine, magari invertendo le posizioni degli elementi o spostando funzionalità da una pagina all’altra. Come è possibile realizzare una cosa del genere? Beh, in pratica è solo necessario che all’interno di una specifica cartella del tema siano presenti file con lo stesso nome dei file dei template originali di WooCommerce. Il sistema di recupero dei template si occuperà, quando necessario, di cercare i file di un template prima nella cartella del tema e solo successivamente in quella del plugin. In casi più complessi, invece, le posizioni in cui piazzare i template possono essere molte e perfino i nomi dei file possono influire sulla scelta da parte del sistema. Ad esempio, solitamente il file del template per mostrare un articolo di un blog è nominato come post.php, quindi inserire un file post.php nel nostro tema ci permetterebbe di intercettare e sostituire il template originale per tutti gli articoli. Tuttavia, se volessimo intercettare il template per uno solo degli articoli del nostro blog, potremmo, ad esempio, nominare il file come post-123.php, dove 123 è l’id dell’articolo, oppure come post-benvenuto.php, dove benvenuto è lo slug, cioè il percorso relativo dell’articolo. Vi rimando sempre alla documentazione per tutti i dettagli, ma sappiate che le possibilità sono tantissime. Si possono specificare template per categorie, per tag, per archivi, per pagine e per ogni tipo specifico di contenuto. Infine, l’ultimo concetto di estendibilità di WordPress è quello del tema figlio. Si tratta di un concetto fondamentale, anche se non capisco perché moltissimi designer lo ignorano totalmente. Prendiamo uno dei casi d’uso più comuni. In pratica, la realizzazione di un sito web con WordPress si compone di almeno questi passaggi. L’installazione di WordPress, ovviamente, l’installazione o lo sviluppo di plugin necessari, l’installazione di un tema grafico di base e la personalizzazione del tema grafico secondo le esigenze del cliente. Delle prime fasi abbiamo già discusso, ma per l’ultima la personalizzazione del tema serve un discorso a parte. I temi, come tutti gli altri componenti, sono molto spesso realizzati da altri sviluppatori, soffrono di bug e vengono migliorati e, pertanto, vanno aggiornati periodicamente. Ora, non serve un genio per capire che se apportiamo le nostre personalizzazioni direttamente al codice di un tema, al primo aggiornamento rilasciato avremo solamente due possibilità. O aggiorniamo, perdendo tutte le modifiche e dovendo riapplicarle da capo, oppure rinunciamo all’aggiornamento. Il tema figlio ci viene in aiuto proprio in questo caso. La logica è abbastanza semplice. Se dobbiamo apportare delle modifiche ad un tema, invece di modificarne direttamente il codice, implementiamo un secondo tema come figlio del primo. In questo modo il nostro tema figlio erediterà tutte le funzionalità del padre e le modifiche da noi apportate saranno gestite attraverso il concetto di gerarchia. Serve un template diverso? Inserisco nel figlio un file con lo stesso nome del template originale del padre, ma con un contenuto diverso. Serve un elemento grafico in più o in meno? Inserisco il codice necessario nel tema figlio. In questo modo saremo liberi di aggiornare il padre quando ci pare e piace, senza intaccare però le nostre personalizzazioni che saranno tutte nel tema figlio. Filosofia di sviluppo Il sistema di hook e di ereditarietà rappresenta anche un sovraccarico dal punto di vista dell’elaborazione ed influisce enormemente sulle prestazioni del software. Ogni hook richiede infatti l’esecuzione di vari blocchi di codice, anche solo per valutare se esiste un filtro o un’azione da eseguire. Gli hook poi possono essere posizionati in parti del codice richiamati anche molte volte. Non è raro vedere che un nostro filtro sia eseguito anche centinaia di volte, magari solo per cambiare un unico valore. Allo stesso modo la ricerca di ogni file template può richiedere vari accessi al disco. Un template potrebbe infatti trovarsi nel tema figlio, o nel tema padre, o in uno qualsiasi dei plugin installati, o infine nel core di WordPress. Insomma, come ogni cosa, questa logica di programmazione non è certo esente da difetti ed è la principale causa di eventuali problemi di performance del nostro sito. Per questo motivo esistono molti sistemi per incrementare l’efficienza di un progetto WordPress, come ad esempio l’utilizzo di CDN o di meccanismi di gestione della cache a vari livelli, ma questi saranno argomenti per un prossimo episodio. Nel frattempo, se siete intenzionati ad approfondire la programmazione in WordPress, vi lascio in descrizione il link alla documentazione ufficiale, mentre se avete bisogno di una consulenza professionale e fatturata per il vostro progetto, trovate sempre in descrizione tutti i miei contatti. Per oggi dunque è tutto. Io vi ringrazio per aver ascoltato fin qui, vi chiedo come al solito di condividere l’episodio con chi credete che possa trovarne beneficio e vi saluto ricordandovi che un informatico risolve problemi, a volte anche usando il computer.

Nascondi