E’ stata rilasciata la versione beta 2 di WordPress 3.2, con alcune importanti novità. In attesa dell’uscita della release definitiva è stata inviata una comunicazione agli sviluppatori con l’invito a fare dei test: ci saranno infatti alcuni cambiamenti rilevanti, ed è bene che siano noti a tutti coloro che usano WordPress soprattutto in ambito lavorativo.

Requisiti minimi: PHP 5.2.4 e MySQL 5.0.15

Il primo fattore da considerare è il cambiamento dei requisiti minimi per l’installazione di WordPress. Dalla versione 3.2 in poi sarà necessario avere installati sul server PHP 5.2.4 e MySQL 5.0.15.

Questo potrebbe causare problemi con alcuni servizi hosting che utilizzano ancora la versione 4 di PHP: non è un caso così raro come si potrebbe pensare. Al momento di aggiornare a WordPress 3.2 ricordatevi di controllare la configurazione del vostro hosting in modo da evitare sorprese.

Aggiornamento a jQuery 1.6.1

Un’altra novità rilevante è l’aggiornamento della versione di jQuery inclusa in WordPress. Si passa da jQuery 1.4.4 alla 1.6.1, con un salto di ben due major release.

Tra le novità più importanti, la versione 1.5.0 e le successive non consentono più l’utilizzo di selettori del tipo [property=value], ma è necessario utilizzare la forma [property="value"].

Inoltre nel passaggio a jQuery 1.6.0 e versioni successive il metodo .attr() è stato sostituito da .prop(): in alcuni casi sarà quindi necessario modificare il codice, ed alcuni plugin potrebbero dare degli errori se non aggiornati di conseguenza.

Chi interessano queste novità?

Se siete tentati di sorvolare su queste novità, potreste avere delle brutte sorprese al momento dell’aggiornamento a WordPress 3.2, quando uscirà la versione finale. Ovviamente i diretti interessati a questo cambiamento sono gli sviluppatori di plugin e temi, ma anche se non siete dei programmatori e state semplicemente utilizzando WordPress per i vostri progetti, vi raccomando di provare ad installare in locale la beta 2 e controllare che tutto funzioni.

Per effettuare dei test sui vostri siti di sviluppo potete scaricare la versione beta 2 di WordPress 3.2 a questo indirizzo.

Il KnowCamp è un evento no-profit che si pone come obiettivo quello di offrire un’opportunità di condivisione di esperienze ed opinioni attorno a tematiche di forte attualità: il Sapere ed il Web. Sapere inteso come conoscenza ed informazione, da ricercare con motivazione ed apertura e da elaborare con senso critico. Per farne opinioni, idee, proposte da diffondere e condividere. In questo processo il Web si rivela strumento ideale: luogo libero ed aperto a ogni prospettiva, in cui ogni voce trova spazio ed eco.

Un ulteriore elemento interessante che riguarda la manifestazione è la contemporanea presenza del WordCamp. Nella giornata di sabato 19 Marzo infatti ci sarà spazio per parlare di WordPress con dei talk mirati, che al momento sembrano promettere molto bene. Ci sarà comunque la possibilità di chiacchierare durante tutta la giornata, come sempre capita durante eventi di questo genere.

Trovate l’elenco dei talk del KnowCamp e del WordCamp sul sito ufficiale, in continuo aggiornamento.

Se avete intenzione di partecipare potete registrarvi su Eventbrite. Vi segnalo anche la pagina di riferimento su wordcamp.it, dove potete segnalare la vostra presenza nel caso Eventbrite non vi bastasse ;)

Io sarò sicuramente presente sabato 19: se pensate di venire fatemelo sapere, ci vediamo a Modena.

La mia attenzione è rivolta soprattutto ad un nuovo elemento che è stato introdotto: i post format.

Cosa sono i post format?

Nella pagina di scrittura di un post adesso è possibile assegnare all’articolo da pubblicare uno specifico formato. Volete pubblicare una citazione in modo che abbia un aspetto diverso dagli articoli? Adesso potete farlo, così come per un semplice video, una foto, o un breve testo (chi pensa agli aggiornamenti provenienti da Twitter?).

Questa nuova feature però non funziona automaticamente: deve essere attivata dal template. Se il tema che utilizzate non supporta i post format non vedrete il nuovo box nella pagina di scrittura post.

Implicazioni tecniche

Per aggiungere ad un tema il supporto ai post format, è necessario specificarlo nel file functions.php:

add_theme_support('post-formats');

Quindi nei file page.php, single.php, ma anche nella homepage del tema è necessario controllare l’esistenza dello specifico formato di cui si vuole modificare l’aspetto:

if ( has_post_format( 'quote' )) {
  echo 'questa è una citazione.';
}

Se non volete modificare il codice HTML, potete sempre fare affidamento alla funzione post_class, che assegna ad ogni post delle classi CSS specifiche. Nel caso dei nuovi formati troverete delle classi corrispondenti, come .format-video o .format-quote.

Sviluppi futuri con i post format

Con l’introduzione di questa novità tutti i temi in circolazione sono diventati automaticamente obsoleti. Tenetelo presente quando rilasciate un tema, che sia gratuito o a pagamento: è diventato fondamentale aggiungere il supporto per i post format.

I temi gratuiti su wordpress.org concedono ancora un po’ di elasticità, ma non mi stupirei se in futuro diventasse obbligatorio supportare i nuovi formati dei post con degli stili ad hoc. A maggior ragione questo discorso vale per i temi premium: poter differenziare i post a seconda del contenuto diventerà la regola da seguire, come succede da tempo su Tumblr.

Sono infatti presenti dei box inutili per degli utenti alle prime armi: campi personalizzati, revisioni, trackback, tutti dettagli che creano solo confusione. E’ possibile modificare il layout delle pagine di amministrazione di WordPress tramite il pannello impostazioni schermo, ma è comunque una soluzione che solo gli utenti più esperti sono in grado di notare.

Fortunatamente esiste un’altra soluzione: la possibilità di modificare i componenti della pagina direttamente tramite il file functions.php del tema utilizzato. E’ sufficiente inserire le seguenti righe di codice:

function customize_post_page() {
  global $current_user;
  get_currentuserinfo();

  if ($current_user->user_level < 2) {
    remove_meta_box('postcustom','post','normal');
    remove_meta_box('postexcerpt','post','normal');
    remove_meta_box('trackbacksdiv','post','normal');
    remove_meta_box('tagsdiv-post_tag','post','normal');
  }
}

add_action('admin_init','customize_post_page');

Con questa modifica, ogni utente registrato con il ruolo di sottoscrittore non vedrà nelle pagine di scrittura post i riquadri di campi personalizzati, excerpt, trackback e tag.

La funzione remove_meta_box prevede vari parametri, che potete trovare ben descritti sul Codex ufficiale. Un consiglio ulteriore è quello di prevedere un’eventuale modifica alla riga

if ($current_user->user_level < 2) {

perché i livelli utente di WordPress sono ormai deprecati e potrebbero diventare obsoleti. Potrebbe essere il caso quindi di controllare il ruolo dell’utente in maniera differente, facendo affidamento alla pagina Roles and Capabilities del Codex ed usando la funzione current_user_can.

Questo parametro però non controlla solo il numero di post della home, ma limita anche il numero dei risultati della ricerca e le pagine corrispondenti al template archive.php (ad esempio la pagina delle categorie e dei tag).

Per modificare il numero di risultati restituiti (in questo caso 10) è sufficiente usare:

<?php query_posts($query_string.'&posts_per_page=10'); ?>

subito prima del loop:

<?php if (have_posts()) : ?>
<?php while (have_posts()) : the_post(); ?>

E’ fondamentale che sia presente il parametro $query_string per mantenere la query originale senza sovrascriverla, altrimenti vi verranno restituiti solo gli ultimi post invece dei risultati della ricerca.

In questo modo è possibile ad esempio avere un numero limitato di post sulla home del blog e 10-20 risultati sulla ricerca.

Altri usi di $query_string

Le query di WordPress possono essere personalizzate in altri modi, anche fuori dal classico loop. Se ad esempio in homepage volessimo mostrare due gruppi di tre post appartenenti esclusivamente a due diverse categorie possiamo scrivere:

<?php $my_query = new WP_Query($query_string.'showposts=3&cat=1&posts_per_page=3'); ?>
<?php while ($my_query->have_posts()) : $my_query->the_post(); ?>

[...]

<?php endwhile; ?>

e

<?php $my_query = new  WP_Query($query_string.'showposts=3&cat=2&posts_per_page=3');  ?>
<?php while ($my_query->have_posts()) : $my_query->the_post();  ?>

[...]

<?php endwhile; ?>

Il parametro cat è fondamentale per indicare quale categoria mostrare (il numero corrisponde all’ID della categoria), mentre showposts e posts_per_page indicano quanti articoli visualizzare, anche nelle pagine successive alla prima.

Non capita tutti i giorni di avere a che fare con query diverse dal solito, soprattutto lavorando a semplici blog, ma in certe situazioni è bene sapere come poter personalizzare WordPress secondo le proprie esigenze. Se siete interessati ad altre personalizzazioni o volete condividere delle scoperte che avete fatto con WordPress lasciate un commento, potremmo approfondire il discorso.

Il 18 giugno scorso ho partecipato al primo WordCamp italiano lontano da Milano: era la prima volta che veniva organizzato un barcamp su WordPress nel sud Italia, e mi ha fatto molto piacere poter essere presente a Catania.

Dopo essere stato presente alle edizioni milanesi del 2008 e del 2009, i confronti vengono quasi spontanei, e devo ammettere che sono rimasto molto contento dell’evento organizzato da Roberto Chibbaro. Era una bella occasione per coinvolgere delle realtà che molto spesso vengono colpevolmente dimenticate, e poter assistere a degli interventi interessanti mi ha permesso di fare diverse conoscenze utili.

Proprio sulle differenze di mentalità ha scritto un post interessante Luca, che è riuscito a dipingere un quadro molto verosimile, confrontando i diversi scenari che ci si possono parare davanti partecipando agli eventi di networking tra Londra, Roma e Catania. Quella della Sicilia è una realtà viva, che ha voglia di mettersi in mostra ed è capace di presentare delle idee interessanti, ma incontra difficoltà nel metterle in pratica. Parlare poi di soldi e finanziamenti per delle idee è quasi un’utopia: difficile trovare qualcuno disposto ad investire.

Nonostante tutto però c’è chi ha ancora voglia di emergere, e per questo non posso che fare i complimenti a chi continua ad insistere cercando una via per mettersi in mostra, come i ragazzi di Your Inspiration Web. I loro talk sono stati interessanti, così come è stato molto discusso l’intervento di Francesco “Fullo” Fullone, che ha esaminato WordPress sconsigliandone l’utilizzo in casi estremi, dove altri CMS si comporterebbero meglio.

Ho cercato di dare anche io il mio contributo, con un breve speech riguardante la mia esperienza con GdR Players. E’ stato utile discutere insieme ai presenti dell’utilizzo di WordPress per una community ridotta ai minimi termini, considerando anche ipotesi alternative come BuddyPress o le novità della versione 3.0. Mi ha fatto piacere ricevere pareri, suggerimenti e proposte interessanti, segno che la semplicità di WordPress continua ad attirare ed incuriosire, anche dopo gli ultimi aggiornamenti.

Se volete avere un quadro ancora più completo dell’evento, in rete potete trovare:

• I video di alcuni interventi, sul canale YouTube di Valerio Novelli.
• Le foto dell’evento su Flickr

Le slide della mia presentazione, dal titolo “WordPress per una community?”, sono le seguenti. Vederle fuori dal contesto non è ovviamente l’ideale, ma potete farvi comunque un’idea del contenuto:

L’appuntamento è per il WordCamp 2011: se avete proposte, suggerimenti, oppure eravate presenti e volete aggiungere qualcosa, i commenti sono a vostra disposizione.

Un ultimo ringraziamento va a Roberto ed a Giovanni, che con i loro consigli mi hanno regalato una fantastica settimana di vacanza in giro per la Sicilia.

Al momento gli interventi proposti sono diversi, ed il numero dei partecipanti continua a crescere. Potete trovare tutte le informazioni sui siti dedicati:

• WordCamp Milano
• WordCamp Catania

Io sarò presente a Catania, approfittando dell’occasione per godermi un po’ di vacanze in Sicilia nei giorni successivi all’evento. Non so ancora se parteciperò con un intervento (potrei raccontare qualcosa su GdR Players…), ma sarà comunque una bella opportunità per conoscere altre persone interessate all’argomento.

Se siete interessati a partecipare, registratevi sul sito del WordCamp che vi interessa. Ci vediamo a Catania!

E’ possibile infatti creare dei menu contenenti contemporaneamente:

• pagine
• categorie
• link diretti ad url specifiche

Questa novità facilita le possibilità di personalizzazione: non è più necessario nemmeno modificare nel template funzioni come wp_list_pages() o wp_page_menu, alle quali andavano passate come parametri le pagine da escludere.

I menu personalizzati sono gestiti in maniera simile alle widget: si selezionano le pagine e con il drag & drop è possibile ordinarle anche su sottolivelli. Il problema più grave di questo metodo riguarda l’accessibilità: non c’è stato alcun miglioramento dalle versioni precedenti di WordPress. E’ infatti impossibile ordinare gli elementi senza usare il mouse.

Rendere compatibile un tema con i menu personalizzati

E’ possibile adattare un tema esistente con i nuovi custom menu senza troppe difficoltà. E’ stata infatti introdotta una nuova funzione, che inserisce automaticamente sul sito il primo menu personalizzato che viene creato:

<?php wp_nav_menu(); ?>

Trovate la documentazione relativa ed i parametri opzionali in questa pagina del Codex. L’unica cosa necessaria da sapere è che se non è stato creato nessun menu personalizzato, la funzione wp_nav_menu va in fallback direttamente su wp_page_menu, di cui avevo già parlato in passato. Questo garantisce sempre la presenza di un menu di navigazione, permettendo agli utenti con esigenze particolari di poterlo personalizzare.

Aggiornamento: in attesa dell’uscita della versione ufficiale, potete scaricare la beta 2 di WordPress 3.0 dal blog.

Esistono vari plugin per mettere online con pochi clic la versione mobile di un blog WordPress (basti pensare a Wp Touch), ma le grandi possibilità di personalizzazione di MobilePress mi hanno convinto più di ogni altra cosa.

Tra i suoi punti di forza includo:

• Possibilità di creare temi per la versione mobile, sfruttando le stesse logiche dei temi standard per WordPress
• Possibilità di fornire un tema esclusivo per iPhone/iPod Touch
• Nessuna difficoltà di installazione e configurazione

Parlando dei difetti, l’unico che ho trovato riguarda l’interfaccia di amministrazione, in particolare l’assegnazione del tema. Se non riuscite a vedere il template corretto sul vostro iPhone, è perché il tema relativo a questo dispositivo viene assegnato separatamente rispetto a tutti gli altri dispositivi mobili. Sarebbe meglio avere un’impostazione di default per dare inizialmente a tutte le piattaforme lo stesso tema, iPhone compreso.

Scarica il mio tema base

Viste le possibilità che questo plugin mette a disposizione, sarebbe interessante realizzare una raccolta di temi gratuiti per dispositivi mobili, così come succede già su WordPress.org per i temi standard.

Voglio dare il mio contributo mettendo a disposizione la base del mio tema mobile, che ho realizzato modificando quello di default. Ho tradotto alcuni testi, modificato il formato delle date ed ottimizzato il codice HTML riducendolo all’essenziale.

MobilePress Theme (.zip – 14kb):

Potete considerarla come una base di partenza su cui fare le vostre personalizzazioni, come il cambio di colori o l’eliminazione di elementi non rilevanti per una versione mobile. Su tomstardust.com ad esempio ho limitato tutto alla visualizzazione dei soli post, nascondendo le pagine. Il mio tema comunque le include, potete decidere autonomamente come gestirle.

Se avete suggerimenti o consigli su quello che vorreste trovare nella versione mobile di un sito, dite la vostra nei commenti: il futuro della rete passerà sempre più attraverso i dispositivi mobili.

Le due funzioni hanno alcune differenze: wp_page_menu è stata introdotta dalla versione 2.7 e va ad estendere wp_list_pages, che comunque fa ancora egregiamente il suo dovere. Recentemente mi sono imbattuto in queste funzioni per un aggiornamento al tema Stardust, ed ho deciso di condividere quello che ho scoperto.

La funzione wp_list_pages

Se lavorate con WordPress, conoscerete bene questo template tag, esistente ormai da anni:

<?php wp_list_pages(); ?>

Il suo punto di forza sono le possibilità di personalizzazione.

Escludere una pagina dal menu

Una delle opzioni più usate è quella che consente di nascondere dal menu alcune pagine. Per farlo è sufficiente usare il parametro exclude (in questo caso elimina dall’elenco le pagine con ID 1 e 7:

<?php wp_list_pages('exclude=1,7'); ?>

Mostrare solo le pagine di primo livello

Un altro parametro molto utile è depth, che permette di nascondere tutte le sottopagine e controllare la profondità del menu:

<?php wp_list_pages('depth=1'); ?>

In questo caso, depth=1 mostra solo le pagine di primo livello.

Nascondere il titolo

Se invece non avete bisogno del titolo prima dell’elenco delle pagine, ad esempio perché il menu non è nella sidebar ma disposto in orizzontale, potete usare il parametro title_li:

<?php wp_list_pages('title_li='); ?>

La funzione wp_list_pages offre ottime possibilità di personalizzazione, e spesso è più che sufficiente. Per tutti i dettagli vi consiglio di consultare anche la pagina ufficiale su WordPress.org, dove sono illustrati i parametri utilizzabili ed i rispettivi valori.

La funzione wp_page_menu

Dalla versione 2.7 di WordPress è stato introdotta la funzione wp_page_menu, che aumenta le possibilità a disposizione degli sviluppatori. La differenza principale con wp_list_pages è nel codice che viene generato, e nella possibilità di mostrare un link alla homepage.

Usando la funzione

<?php wp_page_menu(); ?>

Questo sarà l’HTML creato:

<div class=”menu”>
  <ul>
    <li class=”current_page_item”><a href=”…” title=”…”>Pagina attiva</a></li>
    <li class=”page_item”><a href=”…” title=”…”>Pagina</a></li>
    …
  </ul>
</div>

Non c’è quindi bisogno di aggiungere codice HTML intorno alla funzione php, tutto il necessario viene generato automaticamente.

Cambiare la classe associata al menu

Per cambiare la classe del menu, è sufficiente usare il parametro menu_class:

<?php wp_page_menu('menu_class=navigation'); ?>

Mostrare un link alla home nel menu

La novità principale però riguarda il parametro per includere automaticamente un link alla homepage:

<?php wp_page_menu('show_home=1'); ?>

Utilizzando wp_list_pages questo era possibile solo inserendo manualmente nel template un link alla home, ma è una soluzione poco elegante. Inoltre possono esserci problemi quando la prima pagina del blog è una pagina statica: il link alla homepage apparirebbe duplicato.

Con wp_page_menu questo non accade: con un parametro è possibile gestire tutto senza problemi.

Altri parametri

Una caratteristica non è specificata sulla documentazione ufficiale, ma è fondamentale: la funzione wp_page_menu supporta tutti i parametri di wp_list_pages, essendo un’estensione di quest’ultima.

Se ad esempio volete creare un menu con classe “nav”, mostrando anche la homepage e solo un livello di profondità, questa è la funzione:

<?php wp_page_menu('menu_class=nav&show_home=1&depth=1'); ?>


Potete approfondire il discorso sulla pagina di wordpress.org dedicata alla funzione, ricordandovi quindi anche di wp_list_pages.

Quale funzione utilizzare?

La presenza di due funzioni simili potrebbe confondere le idee, ed in effetti viene da chiedersi quale sia l’utilità del conservarle entrambe. La risposta è da cercare nella retrocompatibilità per le vecchie versioni di WordPress.

Se però dovete sviluppare un nuovo tema e non avete problemi di questo tipo, il mio consiglio è di sfruttare fin da subito wp_page_menu. I vantaggi non sono incredibili ma ci sono: i vostri visitatori non noteranno niente di diverso, ma voi avrete un codice più facile da mantenere.