Questo è il primo articolo di una serie che introdurrà le novità della 2.5 sia dal punto di vista del normale utente che per gli sviluppatori di temi e plugin. no vuole essere una panoramica esaustiva perchè le modifiche sono moltissime grandi, piccole e minuscole e coprirle tutte sarà credo impossibile, inoltre molte cose più tecniche sono raccolte nella serie Weekly Digest che appare ogni settimana. Oggi ci concentreremo sulla migrazione di temi e plugin quindi un argomento di interesse per tutti gli sviluppatori. Ecco la traduzione di una sezione di una pagina del codex inglese:

WordPress 2.5 introduce una nuova interfaccia amministrativa che le altre modifiche a WP non dovrebbero avere un particolare impatto sui temi, nessun tag deprecato, nemmeno quelli più datati è stato eliminato, una cosa interesasnte per chi sviluppa temi è il supporto Gravatars nativo in WP che permette di avere temi che supportano gravatars senza ricorrere a plugin esterni e che sarà oggetto di uno specifico articolo.

La nuova interfaccia del pannello di amministrazione invece impatta notevolmente su tutti i plugin che hanno pannelli di opzione o che inseriscono elementi nei pannelli di amministrazione di WP.

Modifiche al menu di amministrazione

Il cambiamento più sostanziale della futura versione di WordPress version 2.5 è la completa revisione delle schermate di amministrazione e dei menu. I menus sono stati riorganizzati comunque molti plugin dovrebbero funzionare correttamente se utilizzano il metodo standard di aggiunta di menu amministrativi (in inglese) ma alcuni richiederranno degli aggiustamenti.

Schermate di amministrazione

Qualsiasi plugin che abbia aggiunto una sezione alla schermata di scrittura/modifica degli articoli o delle pagine, cos’ coeme in altre schermate di amministrazione, troveranno probabilmente che le modifiche di formattazione e si markup in WP 2.5 fanno si che tali aggiunte non si armonizzino e non appaiano come appartenenti alle normali sezioni preesistenti in WordPress. Inoltre alcuni hook che sino alla versione 2.3 i plugin utilizzavano per aggiungere informazioni nelle varie schermate sono stati rimossi in favore di una nuova API ce utilizza la funzione add_meta_box per definire una sezione da aggiungere alle schermate di modifica di articoli, pagine e link. (Tale funzione con del codice di commento si trova in wp-admin/includes/template.php).

Quindi, gli autori di plugin dovranno rilasciare una nuova versione dei loro plugin specifica per WordPress 2.5 o (preferibilmente) inserire della logica nei propri plugin che determina la versione ed utilizza la formattazione corretta. Un buon modo per fare ciò è quella di controllare se è definita la nuova funzione add_meta_box. Ad esempio:

if (function_exists('add_meta_box')) {
 // codice per la 2.5, in cui richiamare la add_meta_box per definire la schermata
} else {
 // codice per la 2.3, che richiama add_action( 'dbx_post_advanced' ) o funzioni similari
}

Nota: assicurarsi di eseguire il test function_exists ben avanti durante l’inizializzazione di WordPress! Questa funzione non viene caricata nel momento in cui viene inizializzato il plugin. Quindi si suggerisce di farlo all’interno di una azione ‘admin_menu’ e della nuova azione ‘admin_init’.

Activation Global Scope

Un altro cambiamento che può influenzare alcuni plugin è che in WordPress 2.5, gli hook di attivazione dei plugin vengono eseguiti in una funzione con scope non globale (precedentemente erano eseguite con scope globale). Ciò significa che se il vostro plugin ha un hok di attivazione e le funzioni che richiama si basano su variabili globali definite all’interno del file del vostro plugin, potreste scoprire che tali funzioni non lavorano correttamente. Tutto ciò che serve fare per risolvere il problema è, a livello di scope globale del vostro plugin, aggiungere una dichiarazione “global” per queste variabili. Ad esempio:

global $my_plugin_variable;
$my_plugin_variable = 3;

function my_plugin_activation_function() {
   global $my_plugin_variable;

   // rest of activation function
}

TinyMCE

Con WordPress 2.5 viene incluso TinyMCE 3.x che è una versione completamente riscritta di questo editor. Vi sono moltissime modifiche nelle API e tutti i plugin WordPress che aggiungono pulsanti all’editor devono venir aggiornati. Dei buoni punti di partenza sono:

http://wiki.moxiecode.com/index.php/TinyMCE:Plugins/devkit http://wiki.moxiecode.com/index.php/TinyMCE:API

Avviamente aggiungere un pulsante che inserisce del codice nella posizione del cursore è abbastanza semplice. il plugin “pagebreak” è un ottimo esempio da copiare..

Per il caricamento dei plugin vi è un nuovo filtro $mce_external_plugins che prende un array ‘name’ => ‘url’ e lo inserisce nella versione zip di TinyMCE. E’ opportuno utilizzare url assolute (con o senza il nome dell’host) in quanto utilizando URL relative occorrone alcune impostazioni all’array di inizializzazione per mantenere i valori di default (che possono venir cambiati da un plugin WordPress), risultando quindi possibile inrterrompere il caricamento di plugin esterni che utilizzano url relative. TinyMCE continua a non caricare un plugin da un altro dominio diverso da quello di esecuzione.

Il compressore gzip è anch’esso cambiato. Ora raccogli tutti i pezzi di TinyMCE e restituisce un file compresso in un solo passaggio. L’azione “mce_options” è ancora supportata ma deprecata. L’azione “tinymce_before_init” è rimpiazzata da un filtro “tiny_mce_before_init” cjhe si applica all’array con tutte le impostazioni di TinyMCE. Inoltre il file zip viene tenuto in cache su disco per risparmiare memoria/risorse di sistema. Questa cache viene invalidata da qualsiasi modifica all’array di inizializzazione o dal cambiamento dell’argomento ver=[number] quando si richiama tiny_mce_config. Questa versione viene filtrata da “tiny_mce_version” definita in /wp-includes/script-loader.php, così che un plugin la possa cambiare.

VI sono dei cambiamenti anche nel caricamento dei file di linguaggio. Il codice linguaggio è ora solo l’ISO 639-1, che è formato solo dalle prime due lettere ricavate dal valore locale di WordPress, tipo de, fr, es, it, etc. TinyMCE caricherà langs/[lang].js quando un plugin viene caricato e se un plugin ha un popup caricherà langs/[lang]_dlg.js quando si apre il popup.

Il caricamento delle stringhe di linguaggio predefinite è anch’esso differente. Ora sono tutte definite in tinymce/langs/wp-langs.php, così da venir inserite nel file .pot principale e tradotte in tute le lingue disponibili in WordPress [N.d.t. - Cosa che ha reso felici tutti noi dei team di traduzione!!] . Un plugin può utilizzare uqalsiasi stringa presente in tale file, si veda l’oggetto tinyMCE.i18n js quando viene caricato TinyMCE per vedere come vengono referenziate.

N.d.t. Con questo articolo vediamo che molte sono le cose che influenza il funzionamento dei plugin nella nuova versione di WP, a tal fine è già stata attivata una pagina del codex inglese dove sono elencati plugin (con la relativa versione) che risultano sicuramente compatibili o sicuramente non compatibili con la nuova versione di WP.

Si chiude qua il primo articolo di Aspettando WP 2.5, nel prossimo articolo vedremo la nuova bacheca e la struttura logica del pannello di amministrazione.

Con le ultime versioni di WordPress, spostare il blog da un hosting ad un altro è diventata un’operazione più semplice, grazie alla possibilità di export/import del database in un file XML in un formato che WordPress chiama “WordPress eXtended RSS ” o WXR. Questo file contiene post, commenti, categorie e quant’altro; è possibile specificare un singolo autore oppure il blog nella sua totalità. Questa funzione è comoda perché ci evita di dover pasticciare con PHPMyAdmin, a tutto vantaggio della semplicità dell’operazione.

