Saidmade

Il successo di WordPress, come strumento per realizzare Blog ma, soprattutto, come generico CMS per risolvere un qualsiasi portale/sito web, è dovuto essenzialmente alla sua semplicità, alla struttura lineare, alle numerosi funzioni che mette a disposizione sia al programmatore esperto che al semplice utilizzatore. Più semplicemente:

• Basato su tecnologia LAMP (Linux, Apache, MySQL, PHP)
• Vasta disponibilità di Temi (layout) grafici semplici e personalizzabili
• Vasta, vastissima, libreria di plugins gratuiti semplici da installare e realizzare
• Modello di sviluppo lineare PHP; nelle ultime versioni si manifesta un’allineamento alle più recenti versioni del PHP, e quindi uno sviluppo più orientato agli oggetti
• Ottimo come CMS generico

Lasciatemi ora esaminare, con una carrellata di consigli e qualche tips, due dei pilastri di questo prodotto giunto alla versione 3.1: Temi & Plugins.

5 cose sui Temi

1. Cos’è un tema?

Un tema si presenta fisicamente come un insieme di file posizionati all’interno di una cartella, a sua volta posizionata nel percorso:

WordPress si aspetta di trovare “almeno” un determinato tipo di file all’interno della cartella del tema, come:

Come accade per i plugin, WordPress ricerca delle particolati intestazioni poste nei commenti per individuare i file che gli servono. Nel caso dei temi, ad esempio, è sufficiente inserire un commento di questo tipo all’inizio del nostro file .css:

Questo particolare commento fornisce a WordPress tutte le informazioni necessarie e sufficienti a caricare – lato backend – il tema e a segnalarlo come disponibile all’uso. Come è facile intuire, il tema – nell’architettura WordPress – riveste un’importanza fondamentale. Esso, infatti, determina quali contenuti saranno visualizzati e come! Ne deriva che esso rappresenta il cuore del sistema, non solo lato utente (front-end) ma anche e sopratutto lato amministrazione. Come accenneremo più avanti, il tema non si riflette solo nell’aspetto che avrà il nostro sito web, ma può aggiungere o modificare funzionalità anche lato backend.

2. come realizzare un tema

Realizzare un tema per WordPress non è una procedura complicata. Si può partire analizzando e/o modificando i temi di esempio forniti nell’installazione. Tuttavia, come accade in altri contesti, è possibile creare temi semplici e temi complessi. Un tema può essere più o meno articolato in base a vari fattori, che possono essere: grafica e layout, presenza di animazioni Javascript particolari, effetti in risposta ad input utente, complessità nelle funzioni di reperimento delle informazioni, pesanti alterazioni del backend, etc…
Questa è proprio una caratteristica di WordPress; permettere cioè più gradi di complessità, cosa che si riflette sulla quasi totalità delle funzioni del sistema, esattamente come accade con i plugin.
In linea di massima, tuttavia, per realizzare tema quantomeno decoroso, bisogna possedere le seguenti caratteristiche:

• Un minimo di gusto grafico ed estetico
• Capacità di utilizzare strumenti come Adobe Photoshop, lavorandoci tuttavia in modo diverso da quello che farebbe un grafico, ma tenendo presente che ciò che stiamo “disegnando” dovrà diventare una pagina HTML/CSS
• Conoscenza – medio/alta – di HTLM e CSS
• Conoscenza – medio/alta di PHP
• Infine, conoscere la struttura e le funzioni messe a disposizione da WordPress

Vediamo adesso i quattro step principali che si seguono per realizzare un tema:

• Content Design
• Prototipo grafico
• Scrittura codice (PHP/HTML) per visualizzare i contenuti
• Taglio della grafica e scrittura CSS

Content Design

Primi di iniziare si dovrebbe sempre partire da uno schema che indica che tipo di contenuti – e come – il nostro tema dovrà visualizzare:

Il Content Design viene spesso sottovalutato, generando prima o poi problemi e perdite di tempo. Quando non viene fornito dal cliente, sarebbe bene farselo per conto proprio, anche perché è davvero difficile pensare ad una veste grafica senza conoscere cosa vestire. Il Content Design, come mostrato in figura, ci fornisce moltissime informazioni su come dovrà essere il nostro sito web. Inoltre permette di realizzare un grafica puntuale, eliminando subito proposte o idee non coerenti con il wire-frame; come barre di navigazioni verticali o logo a tutto schermo. Ogni sezione del sito, quindi, dovrebbe essere schematizzata in questo modo; dalla home alle pagine interne.
Inoltre è ovvio che un documento come il Content Design ha soprattutto un’utilità commerciale, permettendo di stabilire con maggior precisione le tempistiche di realizzazione e quindi fornire informazioni precise per preventivi e occupazione risorse.

Prototipo grafico

Con il nostro documento di Content Design – approvato – possiamo passare alla realizzazione grafica di un prototipo, la messa in opera della nostra idea. La prima stesura, normalmente, rappresenta un’idea di quello che sarà il risultato finale, non preoccupandosi necessariamente della fase di taglio-grafico e trasformazione in HTML/CSS. L’esperienza, con il tempo, porterà sicuramente ad unire le due fasi.

Scrittura codice (PHP/HTML) per visualizzare i contenuti

Approvato il prototipo grafico, si passa alla stesura del codice HTML e PHP che, di fatto, genera i contenuti del sito web. In questa fase non stiamo implementado ancora la grafica, la teniamo solo a mente quando scriviamo il codice HTML che si collegherà poi agli stili CSS. Man mano che scriviamo il codice, terremo aperto il browser per controllare e verificare il progresso del nostro lavoro.

Si predispongono gli elementi HTML che serviranno da contenitori per i contenuti indicati nel Content Design. Una buona IDE, in questa fase, è vivamente consigliata. In particolare un IDE in grado di trattare PHP/HTML e CSS – giusto per non utilizzare tre applicazioni differenti: per i più bravi va bene anche VI o Blocco Note. A questo stadio dei lavori il nostro tema è al 50% e il sito web avrà un’aspetto simile a questo:

Avremmo cioè reso reale e funzionante il Content Design. Questa fase, che discuteremo anche più avanti, è la parte più delicata di tutta la procedura, in quanto richiede la corretta scrittura del codice HTML – che verrà vestito poi tramite i fogli di stile CSS – e la stesura del codice PHP necessario a risolvere le eventuali esigenze del caso (insieme ovviamente all’uso di plugin). Le funzioni PHP – che come vedremo dopo vengono inserite in un file specifico – potranno interagire anche con il backend.

Taglio della grafica + CSS

Finalmente possiamo tagliare la grafica realizzata in Photoshop (o altro), creandoci tutti i file immagini necessari alla composizione. Contestualmente si definiscono i fogli stile:

Come fatto nella fase precedente, man mano che scriviamo il codice CSS terremo un browser (anzi, più correttamente i browser: Safari, FireFox, Chrome, etc…) aperto per verificare che tutto proceda correttamente:

3. Cosa visualizzare

WordPress permette sostanzialmente di collezionare contenuti testuali (POST, PAGE, …) e multimediali (immagini, video, documenti PDF, …). Questi contenuti (descritti nel Content Design) possono essere estratti in vari modi: tramite le funzioni – il tema – standard di WordPress, tramite l’uso di Plugin, scrivendo proprie funzioni. Ogni file nel tema di WordPress svolge una funzione particolare e viene automaticamente richiamato da WordPress in determinate circostanze. I file più importanti di un tema (che può essere composto anche da numerosi file) sono:

In linea di massima potremmo affermare che tutti i file elencati, tranne l’ultimo style.css, determinano il cosa verrà visualizzato, mentre style.css il come. index.php, ad esempio, è il file principale, quello che corrisponde alla Home Page. header.php e footer.php contengono il codice HTML e PHP utilizzato rispettivamente nell’header e nel footer. Questa tecnica permette alle altre pagine di occuparsi esclusivamente del contenuto che cambia, normalmente la parte centrale. A livello logico tutte le pagine di un tema possono essere ricondotte a questo schema:

WordPress permette varianti e semplificazioni relative al naming dei file del tema. Ad esempio il file archive.php è quello che si occupa della visualizzazione degli archivi, cioè la lista dei contenuti (post) per categoria, tag, data, etc… Capita spesso, sopratutto in siti web che non sono necessariamente dei blog, di diver trattare la visualizzazione di una categoria diversamente da un’altra. In prima analisi verrebbe immediatamente spontane inserire una condizione all’interno del file archive.php del tipo:

Nonostante sia corretto, WordPress fornisce una più semplice ed elegante soluzione: basta creare un file composto da category- lo slug (abbreviazione) della nostra categoria, tipo: category-news.php. Questa caratteristica può essere utilizzata anche per le pagine e le sidebar, ma non per i post. Per le sidebar si nomina un file con una notazione simile a quella utilizzata per le categorie, tipo sidebar-footer.php, ma si usa una funzione per discriminare le varie sidebar:

Uno dei file più potenti e utili, presente nei temi, è functions.php. Questo contiene di solito tutte le funzioni PHP che possono essere richiamate all’interno di uno qualsiasi dei file del tema. In questo file, poi, possono essere eseguite funzioni tali da aggiungere o modificare funzioni presenti nel backend!
Tutte le funzioni inserite in questo file saranno disponibili esattamente come un qualsiasi altra funzione WordPress. Un qualsiasi file del tema, come single.php ad esempio, potrà accedere a queste funzionalità.

4. Snippet

Il codice qui qui sopra va inserito nel file header.php e permette di associare automaticamente al tag body una o più classi in base alla sezione di WordPress visualizzata, come ad esempio: <body class="home blog logged-in">. In questo modo possiamo “comunicare” al foglio di stile come comportarsi quando il tag body possiede una di quelle classi. Nell’esempio di sopra al tag body sono associate tre classi che indicano rispettivamente: siamo nella Home Page, categoria blog, utente “loggato”.
È possibile anche aggiungere proprie classi in base a determinate circostanze, passandole come parametro della funzione body_class() o utilizzando i filtri:

Vi propongo una carrellata di utili snippet da utilizzare prontamente nel vostro tema! Snippet da inserire nel file functions.php:

5. Il tema e il backend

Come anticipato WordPress permette di personalizzare il backend, sia tramite l’uso di plugin sia direttamente dal tema. Ad esempio è possibile fornire nel backend la possibilità di modificare l’immagine nell’header:

Altra importantissima funzionalità è quella di presentare in modo più “usabile” i campi personalizzati all’utente che opera l’inserimento di un post. Questa è un’altro punto a favore di WordPress, cioè la possibilità di alterare la maschera di inserimento di un post/pagina, rendendo il backend estremamente più semplice da utilizzare per il cliente. Normalmente nel backend i campi personalizzati si presentano come:

Questo maschera, per quanto funzionale, non è certo l’ideale per un cliente. Meglio sarebbe avere una maschera propria, con proprie label e controlli sui campi. Ad esempio nel backend del nostro sito abbiamo aggiunto una maschera quando l’inserimento riguarda un prodotto:

Come risulta evidente questa soluzione è sicuramente migliore, più usabile e chiara. Per implementarla non è necessario l’uso di plugin ma basta inserire poche righe di codice nel nostro file functions.php sfruttando la funzione add_meta_box() ben documentata qui.

5 cose sui Plugin

1. quando scrivere un plugin

In base a quello che abbiamo visto nella sezione precedente, risulta evidente che spesso si abusa l’uso e la scrittura di plugin. Non sempre è necessario scrivere o utilizzare un plugin, perché alcune funzionalità possono essere inserite direttamente nel file functions.php, con il vantaggio di essere legate al tema, pesare meno al sistema, non poter essere disabilitate.
Un plugin conviene scriverlo quando riteniamo svolga una funzione generica, non legata all’esigenza contestuale. A differenza poi delle funzioni inserite manualmente nel tema, un plugin permette di essere condiviso, aggiornato e installato in qualsiasi contesto. Tutto questo ha un prezzo nelle performace del sistema; aggiungere 30 plugin non è certo salutare.

2. le funzioni più importanti

Le funzioni più potenti presenti in WordPress, che permettono spesso di risolvere problematiche apparentemente complesse sono le “poco documentate” add_filter() e add_action(). Per questione storiche – legate anche a vari snippet che si trovano in rete – le segnalo entrambe anche se add_action() non fa altro che chiamare add_filter()! Queste gestiscono un sistema davvero ingegnoso che permette al programmatore di alterare il normale comportamento delle funzioni di sistema. Le abbiamo già incontrate negli snippet presentati sopra, ma vediamo nel dettaglio come funzionano e come usarle.
Un esempio chiarificatore può essere:

