Il nostro Andrea ci segnala che è disponibile la uova versione di WordPress Menubar.

Le novità sono due:
1) i link generati rispettano la struttura dei permalink;
2) il link ad una pagina rimane evidenziato anche quando si visitano eventuali pagine figlie.

[Download ]

Segnaliamo un bell’articolo di Fucinaweb in cui si analizzano le nuove funzionalità di WP 2.3. Anche se le schermate proposte sono in inglese l’articolo è interesante anche per il fatto che l’autore ne ha provato l’installazione e riporta le sue impressioni segnalando eventuali problemi ch un utente potrebbe incontrare.

Segnaliamo un articolo di Time’n'doom in cui ci racconta come è andato l’aggiornamento del suo blog a WordPress 2.3 (vi anticipiamo che è andato bene), spiegando passo passo i vari passaggi e le prime impressioni.

Sempre per documentare al meglio le novità della versione 2.3 di WordPress ecco un altro articolo di Ryan Boren sulle modifche al database

WordPress 2.3 modifica lo schema dei database in tre posti. La modifica più grossa riguarda le modifiche relative alla tassonomia di cui abbiamo già discusso precedentemente. Poiché la tassonomia avrebbe causato dei problemi di compatibilità con le versioni precedenti, abbiamo deciso di distruggerla completamente e di creare qualche cosa che ci piacesse. Ecco quindi che le tabelle post2cat e link2cat sono state eliminate e rimpiazzate con tre nuove tabelle. I plugin che fanno riferimento alle vecchie tabelle non funzioneranno. Dovranno venir aggiornati preferibilmente tramite l’uso delle API o utilizzando del codice SQL che faccia riferimento alle nuove tabelle invece che alle vecchie.

Le altre due modifiche sono più piccole e di minore impatto. E’ stato aggiunto un nuovo stato ‘pending’ al campo post_status della tabella posts. Ciò non influenzerà molti plugin. Quei plugin che verificano lo stato di un articolo potrebbero avere problemi.Questi plugin possono utilizzare una programmazione difensiva per isolare se stessi da nuove aggiunte di stati.

Per finire, diversi campi non utilizzati sono stati eliminati dalla tabella delle opzioni. option_can_override, option_type, option_width, option_height, option_description e option_admin_level sono stati eliminati. Questi campi sono rimasti inutilizzati per anni. E’ venuto il tempo di eliminarli e ripulire la tabella delle opzioni.

Una delle novità principali della versione 2.3 riguarda la nuova gestione dei tag, per questa nuova funzionalità la struttura dei database è cambiata in maniera significativa, di seguito la traduzione di un articolo di Ryan Boren a riguardo:

WordPress 2.3 introduce un nuovo schema per la tassonomia. Questo nuovo schema rimpiazza le tabelle delle catgorie: post2cat e link2cat con tre nuove tabelle che risultano essere molto più flessibili. La prima tabella terms. Contiene le informazioni di base su un dato termine. La sua struttura si presenta così:

term_id bigint(20) NOT NULL auto_increment,
name varchar(55) NOT NULL default '',
slug varchar(200) NOT NULL default '',
term_group bigint(10) NOT NULL default 0,
PRIMARY KEY (term_id),
UNIQUE KEY slug (slug)


“name” è semplicemente il nome di un dato termine. “slug” è il nome ridotto in una forma “URL friendly”. “term_group” ha lo scopo di raggruppare termini simili. “term_id” è un ID unico per il termine.

Un termine non è ne una categoria ne un tag. Gli viene assegnato un contesto tramite la tabella term_taxonomy:

term_taxonomy_id bigint(20) NOT NULL auto_increment,
term_id bigint(20) NOT NULL default 0,
taxonomy varchar(32) NOT NULL default '',
description longtext NOT NULL,
parent bigint(20) NOT NULL default 0,
count bigint(20) NOT NULL default 0,
PRIMARY KEY (term_taxonomy_id),
UNIQUE KEY term_id_taxonomy (term_id,taxonomy)


La tabella term_taxonomy posiziona un termine in una tassonomia. Ciò è quello che rende un termine una categoria o un tag (o entrambe le cose). “term_id” è l’ID di un termine presente nella tabella terms. “taxonomy” designa la tassonomia nella quale il termine risiede. Le tassonomie predefinite sono “category”, “link_category” e “post_tag”. “term_taxonomy_id” è un ID unico per la coppia termine+tassonomia. Il resto dei campi forniscono informazioni riguardanti il termine nel contesto della tassonomia. Il campo “parent” tiene traccia delle relazioni gerarchiche fra i termini della tassonomia. “description” fornisce una descrizione specifica per la tassonomia del termine . “count” traccia quanti oggetti sono associati con la coppia termine+tassonomia. Data ad esempio una tassonomia “categoria”, “count” tiene traccia di quanti articoli sono in quella categoria.

L’ultima tabella, term_relationships, relaziona oggetti come articoli o link ad un term_taxonomy_id della tabella term_taxonomy.

object_id bigint(20) NOT NULL default 0,
term_taxonomy_id bigint(20) NOT NULL default 0,
PRIMARY KEY (object_id,term_taxonomy_id),
KEY term_taxonomy_id (term_taxonomy_id)


“object_id” è l’ID di un articolo o di un link. “term_taxonomy_id” è l’ID della tabella term_taxonomy che indica una coppia termine+tassonomia specifica.

La flessibilità dello schema e le relative API fanno si che i plugins possano aggiungere nuove tassonomie e tipi di oggetto in maniera estremamente semplice. Uno dei progetti del Summer of Code realizza proprio questo. Tale flessibilità ci permette anche di ritrovare facilmente gli oggetti associati ad un dato termine indipendentemente dalla tassonomia, recuperare tutti i termini da tutte le tassonomie per un dato oggetto e convertire tutte le actegorie in tag con una sola query.

Lo schema della tassonomia è nascosto dietro una API per la tassonomia abbastanza completa. Le API di categoria rimangono come una strato di compatibilità isopra le API di tassonomia. I plugin che usano le API di categoria non dovrebbero richiedere aggiornamenti con la 2.3. I plugin che eseguono query SQL direttamente sulla tabelle di categoria link2cat o post2cat purtroppo non funzioneranno.

Ecco quindi il nuovo schema. Darà problemi a qualche plugin nel breve termine, ma sul lungo termine ci permetterà di aggiungere nuove tassonomie che si rendessero necessarie senza la necessità di cambiare nuovamente la struttura del database a riguardo.