L’unico problema da gestire con attenzione riguarda la migrazione del dominio, e non è strettamente legato a WordPress. Quando si trasloca il proprio dominio da un hosting ad un altro, c’è un lasso di tempo durante il quale il cambio di indirizzo IP si propaga attraverso tutti i server DNS in internet; normalmente dura circa 24/36 ore durante le quali il dominio è “ballerino” e il nome punta al vecchio o al nuovo server a seconda che il DNS utilizzato abbia già aggiornato il record relativo. Durante questo periodo sarebbe meglio pubblicare un post di avvertimento e chiudere i commenti, in modo da non perderne nel passaggio.

L’ideale sarebbe avere una installazione pulita e pronta sul nuovo hosting; come farlo dipende dal provider che avete scelto: se si riesce a conoscere prima l’indirizzo IP e lo spazio è già disponibile a volte è possibile procedere da subito con l’installazione, altrimenti si dovranno fare le cose “al volo”. Alcune volte si riesce ad accedere contemporaneamente al vecchio ed al nuovo modificando di volta in volta i server DNS e ripulendo la cache con un ipconfig /flushdns, oppure giocando con il file hosts residente sul vostro computer.

La cosa fondamentale da ricordare è che l’esportazione va fatta assolutamente prima dell’inizio del trasferimento di domino, in modo da essere certi di poter accedere senza problemi al blog originale. L’operazione è molto semplice: Manage –> Export, scegliete un autore o tutti ed esportate. Adesso accedete via FTP alla cartella nella quale risiede il blog, che di solito è una cosa tipo httpdocs o htdocs, e salvate tutto il contenuto. Controllate di stare effettivamente salvando tutto quello che vi serve, specialmente la cartella wp-content. (vedi procedure di backup?).

Se non avete pasticciato troppo il vecchio blog, ci sono il 99% delle possibilità che tutti i file che dovrete ripristinare via FTP risiedano nella wp-content e relative dipendenti, ma nel caso aveste materiale “sparso” ripristinatelo nella posizione originale. Accertatevi che le versioni di WordPress siano identiche, eventualmente aggiornate prima di spostare il blog; questo è molto importante, perché elimina il rischio di una sovrascrittura accidentale quando ripristinate i file via FTP.

A questo punto siete pronti per andare in Manage –> Import –> WordPress e qui potrebbe sorgere un problema: la dimensione massima del file accettato, che spesso è inferiore a quella del vostro file XML (WXR). E’ necessario a questo punto spezzarlo in più parti di dimensione adeguata. E’ sufficiente editare il file “principale” e estrarne alcune sezioni che andranno incollate in nuovi file, sempre con estensione .xml e l’accortezza di estrarre gli item nella loro interezza. Quindi i file “figli” dovranno iniziare con <item> e terminare con </item>; il file da importare per primo sarà comunque quello di partenza, che adesso avrà dimensioni inferiori. Procedete con gli altri file, meglio se in ordine di estrazione.

Al termine delle operazioni di spostamento file e ripristino database, dovreste avere trasferito il vostro blog sul nuovo hosting. Attivate i plugin e ripristinate il vostro template per completare il lavoro.

Nel mondo reale, purtroppo, non sempre le cose vanno lisce: è consigliabile fare una prova su una installazione in locale sul vostro computer, prima di fidarvi del tutto della procedura. Io ho avuto problemi con i tag che non vengono importati, ad esempio. Se l’esportazione/importazione tramite XML fallisce, non resta che affidarsi al metodo tradizionale di backup e restore del database tramite PHPMyAdmin. E’ probabile che anche in questo caso ci siano problemi dovuti alle dimensioni del file, quindi l’operazione di “split” del file dovrà comunque essere fatta. Non è difficile, ma richiede un po’ di pazienza e di occhio per capire in quali punti il file potrà essere spezzato. Se non vi sentite sicuri, magari chiedete aiuto a qualcuno. Vi ricordo che in questo caso è necessario modificare a mano i campi siteurl e home della tabella wp-options, in cui andrà specificato l’url del blog di destinazione. Questo campo non dovrebbe cambiare in caso di spostamento di hosting, mentre va sicuramente modificato per una installazione locale, a meno di non fare qualche giochino con il proprio file hosts.

In definitiva, i consiglio che vi posso dare e volete essere assolutamente sicuri è di usare il “metodo XML”, ma di fare comunque un backup tramite PHPMyAdmin, che non si sa mai.

[Autore: Andrea Beggi]