In questo esempio abbiamo aggiunto una nostra funzione quando WordPress si prepara ad emettere l’output dell’header nell’amministrazione. Il primo parametro indica a quale azione (o filtro) vogliamo collegarci. Il secondo è il nome della nostra funzione da eseguire. Di filtri (e o azioni) ne esistono tanti, alcuni documentati altri no:

• Azioni
• Filtri

Con le ultime versioni di WordPress, a livello di sistema, azioni e filtri sono la stessa cosa. Tuttavia concettualmente vengono (a ragione) distinti. Una action è appunto un’azione, tipo:

I filtri, a differenza, vengono usati ad esempio per alterare l’output o il comportamento di alcune funzioni:

Per capire come funzionano i filtri, ecco un’estratto del codice sorgente della funzione che usa WordPress nel caso esposto qui sopra:

Ingegnoso!

3. come scriverlo

Una disamina sulla struttura di un Plugin è disponibile su: Sulla struttura ad oggetti di un Plugin WordPress, dove viene illustrato un possibile scheletro per confezionare adeguatamente un plugin.

4. tools

Dal punto precedente due consigli: una buona IDE e strumenti che agevolano la scrittura!

PhpStorm

WordPress Plugin Maker

5. anteprima di una possibile evoluzione

Partendo da Sulla struttura ad oggetti di un Plugin WordPress stiamo sviluppando un’evoluzione orientata al paradigma MVC (Model View Controller), utilizzato in ruby e Objective-C.
Lo scenario che si prospetta, relativamente alla scrittura di Plugin, è quello di fornire un Framework – un insieme di classi – da utilizzare per la scrittura veloce di Plugin, estendendo ed implementando una serie di interfaccia ancor oggi assenti nell’ambiente WordPress.
Grazie all’esperienza maturata in ambito Objective-C, si è pensato di riproporre un modello di sviluppo simile, sfruttando alcune caratteristiche simile di Objective-C e PHP.
L’idea sarebbe quella di poter iniziare lo sviluppo di un Plugin estendendo una classe al pari di quello che accade in ambiente iOS. Costruire cioè quel collegamento con la programmazione ad oggetti che, di fatto, manca nell’ambiente WordPress:

Al pari di:

Questa idea sarebbe affiancata da una nuova versione di WordPress Plugin Maker. La classe SMWordpressPlugin fornirebbe un ponte tra un’approccio Object Oriented all’attuale linearità del kernel WordPress. Fornirebbe già tutta una serie di metodi predisposti a gestire il backend di WordPress, come la gestione dei meta-box ad esempio. Inoltre renderebbe le azioni e filtri visti sopra, più simili ai delegati di Objective-C.

Questo stesso approccio potrebbe servire anche nello sviluppo di un tema, permettendo di sfruttare una classe come SMFunctions da usare nel file functions.php.

Oggi che PHP5 e lo sviluppo ad oggetti è più diffuso, sarebbe per WordPress una naturale evoluzione che, dal canto nostro, possiamo anticipare.

Author BIO

A 13 anni mi sono trovato a scegliere tra l’acquisto di una macchina (stop motion) per realizzare cartoni animati fai da te o un Commodore 64! Dopo attenta riflessione ho avuto il sentore che un giorno, forse, i cartoni sarebbero stati realizzati con macchine come quella, chiamate “personal computer”. Così ho scelto il “PC” e ho avuto la fortuna di conoscere un mondo, quello informatico, pieno di sorprese e soddisfazioni, che mi ha permesso di reliazzare molto più di un “cartone fai da te”. Dalla programmazione in Basic e in Assembly del 6502, passando per i processori Motorola 680×0 e 80×86, il C su Unix, Visual Studio, Javascript, PHP, Actionscript e Objective-C, mi ritrovo qui come responsabile del reparto di ricerca e sviluppo software, ancora oggi curioso come allora.

Tags

Content Design giovambattista fazioli LAMP linux mysql Plugin Plugins saidmade sviluppo wordcamp WordPress

<pre></pre>                                  // blocco generico
<code></code>                                // blocco generico
[cc_actionscript][/cc_actionscript]          // Actionscript
[cc_actionscript3][/cc_actionscript3]        // Actionscript 3
[cc_css][/cc_css]                            // CSS Style Sheet
[cc_html][/cc_html]                          // HTML
[cc_js][/cc_js]                              // Javascript
[cc_objc][/cc_objc]                          // Objective-C
[cc_php][/cc_objc]                           // PHP
[cc_sql][/cc_sql]                            // SQL