Come risparmiare banda: ridurre le email dei commenti e i backup via FTP, usare le AJAX Library API di Google con il plugin per WordPress e disattivare Google Translator che non porta traffico utile ad Adsense
Più volte mi sono dovuto imbattere in ottimizzazioni certosine per ridurre i consumi di banda mensile sul mio sito: riducendo le dimensioni dei file javascript, attivando la compressione HTTP e, a volte, anche spostando le immagini su un altro server. Ma non ho mai dovuto affrontare incrementi di banda di oltre 10/20 GB in un solo mese.
Infatti, lo scorso Giugno, con mia grande sorpresa a soli 20 giorni dall’inizio del mese, il mio sito aveva già esaurito la banda di 40 GB messa a disposizione dal Blooweb, arrivando, a fine mese, ad oltre 50 GB di banda totale. Grazie alla gentilezza dello staff del mio hosting, mi hanno ripristinato temporaneamente il servizio in attesa che capissi da cosa fosse dipeso questo improvviso aumento di banda.
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.
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
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
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.
Nuove modalità per risparmiare banda con WordPress 2.5: addio alla compressione Gzip direttamente da WordPress e comprimere del 60% il file prototype.js v1.6.0
Tempo fa scrissi un paio di guide su come risparmiare banda sul proprio sito comprimendo tutte le pagine con Gzip e riducendo le dimensioni del file javascript prototype. Le operazioni che, però, avevo descritto in quei tutorial non sono più del tutto valide in WordPress 2.5. Ecco, in particolare, cosa è cambiato e come agire di conseguenze.
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).
Eccomi di nuovo online: nuovo server, PHP 5 e WordPress 2.5
Forse qualcuno di voi si sarà accorto che latitavo da qualche giorno su questo blog: purtroppo non dipendeva da me ma dal fatto che il mio sito era congestionato su un server che non riusciva più a tenere il notevole carico di visite. Le pagine web erano molto lento a caricarsi e molto spesso mi dava errori del tipo:
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.
WordPress Plugin: Respond to Author’s Comment
Questo è il mio primo plugin ufficiale per WordPress. Sul mio blog ho sempre realizzato delle personalizzazioni sia di interfaccia che di funzionalità ma, siccome erano nate da alcune particolari esigenze del mio sito, non ho mai pensato potessero essere utili anche ad altri, e, al massimo, se le reputavo interessanti, ero solito scrivere qualche articolo che spiegasse come avessi risolto un particolare problema o come avessi implementato una nuova funzionalità.
Questa volta, però, ho creduto che il plugin “Respond to Author’s Comment” potesse essere utile ad altri blogger visto che non sono riuscito a trovare nulla di simile nella directory dei plugin ufficiali di WordPress.
Descrizione
La sua implementazione è molto semplice, ma il vantaggio di questo plugin è quello di velocizzare la modalità di risposta diretta agli autori dei commenti, aggiungendo in fondo ad ogni intervento, un link che permette, via javascript, di inserire la nota formula “@Nome Autore: ” nella textarea di inserimento commenti.
Ho creato questo plugin perché, quando mi ritrovavo a dover rispondere direttamente all’autore di un commento, ero costretto ogni volta a fare un copia e incolla del nome (dato che, a volte, alcuni nickname non sono molto facili da riscrivere manualmente). Un’operazione che, a dire la verità, portava via solo un paio di secondi, ma con l’inserimento del link “Rispondi a” al termine di ogni commento, ho potuto velocizzare ancora di più le operazioni.
In questo modo, ogni volta che qualcuno vorrà rispondere direttamente ad un commentatore, basterà semplicemente cliccarci sopra per essere automaticamente portati in fondo alla pagina, nella textarea di inserimento dei commenti, dove troverete già inserito il nome della persona a cui vorrete rispondere, nella forma: “@Nickname: “.
Tra le caratteristiche troviamo che:
- Il plugin prevede l’inserimento di più nickname accodati uno dopo l’altro: basterà cliccare su tutti i link “Rispondi a” interessati per avere qualcosa tipo:
@Nickname1:
@Nickname2: - Il plugin prevede anche la discriminazione dei commenti dai pingback e trackback, di modo che, il link “Rispondi a” venisse visualizzato solo nei commenti veri e propri. Per esigenze particolari di formattazione, ho pensato di aggiungere anche due parametri “before” e “after” in modo da poter inserire del testo (anche html) o dei separatori prima e dopo il link “Rispondi a”.
- Il plugin Respond to Author’s Comment è compatibile con tutte le piattaforme di navigazione più famose (Firefox, Explorer, Safari ed Opera) e con tutte le versioni di WordPress, dalla 1.5 alla 2.6.2..
Installazione
- Scaricare il pacchetto, decomprimerlo e caricarlo nella cartella dei plugin di WordPress (wp-content/plugins/).
- Attivare il plugin “Respond to Author’s Comment” da Gestione Plugin nel Pannello di Amministrazione
- Inserire la funzione di “respond_comment()” nel file comments.php del proprio tema (wp-content/themes/[yourtheme]/), nella posizione in cui si desidera visualizzare il link.
In particolare, per evitare che la funzione venga richiamata quando il plugin è disattivo (dando inevitabilmente un errore php), la funzione va inserita nel seguente modo:Questa può accettare sette argomenti opzionali::
- i primi due servono per localizzare nella propria lingua il plugin, che altrimenti di default è in inglese (il primo è il testo da visualizzare per il link, mentre il secondo è il testo esteso per il title del link);
- i successivi due argomenti opzionali (“before” e “after“) servono per aggiungere del testo prima e dopo il link “Rispondi a”;
- altri due parametri facoltativi (“pretag” e “posttag“) servono inserire la formattazione html nella risposta;
- e l’ultimo parametro opzionale ($id_comment) permette di far funzionare il focus nella textarea anche per quei temi che hanno un id diverso da quello di default “comment“
In definitiva, ecco la funzione con tutti gli argomenti:
e questo è un esempio di applicazione standard:
", "", "comment"); } ?>
Personalizzazioni
Nel caso il vostro blog fosse in inglese, allora è sufficiente inserire semplicemente la funzione senza argomenti:
Altrimenti, potete inserire la traduzione in italiano (o in qualunque altra lingua) direttamente nei primi due argomenti:
Infine, se volete inserire del testo prima e dopo il link “Rispondi a”, magari per formattarlo correttamente, basterà aggiungere altri due argomenti facoltativi (“before” e “after“):
Nella versione 1.3 ho aggiunto, dopo alcuni suggerimenti, anche la possibilità di dare una formattazione html al testo di risposta che viene copiato nella textarea, con la semplice aggiunta di altri due parametri opzionali (“pretag” e “posttag“). Per esempio, per produrre una risposta in grassetto ecco come bisogna scrivere la funzione:
E nella textarea dei commenti verrà inserito il seguente codice html:
@Nickname:
Nella release 1.4, invece, ho inserito anche la possibilità di personalizzare l’id_comment in modo da far funzionare il focus nella textarea anche per quei temi che hanno un id diverso da quello di default “comment“. In particolare, se si omette il parametro $id_comment allora verrà usato quello di default “comment” e il link punterà a “href=’#comment’“. Invece, se volete adattarlo al vostro tema, che, per esempio ha un nell’area commenti il valore id=”postcomment”, allora dovrete scrivere:
per avere, quindi, un link come: “href=’#postcomment’”
Attenzione: se passate un valore nullo al parametro $id_comment, il ljnk risultante sarà: “href=’#’” che vi porterà ad inizio pagina. Per cui se non dovete modificare l’id, omettete completamente questo parametro.
Infine, nella versione 1.5 ho usato un WP Hooks (wp_head) per inserire, una volta sola, nell’header della pagina html la funzione javascript che inserisce il nome del commentatore a cui si vuole rispondere nella textarea di inserimento commenti. In questo modo, si evita di dover scrivere, per ogni commento, il codice js relativo.
Altre personalizzazioni
Per avere una piena compatibilità e per sfruttare totalmente le potenzialità del plugin, vi suggerisco di aggiungere, nella dichiarazione della textarea dei commenti, il seguente parametro:
mentre nella dichiarazione del form, aggiungete questo altro parametro:
In tal modo, quando si clicca sul link “Rispondi a” il testo verrà scritto correttamente nella textarea dei commenti.
Esempio:
History
- 1.5.2 (10/09/2008): Apportata una piccola modifica nel codice javascript per passare la validazione XHTML (thx Sniper Wolf)
- 1.5.1 (30/01/2008): Sfruttando il ‘Decode above code” del Javascript Compressor, ho ridotto ad una sola riga il codice javascript da inserire nell’header della pagina html: in tal modo, oltre a ridurre il peso complessivo e ad essere più veloce a caricarsi, è anche meno invasivo rispetto ad una versione indentata a più righe.
- 1.5 (28/01/2008): Usato un WP Hooks (wp_head) per inserire, una volta sola, nell’header della pagina html la funzione javascript che inserisce il nome del commentatore a cui si vuole rispondere nella textarea di inserimento commenti. In questo modo, si evita di dover scrivere, per ogni commento, il codice js relativo. (thx Daniele Alessandri)
- 1.4 (25/01/2008): Inserito nuovo parametro “$id_comment” in modo da far funzionare il focus nella textarea anche per quei temi che hanno un id diverso da quello di default “comment“.
- 1.3 (25/01/2008): Inseriti due nuovi parametri: “$pretag” e “$posttag” per inserire la formattazione html nella risposta (thx MAvero) e corretto un puntamento all’id comment per lo scroll della pagina (thx Daniele).
- 1.2 (24/01/2008): Inseriti due nuovi parametri: “$before” e “$after” per inserire del testo (anche html) prima e dopo il link “Rispondi a” per formattare correttamente il nuovo campo.
- 1.1 (23/01/2008) : Ora il plugin discrimina il comment_type e da la possibilità di rispondere solo ai commenti e non ai pingback o trackback
- 1.0 (07/01/2008) : Versione iniziale
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: Respond to Author’s Comment
Autore: Antonio Troise
Descrizione: Questo plugin permette di rispondere ad un commento inserendo la nota formula “@Author: ” nel form dei commenti grazie ad un link javascript.
Versione: 1.5.2
Scarica respond_author_comment.zip 1.5.2 | |
Dimensione: 1.27 KB |
[ENGLISH]
Plugin Name: Respond to Author’s Comment
Author: Antonio Troise
Description: This plugin allows commenters to responde other comments inserting “@authorname: ” in the comment form with Javascript’s Link.
Release: 1.5.2
Usage:
- Download the plugin, unzip and upload in the directory of plugin of WordPress (wp-content/plugins/).
- Activate “Respond to Author’s Comment” plugin from Manage Plugin in the Administration Area of WordPress
- Insert the function di “respond_comment()” in the file comments.php of own theme:
Download respond_author_comment.zip 1.5.2 | |
Size: 1.27 KB |
Come visualizzare un maggior numero di Bozze su WordPress
Dalla release 2.3 di WordPress è stato modificata la classica visualizzazione delle Bozze, ovvero quegli articoli scritti ma che non sono ancora stati pubblicati. Se prima era possibile vedere, dall’area di Amministrazione di WordPress, una lista completa di tutte le bozze presenti su proprio blog, sia da Gestione -> Articoli che direttamente nella pagina di Scrivi ->Scrivi articolo, dall’ultima Major Release ciò non vale più.
Infatti, nella sezione Gestione -> Articoli non vengono più visualizzate automaticamente tutte le bozze, ma vengono mostrati solo gli articoli pubblicati o da pubblicare in data futura. In alto, però, sono presenti dei campi di ricerca per filtrare un articolo per termine (contenuto nel titolo o nel testo del post), per status (Any, Pubblicato, Bozza o Privato), per mese di pubblicazione o per categoria. A questo punto è possibile eseguire una ricerca mirata per i soli articoli in Bozza, come di seguito mostrato:
Nella pagina, invece, di Scrivi articolo è possibile visualizzare solo i titoli delle ultime 3 Bozze create o modificate e, alla fine, viene mostrato un link che reindirizza alla pagine di gestione articoli filtrata già per visualizzare la prima pagina degli articoli in Bozza:
https://www.levysoft.it/wp-admin/edit.php?post_status=draft&author=1&paged=1
Probabilmente, questa scelta è stata dettata, oltre che per un puro fattore estetico, anche dal fatto di voler ridurre il numero di query generate in modo da velocizzare il caricamento delle pagine.
In molti, però, trovano questa visualizzazione scomoda, specie se si ha qualche centinaio di post in bozza perché si è costretti a scorrere di pagina in pagina per cercare un articolo visto che non è possibile visualizzarli tutti insieme e l’ordinamento avviene per data di modifica. Infatti, anche se è presente la possibilità di ricercare un termine contenuto nei post nello stato di Bozza, spesso, specie se si hanno così tanti post, non si ha bene in mente cosa cercare e si preferisce dare un’occhiata agli articoli in bozza per decidere su quale continuare a scrivere. Con questo genere di visualizzazione, si rischia di lasciare abbandonati i post più vecchi che, quindi, perderanno di importanza.
Se volete ripristinare, almeno parzialmente, la visione precedente dei post in bozza, allora l’unico modo è quello di modificare il file php che gestisce la scrittura di nuovi articoli.
Dove scaricare i framework Prototype compressi per WordPress per risparmiare banda e velocizzare il caricamento delle pagine
Quando descrissi come risparmiare banda per il proprio sito comprimendo, tra le altre cose, il voluminoso framework Prototype (un file JavaScript che ha loscopo di facilitare lo sviluppo di applicazioni web dinamiche di tipo Ajax) in uso su WordPress, ho detto che era possibile comprimerlo usando alcuni interessanti compressori javascript online: Dean Edwards’ Javascript Compressor, Dojo ShrinkSafe e MemTronic’s HTML/JavaScript Cruncher & Compressor.
Tra questi avevo suggerito di usare il Dean Edwards’ Javascript Compressor, perché aveva, in assoluto, il miglior rapporto di compressione, oltre il 50%, portando il prototype.js da 94.05 KB a 39.23 KB, con risultati significativi sia in termini di banda che di tempi di caricamento della pagina.
Il problema era che, ad ogni upgrade di WordPress, bisognava verificare la release del framework Prototype e ed eseguire ogni volta la compressione.
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, quindi, è 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.
Come risparmiare banda del proprio sito riducendo le dimensioni dei file javascript e attivando la compressione HTTP da WordPress
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
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.
Ecco finalmente il mio secondo plugin per WordPress: Filter Badwords Comment.
Nato soprattutto per l’esigenza di censurare alcune parole offensive presenti nei commenti su questo sito (specie nella calda sezione Xbox 360 vs PlayStation 3) ho deciso di renderlo pubblico per dare ad altri webmaster e blogger la possibilità di proteggere i propri lettori dalla lettura di parole che potrebbero offendere la sensibilità personale.
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:
[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: