Come attivare Google Friend Connect

Rispetto ai primi tempi in cui il servizio era attivo, ora non è più necessario scaricare e inserire nella root del proprio sito web i file rpc_relay.html e canvas.html e l’attivazione è molto semplice. Infatti, dopo essersi loggati con il proprio account Google (che equivale al proprio account Gmail), sarà sufficiente accettare i “Termini di servizio per gli sviluppatori di Friend Connect”

e verrete subito mandati ad una pagina in cui potrete inserire il nome e la url del vostro sito

per poter attivare la vostra nuova community!

Bene, ora non resta altro che creare un gadget che permetta agli utenti del proprio sito di unirsi alla vostra nuova community.

La procedura è molto semplice e guidata

e vi permetterà di creare del codice HTML del tipo:

da inserire nella vostra sidebar (di solito corrisponde al file sidebar.php del vostro tema Wordpress). Se volete evitare di mettere mano al codice html, potete installare il seguente widget per Wordpress: Google Friends Connect Widget. Dopo averlo attivato dalla pagina dei plugin, nella pagina della Gestione Temi di Wordpress trovate la sezione Widget. Qui basterà spostare, con un semplice drag e drop, il widget interessato nella posizione desiderata

e configurare correttamente il proprio “site id“ (quello che nel codice html compare in fondo dopo “site:“)

Problema di visualizzazione del gadget di Google Friend Connect

In realtà tutto questo è in linea teorica, perché sia usando il widget per Wordpress, sia inserendo il codice html fornito dalla pagina di Google Friend Connect, questo è stato il risultato visualizzabile sui browser che uso solitamente sul mio Macbook Pro: Safari 4.0.4 e Firefox 3.5.6.

Sembra, infatti che su alcuni browser il gadget di Google non venga visualizzato correttamente (da quanto leggo sembra che Firefox avrebbe dovuto visualizzare correttamente il gadget ma probabilmente il browser testato era per Windows).
Per rendere visibile il gadget su qualsiasi browser di qualsiasi sistema operativo è sufficiente inserire il seguente codice html subito prima del tag di chiusura </body> (e quindi, nel caso di un tema standard per Wordpress, troverete il tag richiesto nel file footer.php della cartella del vostro template) in moda da istruire il browser ad usare il parser Prototype JSON invece che quello Native JSON.

e questo sarà il risultato!

Ora che finalmente è attiva la funzione di Friend Connect, cosa aspettate: cliccate sul pulsante “Login” che trovate nella colonna qui a lato ed entrerete anche a voi far parte della community di Levysoft!

Condividi

Infine, cosa molto utile, è stata aggiunta la funzione di inclusione automatica dei video, semplicemente incollando la URL del video su una sola riga e magicamente questa verrà trasformata nel corretto codice di embed. I siti supportati sono: YouTube, Daily Motion, Blip.tv, Flickr, Hulu, Viddler, Qik, Revision3, Scribd, Google Video, Photobucket, PollDaddy e WordPress.tv.
Per chi non lo sapesse, questa funzionalità è nota col nome di oEmbed, il formato aperto di incorporamento automatico dei video. Infatti, in genere è necessario copiare il codice per l’incorporamento di un video di YouTube dal video stesso e incollarlo nel proprio sito web/blog. Se il sito web supporta oEmbed, però, è possibile incollare l’URL del video anziché l’intero codice per l’incorporamento. Il video verrà comunque visualizzato come incorporato nella pagina.
Quindi, se prima occorreva scrivere il seguente codice per visualizzare un video sul proprio sito:

<object width="425" height="350"><param name="movie" value="http://www.youtube.com/v/HEheh1BH34Q"></param><embed src="http://www.youtube.com/watch?v=HEheh1BH34Q" type="application/x-shockwave-flash" width="425" height="350"></embed></object>

ora, con oEmbed è possibile semplicemente incollare l’URL del video nel proprio blog:

http://www.youtube.com/watch?v=HEheh1BH34Q

Come vedete, oltre a risparmiare codice html, ne risente positivamente la pulizia del codice.

Per testare questa nuova funzionalità offerta da Wordpress 2.9, eccovi un video affascinante che ci fa capire quanto siamo piccoli nell’universo (da mettere i brividi):

Condividi

Warning: require_once(Text/Diff/Renderer.php) [function.require-once]: failed to open stream: No such file or directory in /home/public_html/wp-includes/Text/Diff/Renderer/inline.php on line 17

Fatal error: require_once() [function.require]: Failed opening required ‘Text/Diff/Renderer.php’ (include_path=’.:/usr/lib/php:/usr/local/lib/php’) in /home/public_html/wp-includes/Text/Diff/Renderer/inline.php on line 17

Descrizione del problema

Come già scritto in precedenza, con il rilascio della release 2.6 di Wordpress, è stata introdotta la gestione delle revisioni dei post (Post Revisions Tracking) per tenere traccia delle modifiche di ogni articolo e pagina (mostrando le differenze in maniera visuale), con la possibilità di ripristinare la versione precedentemente salvata. Ovviamente, essendo il mio sito un blog esclusivamente monoautore, questa funzionalità è stata subito disattivata, risparmiando, così, spazio sul database e risorse per gestirla.

Da quando, però, ieri ho installato l’ultima release stabile 2.6.5, mi si è presentato un problema che non mi era mai accaduto, ma che, leggendo su internet, era presente sin dal primo rilascio della 2.6: il famoso Fatal error in Text/Diff.php, un fastidioso “bug” che impediva la modifica degli articoli pubblicati. Infatti, cercando di editare un articolo pubblicato si incappava in un messaggio di errore relativo alla directory Text contenuta in /wp_includes (che gestisce la funzione di revisione dei post), tanto da rendere impossibile qualsiasi modifica all’articolo a meno che non si provvedeva alla cancellazione e riscrittura dell’articolo stesso.

Il motivo che genera questo misterioso errore è, però, da ricercarsi nel fatto che molti server provider non permettono l’uso della funzione ini_set(). Probabilmente, quindi, la causa del presentarsi improvviso di questo errore sulle revisioni (nonostante siano state disattivate da tempo), non dovrebbe imputarsi alla release Wordpress 2.6.5, bensì, forse, solo ad un cambio di policy del mio server provider (devo comunque ancora chiedere delucidazione a blooweb).

La soluzione del problema

Per risolvere questo problema, senza dover ricorrere alle modifiche manuali sui file php di Wordpress (come suggerito qui, anche se l’autore sembra prevedere solo delle modifiche a due soli file, mentre in realtà dovrebbero essere fatte a 4 file: pluggable.php, wp-diff.php, Diff.php, inline.php), potete scaricare questo pacchetto zip che contiene direttamente i 4 files patchati: wp-includes-WP-2.6.0.zip

Il problema, però, è che questo pacchetto è stato realizzato il 23 Luglio 2008, quando ancora vi era la release 2.6, mentre da Luglio a Novembre 2008 sono intercorse 3 minor release (4 con la 2.6.1) che hanno interessato le modifiche ai seguenti file:

[source language=":php"]
[http://codex.wordpress.org/Version_2.6.5]
wp-admin/users.php
wp-content/plugins/akismet/akismet.php
wp-includes/feed.php
wp-includes/post.php
wp-includes/version.php
xmlrpc.php

[http://codex.wordpress.org/Version_2.6.3]
wp-admin/includes/media.php
wp-content/plugins/akismet/akismet.php
wp-includes/class-snoopy.php
wp-includes/version.php

[http://codex.wordpress.org/Version_2.6.2]
wp-admin/includes/template.php
wp-admin/includes/image.php
wp-admin/import/textpattern.php
wp-admin/css/press-this-ie.css
wp-includes/post.php
wp-includes/version.php
wp-includes/query.php
wp-includes/formatting.php
wp-includes/pluggable.php
wp-includes/widgets.php
wp-login.php
wp-settings.php
[/source]

Siccome i file modificati dal pacchetto sono:

[source language=":php"]
wp-includes/wp-diff.php
wp-includes/pluggable.php
wp-includes/Text/Diff/Diff.php
wp-includes/Text/Diff/Renderer/inline.php
[/source]

abbiamo che nel pacchetto di patch, il file wp-includes/pluggable.php non risulta aggiornato (perché modificato con la release 2.6.2).
A questo punto non resta che realizzare un nuovo pacchetto di file patchati comprensivo del nuovo wp-includes/pluggable.php aggiornato alla release 2.6.5 (che comunque risulta invariato dalla release 2.6.2) per non portarci dietro i vecchi bug risolti da mesi. Fortunatamente, l’autore del BUGFIX ha commentato tutte le righe con la seguente frase:

[source language=":php"]
//BUGFIX: changed for systems doesn’t support ini changes (www.code-styling.de)
[/source]

Per cui è stato facile individuare tutte le modifiche apportate ai file. In particolare, non ha fatto altro che, almeno per questo file, commentare una riga di codice nel seguente modo:

[source language=":php"]
//BUGFIX: changed for systems doesn’t support ini changes (www.code-styling.de)
// ini_set(‘include_path’, ‘.’ . PATH_SEPARATOR . ABSPATH . WPINC );
[/source]

In realtà, ho poi scoperto che, questa riga, nelle ultime release, è stata eliminata; in questo modo, nel pacchetto finale, compatibile con Wordpress 2.6.5, basterà eliminare il file wp-includes/pluggable.php visto che con la release 2.6.2 l’ini_set è stato eliminato.

Ecco quindi, in definitiva, il nuovo pacchetto zip aggiornato alla release 2.6.5 contenente i 3 file php patchati: wp-includes-WP-2.6.5.zip

Il mistero delle revisioni che non si disattivano completamente

Dopo aver copiato i nuovi file nelle specifiche cartelle di Wordpress, se andrete ad editare un post già pubblicato, non avrete più quel messaggio di errore, bensì, almeno inizialmente, come è accaduto a me, un semplice avviso bordato di rosso che dice:

Vi è un salvataggio automatico per questo articolo che è più recente della versione sottostante. Visualizza il salvataggio automatico.

Confrontando l’ultima revisione ho scoperto che, fortunatamente, conteneva le modifiche (salvate con il Salvataggio Automatico) che avevo fatto all’articolo prima che mi desse il messaggio di Fatal error in Text/Diff.php.

Il fatto strano, però, è che in teoria la funzione di revisione doveva essere stata completamente disattivata sul mio blog, perché nel file wp-config.php ho inserito la seguente riga:

[source language=":php"]
define(‘WP_POST_REVISIONS’, false); //Disabilita la revisione dei POST
[/source]

Invece, lanciando la seguente query SQL da PhpMyAdmin:

[source language=":sql"]
SELECT * FROM wp_posts WHERE post_type = ‘revision’
[/source]

scopro che ho ben 19 revisioni che risalgono addirittura dal 28 Luglio 2008, esattamente 7 giorni dopo aver disabilitato le revisioni su Wordpress. Non capisco come possano essere state create le revisioni di alcuni articoli, mentre su tutti gli altri scritti in questo intervallo di tempo no. Presumo che, forse, siano state create solo le revisioni degli articoli pubblicati, e, in seguito, modificati, ma non è ho comunque la certezza. Mi riservo in futuro di effettuare ulteriori analisi, con la speranza che la patch inserita possa aver risolto il problema.
In definitiva, però, è evidente che risulta un funzionamento anomalo delle revisioni di Wordpress che non verrebbero mai definitivamente disattivate. Qualcuno di voi può verificare o ha già riscontrato un simile comportamento?

Ritornando alla mia situazione, una volta constatata la presenza delle revisioni, ho deciso che, per avere un DB pulito, di rimuoverle tutte con il seguente comando MYSQL:

[source language=":sql"]
DELETE FROM wp_posts WHERE post_type = ‘revision’;
[/source]

Download Patch Fatal error in Text/Diff.php aggiornato a WordPress 2.6.5

	Scarica wp-includes-WP-2.6.5.zip
	Dimensione: 13.5 KB

Condividi

Soluzione Manuale

Per risolvere il problema manualmente basta andare nell’area di Amministrazione, selezionare “Impostazione/Opzioni“, e nella sezione “Fuso orario” (in fondo alla pagina), troverete il campo “Orario UTC“. Normalmente, durante l’ora solare, questo campo (per i bloggers italiani) deve essere posto a “UTC + 1″, ovvero rispetto all’ora UTC l’ora di sistema deve differire di un’ora in avanti. Quando si passa all’ora legale questo campo deve invece essere impostato a UTC+2! In questo caso, se ancora non lo avete fatto, da domenica 26 Ottobre 2008, il campo deve essere posto a UTC+1.

Ovviamente, come avete intuito, la scomodità sta appunto nel doversi ricordare, due volte l’anno, di cambiare il fuso orario (qui, per esempio, potete verificare in che giorno avverrà il prossimo cambio dell’ora in Italia).

Soluzione automatica con i plugin per Wordpress

In attesa che il team di Wordpress risolva, al più presto, questo problema (loro stessi, nella pagina di configurazione ci dicono che: “Sfortunatamente, occorre aggiornare manualmente questa voce per l’ora legale. È brutto lo sappiamo, ma verrà corretto in futuro.“), possiamo provare a risolverlo grazie al lavoro indipendente di altri programmatori che hanno sviluppato plugin per Wordpress.

Tra questi ne ho selezionati due: Time Zone 2.3 (già recensito nel lontano 2005) e Automatic Timezone (qui potete scaricare il plugin tradotto in italiano).

Inizialmente usai Time Zone, ma, siccome per molto tempo non è stato compatibile con la release 2.x di Wordpress (ma ora sembra che lo sia), ultimamente ho installato Automatic Timezone, un plugin ancora più intuitivo del precedente, che consente di evitare di inserire manualmente le modifiche durante il passaggio dall’ora solare (UTC + 1 per l’Italia) a quella legale (UTC + 2) e viceversa grazie all’utilizzo dello zoneinfo database (qui è possibile scaricare solo il database). Una volta attivato il plugin, sarà sufficiente impostare il fuso orario locale in corrispondenza con il nome della città più vicina (nel nostro caso Rome) e, quindi, salvare le modifiche apportate cliccando sul tasto “Aggiorna il Fuso Orario>>”.

Ecco un esempio di cosa accade quando, avendo settato su Wordpress UTC+2 (ora legale italiana) si decide di attivare il plugin mentre vige l’ora solare con UTC+1.

Come vedete il plugin capisce il fuso orario in corso (UTC+1) e se al momento è in uso l’ora solare o meno. Quindi indica l’ora corrente in UTC e col proprio fuso orario, e vi avvertirà di quando avverrà il prossimo cambio di ora legale e che fuso orario verrà usato di conseguenza (UTC+2).

Condividi

La versione di WordPress 2.6.1 corregge oltre 60 bachi, ma le migliorie più importanti sono:

• Miglioramento degli stili nel lato amministrativo per i linguaggi scritta da destra a sinistra.
• Correzione di un bug di Gettext causato da certe configurazioni di PHP.
• Per gli utenti IIS, corretti molti problemi sui permalink.
• Correzione del problema di inserimento immagini utilizzando la funzione Pubblicalo! tramite IE.
• Corretto un bug di prestazione nel lato amministrativo per gli utenti con molti plugin che sperimentavano una estrema lentezza nel caricamento di alcune pagine.

Condividi

Quindi, in questo post, vorrei elencare tutte quelle soluzioni che prevedono anche l’uso della rotellina del mouse per scorrere fluidamente le immagini. Starà poi al lettore scegliere la migliore secondo i propri gusti ed esigenze.
In questo elenco troviamo quindi:

• Protoflow, una libreria che utilizza Prototype.js e Script.aculo.us per mostrare cover di immagini con effetto Coverflow e che si avvale anche dello script Reflection.js per creare gli elementi canvas che rappresentano le immagini riflesse.
• ImageFlow (demo), di cui esiste anche u plugin per Wordpress, che si integra con NextGEN Gallery, che risulta molto utile per integrare coverflow nei propri post.
• SlideFlow (demo)

Coverflow nei motori di ricerca

Ma l’effetto CoverFlow è stato anche molto sfruttato nei motori di ricerca. Infatti, con CreativeSpace è possibile navigare, tutto in Ajax, in modalità Coverflow attraverso i risultati restituiti dalle ricerche su Google Images.
Mentre con Searchme è possibile sfogliare, sempre in coverflow, i risultati delle ricerche con l’anteprima delle pagine, rendendo di fatto più semplice la scelta del risultato. Peccato che il database di Searchme non è nulla in confronto allo sterminato db di Google, e, spesso, accade di non riuscire a trovare ciò che si cerca!

Coverflow su Windows Mobile

Per finire, la moda del CoverFlow, oltre al web, attira anche altre piattaforme, come quella mobile che, dopo aver sfornato decine di cloni dell’iPhone, tenta di integrare questo effetto grafico anche sugli smartphone già esistenti con Windows Mobile, grazie al plugin Face Contact.

Condividi

Questo plugin sfrutta il concetto di pageless pagination (letteralmente, paginazione senza pagine), avvistata per la prima volta sul sito di Google Reader e che permetteva di caricare dinamicamente, in presenza di una lunga lista di item non letti, le informazioni mano a mano che si proseguiva nella lettura; da quel momento, poi, questa tecnica ha iniziato ad essere inclusa silenziosamente (come ogni cosa che semplifica le operatività maggiore è suo grado di trasparenza e immediatezza e maggiore è il suo successo) nelle varie applicazioni del web 2.0 fino ad arrivare, finalmente, grazie al contributo di infinite-scroll.com, anche sui nostri blog con piattaforma Wordpress.

Caricamento dinamico degli articoli

Sino ad ora, a sfruttare le caratteristiche ajax, erano solo plugin quei che permettavano di passare da una pagina all’altra di un blog senza ricaricare l’intero sito. Ma ora, finalmente, siamo giunti alla piena usabilità, grazie ad un plugin che richiede pochissime conoscenze per il suo corretto funzionamento.
Il contenuto della propria homepage, infatti, viene normalmente caricato col normale numero di articoli impostabili dal Pannello di Amministrazione di Wordpress (Gestione -> Lettura) ma, quando si arriva in prossimità dell’ultimo post in fondo alla pagina, vengono caricati un altrettanto numero di articoli e così via fino ad arrivare, con un po’ di pazienza, alla fine degli post scritti.

Il sistema è davvero semplice e al contempo geniale perché permette, soprattutto ai nuovi visitatori che vogliono avere una rapida panoramica di quello che viene scritto in un blog, di scorrere rapidamente i vari articoli, che vengono svelati mano a mano che si scorre la pagina verso il fondo, senza dover aspettare che la pagina si ricarichi nuovamente cliccando sul classico link di navigazione “Pagina Successiva”. E’ facile immaginare che questa sorta di scrolling infinito della pagina, permette di far conoscere un maggior numero di articoli ai nuovi visitatori perché, si sa, un po’ come accade nei motori di ricerca, è difficile andare oltre la seconda o terza pagina di navigazione!

Installazione

1. Scaricare il plugin
2. Dopo averlo scompattato il pacchetto zip, installare il contenuto nella directory dei plugin di Wordpress (/wp-content/plugins/)
3. Attivare il plugin
4. Nella pagina Impostazioni/Infinite Scroll occorre settare alcuni selettori css (Content CSS Selector, Post CSS Selector, Navigation links CSS Selector, Previous Posts CSS Selector) che si trovano nel proprio template (nel file index.php del tema installato). L’autore garantisce che, per la maggior parte dei temi, il plugin dovrebbe funzionare senza alcuna modifica e con i selettori di default. Personalmente sul mio sito ho dovuto personalizzare i selettori css relativi alla barra di navigazione (div.navigation_bottom e div.navigation_bottom a:first) dove si installa l’ajax loader che visualizza il caricamento in corso degli articoli (e che sostituisce i link Pagina Successiva e Pagina Precedente)
5. Di default il plugin funziona solo se si è loggati come utente Administrator ed è disabilitato a tutti gli altri utenti o a chi non è loggato. Lo scopo è permettere la corretta messa a punto del plugin senza disservizi. Terminata la fase di configurazione, nella pagina Impostazioni/Infinite Scroll è possibile abilitare a tutti la funzionalità di scrolling dinamico.

Impressioni

Devo dire che rispetto al Live Scrolling di Google Reader, il sistema mi sembra meno reattivo, nel senso che mentre nel primo caso neanche ci si accorge del caricamento dei nuovi item, con questo plugin occorre arrivare all’ultimo post per iniziare il caricamento dei successivi (secondo me dovrebbe iniziare almeno a due o tre articoli dalla fine) e attendere qualche secondo. Credo, però, che ciò in parte sia da imputarsi alla ovvia differenza prestazionale di un server come quello di Google rispetto a quello usato da me; inoltre queste differenze si notano soprattutto perché scorrevo la pagina con la rotellina del mouse senza leggere, ma in condizioni normali, un visitatore darebbe una occhiata agli articoli e quindi, forse, neanche si accorgerebbe del caricamento.
In teoria è possibile anche impostare un basso numero di articoli visualizzabili in homepage (2 o 3 al massimo) perché i successivi verrebbero caricati dinamicamente mentre si scorre la pagina.

Bug

Ho incontrato una non perfetta compatibilità con il plugin SyntaxHighlighter, in quanto non riesco a visualizzare correttamente il codice incluso negli articoli caricati dinamicamente. Ho intenzione di contattare l’autore del plugin per metterlo a conoscenza di questa problematica.

In conclusione

Non so quanto questo plugin possa incidere a livello prestazionale e di banda occupata ma non credo che possa apportare grossi problemi, a tutto vantaggio di una navigazione più veloce e fluida.
Se volete vedere il plugin in azione, andate nella homepage di Levysoft e scorrete la pagina verso il basso.

Condividi

E’ ovvio che questo genere di caratteristica si addice maggiormente ad un blog multiautore, in cui è presente un revisore che ha la responsabilità, prima di pubblicare un articolo, di controllare e correggere un post di un suo collaboratore. Per tutti coloro che, invece, essendo gli unici autori del blog, non necessitano di questa funzionalità, esiste la possibilità di disattivare la gestione delle revisioni, risparmiando, così, spazio sul database (in particolare in ogni riga della tabella wp_post) e risorse per gestirlo.

Considerate, però, che il numero di revisioni salvate corrisponde esclusivamente al numero di salvataggi manuali che effettuerete, mentre quelli automatici non lo influenzerà. Quindi il loro peso sul database, sarà funzione di quante volte siete soliti premete sul pulsante “Salva” mentre state scrivendo un articolo: io, per esempio, con soli due post ho ho accumulato ben 41 revisioni!

Come disattivare la gestione delle revisioni su Wordpress 2.6

Per disattivare la revisione dei post sarà sufficiente aggiungere la seguente riga nel file wp-config.php:

E’ strano, però, che si debba mettere mano direttamente al codice di Wordpress, piuttosto che prevedere una semplice opzione da attivare/disattivare dal Pannello di Amministrazione di Wordpress (magari con un plugin si potrebbe sopperire a questa mancanza). Inoltre, sarebbe stato anche auspicabile che questa opzione fosse stata disattivata di default, visto che la maggior parte dei blog sono monoautore.

Analisi delle modifiche apportate al DB per inserire le revisioni

Quando la funzionalità di Post Revisioning doveva essere sviluppata su Wordpress, i programmatori avevano pensato, inizialmente, di creare una nuova tabella chiamata: wp_post_revisions (che tendeva, per sua stessa natura, a crescere a dismisura).
In realtà, forse a causa della lentezza delle interrogazioni, o per uniformare i dati, le revisioni dei post sono poi stati incluse direttamente nella tabella wp_posts e identificata dai seguenti valori dei campi:

post_type= “revision”
e
post_status = “inherit”

Inoltre sono stati aggiunti e modificate anche alcune funzionalità di altri campi: è stato aggiunto, per esempio, il campo post_parent (che riporta l’ID del post principale), mentre il campo post_name ora contiene, oltre il titolo del post principale, anche il titolo delle revisioni (p.es. 1834-revision, 1834-revision-2, 1834-revision-3, 1834-revision-4, etc…).

In pratica, se prima un nuovo articolo veniva identificato da un inserimento di una singola riga nella tabella wp_posts, ora, con la release 2.6 di Wordpress, ad ogni post corrispondono 5, 10, 15 riga nella tabella, a seconda del numero di revisioni salvate (che corrispondono al numero di salvataggi manuali, e non automatici, effettuati).
Cosa comporta ciò? Che in pratica lo spazio occupato per ogni post viene decuplicato inutilmente. Inoltre, se prima, a meno di cancellazioni, ad ogni ID corrispondeva un post diverso, ora l’identificativo è usato sia per indicare un articolo che per indicare una revisione. Ciò significa che un post con ID=1830 potrebbe essere seguito non più da un post con ID=1831 ma, bensì, come è successo a me, da un ID?1845!

Pulire il database dalle revisioni salvate sino a quel momento

Ecco che, quindi, dopo aver disattivato le revisioni dei post conviene anche eliminare tutte le righe aggiunte per le revisioni scrivendo questa query da PhpMyAdmin (abbiate prima l’accortezza, però di effettuare un preventivo backup dell’intero database o, almeno, della tabella wp_posts):

Se, volete essere sicuri di andare a cancellare solamente le revisioni e non altri post pubblicati, potete fare prima una select con gli stessi parametri:

e quindi cancellare tutte le revisioni con il precedente comando SQL.

Modificare l’intervallo di tempo per i salvataggi automatici dei post

Infine, dato che prima avete messo le mani nel file wp-config, dovete sapere che è possibile anche cambiare l’intervallo temporale con cui Wordpress effettua i salvataggi automatici dei post.
Basterà, infatti, aprire il file wp-config ed inserire la seguente riga:

Dove al posto di 60 (che indica l’intervallo temporale espresso in secondi), potete inserire qualunque valore numerico a vostra scelta.

Condividi

Ecco tutte le novità:

1. Gestione versioni Sistema di gestione delle revisioni di articoli e pagine. Una feature molto utile per blog multiautore. Infatti, è possibile vedere le modifiche che avete apportato e quando, a qualsiasi news postata, il tutto attraverso un interfaccia semplice, con la possibilità di ripristinare la versione precedentemente salvata.
2. Press This! Un bookmarklet per che fornisce un popup intelligente e veloce per pubblicare “al volo” sul proprio blog mentre navighiamo il web.
3. Google Gears Con questa prima implementazione di Google Gears, molti file del lato amministrativo possono essere mantenuti in una copia locale velocizzando enormemente il passaggio da una funzione all’altra. Supportato da IE e FF e a breve anche da Safari e Opera.
4. Anteprima e paginazione dei temi Quando si seleziona un tema questi viene presentato in anteprima, con un effetto simile a lightbox, senza dover effettivamente attivarlo, permettendo di verificarne la correttezza prima di renderlo disponibile al pubblico.
   Inoltre, se avete decine di temi installati, ora è stata attivata la paginazione dei temi, ovvero potete vederli suddivisi per pagine (15 alla volta), in modo da velocizzare il caricamento.
5. Conteggio parole Non si dovrà più tirare ad indovinare di quante parole è composto il nostro articolo..
6. Didascalia immagine, per poter aggiungere una didascalia alle proprie immagini sullo stile di Political Ticker does.
7. Gestione di massa dei plugin: ora sono divisi i plugin da attivare da quelli già attivati.
8. Una completa revisione del controllo immagine per permettere inserimenti, fluttuazioni e ridimensionamenti facili alle proprie immagini. Ora completamente integrato con l’editor WYSIWYG.
9. Riordinamento delle gallerie tramite Drag-and-drop.
10. Avviso di aggiornamento plugin tramite bubble in modo da non essere più necessario visualizzare la pagina dei plugin per vedere se sono presenti aggiornamenti.
11. Avatar standard personalizzabile.
12. Caricamento di media anche con l’editor in modalità a schermo pieno.
13. Pubblicazione remota tramite XML-RPC e APP disabilitata di base,ma è possibile riattivarli facilmente tramite la finestra delle impostazioni.
14. Supporto SSL completo nel codice di WP e possibilità di forzare l’SSL per migliorare la sicurezza.
15. Possibilità di avere diverse migliaia di pagine o categorie senza problemi di interfaccia.
16. Possibilità di spostare il file wp-config e la directory wp-content in un posizione personalizzata.
17. Selezione di un insieme di caselle di spunta tramite l’uso di “shift-clic.”
18. Possibilità di passare dall’uploader Flash a quello classico.
19. Una serie di miglioramenti alla sicurezza proattiva, che comprendono i cookie e le interazioni col database.
20. Versioni migliori e più veloci di TinyMCE, jQuery, e jQuery UI.
21. La versione 2.6 corregge circa 194 bachi.

Video presentazione di Wordpress 2.6

Il team inglese ha anche realizzato un breve filmato di 3 minuti e mezzo di presentazione delle novità di WordPress 2.6:

Note sulla installazione

Due note sulla installazione e configurazione di questa nuova release. A differenza della precedente release i file di localizzazione sono posti dentro la directory wp-content/languages e non più in wp-includes/languages; quindi, se volete, potete anche rimuovere quest’ultima directory.

Inoltre, con questa versione sono state introdotti 3 nuovi parametri per il file wp-config.php che ora definisce una serie di 3 SECRET KEY (prima ne era presente solo una): AUTH_KEY, SECURE_AUTH_KEY e LOGGED_IN_KEY. Per generarle in maniera automatica potete, in generale, fare riferimento a GRC’s Ultra High Security Password Generator oppure, più specificatamente per Wordpress, fare riferimento a Secret Key, un tool online messo a disposizione dal team di Wordpress.org che genererà un codice analogo a questo:

Download

Per scaricare la nuova versione potete andare nella sezione download del sito ufficiale di Wordpress.org (per il futuro, esiste anche un link universale che permette di scaricare l’ultima release disponibile: http://wordpress.org/latest.zip) oppure scaricare la versione localizzata dl team di Wordpress-it.it.

Alcuni suggerimenti: le origini di Wordpress e la Reference Template Tag

Per i più affezionati a questo strumento per il blogging, consiglio allora la lettura di Evolution of WordPress: B2/Cafelog to WordPress 1.0, che spiega tutti i passi che sono stati necessari per passare dal padre putativo B2/Cafelog alla prima versione stabile di Wordpress.

Infine, se volete personalizzare il vostro tema e non volete impazzire nella sezione Template Tag del WordPress.org Codex, allora vi consiglio di leggere Wordpress Template Tags Reference Guide, una intuitiva guida realizzata dal team di DBS Interactive che raccoglie in una unica pagina e in macro categorie (come Author, Comments o Permalinks) tutti i tag usati per lo sviluppo dei temi per Wordpress, con tanto di esempi.

Condividi

“si vede che gli interessi si sono spostati altrove: se le persone sono disposte a fare la file per spendere 600 euro per un cellulare, è chiaro che i soldi ci sono e non viviamo un momento di recessione economica, ma semplicemente si è spostato l’interesse della gente verso altri prodotti”.

Battezzato addirittura “the God machine”, la macchina di Dio, quando fu presentato dalla Apple un anno fa perché sembrava avesse attinto la sua tecnologia direttamente dal futuro, la nuova reincarnazione dell’iPhone ha reso tutti folli.

Infatti, in tutto il week end, non ho fatto altro che sentire ovunque, in maniera diretta o indiretta, del iPhone 3G.

Le mie testimonianze

Ma quello che era ancora più strano era sentire la gente parlare dell’iPhone come oggetto del desiderio, per poi capire che non sapevano quasi nulla delle sue caratteristiche. Quando un mio collega mi ha detto che era intenzionato a comprarsi l’ultimo gioiellino di casa Apple, gli ho suggerito di guardare il video tutorial che spiegava cosa facesse l’iPhone: ebbene, dai suoi sguardi ho capito che non sapeva quasi nulla dell’iPhone e ha fine presentazione era ancora più convinto del suo futuro acquisto!

Sempre lo stesso giorno, una mia amica mi ha raccontato che nel ufficio era passato un cliente con in mano l’iPhone e tutti ne parlavano: ma lei non aveva avuto modo di vedere come fosse fatto e cosa facesse. Al che gli ho detto che potevo fargli vedere il mio iPod Touch, che nulla aveva che spartire con il nuovissimo iPhone 3G, ma almeno poteva avare un assaggio delle potenzialità della nuova e intuitiva interfaccia del cellulare di casa Apple. A fine demo era estasiata di cosa potesse fare quel prodotto e mi disse che aveva finalmente capito perché tutti ne parlavano!

Reality Distortion Field dell’iPhone

Insomma, come vedere sembra che anche l’iPhone riesca a generare intorno a sè il famoso “Reality Distortion Field” (RDF) che contraddistingue i Keynote di Steve Jobs. Come la distorsione spazio temporale di un singolarità cosmica, anche l’iPhone sembrava riuscire, durante tutto lo scorso weekend, a creare intorno a sè un campo di attrazione gravitazionale tale da attirare sia l’early-adopter e gli Apple Addicted, che l’uomo di strada completamente digiuno di tecnologia.

Gli eventi della follia iPhone

Così, forse per sfruttare questo hype, venerdi 11 Luglio 2008 è accaduto davvero di tutto. TIM ha lanciato l’iniziativa “La Notte Bianca di Tim” (alcuni punti vendita TIM hanno effettuato una apertura speciale per presentare iPhone 3G dalle 00:00 di venerdi 11 luglio), mentre Vodafone apriva myLive, ovvero un portale totalmente dedicato ad iPhone 3G, accessibile tanto da browser (anche su computer fisso) che da una applicazione specifica che si scaricherà dall’App Store.

Dalla mezzanotte di venerdi, si sono susseguiti decine di reportage con foto, filmati e cronache di tanti utenti entusiasti e pazienti in fila per il lancio di iPhone 3G dai vari centri TIM sparsi per la penisola. Ovviamente foto d’onore e interviste ai primi cittadini ad accaparrarsi il prezioso oggetto, ma anche a chi manifestava contro le tariffe vergognose di Tim e Vodafone.

A fare un reportage in grande ci ha pensato Engadget che ha raccolto una serie di immagini e video che testimoniavano le file che si accalcavano in tutto il mondo, dallo Store della Fifth Avenue a Manhattan al Giappone, dalla Danimarca alla Nuova Zelanda (che tra l’altro, per via dei fusi orari, era stato il primo paese in cui è cominciata la vendita di iPhone 3G).

Intanto, come era logico supporre, migliaia di aggiornamenti del firmware dell’iPod touch, attivazione di centinaia di migliaia di iPhone, download di milioni di applicazioni free, passaggio da .mac a mobile me, tutto in un solo giorno, era davvero troppo per i server Apple, tanto che negli Usa e in molti altri paesi, come in Italia, si segnalavano gravi problemi per l’attivazione dell’iPhone 3G, con server sovraccarichi dalle troppe richieste. Analoghi problemi di gioventù si incontravano anche con il neonato MobileMe e con l’App Store, in cui 135 applicazioni delle 552 presenti per iPhone/iPod Touch erano gratis (anche se devo dire pochissimi erano di buona qualità, tra queste non posso non citare Remote, sviluppata da Cupertino stessa, che trasforma l’iPhone e l’iPod touch in telecomandi via Wi-Fi definitivi per pilotare iTunes su Mac e Apple TV) e la gran parte di quelli a pagamento non superavano i cinque dollari.

E mentre qualcuno lo aveva già smontato pezzo per pezzo, l’iPhone Dev Team dichiarava che era già molto vicino a craccare la versione due del firmware degli iPhone.

Ma la follia dell’iPhone ha colpito anche i giornali che hanno subito affiancato i loro siti classici con le rispettive versioni ottimizzate per iPhone: dal Corriere, che proponeva le notizie in una veste grafica che si adatta perfettamente allo schermo del telefonino, a Repubblica, da Radio Deejay alla RAI che inaugurava un portale compatibile con l’interfaccia di iPhone e iPod touch, per essere sempre aggiornati on-the-go sugli ultimi avvenimenti.

Ovviamente non potevano mancare il giro di illustre recensioni: Dopo le recensioni delle 3 grandi “voci” americane, sono arrivate anche quelle di importanti giornalisti italiani, come quelle di Marco Pratellesi (Corriere), Ernesto Assante (Repubblica), Nicola Porro (Il Giornale), Antonio Dini (Sole24Ore) e Luca Sofri (Gazzetta).

Intanto, tutti i blogger, restano in trepidante attesa, dell’applicazione, creata direttamente dal team di Wordpress, che consentirà il blogging mobile, per poter aggiornare il proprio blog basato su Wordpress direttamente da iPhone o da iPod touch.

Condividi

Caratteristiche del plugin

Filter Badwords Comment, è stato strutturato in modo da essere altamente personalizzabile anche dal Pannello di Amministrazione di Wordpress. Infatti presenta, sotto il menu Impostazioni, una sezione “Filter Badwords Comment” in cui, è presente una textarea con elencate tutte le parole da filtrare. Inizialmente questa area è nascosta, per evitare di offendere la sensibilità delle persone.

Solo dopo aver visualizzato sul tasto Show (Visualizza nel caso abbiate la versione di Wordpress localizzata in italiano) verrà visualizzata una area di modifica del dizionario delle parole, una per riga, da censurare.

Qui sono presenti sia singole parole (per quanto possibile nella loro versione al plurale e al singolare e in quelle artefatte) e sia da parole composte (le classiche frasi fatte offensive).
Per il plugin ho realizzato 2 vocabolari: badwords_IT.txt e badwords_EN.txt. Entrambi contengono parole offensive nelle rispettive lingue ITALIANO e INGLESE. A seconda di quale database di base scegliete dovete rinominarlo nell’unico file che il plugin legge: badwords.txt (che di default ho comunque incluso e contiene solo le parole italiane). Ovviamente nulla esclude che potete creare un vostro nuovo file con le parole da censurare: quello che ho fatto io è solamente di fornirvi tutti gli strumenti in modo da avere una base di partenza su cui far funzionare il plugin per wordpress.

Per i blog multilingua, potete benissimo realizzare un file unico che racchiuda entrambe le lingue anche se lo sconsiglio perché le parole inglesi potrebbero essere facilmente trovate in parte di quelle italiane (un esempio è: “mettere in ballo” in cui la parola “ball” verrebbe censurata).
Anche nel caso di parole italiane vi potrebbero essere problemi di censure parziali delle parole perché, magari, in mezzo è stata trovata una parola da censurare (è il caso, per esempio, di grafica“).
Per come ho sviluppato il plugin, che usa la funzione php di str_replace() su tutto il testo del commento e non tiene in considerazioni le sentence, il problema non è facilmente risolvibile. Per cui ho risolto eliminando quelle parole da censurare che potrebbero essere facilmente confondibili con altre di uso comune.
Se avete qualche suggerimento per migliorare questo plugin siete sempre i benvenuti!

Come funziona

Il plugin Filter Badwords Comment non fa altro che, ogni volta che Wordpress deve visualizzare un commento, interrogare un file di testo e ricercare le relative corrispondenze. Una volta trovate le parole da censurare, queste vengono nascoste dietro degli asterischi solo in visualizzazione (le parole rimangono comunque inalterate nel database). So che la soluzione del file di testo non è la soluzione più veloce di interrogazione di un elenco di dati, ma sicuramente era quella più veloce e funzionale, perché, a differenza di un array interno al plugin o di un campo in una tabella mysql, è facilmente modificabile ed esportabile in quanto è un semplice file di testo in ASCII. Per semplificare la modifica online del parole da censurare ho, comunque, previsto la possibilità di poter modificare il file dal Pannello di Amministrazione di Wordpress.

Da qui, inoltre, è possibile anche scegliere se censurare l’intera parola da fltrare con tutta una serie di asterischi pari al numero di lettere di cui è composta, oppure, per lasciare intendere il senso della frase, di lasciare visibile solo la prima e l’ultima lettera.

Compatibilità

Il plugin Filter Badwords Comment è stato testato sul mio blog per diversi giorni ed è compatibile con tutte le versioni di Wordpress, quindi anche con la release 2.5.1. In ogni caso, il plugin agisce solo nell’area commenti e non fa altro che lavorare sulla sola visualizzazione senza alterare alcun dato. Il plugin è stato rilasciato esclusivamente in lingua inglese ma presumo che le sue funzionalità e caratteristiche siano abbastanza chiare.

Possibili evoluzioni

Una possibile evoluzione del plugin potrebbe essere quello di non permettere l’inserimento dei commenti se sono presenti parole da censurare. In questo modo si risolverebbe il problema a monte e si educherebbero i commentatori a non scrivere parole offensive! Il problema è che questo non può essere l’unica soluzione ma solo una caratteristica in più, da abbinare alla censura in visualizzazione delle parole, poiché, specie nei siti attivi da più anni e con diversi migliaia di commenti, bisogna comunque filtrare le parole offensive.

L’origine della badlist

Ci tengo a precisare che la lista italiana delle parole da censurare è stata tratta quasi integralmente, ad eccetto di alcune aggiunte da me, dal sito di Clarence che riportava una gaffe notata su un CD di Infinito che aveva lasciato visibile un file badlist.txt con tutte le parole da censurare durante la registrazione, compresi alcuni nomi di partiti italiani.

Supporto

Il plugin può essere testato nella sezione dei commenti di questa pagina. Se avete suggerimenti, domande o segnalazioni di anomalie, potete commentare qui sotto, oppure, contattarmi direttamente per mail dalla sezione Contattami.

Download

[ITALIANO]

Nome Plugin: Filter Badwords Comment
Autore: Antonio Troise
Descrizione: Questo plugin permette di censurare dai commenti le parole che risultano essere offensive prelevandole da un database italiano o inglese. Il plugin agisce solo sulla visualizzazione dei commenti dove è possibile nasconderle completamente dietro una serie di asterischi pari al numero di lettere di cui sono composte, oppure, per lasciare intendere il senso della frase, è possibile lasciare visibile solo la prima e l’ultima lettera.
Versione: 1.0.2
Installazione:

1. Scaricate il plugin, decomprimetelo e fate l’upload della dictory badwords nella directory dei plugin di WordPress (wp-content/plugins/).
2. Rinominate badwords_IT.txt o badwords_EN.txt nel DB file di default: badwords.txt
3. Attivate il plugin “Filter Badwords Comment” plugin da “Gestione plugin” nell’Area di Amministrazione di Wordpress.
4. Configurate la lista delle parole da censurare e la modalità di mascheramento degli asterischi da Impostazioni » Filter Badwords Comment

	Scarica filter_badwords_comment.zip 1.0.2
	Dimensione: 6.6 KB

[ENGLISH]

Plugin Name: Filter Badwords Comment
Author: Antonio Troise
Description: This plugin allows to filter the bad words present in the comments with asterisk from italian/english dictionary. When the comments get displayed, WordPress gives the comment content to the comment filter plugin and returns the modified content that replace the bad word with asterisk.
Release: 1.0.2
Usage:

1. Download the plugin, unzip and upload in the directory of plugin of WordPress (wp-content/plugins/).
2. Rename badwords_IT.txt or badwords_EN.txt in default DB file: badwords.txt
3. Activate “Filter Badwords Comment” plugin from Manage Plugin in the Administration Area of Wordpress
4. Configuration: Options » Filter Bad Words Comment.

	Download filter_badwords_comment.zip 1.0.2
	Size: 6.6 KB

Condividi

Sicuramente nell’ultimo mese avevo ricevuto un incredibile aumento di visitatori e questo aveva sicuramente influenzato le statistiche: oltre 30.000 visitatori unici in più (103.000 solo a Giugno) rispetto alla media dei mesi scorsi con un incremento di banda sproporzionato di oltre 16 GB in più (giungendo a 39.52 GB a fine mese di solo traffico HTTP).

La banda è la somma del traffico HTTP, FTP, SMTP e POP

Quello che mi aveva colto impreparato, però, era che il traffico HTTP (evidenziato da tool statistici com Awstats) non era l’unico elemento che veniva conteggiato nella soglia di banda messa a disposizione da un hosting (ed evidenziato nella homepage del mio cPanel): infatti, oltre al traffico HTTP, veniva conteggiato anche quello FTP, SMTP e POP. Normalmente, però, questi valori sono sempre trascurabili rispetto alla banda generata dal traffico delle pagine web. Questo, però, fino a questo mese, visto che il 20 Giugno, a fronte di un traffico HTTP di soli 28.76 GB, il sistema misurava una banda totale che superava i 40 GB! Ovvero, stavo consumando oltre 10 GB tra traffico FTP, SMTP e POP! Una cosa davvero incredibile rispetto alla media dei mesi precedenti.

Troppi commenti con false email generano traffico SMTP

Analizzando con calma la situazione ho scoperto che la funzione di segnalazione dei commenti (del plugin per Wordpress Subscribe To Comments) inviava quotidianamente molti messaggi che non venivano mai recapitati correttamente (nell’ordine di alcune centinaia al giorno), probabilmente perché molti utenti che lasciavano commenti sul mio blog non inserivano email reali. Ciò creava un indubbio traffico SMTP anche se credo non della portata di 10 GB mensili, visto che i messaggi recapitati erano solo ASCII.
Comunque, onde evitare problemi, ho provveduto ad eliminare tutte le email che si erano registrati su un solo articolo del mio sito (oltre il 95% delle mail memorizzate), supponendo che chi scrive un commento con una email fittizia sia un visitatore di passaggio e quindi non un commentatore abituale. In tal modo non ho dovuto disattivare completamente questa funzione.

Fare spesso via FTP i backup di siti molto grandi riduce la banda mensile

Un altro problema che ho messo in luce è che, se è vero che nel conteggio del traffico totale mensile, era prevista anche la banda FTP usata, allora ogniqualvolta eseguivo un backup del mio sito, questo erodeva la quota mensile. Ora siccome dal cPanel è possibile eseguire un backup di tutta la mia home directory e non solo della directory in cui risiedono le mie pagine web, ogni volta che faccio il backup del sito, scarico ben 639 MB (a fronte di un peso effettivo del mio blog di poco più di 200 MB). Se in un mese, come è accaduto a Giugno, eseguo 4-5 backup, consumo oltre 3 GB di banda mensile.
Per risolvere questo problema ho deciso di scaricare solo il contenuto effettivo del mio sito e, laddove possibile, sempre verso fine mese, in modo da tenere sotto controllo il consumo di banda.

Il problema ricorrente delle dimensioni dei file Javascript e le AJAX Library API di Google

Se questi ultimi 2 punti sono stati volti a risparmiare quel fattore di banda invisibile e difficilmente monitorabile, ho deciso anche di intervenire, ancora una volta, su quella HTTP. Devo dire che, mano a mano che avanza lo stato di ottimizzazione del sito, affrontare il problema della banda, è un lavoro davvero certosino e occorre considerare diverse variabili prima trascurate e, non da ultimo, alcuni elementi nuovi (come l’installazione di nuovi plugin) che sono intercorsi dall’ultima analisi.

Tra questi troviamo anche un vecchio problema: i file javascript. Infatti, nonostante la precedente volta li abbia compressi più che mai, nel solo mese di Giugno, i soli file JS occupavano ben 8.96 GB di banda mensile!

Per risolvere parzialmente questo problema, ho pensato, quindi, di poter sfruttare le AJAX Library API di Google. In pratica, Google, recentemente ha messo a disposizione di tutti le maggiori librerie javascript e ajax compresse, linkabili direttamente dai loro server: jQuery, Prototype, script.aculo.us, Mootools e Dojo!

Centralizzando la distribuzione dei framework javascript e sfruttando le infrastrutture della rete di Google è possibile ottenere innumerevoli vantaggi: caching (utilizzando il medesimo URL per i file, c’è la probabilità che il browser dell’utente abbia già scaricato la libreria precedentemente), compressione Gzip/Minify, e file ospitati sui server veloci di Google e quindi riduzione del traffico generato dal proprio sito.

E’ possibile richiamare gli script all’interno delle proprie pagine utilizzando la classica sintassi:

oppure con il metodo google.load(), che di fatto è molto più potente e performante, perché permette di indicare anche la versione desiderata della libreria:

Nel caso di script.aculo.us dovremo caricare anche prototype:

Infatti, per garantire la compatibilità delle applicazioni, Google offre anche una serie di versioni diverse per ogni libreria Javascript e permette di specificare quella desiderata. Il versioning è, però, anche intelligente. Infatti, se si specifica una versione parziale della libreria (p.es 1.8), Google ci farà scaricare l’ultima release stabile di quella revision (p.es. 1.8.4), mentre se si specifica solo la versione “1″ allora lui scaricherà l’ultima disponibile, ovvero, la “1.9.1″.

Plugin per Wordpress per le Google AJAX Libraries API

Se non volete mettere mano al codice della funzione wp_head() di Wordpress per eliminare il riferimento al file prototype residente sul server ed inserire il link a quello residente sul server di Google, esiste un comodissimo plugin: Google AJAX Libraries API Plugin. Una volta attivato non farà altro che sostituire (con un add_filter()) il riferimento a tutti i framework gestiti con la versione ospitata sui server di Google.

L’unico svantaggio è che non usa la versatile funzione google.load() (che permette di puntare dinamicamente alla ultima release stabile) bensì il classico link diretto al file javascript. Ciò vi costringerà a tenere sotto controllo la versione di Prototype usata da Wordpress e aggiornare di conseguenza il plugin (che ancora non è inserito nella Repository Ufficiale dei Plugin per Wordpress) oppure modificarlo a mano.
Inoltre, non punta neanche alla versione compressa del file javascript, il che comunque non rallenta minimamente il caricamento della pagina.

Infatti, come è possibile vedere, eseguendo i test con i Pingdom Tools, usando la versione non compressa di Google abbiamo un peso di 123,2 KB (che comunque non influenza la banda del proprio sito) e un tempo di caricamento di 0.5 secondi

mentre usando la versione ospitata sul mio server, a fronte di un peso complessivo di 46,6 KB abbiamo un tempo di caricamento di oltre 1,2 secondi!

Disabilitazione di alcuni plugin

Inoltre, tra i file più letti ho trovato tutta una serie di plugin per i commenti:

• quoter.php (plugin: Quoter)
• ajax-comment-preview-js.php (plugin: AJAX Comment Preview)
• lmbbox-comment-quicktags.php (plugin: LMB^Box Comment Quicktags)

Ho deciso, quindi, in via del tutto sperimentale, di disattivarli (visto che comunque non sono essenziali per l’inserimento di un commento), per capire che influenza avevano sulla banda totale e sulla velocità del sito (monitorabile facilmente con i Pingdom Tools).

Disattivare Google Translator che non porta traffico utile ad Adsense

Al termine di queste mie analisi ho scoperto che un plugin che avevo installato stava producendo un aumento di banda non indifferente in maniera totalmente indiretta e difficilmente monitorabile: sto parlando del plugin per Wordpress Global Translator, un tool per la traduzione automatica delle pagine nelle principali lingue sfruttando le API di Google Translator.

Infatti, da quando a fine Maggio lo avevo installato, il traffico proveniente dagli Stati Uniti è quasi raddoppiato, passando da 15.08 GB a ben 28.06 GB! Considerando che il mio sito è scritto in italiano, è facilmente intuibile che quel plugin aveva avuto il pregio di allargare la mia fetta di visitatori ad un pubblico che solitamente non mi leggeva.

Ma allora mi sono chiesto: il traffico in più proveniente dagli Stati Uniti era traffico utile e valido e poteva essere vantaggioso per il mio sito oppure era solo uno spreco inutile di banda? Il fatto che la traduzione automatica di Google non potrà mai rispecchiare fedelmente il testo scritto nella propria madre lingua, può portare gente realmente interessata a quello che dico o solo a visitatori passivi che incappano per errore nelle mie pagine? Devo dire che, per certe keyword specifiche, il mio sito risultava primo anche in lingua inglese, e ciò conferma il fatto che Google ha svolto un ottimo lavoro di indicizzazione delle mie pagine. Ma la mia esperienza con le pagine tradotte in automatico non è delle migliori, perché spesso non si riesce a cogliere il senso più profondo delle frasi ma solo una descrizione sommaria. E purtroppo non è questo quello che desidero dare ad un lettore!

Inoltre, per i più veniali, un altro indubbio svantaggio è che, a fronte di un raddoppio di banda usata e di pagine viste, ciò non portava ad alcun incremento degli introiti di Google Adsense che si attestavano sempre sugli stessi valori dei mesi precedenti. Questo capita perché, come ho potuto constatare, anche se la pagina risulta tradotta in inglese (o in qualsiasi altra lingua), i banner Adsense risultano sempre visibili in italiano, vanificando quindi il loro scopo perché nessun inglese cliccherà mai su una pubblicità scritta in un’altra lingua.

Quindi, a ragione, ho provvedduto a disabilitare la traduzione automatica del sito, sperando che, quando Google avrà tolto dal suo indice le pagine scritte in un altra lingua al di fuori dell’italiano, la quota mensili di banda consumata si possa attestare su valori ragionevoli.

Il problema della banda dei server italiani

Il problema dei server che risiedono in Italia è che la banda viene ceduta quasi a peso d’oro: un upgrade di soli 5 GB di traffico mensile mi viene a costare bene 42.00 € in più; considerando che, in teoria, avrei bisogno di almeno altri 20 GB di banda, il costo di gestione del mio sito lieviterebbe di oltre 120.00 €!
Capite bene perché, ogni 2-3 mesi, sono costretto ad ottimizzare al massimo le prestazioni del mio sito riducendo inutili sprechi! Spero che questa mia testimonianza possa essere utile a qualcuno che, come me, combatte quotidianamente con il traffico mensile.
Se poi avete qualche altra idea o suggerimento sono sempre disponibile ad ascoltarvi.

Condividi

Pochi pensano alla versione Touch Friendly del proprio sito

Purtroppo, nonostante esistano versioni mobili di molti siti, in pochi hanno realizzato versioni per iPhone, forse perché ancora considerato, ingiustamente, di nicchia. In realtà, visto che oramai è certo che già entro Giugno 2008 anche nel nostro bel paese approderanno ufficialmente gli iPhone, allora è bene familiarizzare con questi neologismi e iniziare a pensare a come realizzare diversamente i propri siti.
Infatti, se si analizza il traffico Web dei dispositivi mobili, si vede che una fetta consistente è costituito, appunto, da iPhone. E la ragione è una sola: navigare con Safari Mobile è una vera delizia poiché non è necessario alcun adattamento ed è possibile visualizzare la pagina perfettamente come la si vedrebbe con un pc (ad eccezione dei file flash che ancora non sono supportati).

Il problema del dito come dispositivo di puntamento

Ma dopo questa affermazione allora ci si potrebbe chiedere perché è necessario creare dei siti touch friendly? La ragione è semplice: è facile navigare su qualsiasi sito con un iPhone ma, spesso, visto che la risoluzione nativa dell’iPhone è di 320 x 480 pixel, per visualizzarne correttamente uno o per cliccare su qualche elemento, è necessario zoomare più volte con le dita. Cosa che di per sè è molto semplice ma, a lungo andare può risultare noiosa. Ecco perché il lavoro del webmaster dovrebbe essere rivolto ad adattare il proprio sito anche a questi evoluti dispositivi che, secondo me, presto invaderanno il mercato del mobile.

Lo screen dell’ iPhone visualizza infatti 160 pixels ogni pollice, e per utilizzarlo si usano le dita. Il problema è che, il dispositivo di puntamento di un iPhone/iPod non è un cursore o la freccetta del mouse, bensì esclusivamente le nostre dita! Se, quindi, si preme in un punto del display, lo spazio premuto sarà compreso tra i 40 e gli 80 pixels. Quindi, la prima regola base nella costruzione di un sito Touch Friendly è quello di distanziare due elementi selezionabili di almeno di 40 pixel, altrimenti l’utente che visiterà il portale tramite iPhone difficilmente riuscirà ad effettuare una selezione senza zoomare più volte. Per questo è sempre bene ingrandire i font e gli elementi della pagina, magari raddoppiandone le dimensioni; ad esempio, se si ha impostata la dimensione di un font a 18px, buona idea sarebbe portarlo a 32px.

Una delle caratteristiche più particolari dell’ iPhone è il supporto nativo alla “viewport“, ovvero quella funzione che permette di visualizzare solo uno spezzone alla volta di sito. Questo perchè le pagine web sono adattate alle dimensioni degli schermi da PC, mentre lo schermo dell’ iPhone è di dimensioni ben minori.
Per evitare, quindi, caratteri microscopici e selezioni impossibili, si è ricorso a questo stratagemma. Di default, aprendo una pagina web, la viewport è impostata per mostrare un riquadro del sito delle dimensioni di 980-pixel.

I kit IUI e WebApp.net per realizzare siti Touch Friendly

Se non volete impazzire col codice, allora vi consiglio di usare alcuni framework javascript per realizzare in pochi minuti un sito iPhone Style. Il primo a nascere fu IUI: User Interface (UI) Library for Safari development on iPhone, un progetto davvero interessante giunto alla release 0.13 ma che, dalle prove che ho fatto, è mancante di molti elementi di una pagina web.
Ho trovato, invece, molto interessante il fork di quest’ultimo progetto: WebApp.net. L’ho trovato molto più completo del primo e ho già realizzato un paio di siti in questo modo e devo dire che, nonostante qualche differenza sintattica rispetto ad IUI, e una volta presa la mano, è davvero semplice realizzare un sito Touch Friendly con WebApp.net, anche grazie al set grafico fornito di serie. Giunto alla versione 0.2.0 qui trovate una demo della sue potenzialità e qua sotto un video che illustra cosa è possibile fare con questo kit:

Qui, invece, trovate tutta la documentazione per iniziare (è ancora in fase di scrittura)

ATTENZIONE: Ovviamente su Explorer non è possibile visualizzare correttamente questo genere di siti, ma potete visualizzarli correttamente con Safari, Firefox e Camino.

I siti Touch Friendly e la mancanza di Wikipedia

Già esistono numerosi plugin per Wordpress allo scopo, Meebo e Mundu, due servizi di messaggistica istantanea via web, hanno già pensato di creare una versione adatta allo scopo, ed è già è stata creato un client web per Twitter, Hahlo, Google Reader, ma Wikipedia, nonostante le dimensioni di questa comunità non ha ancora pensato a sviluppare una versione per iPhone.

Fin’ora si era solo pensato ad installare wikipedia sull’iPhone/iPod Touch per dare la possibilità a tutti di consultare l’opera offline senza necessariamente esser connessi ad internet. Il trucco stava nell’usare il programma Wiki2Touch e Scaricare il database di wikipedia in italiano da questa pagina (il dump è grande circa 2 Gb). Seguendo questa procedura è molto semplice, in pochi minuti, installare l’intera enciclopedia sui nostri dispositivi mobili.

Ma se noi volessimo semplicemente navigare su Wikipedia online con una interfaccia touch friendly? Allora dovremmo rivolgerci ad un prodotto di terze parti: iPodia. iPodia, infatti, grazie alla tecnologia Picklr Engine, rende l’enciclopedia Wikipedia ottimizzata per i dispositivi avanzati della Mela. In pochi tap di dito potrete selezionare la lingua e scrivere la parola da ricercare. Le pagine si adattano perfettamente al formato dello schermo e basta spostare il dito dall’alto verso il basso per leggerne il contenuto.

Condividi

Addio alla compressione Gzip da Wordpress

Su Wordpress 2.3, per attivare la compressione delle pagine web, era sufficiente andare nel Pannello di Controllo di Wordpress e, nella sezione Opzioni/Lettura (Options/Reading per la versione in lingua inglese), spuntare la voce “WordPress deve comprimere gli articoli (gzip) se il browser lo richiede“. Questo permetteva, in tutta semplicità, di comprimere in formato Gzip (attivando la compressione HTTP) prima di inviarlo al browser, in modo da alleggerire la dimensione della pagina (risparmiando quasi il 70% di dimensioni in una pagina di puro testo) e diminuirne il tempo trasferimento facendo lavorare un po’ di più il computer dei vostri lettori.

Ora, con Wordpress 2.5, tutto questo non è più possibile. Sono andato a vedere in tutti i menu e sottomenu dell’Area di Amministrazione di Wordpress, ma della voce per la compressione del contenuto delle pagine web tramite gzip, non ve ne era più traccia. Ho trovato la conferma anche qui: pare che in In WordPress 2.5 questa opzione non sia più presente!

Pare che la spiegazione, data da Ryan Boren, sia quella che era nata nel Team di Sviluppo di Wordpress, l’esigenza di voler spostare la decisione della compressione delle pagine web al server stesso; infatti, oramai, qualsiasi webserver è in grado di gestire la compressione del contenuto, e la maggioranza dei piani di hosting prevede questa funzione, sia abilitata per default, sia opzionale (come nel caso di cPanel). Evidentemente questo dovrebbe avere ovvi vantaggi prestazionali, anche se non ho ben chiaro quanto possa essere.

Riattivare la compressione gzip da php

Se, però, il vostro webserver è tra i pochi che non supporta la compressione gzip (sul mio per esempio no ho trovato la funzione), potete verificare, come suggerisce Elliott C. Back, se almeno il vostro interprete php offre le funzioni di controllo dell’output, e attivarle tramite .htaccess con queste due righe di comando:

Altrimenti, dovrete modificare il vostro file index.php nel seguente modo:

Attenzione, però: se attivate la compressione via php, dovrete modificare il file tiny_mce_config.php (in wp-includes) come suggerito da Andrew Ozz nella lista wp-testers, e disabilitare la compressione in questo file, altrimenti l’editor visuale verrà compresso due volte!

Riattivare la compressione gzip con un plugin per Wordpress

Se, però, come immagino, non volete mettere mano ai file php e non potete comunque attivare la compressione sul vostro webserver, potete allora installare il plugin realizzato da Sergej Müller. Si chiama Compress for WordPress 2.5, ed è un plugin che agisce pressoché allo stesso modo descritto nel capitolo precedente senza, però, richiedere alcuna modifica manuale. Purtroppo è in tedesco ma è abbastanza chiaro quello che fa: è sufficiente attivarlo e lui comprimerà e vostre pagine web da php.

Come verificare che il plugin Compress for WordPress 2.5 svolga il suo lavoro

Di solito mi fido delle descrizioni che gli autori danno dei propri plugin, ma siccome, in questo caso, ci troviamo di fronte ad un plugin che non rilascia alcun feedback su quello che fa e risulta essere del tutto trasparente a tutti tranne che al browser, ho deciso di verificare se Compress for WordPress 2.5 funzionava correttamente, anche perché non volevo segnalare qualcosa di cui non ero neanche io certo sul suo funzionamento!

Per farlo ho installato una comoda estensione per Firefox, Live HTTP Headers 0.13.1, che permette di catturare e analizzare l’headers delle pagine HTTP che il browser visualizza. Infatti, l‘informazione che ci dice se la pagina è stata compressa, è contenuta in una variabile: Content-Encoding.

Se, quindi, attivo il plugin Compress for WordPress 2.5, e ricarico l’homepage del mio sito, vedrò che la maschera di Live HTTP Headers (raggiungibile da Firefox dal menu Strumenti/Live HTTP Headers) mostra il parametro suddetto settato come:

Content-Encoding: gzip

Se, invece, disabilito il plugin, il parametro di Content-Encoding non viene neanche passato e, l’unica cosa che è possibile trovare (e che si trova anche nel caso) precedente, è il parametro “Accept-Encoding: gzip,deflate” che sta ad indicare che il nostro browser è in grado di gestire i contenuti compressi.

Quindi, in soli due minuti, abbiamo verificato che il plugin svolgesse correttamente il suo lavoro!

Compressione del 150% del file prototype.js 1.6.0

Per quanto riguarda, invece, la compressione del voluminoso framework Prototype (un file JavaScript che ha loscopo di facilitare lo sviluppo di applicazioni web dinamiche di tipo Ajax) in uso su Wordpress, non è cambiato molto se non la versione da utilizzare. Infatti, rispetto a Wordpress 2.3, che usava la versione 1.5.1.1, la nuova release di Wordpress 2.5 usa la versione 1.6.0.
Potete controllarlo voi stessi: basterà leggere la prima riga del file wp-includes/js/prototype.js

Quindi, se non volete comprimere voi stessi il file javascript (che di per sé è grande 121 KB), con un dei tanti tool online che ho descritto in precedenza, dovete fare riferimento all’ottimo lavoro svolto da John-David Dalton che ha compresso per noi tutte le versioni di Prototype.

Quello che dovrete fare voi, quindi, è scaricare il file protopack_v2.19b.zip dal sito Prototype: Core (nel vecchio tutorial era il protopacked_v2.17.zip), scompattarlo e vi troverete una ricca collezione di framework Prototype/Scriptaculous.
In particolare questo package contiene le release 1.4, 1.5, 1.5.1.2 e 1.6.0.2 di Prototype e la release 1.7.1_beta3, 1.8.1 di Scriptaculous. Se sul vostro sito usate anche Scriptaculous allora potete far riferimento direttamente al file Protoculous (esistono le versioni 1.5.1.2 + 1.7.1_beta3 e 1.6.0.2 + 1.8.1), che altro non è che la combinazione in un unico file di Prototype and Scriptaculous.

In generale, però, nel nostro caso sarà sufficiente scegliere la versione compressa del file prototype.js. Quindi, una volta scaricato e scompattato il pacchetto zip protopack_v2.19b.zip, aprite la cartella “files” e vi troverete 3 cartelle: qui aprite la cartella “compressed“, quindi la cartella “prototype” e, infine, entrate nella directory “v1.6.0.2“ (non è esattamente la stessa versione rilasciata con Wordpress 2.5, ma i cambiamenti sono davvero minimi e comunque compatibili con una release inferiore).
Qui, vi troverete, dinanzi a due differenti versioni compresse dello stesso file Prototype.js:

prototype-1.6.0.2-packer.js : compresso con Dean Edward’s Packer 3 \w con le opzioni “Base62 encode” e “Shrink variables”
prototype-1.6.0.2-shrinkvars.js : compresso con Dean Edward’s Packer 3 \w con la sola opzione “Shrink variables”.

La differenza, sostanzialmente, sta nelle dimensioni: il prototype-1.6.0.2-packer.js è grande 48 KB (la versione 1.5.1.1 compresso, che si usava con Wordpress 2.3, invece, era grande solo 40 KB) mentre prototype-1.6.0.2-shrinkvars.js arriva fino a 76 KB.
Io, per il mio sito, ho usato prototype-1.6.0.2-packer.js (risparmiando oltre il 60% di spazio) che ho, ovviamente, rinominato in prototype.js e, quindi, salvato nel percorso “wp-includes/js” sostituendo il precedente file (magari fatene un backup per sicurezza).

Condividi

Error estabilishing a database connection

tanto frequentemente che non riuscivo mai a scrivere un post!

Fortuna che, dopo qualche scambio di mail con l’Helpdesk di Blooweb, siamo riusciti a trovare la soluzione: i ragazzi di Blooweb mi sono venuti incontro e, in maniera del tutto professionale e competente, mi hanno spostato su un server più potente. Sono rimasto davvero impressionato dalla loro disponibilità (dimostrata anche in passato quando richiesi l’installazione delle Librerie Curl), fattore non facilmente reperibile tra i web hosting italiani!

Ora risiedo su un server con PHP 5 e sto ritestando un po’ tutti gli script perché, a quanto pare, non tutti sono stati sviluppati per questa versione.

Infine, visto che stavo rimettendo le mani sul server, ho deciso di passare direttamente alla nuova release 2.5 di Wordpress. Le prime impressioni sono state davvero favorevoli: la nuova interfaccia grafica del Pannello di Amministrazione è davvero gradevole mentre si scrive un post anche se devo abituarmi al fatto che la sidebar delle Opzioni Avanzate è ora posta in basso e non più lateralmente.
Inoltre ho ritrovato molte features che mi ero implementato da solo su Wordpress 2.3, segno che lo sviluppo di questa release ha tenuto molto conto delle esigenze degli utenti: insomma le oltre 1.300 modifiche individuali sono servite a qualcosa!

Ora passerà qualche giorno per la fase di testing del nuovo server e della nuova release di Wordpress (per esempio, al momento, sembra che il plugin Addicted To Live Search 1.02 non sia compatibile con WP 2.5), dopodiché riprenderò le pubblicazioni regolarmente.

Mi scuso ancora con coloro che in questi giorni hanno trovato difficoltà a scrivere commenti o a raggiungere il sito, ma credo che ora dovrebbe funzionare tutto bene. Se notate qualcosa che non va, segnalatemelo pure.

Condividi