Css | Rev0lut1on 2.0 of my mind engine

Lug 23 2008

Come abilitare lo scrolling infinito della homepage del proprio blog su WordPress caricando dinamicamente gli articoli

Ecco un nuovo plugin per WordPress che permette di rendere l’homepage del proprio blog virtualmente infinita: Infinite Scroll.

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

Scaricare il plugin
Dopo averlo scompattato il pacchetto zip, installare il contenuto nella directory dei plugin di WordPress (/wp-content/plugins/)
Attivare il plugin
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)
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.

Tag:Ajax, Blog, Css, Javascript, Php, Plugin, template, Web 2.0, Wordpress

14 comments

Giu 3 2008

Come realizzare siti con interfaccia Touch Friendly per iPod Touch e iPhone con i kit IUI e WebApp.net e analisi sulla mancanza di una versione per iPhone di Wikipedia

Posted by Antonio Troise

La rivoluzione della tecnologia touch di un iPhone o un iPod Touch è tale che, per forza di cosa, è stato necessario coniare un nuovo termine per i siti o gli applicativi dedicati a questa serie di dispostivi mobili: touch friendly, ovvero che sia compatibile col tocco delle dita, tipico della navigazione con i nuovi dispositivi di casa Apple.

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

Finger iPhone 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

Webapp.net 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

Touch Friendly Meebo 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.

Tag:Css, firefox, iPhone, iPod, ipod-touch, Javascript, Plugin, safari, touch friendly, Wordpress

1 comment

Gen 29 2008

Perché spesso le guide html non dicono che l’attributo TARGET per aprire nuove finestre non è HTML Strict? Tre soluzioni per avere lo stesso effetto senza invalidare il codice e avere un sito accessibile

Posted by Antonio Troise

Quando ho iniziato a programmare, il tag A (per la definizione di link ipertestuali) supportava pienamente l’attributo TARGET per aprire in una nuova finestra un sito web magari esterno al proprio, con lo scopo (illusorio) di non perdere visitatori. Ricordo ancora, quando farcivo le mie pagine html con formule tipo:

Link esterno

e magicamente, a mo’ di popup, si apriva un’altra finestra del browser (all’epoca ancora non esisteva il concetto navigazione a schede o tab).

Da qualche anno, però, l’attributo TARGET del tag A è stato completamente abolito dalle specifiche Strict dell’HTML per la realizzazione di un sito accessibile. Il motivo è ben chiaro a tutti: solo l’utente dovrebbe decidere se aprire o no un link in una nuova finestra (ad esempio tenendo premuto Shift) e non dovrebbe essere obbligato a subire le scelte del webmaster di turno: il rischio, infatti, è quello di trovarsi lo schermo invaso da finestre flottanti o, se usate Firefox ben configurato, decine di tab aperte! Inoltre aprendo una nuova finestra si pregiudica l’utilizzo del tasto “Indietro” che è il tasto di navigazione più utilizzato.

Una informazione spesso omessa nelle guide html

Purtroppo non tutti lo sanno e in molti corsi html sparsi per la rete, questo fatto viene ancora ignorato o comunque non messo bene in evidenza (provate a cercare su google ‘corso html‘ e vedrete che i primi risultati portano a dei corsi che non accennano a questa nuova regola).

Addirittura, ho trovato un riferimento spensierato all’attributo TARGET sulla pagine delle FAQ del Centro assistenza clienti AdSense, quando spiega come creare un link ipertestuale:

Utilizza target=”_top”: questo codice dice al browser quale finestra utilizzare per il caricamento della pagina di destinazione dell’immagine cliccabile. Se non includi nel codice questo tag (il punto in cui inserirlo è descritto più avanti), il browser tenterà il caricamento della pagina di destinazione all’interno del formato degli annunci.

Non che il concetto di TARGET sia errato ma essendo oramai obsoleto e deprecato, questa omissione può portare molta gente, che decidendo oggi di imparare il linguaggio html, apprende un concetto errato e quando si dovrà a dover validare il codice, si troverà dinanzi ad un attributo target che inspiegabilmente non passa il check. Sarebbe stato auspicabile almeno un cenno a questo fatto, per evitare di commettere errori all’inizio della propria carriera di programmatori web.

Dove trovare informazioni sulle specifiche HTML Strict

Basterà, però andare, per esempio, su w3schools e notare che, nella tabella riepilogativa, l’attributo TARGET (il cui valore può essere _blank, _parent, _self, _top) non è non previsto nelle DTD Strict, ma è previsto solo nella DTD Transitional.

Una ulteriore conferma, basta andare a leggere il regolamento attuativo della L. 4/20041 (“Decreto Ministeriale 8 luglio 2005—Requisiti tecnici e i diversi livelli per l’accessibilità agli strumenti informatici. Allegato A”) e si noterà che nell’elenco dei requisiti di accessibilità per i siti Internet, al primo punto, compare la voce:

per tutti i siti di nuova realizzazione utilizzare almeno la versione 4.01 dell’HTML o preferibilmente la versione 1.0 dell’XHTML, in ogni caso con DTD (Document Type Definition – Definizione del Tipo di Documento) di tipo Strict;

per i siti esistenti, in sede di prima applicazione, nel caso in cui non sia possibile ottemperare al punto a) è consentito utilizzare la versione dei linguaggi sopra indicati con DTD Transitional, ma con le seguenti avvertenze:

evitare di utilizzare, all’interno del linguaggio a marcatori con il quale la pagina è realizzata, elementi ed attributi per definirne le caratteristiche di presentazione della pagina (per esempio, caratteristiche dei caratteri del testo, colori del testo stesso e dello sfondo, ecc.), ricorrendo invece ai Fogli di Stile CSS (Cascading Style Sheets) per ottenere lo stesso effetto grafico;

evitare la generazione di nuove finestre; ove ciò non fosse possibile, avvisare esplicitamente l’utente del cambiamento del focus;

pianificare la transizione dell’intero sito alla versione con DTD Strict del linguaggio utilizzato […]

Come si vede, quindi, in ogni caso, sia che il sito è esistente da anni o di nuova realizzazione, la generazione di nuove finestre andrebbe evitata, a meno che non si avvisi esplicitamente l’utente del cambiamento del focus!
Tra le altre cose da evitare per avere un sito accessibile vi sono: i frame e le scritte lampeggianti. Tutte cose che spopolavano anni fa nei primi siti web che comparivano su internet e che, tutt’oggi, le guide html ancora raccontano omettendo che sono deprecate per avere un sito accessibile.

Prima soluzione

Quindi, se l’apertura incondizionata di nuove finestre o di “popup” è deprecata e da evitare, se proprio non se ne vuole fare a meno, allora è necessario avvisare l’utente che si aprirà una nuova finestra.
Per adottare questa tecnica, bisogna, però, è necessario ricorrere a Javascript, sfruttando comandi come window.open() e all’evento onclick, da associare all’attivazione del link, evitando, comunque, di generare elementi o attributi non consentiti.

Qui ho trovato un semplice esempio di come utilizzare un accorgimento particolare che sfrutta javascript senza però andare ad invalidare il codice e soprattutto avvisando l’utente del cambiamento di focus:

<br /> <a href="versionestampabile.html" onclick="window.open(this.href); return false;" onkeypress="window.open(this.href); return false;" title="Versione stampabile della pagina [attenzione: si aprirà in una nuova finestra]">Stampa</a><br />

E’ ovvio che, questo genere di soluzioni, andrebbero usate solo laddove non se ne può fare a meno, come, per esempio, la generazione di una pagina stampabile.

Seconda soluzione

Un’altra alternativa, la propone Ecologia dei siti web, che, nel tentativo di rispettare la legge L. 4/2004 (come pure le WCAG) che, indica, giustamente, di non vincolare l’utente all’uso di uno specifico dispositivo di input, consiglia di usare l’evento onclick sempre assieme all’evento onkeypress controllando che il tasto premuto corrisponda al tasto ENTER.

Ecco la sua soluzione:

<br /> function inizializza() {<br /> a = document.getElementsByTagName(‘A’);<br /> for(i=0;a[i];i++) if(a[i].className.indexOf(‘blank’) != -1) {<br /> a[i].title += ” [il collegamento apre una nuova finestra]”;<br /> a[i].onclick = function () {window.open(this.href, ‘_blank’);return false;};<br /> a[i].onkeypress = function (e) {<br /> k = (e) ? e.keyCode : window.event.keyCode;<br /> if(k==13) {<br /> window.open(this.href, ‘_blank’);<br /> return false;<br /> }<br /> }<br /> }<br /> }<br /> window.onload = function() {inizializza();}<br />

Mentre i collegamenti da aprire in una nuova finestra sono identificati semplicemente tramite l’associazione alla classe blank:

<br /> <a href="http://www.google.it/" class="blank">Google</a><br />

Terza soluzione

Per finire non mi resta che citare un’ultima interessante alternativa tutta italiana: si chiama Wi.Li. (Windowed Links) ed è opera di Diego La Monica che l’ha realizzata partendo da un’idea di Carlo Filippo Follis.

Wi.Li. è uno script che ha il compito di eseguire una scansione di tutti i link sulla pagina in cui è inserito verificandone la destinazione. Nel momento in cui un utente effettua un click su un collegamento, Wi.Li. adotta un comportamento differente in base alla decisione dell’utente che può essere: aprire la pagina in una nuova finestra oppure rimanere nella stessa finestra di navigazione.

Il vantaggio di Wi.Li., quindi, è quello di poter integrare nel proprio sito “finestre popup discrezionali” accessibili, senza dover intervenire manualmente sul codice HTML che rimane validato.

Dagli esempi, si evince il suo funzionamento che, per quanto intuitivo, non rispetta comunque una delle direttive del regolamento attuativo della L. 4/20041, ovvero quella relativa all’avviso esplicito all’utente del cambiamento del focus.

Tag:Css, html, html_validators, Javascript

4 comments

Gen 2 2008

Come risparmiare banda del proprio sito riducendo le dimensioni dei file javascript e attivando la compressione HTTP da WordPress

Posted by Antonio Troise

Il 28 Dicembre 2007 il mio sito aveva finito la banda messa a disposizione dal mio server di hosting Blooweb: ben 40 GB mensili. Se questo, da un lato, non poteva che farmi contento perché significava che avevo un discreto numero di visitatori quotidiani, da un altro correvo il rischio di rendere inaccessibile il mio sito per ben 3 giorni consecutivi. Fortuna che i ragazzi del servizio di assistenza tecnica mi sono venuti incontri e gentilmente mi hanno concesso qualche giga in più per arrivare a fine mese! Il problema però rimaneva: se qualche mese prima arrivavo a 20-25 GB di banda mensile adesso in soli 31 giorni superavo la quota di 40 GB. Cosa era accaduto in questo periodo? Sicuramente un aumento del numero di utenti era stata una delle cause ma qualcos’altro era latente nel codice html del mio sito.

Analisi del log degli accessi

Dalle statistiche mensile di Awstats ho scoperto che se le pagine html/xhtml occupano al mese 10 GB di banda (in teoria questo valore dovrebbe essere direttamente proporzionale al numero di articoli che scrivo), quello che mi sconcertava era che i file Javascript occupavano ben 15.31 GB complessivi! Una cifra davvero spropositata.

Ecco allora che era venuto il momento di porre rimedio alla situazione.

Analisi del codice HTML

Come prima cosa ho analizzato il codice html della homepage e ho preso nota dei file javascript che caricava.
Così ho visto che nell’header caricava:

mentre nel footer

<br /> <br /> <script type="text/javascript" src="http://www.levysoft.it/wp-content/plugins/syntax/Scripts/shCore.js"></script><br /> <script type="text/javascript" src="http://www.levysoft.it/wp-content/plugins/syntax/Scripts/shBrushCpp.js"></script><br /> <script type="text/javascript" src="http://www.levysoft.it/wp-content/plugins/syntax/Scripts/shBrushCss.js"></script><br /> <script type="text/javascript" src="http://www.levysoft.it/wp-content/plugins/syntax/Scripts/shBrushJScript.js"></script><br /> <script type="text/javascript" src="http://www.levysoft.it/wp-content/plugins/syntax/Scripts/shBrushPhp.js"></script><br /> <script type="text/javascript" src="http://www.levysoft.it/wp-content/plugins/syntax/Scripts/shBrushSql.js"></script><br /> <script type="text/javascript" src="http://www.levysoft.it/wp-content/plugins/syntax/Scripts/shBrushXml.js"></script><br /> <script type="text/javascript">dp.SyntaxHighlighter.HighlightAll('code');</script><br /> <br />

Rispettivamente abbiamo, quindi:
prototype.js?ver=1.5.1.1 -> 94.05 KB addicted_live_search/js/prototype.js -> 53.86 KB addicted_live_search/js/live_search.js -> 692 bytes audio-player/audio-player.js -> 767 bytes syntax/Scripts/shBrush*.js -> 42.13 KB

Eliminare le ridondanze

Come vedete il plugin Addicted To Live Search caricava il file prototype.js che è lo stesso che nativamente usa WordPress. Cambia solo la release: se WordPress usa la versione 1.5.1.1, questo plugin usava la 1.5.0_rc0 (attualmente esiste la release 1.6).
Come primo passo, quindi, era inevitabile che modificassi il plugin “Addicted To Live Search” in modo da non caricare inutilmente due volte lo stesso framework javascript. Quindi ho editato il file live_search.php e commentato la riga relativa al framework prototype:

Con questa piccola modifica ho risparmiato 53.86 KB che, moltiplicato il numero di visite mensili, è sicuramente un valore non trascurabile, dato che questi codici javascript vengono caricati ad ogni singola pagina!

Per intenderci meglio, se un sito ha un numero giornaliero di pagine viste pari a 1.000, al mese abbiamo 31.000 pagine viste che moltiplicato quasi 54 KB, abbiamo un risparmio netto di oltre 1,6 GB di banda mensile (in questi calcoli ho considerato trascurabili gli effetti cache dei browser)! Con 100.000 visite al mese, avremmo un risparmio di 5,4GB di banda. Insomma, a conti fatti, risparmiare 54 KB non sembra poi una operazione inutile!

Comprimere i file Javascript

A questo punto bisognava risolvere anche il problema dell’eccessiva dimensione del file Prototype.js: ben 94.05 KB. Per farlo non ho fatto altro che comprimere il contenuto di questo file con uno dei tanti compressori di file javascript che si trovano in giro per la rete, in grado di ridurne le dimensioni, il tempo di caricamento di una pagina e, conseguentemente, la banda complessiva occupata!

Per scegliere quale fosse il miglior compressore per il file Prototype.js 1.5.1.1 ho eseguito diversi test con i seguenti 3 popolari compressori javascript online: Dean Edwards’ Javascript Compressor, Dojo ShrinkSafe e MemTronic’s HTML/JavaScript Cruncher & Compressor.
I risultati sono visualizzati in questa tabella riepilogativa:

	Original	Dean Edwards’	ShrinkSafe	MemTronic’s
file size(kb)	94.0	39.2	64.5	40.4
gzipped size(kb)	20.6	16.7	18.4	20.4

Anche se per pochi kilobyte, ho deciso, quindi, di prendere in considerazione Dean Edwards’ Javascript Compressor. Come risultato ho ottenuto, quindi, una riduzione delle dimensione di oltre il 50%, da 94.05 KB a 39.23 KB, per un risparmio complessivo di ben 54,82 KB.

Ovviamente, per continuare ad adottare questa soluzione, ad ogni upgrade della propria piattaforma di blogging WordPress, ci si dovrà ricordare di comprimere il nuovo file JS, operazione che consta in appena 2 minuti di attività.

UPDATE: Se però volete risparmiare tempo ed evitare di dover, ogni volta, comprimere i nuovi file Prototype.js che vengono rilasciati insieme alla distribuzione di WordPress, potete, allora, fare riferimento all’ottimo lavoro svolto da John-David Dalton che ha compresso per noi le versioni di Prototype 1.4, 1.5, 1.5.1.1, 1.6.0. Quello che dovrete fare voi è scaricare il file protopacked_v2.17.zip, scompattarlo e vi troverete una ricca collezione di framework Prototype/Scriptaculous. In particolare questo package contiene la release 1.4, 1.5, 1.5.1.1, 1.6.0 di Prototype e la release 1.7.1_beta3, 1.8.0 di Scriptaculous. Se sul vostro sito usate anche Scriptaculous allora dovete far riferimento al file Protoculous, che altro non è che la combinazione in un unico file di Prototype and Scriptaculous.

In generale, però, una volta scompattato il pacchetto zip, aprite la cartella “files” e vi troverete 3 cartelle: qui scegliete di aprire la cartella “compressed“, quindi la cartella “prototype” e, infine, entrate nella directory “v1.5.1.1“. Qui, vi troverete, dinanzi a due differenti versioni compresse dello stesso file Prototype.js:

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

La differenza sta nelle dimensioni: il prototype-1.5.1.1-packer.js è grande neanche 40 KB mentre prototype-1.5.1.1-shrinkvars.js arriva fino a 60 KB. Io, per il mio sito, ho usato prototype-1.5.1.1-packer.js che ho, ovviamente, rinominato in prototype.js e, quindi, salvato nel percorso “wp-includes/js” sostituendo il precedente file.

Quindi, in definitiva, ad ogni aggiornamento di WordPress, quello che dovrete fare è, andare su Prototype: Core e scaricare la versione desiderate del framework Prototype compresso.

Attivare la compressione HTTP da WordPress

Un’altra cosa da fare è quello di andare nel Pannello di Controllo di Wordpress e, nella sezione Opzioni/Lettura, spuntare la voce “WordPress deve comprimere gli articoli (gzip) se il browser lo richiede“.
Infatti, WordPress permette di comprimere in formato Gzip (attivando la compressione HTTP), se il browser del visitatore lo supporta, in modo da alleggerire la dimensione della pagina e diminuirne il tempo trasferimento facendo lavorare un po’ di più il computer dei vostri lettori.

In pratica, quindi, quando un visitatore richiede una pagina questa viene creata dal server, compressa in Gzip ed inviata al browser del nostro lettore che provvederà in automatico a scompattarla e successivamente a visualizzarla.
Fate attenzione però che, se usate dei plugin che velocizzano il blog mediante lavoro sulla cache, come WP-Cache o WP Super-Cache (di fatto l’evoluzione di WP-Cache) e attivate la compressione Gzip, i plugin potrebbero non funzionare.
In particolare, nel caso di WP-Cache, per far convivere entrambe le soluzioni, dovrete modificare il file wp-cache-phase1.php seguendo la procedura indicata da Davide Salerno.

In definitiva questa operazione dovrebbe influenzare il valore della banda occupata dalle pagine HTML/XHTML static page (che, ne mio caso, a Dicembre 2007 era di ben 10.80 GB senza alcuna compressione attiva!)

C’è da dire che la compressione Gzip era sempre stata attiva sul mio sito: presumo quindi che, in seguito all’ultimo grande cambio release alla versione 2.3 di WordPress, questo opzione deve essere stata disabilitata per errore. Sono curioso, ora, di vedere quanto possa influenzare sulle banda complessiva.

Non resta che attendere

Per ora, mi sono fermato così. Al momento ho risparmiato complessivamente, per ogni pagina caricata ben 109 KB di Javascript, e un valore imprecisato di kilobyte attivando la compressione html, che al mese significa (sempre riportando un valore medio di 100.000 pagine) un risparmio di quasi 11 GB di bandwidth!

Al momento, gli altri file javascript non li ho compressi e forse, ad una analisi successiva, potrei anche rimuovere i plugin ad essi correlati (sostituendoli con altri più leggeri). Per il momento ho intenzione di aspettare 15 giorni per capire se tutte queste modifiche sono state sufficienti per recuperare un po’ di banda. Se così non fosse potrei provare a comprimere tutti i file Javascript e, magari, spostare su un altro server le immagini JPG, GIF e PNG che complessivamente occupano 4.81 GB di banda.

Infine, potrebbe anche essere utile comprimere i file CSS (nel mio caso arrivo a circa 18.14 KB complessivi): in questo caso vi suggerisco Compressor, una applicazione online in grado di comprimere sia codice Javascript o i fogli di stile CSS.

Intanto, per fosse interessato, metto a disposizione il file Prototype.js 1.5.1.1 compresso di WordPress 2.3.2: lo potete scaricare qui.

Tag:Ajax, bandwidth, browser, Css, Javascript, Php, Plugin, prototype, Wordpress

26 comments

Nov 16 2007

Come cambiare un tema di un sito senza che nessuno se ne accorga

Posted by Antonio Troise

Anche se non sembra, ho completamente riscritto da zero il tema di Levysoft. Se prima era basata sul buon Unnamed 1.0, che sfruttava a piene mani la tecnologia Ajax per inviare commenti e fare ricerche all’interno del sito, oggi si basa sul tema SEO ProSense-Grey, totalmente stravolto da un ricco mashup di funzionalità ispirate dai temi, come The Wrong Advices, diploD, iqwolf. Quindi ho inserito la ricerca ajax grazie al bel plugin per WordPress addicted to live search mentre per il momento ho eliminato l’inserimento live dei commenti e, almeno ora come esperimento, anche qualsiasi tipo di captcha grafico o matematico (ogni tanto mi davano qualche problema).

Insomma un lavoro di una settimana per stravolgere il codice, renderlo più leggero, e ottimizzato SEO, ma senza alterare nelle sue parti fondamentali il layout grafico del sito. Certo ho cambiato il font usato e il footer (ora più ricco di informazioni), ho cambiato alcuni colori (ora sono più soft e uniformi e lo sfondo del sito ora è sul bianco sporco in modo da non contrastare troppo col testo) e aggiunto, oltre a nuove icone, anche un extract di altri 5 articoli (senza quindi visualizzarli per intero) alla fine della index.php. Insomma piccole migliorie e qualche accorgimento in più, oltre che a qualche esperimento, ma sostanzialmente il sito è molto simile al precedente.

Sicuramente molti di voi si staranno chiedendo perché fare tutto questo lavoro, se poi ha quasi le stesse funzionalità live e lo stesso impatto grafico del precedente.
I motivi che mi hanno fatto decidere per un completo remake del codice del tema sono stati:

Il tema che usavo era Unnamed 1.0, una release customizzato con Ultimate Tag Warrior (che su WordPress 2.3 non è più necessario).
Era ricco di funzionalità live che, anche se lo rendevano più usabile, come peso totale del tema, era quasi il doppio del presente tema.
Il vecchio tema usava una versione di Prototype incompatibile con WP e con molti plugin grafici come “Lightbox 2.02 Plugin“
Ora con il nuovo tema ho il controllo di ogni byte del mio sito mentre con il precedente mi fidavo ciecamente del lavoro dell’autore: da programmatore il mio ego ora risulta appagato!

Attualmente il tema è ancora in una fase di beta a causa di problemi di gioventù (devo ancora finire la validazione XHTML e CSS), ma ho preferito adottarlo subito sul mio sito perché, continuando a lavorare in locale, non riuscivo a simulare tutte le casistiche che solo una messa in campo può dare (come il fatto che appena installato solo io riuscivo a mandare commenti a causa di un non corretto funzionamento di un plugin).
Ora sono in cerca di un perfezionamento del CSS per la sezione del footer che su Firefox e Safari non mi visualizza correttamente l’ombreggiatura. Inoltre vorrei eliminare, durante il caricamento della pagina, che venga visualizzato prima di ogni altro layer, lo sfondo grigio che, con i caratteri neri del testo, non è un bel vedere.
Qualcuno ha qualche suggerimento?
Un altro problema che ho incontrato è che la nuova release 0.39 di MBLA – MyBlogLog Avatars è incompatibile con il plugin Google XML Sitemaps poiché entrambi accedono alla stessa area cache, cosa che mi ha costretto a lasciare la vecchia release 0.18 di MBLA.

Spero che questa tema possa incontrare i favori dei miei lettori, ma se avete qualche precisazione o miglioria da segnalare, ogni segnalazione è la benvenuta!

Tag:Ajax, Css, Plugin, tema, Wordpress

27 comments

Ago 14 2007

Come inserire una immagine in un campo di testo: esempio applicato al campo antispam matematico

Posted by Antonio Troise

Inserire una immagine in un campo di testo Dopo aver introdotto nei commenti il captcha matematico e aver inserito una facility per lo user-uman, ho pensato di dare un tocco grafico al campo anti-spam inserendovi un immagine di un un lucchetto che rendesse immediato e chiaro lo scopo di questa casella di testo.

Per fare questo ho sfruttato la proprietà Background dei CSS, con cui è possibile controllare lo sfondo degli elementi, sia per quanto riguarda i colori che per quanto riguarda le immagini.
Nel nostro caso ci interessa usare la seconda possibilità ed in particolare mi soffermerò sulla modifica del campo antispam proposto nel Math Comment Spam Protection Plugin, ma deve essere chiaro questa procedura è valida per qualsiasi casella di testo.

Inserire nel foglio di stile del proprio tema questa proprietà:

<br /> input#mcspvalue {<br /> background:#FFFFFF url(images/lock.png) no-repeat scroll left center;<br /> border:1px solid #DDDDDD;<br /> padding:2px 2px 2px 20px;<br /> }<br />

Come si vede, il codice CSS, non fa altro che assegnare certi parametri a tutte le caselle di testo di tipo INPUT (quindi si escludono, per esempio, le textarea) che hanno un valore di ID pari a mcspvalue (valore di default assegnato dal plugin wordpress di antispam). Questi parametri consistono in uno sfondo di default bianco ma che deve caricare un file PNG 6×16 di nome lock.png posizionato a sinistra e centrato in altezza e che non viene ripetuto ne scrollato.

Molto importante è anche l’entry padding: dato che l’immagine è larga 16 pixel, occorre posizionare il testo subito dopo l’immagine, per evitare una sovrimpressione sgradevole alla vista. Per fare ciò uso la proprietà padding il cui ultimo valore corrisponde a quanti pixel da sinistra deve posizionarsi il testo.

Come ben insegna Davide, come regola mnemonica basta ricordare che, nel caso che la dichiarazione generica contenga quattro valori, questi seguono un ordine in senso orario a partire dall’alto: padding:top right bottom left;

Una volta modificato il css come suggerito e scelta una immagine da applicare allo sfondo del campo di input (cliccate qui per scaricare l’immagine lock.png), il gioco è fatto e il risultato è quello che vedete qui sotto nei commenti.

Tag:antispam, Css, spam

0 comments

Lug 13 2007

Firebug e la funziona di INSPECT per modificare al volo le pagine html e come fare Hacking di applicazioni web con Firefox

Posted by Antonio Troise

Firebug Firebug, è una estensione per Firefox che facilita la vita a chi deve costruire siti e applicazioni web. Tra le centinaia di funzionalità di cui si dispone installando Firebug, come la possibilità di analizzare ed editare il codice HTML, CSS e Javascript, la visualizzazione di tutte le dipendenze, utili strumenti di debug e di esplorazione del DOM e il monitoraggio dettagliato del caricamento delle pagine e degli elementi che le compongono, ve ne è una che, tra tutte, le supera di gran lunga: è la funzione di “Inspect element”.

Inspect Questa opzione, che appare nel menu contestuale quando si attiva firebug in corrispondenza dell’elemento identificato dal mouse (oppure cliccando sul pulsante Inspect e poi selezionando con un click del mouse l’elemento che interessa), permette di modificare e testare “a caldo” qualunque pagina HTML, foglio di stile CSS o funzione Javascript di un qualsiasi sito web senza provocare alcun impatto sulla navigazione per i vostri visitatori.
Così facendo nella parte inferiore della finestra sarà possibile visualizzare il codice html e gli stili associati all’elemento selezionato: per esempio, nella sezione css vengono visualizzate le proprietà dell’oggetto, dichiarate direttamente oppure ereditate (le dichiarazioni che trovate barrate sono quelle sovrascritte da dichiarazioni successive). E’ possibile, quindi, modificare il css e l’html e le funzioni javascript agendo direttamente sulla finestra di Inspect e verificare immediatamente gli effetti della variazione; per ritornare alla pagina originale basta fare un semplice refresh da Firefox.
Addirittura è anche possibile, nella finestra relativa ai css, visualizzare un’anteprima dei colori usati semplicemente posizionando il puntatore sopra al valore esadecimale.

Il bello della funzione di INSPECT di Firebug è che è possibile testare velocemente le modifiche al proprio sito online lavorando localmente su Firefox e in tempo reale. Inoltre, è possibile analizzare molto velocemente la struttura di un altro sito di cui magari se ne vuole carpire qualche trucchetto html o css.

Un esempio pratico delle potenzialità dell’INSPECT di Firebug lo trovate nel Video Tutorial su come modificare il proprio tema WordPress in 5 minuti con FireBug di Daniele Salamina

Altri Toolkit simili è possibile trovarli installando a Web Developer Toolbar oppure Venkman, anche se, a mio parere, non sono così completi performanti come Firebug.

Per chi, invece, non usa Firefox, è possibile testare la console di Firebug con Firebug Lite. Si tratta di uno script da inserire nelle pagine che vogliamo testare e che attiva la visualizzazione della console nella parte inferiore della pagina stessa usando il tasto F12 o la combinazione CTRL+SHIFT+L.

Qui, invece, trovate la traduzione dell’articolo Hacking Web 2.0 Applications with Firefox di Shreeraj Shah pubblicato originariamente su SecurityFocus che insegna come fare hacking di applicazioni Web 2.0 con Firefox e Firebug.

Se poi, l’idea di trasformare Firefox in una hacking platform vi alletta molto, allora non dovete fare altro che seguire l’articolo Turning Firefox to an Ethical Hacking Platform pubblicato da Security Database in cui vengono elencate numerose estensioni per Firefox da installare per avere a disposizione tutto il necessario per l’hacking di applicazioni web.
Queste le categorie: Whois and geo-location, Enumeration / fingerprinting, Social engineering, Googling and spidering, Editors, Headers manipulation, Cookies manipulation, Security auditing, Proxy/web utilities, Hacks for fun, Encryption, Malware scanner, Anti Spoof.

Tag:Ajax, Css, editor, firebug, firefox, hack, html, Javascript, toolkit, Tutorial, Video

5 comments

Lug 9 2007

Come impaginare su WordPress i commenti adattandoli al tema del vostro sito ed evidenziare quelli dell’autore del blog

Posted by Antonio Troise

L’altro giorno ho fatto una piccola modifica al mio blog in modo da renderlo più efficiente: ho installato un plugin che dividesse in pagine i commenti e ho modificato il foglio di stile in modo da evidenziare con un solo colpo d’occhio il commento dell’autore del blog (ovvero me) da quelli di tutti gli altri.
Questa esigenza è nata dal fatto che alcuni miei articoli hanno centinaia di commenti (come Xbox 360 vs PlayStation 3 con 555 commenti e 999 inviti Joost tutti per voi con 166) che inficiavano notevolmente le prestazioni del sito durante il caricamento della pagina. Inoltre, tra tutti questi articoli, era necessario effettuare un highlight dei commenti dell’autore, in modo da evidenziare, tra le centinaia di commenti, le mie risposte.

Tag:Css, Plugin, Wordpress

5 comments

Lug 5 2007

Installare Syntax Highlighter per WordPress

Posted by Antonio Troise

Ero alla ricerca di un efficiente Syntax Highlighter per WordPress, ovvero un plugin che rendesse visibile la sintassi colorata del codice html, js e php. Nelle mie ricerche alla fine sono approdato sull’interessante progetto di SyntaxHighlighter, un syntax highlighter gratis scritto in JavaScript.
Questi i linguaggi supportati:

Language	Aliases
C++	`cpp`, `c`, `c++`
C#	`c#`, `c-sharp`, `csharp`
CSS	`css`
Delphi	`delphi`, `pascal`
Java	`java`
Java Script	`js`, `jscript`, `javascript`
PHP	`php`
Python	`py`, `python`
Ruby	`rb`, `ruby`, `rails`, `ror`
Sql	`sql`
VB	`vb`, `vb.net`
XML/HTML	`xml`, `html`, `xhtml`, `xslt`

Ho scelto questo plugin piuttosto che IG Sintax Hiliter perché quest’ultimo non permetteva il copia e incolla del codice senza il numero delle righe, il che risultava molto fastidioso.

Per WordPress esiste, inoltre, anche un comodo plugin di SyntaxHighlighter sul sito di Erik che permette, una volta attivato, di scegliere, attraverso un comodo pannello di controllo, quali linguaggi caricare tra quelli disponibili (visto che ad ognuno corrisponde un file javascript, per rendere più snello il caricamento, si permette la scelta di quelli che si pensa di utilizzare), la grandezza in righe e colonne della textarea e se visualizzare o meno i numeri delle righe e la barra di visualizzazione del codice sorgente in ascii.
Il suo uso è molto immediato: basta seguire la seguente sintassi:

 str source

Per esempio, se volessi scrivere del codice css, dovrò inserire nel mio post il seguente codice:

.class-comment1 {
margin:15px 10px;
border:1px solid #6BA4DC;
}

.class-comment2 {
margin:15px 10px;
border:1px solid #ddd;
}

Per avere il seguente risultato:

<br /> .class-comment1 {<br /> margin:15px 10px;<br /> border:1px solid #6BA4DC;<br /> }</p> <p>.class-comment2 {<br /> margin:15px 10px;<br /> border:1px solid #ddd;<br /> }<br />

Come vedete, la lettura del codice risulta molto chiara e maggiormente scorrevole, che non se fosse stato scritto senza formattazione dei colori.

Il plugin di Erik, però, risale al 26 Settembre del 2006, mentre il codice javascript originale di Alex Gorbatchev è stato aggiornato alla release 1.5 l’11 Maggio del 2007. Anche se il plugin funziona egregiamente, con l’ultima release sono stati aggiunte molte funzionalità interessanti, tra cui anche l’eliminazione dell’uso del tag TEXTAREA sostituito dal tag PRE.
In definitiva, però, le modifiche non sono tali da pregiudicare il funzionamento e le prestazioni del plugin che si basa su una vecchia release.

Tag:Css, Javascript, Plugin, Wordpress

1 comment

Mag 27 2007

Rollover e preload delle immagini con i CSS per evitare l’effetto vuoto

Posted by Antonio Troise

L’altro giorno stavo provando a personalizzare i link della sidebar del mio tema WordPress con delle immagini in rollover: un giochetto da nulla ma l’ho effettuato non con il classico metodo delle 2 immagini distinte che si caricano a seconda se il mouse è sopra il link o meno, ma utilizzando il metodo del posizionamento del background.
Infatti se per il rollover si usano 2 immagini differenti, all’apertura della pagina è caricata la sola immagine di a:link (nuovo o visitato), mentre quella dell’ a:hover è caricata solo al passaggio del mouse.
A volte, però, il caricamento dell’immagine associata all’evento hover, può provocare uno spiacevole effetto “vuoto”; questo fenomeno si accentua per un bug del browser Internet Explorer 6 e si ripropone ogniqualvolta si apre la pagina.
Il problema si risolve usando sempre una tecnica CSS attribuendo allo sfondo una unica immagine che, quando si attiva a:hover scorre l’immagine (avanti o indietro, sopra o sotto) di un certo numero di pixel, cambiando di fatto lo sfondo.
In questo ambito descriverò la tecnica usata per il mio template WordPress (che è molto simile a tanti altri, almeno per quanto riguarda la sezione della sidebar dei link dei post).

Icon Post Innanzitutto caricare nella propria cartella images del proprio template il file icon_post.gif (l’immagine è stat presa dal tema minyx-theme).

Quindi aprire il file sidebar.php del proprio template e nella sezione degli ultimi articoli, inserire nel tag ul la classe “listPost”

Utilizzando un qualsiasi programma di grafica potrete dedurre le coordinate e le dimensioni di una selezione. Infine, aprire il proprio foglio di stile e inserire queste righe:


	/* Rollover link in sidebar with class listPost*/
	#sidebar ul li a{
		padding:4px 0px 4px 35px;
		display:block;
		background-repeat:no-repeat;
	}

	#sidebar ul li a:visited{
		background-position:5px 0px;
	}

	#sidebar ul li a:hover{
		background-position:5px -23px;
	}

	#sidebar .listPost li a{
		background-image:url(images/icon_post.gif);
		text-transform:lowercase;
	}
	/* End Rollover link in sidebar with class listPost*/

Come vedete, per ogni link andranno specificati lo stato normale, lo stato hover e quello attivo, intervenendo sul background-position: da notare che le coordinate dello stato hover corrispondono alla posizione dello stato normale traslando, però, la coordinata “y” di 23 pixel verso il basso (quindi si assegnano valori negativi).

Tag:Css, rollover, sidebar, Wordpress

0 comments

Dal 2004 il blog di Antonio Troise

Come abilitare lo scrolling infinito della homepage del proprio blog su WordPress caricando dinamicamente gli articoli

Caricamento dinamico degli articoli

Installazione

Impressioni

Bug

In conclusione

Come realizzare siti con interfaccia Touch Friendly per iPod Touch e iPhone con i kit IUI e WebApp.net e analisi sulla mancanza di una versione per iPhone di Wikipedia

Pochi pensano alla versione Touch Friendly del proprio sito

Il problema del dito come dispositivo di puntamento

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

I siti Touch Friendly e la mancanza di Wikipedia

Perché spesso le guide html non dicono che l’attributo TARGET per aprire nuove finestre non è HTML Strict? Tre soluzioni per avere lo stesso effetto senza invalidare il codice e avere un sito accessibile

Una informazione spesso omessa nelle guide html

Dove trovare informazioni sulle specifiche HTML Strict

Prima soluzione

Seconda soluzione

Terza soluzione

Come risparmiare banda del proprio sito riducendo le dimensioni dei file javascript e attivando la compressione HTTP da WordPress

Analisi del log degli accessi

Analisi del codice HTML

Eliminare le ridondanze

Comprimere i file Javascript

Attivare la compressione HTTP da WordPress

Non resta che attendere

Come cambiare un tema di un sito senza che nessuno se ne accorga

Come inserire una immagine in un campo di testo: esempio applicato al campo antispam matematico

Firebug e la funziona di INSPECT per modificare al volo le pagine html e come fare Hacking di applicazioni web con Firefox

Come impaginare su WordPress i commenti adattandoli al tema del vostro sito ed evidenziare quelli dell’autore del blog

Installare Syntax Highlighter per WordPress

Rollover e preload delle immagini con i CSS per evitare l’effetto vuoto

Categorie

Commenti Recenti

Meta

Friends Link

Seguimi su: