Novembre 2009 - TomStardust.com

Come personalizzare i default Widget di WordPress

Una guida alla creazione di Widget personalizzati per Wordpress.

WordPress include una serie di widget molto utili, che possono essere inseriti fin da subito all’interno di ogni tema. Possono essere visualizzati gli ultimi commenti, i post più recenti ed una serie di altre informazioni utili gestendo tutto dal pannello di amministrazione.

Spesso però i default widget sono limitati e non adatti a tutte le occasioni: potreste avere la necessità di eliminare una particolare categoria dagli ultimi post, o di modificare il codice html con cui viene presentato il box di ricerca.

La soluzione fortunatamente esiste e non è complessa: è possibile infatti recuperare i widget esistenti, modificarli e farli apparire sul pannello di amministrazione accanto a quelli standard.

Aggiornamento 2022: WordPress è cambiato nel tempo e i default Widget ora sono suddivisi ognuno nel suo file, all’interno della cartella wp-includes/widgets. Le istruzioni di questo post restano valide.

I passi da seguire

Se avete un minimo di basi di php, creare i vostri widget è semplice. Questa è la procedura in sintesi:

Aprite il file wp-includes/default-widgets.php, dove sono presenti tutti i widget di default.
Individuate il widget da personalizzare. Ognuno ha qualche riga di commento che ne chiarisce la funzione, ma i nomi delle classi sono già autoesplicativi: WP_Widget_Search, WP_Widget_Recent_Comments, WP_Widget_Tag_Cloud, ecc.
Copiate tutto il codice del widget che vi interessa dentro il file functions.php del vostro tema (se non l’avete, createlo).
Personalizzate il nome della classe in tutte le sue occorrenze e le altre informazioni necessarie (ad esempio la descrizione che appare sul pannello di amministrazione).
Modificate il codice secondo le vostre esigenze. Qualche esempio? Personalizzare i link del widget meta, cambiare il form nel widget della ricerca, mostrare gli ultimi post di una specifica categoria… le possibilità sono infinite.
Aggiungete subito dopo la definizione del nuovo widget, nel file functions.php, la riga
register_widget('nome_del_widget_personalizzato');

I vantaggi di questo metodo sono notevoli:

Non è necessario conoscere php approfonditamente, basta saperlo leggere per poter aggiungere qualche riga di codice
E’ possibile aggiornare WordPress senza problemi
Il nuovo widget appare sul pannello di amministrazione, e può essere usato anche da utenti non esperti (l’ideale quando si ha a che fare con clienti poco tecnici)

Se decidete di personalizzare i widget, fate però attenzione: non modificate direttamente il file default-widgets.php, è bene che il core di WordPress resti intatto. Utilizzare functions.php è l’ideale: eviterete possibili problemi e soprattutto potrete aggiornare WordPress senza preoccupazioni. Gli update della piattaforma sono frequenti e spesso essenziali per motivi di sicurezza, non è mai bene vincolarsi ad una particolare versione.

Pirobox: la nuova versione

Un ottimo plugin per la visualizzazione di immagini, realizzato in Italia.

Pirobox è un plugin di jQuery per la creazione di gallerie di immagini. E’ una creazione tutta italiana, e ne avevo già parlato in passato su questo sito. Mi ha fatto molto piacere scoprire che Diego Valobra, il suo creatore, ne ha appena rilasciato la nuova versione con alcuni miglioramenti:

diminuito il peso del codice, per una maggiore velocità di caricamento: da 25kb a 11kb
implementata la navigazione da tastiera
controllo sui link errati, che non fermano lo script ma visualizzano un’immagine di avviso
riposizionamento automatico delle immagini durante lo scroll della pagina
png fix per Explorer 6

Tutto questo si aggiunge all’ottimo lavoro che Diego aveva già fatto. Sono notevoli anche le opzioni di personalizzazione: tre skin sono già pronte (nera, bianca e trasparente), e c’è la possibilità tramite alcuni parametri di decidere la posizione delle frecce di scorrimento nelle gallerie di immagini (alla base dell’immagine o ai lati della pagina).

Se nel vostro prossimo progetto avete bisogno di uno script simile a Lightbox per mostrare anteprime di immagini, provate Pirobox. Alcuni dettagli come la navigazione da tastiera possono fare la differenza, e l’implementazione non richiede tag aggiuntivi nel codice: è sufficiente una classe html per abilitare lo script, in modo semplice e pulito.

Per vedere le demo e le caratteristiche di questo plugin in dettaglio vi rimando alla pagina ufficiale di Pirobox.

Ombre cross-browser con i CSS, senza immagini

Come sfruttare la proprietà box-shadow dei CSS3 ed ottenere risultati simili anche su Internet Explorer.

La proprietà box-shadow (CSS3) permette di applicare ombre ad elementi contenitori di tipo block. Funziona in maniera simile alla proprietà text-shadow, ma il W3C al momento ne ha sospeso l’approfondimento per studiarne l’implementazione in maniera più approfondita.

Come funziona box-shadow?

La proprietà può essere utilizzata su Firefox 3.5 e sui browser basati su webkit (Safari e Chrome) con i soliti prefissi:

-moz-box-shadow per Firefox
-webkit-box-shadow per Safari e Chrome

L’espressione è semplicemente:

box-shadow: 5px 5px 10px #000;

dove i parametri sono nell’ordine:

la distanza dell’ombra in orizzontale ed in verticale
il raggio
il colore

Ho notato che tra i browser webkit la resa è migliore su Safari: Chrome pur visualizzando l’ombra ha qualche problema con gli angoli ed il loro arrotondamento.

La soluzione per Internet Explorer

La cosa interessante, scoperta per caso sul blog di Nick Dunn, è che con alcuni hack è già possibile sfruttare questa proprietà per ottenere un risultato valido anche su Internet Explorer.

Esistono infatti alcuni filtri proprietari della Microsoft che in queste circostanze sono l’unica soluzione possibile. Era già successo per i .png trasparenti su IE6, e la situazione è analoga anche in questo caso. Combinando i filtri Glow e Shadow, o ancora meglio utilizzando solamente Shadow è possibile ottenere un’ombra molto simile su tutte le versioni di Explorer, a partire dalla 5.5.

Il codice necessario è il seguente, da inserire in un commento condizionale:

filter:
    progid:DXImageTransform.Microsoft.Shadow(color=#eeeeee,direction=0,strength=7)
    progid:DXImageTransform.Microsoft.Shadow(color=#dddddd,direction=90,strength=10)
    progid:DXImageTransform.Microsoft.Shadow(color=#dddddd,direction=180,strength=10)
    progid:DXImageTransform.Microsoft.Shadow(color=#eeeeee,direction=270,strength=7);

Color e strenght dell’ombra possono ovviamente essere modificati secondo le necessità.

Demo

Ho realizzato una pagina dimostrativa di questo effetto.

Il risultato cambierà leggermente a seconda del browser utilizzato, ma resterà comunque coerente. La soluzione non è esente da difetti, ma è un buon compromesso per aggiungere dettagli in più ad un design senza appesantirlo con delle immagini. C’è anche da considerare che spesso è complicato dare un’ombra ad un contenitore, soprattutto se questo ha delle dimensioni variabili: l’unica soluzione è utilizzare del codice html superfluo o adottare questo metodo.

I difetti principali che ho riscontrato sono:

CSS non valido
niente ombra su Firefox < 3.5 e su Opera
uso di hack per Internet Explorer

A voi la scelta se adottare questa soluzione: è una possibilità da tenere in considerazione, ma la sua efficacia è da valutare a seconda del progetto. Niente vieta comunque di adottare anche solo la soluzione per Firefox come progressive enhancement, offrendo un’esperienza migliore di navigazione ad alcuni utenti.

Il Web per non vedenti: qual è il giudizio degli utilizzatori di Screen Reader?

Un sondaggio rivolto ad utenti di Screen Reader mostra qualche sorpresa ed i progressi del web mobile.

WebAIM ha pubblicato i risultati di un recente sondaggio (Ottobre 2009), tra 665 utilizzatori di screen reader. E’ la seconda edizione di questo sondaggio: ne avevo infatti già parlato l’anno scorso, in un articolo sull’utilizzo dei lettori di schermo per effettuare test di accessibilità.

I risultati sono importanti: non condizioneranno in maniera rivoluzionaria le abitudini dei web designer attenti a queste tematiche, ma danno un quadro completo di questa specifica categoria di utenti. Tra le note più interessanti:

Il 66,4% utilizza JAWS come screen reader principale
Il 49% usa abitualmente più di uno screen reader, a seconda del contesto
Il 53% degli utenti disabili usa uno screen reader su un dispositivo mobile
I problemi principali sulle pagine web sono dati da CAPTCHA, contenuti Flash inaccessibili e link ambigui
Il 46% pensa che il web stia diventando più accessibile che in passato
Social Media: il 51% usa YouTube, il 47% un blog, il 42% Facebook ed il 38% Twitter
Twitter è giudicata la piattaforma più accessibile
Per trovare informazioni su una pagina, il 50% scorre i titoli (h1, h2…) ed il 22% usa la ricerca interna

Uno dei dati più sorprendenti riguarda l’utilizzo di dispositivi mobili. Sicuramente è un settore in cui sono stati fatti molti progressi nell’ultimo anno, e credo che abbia avuto una buona importanza anche l’uscità dell’iPhone 3Gs con VoiceOver. Potrebbe sembrare strano, ma i dispositivi touchscreen accessibili sono ormai realtà, e se siete interessati vi consiglio di leggere recensioni come quella di Marco Zehe, che racconta la sua esperienza personale con questo smartphone.

Rispetto all’anno scorso, le raccomandazioni rimangono più o meno le stesse: le intestazioni continuano ad avere una grande importanza per l’accessibilità di una pagina web, ed uno dei problemi principali sono ancora i CAPTCHA e Flash. In certi progetti è impossibile farne a meno, ma sapere che potrebbero creare problemi è già un primo passo.