Levysoft
  • Home
  • Portfolio
  • WordPress Plugin
  • Contattami

Dal 2004 il blog di Antonio Troise

RSS FeedTwitterFacebook
Lug 14 2008

Tutte le follie del iPhone in grado di creare un Reality Distortion Field anche sul comune uomo di strada che ne parla senza sapere cosa sia

Posted by Antonio Troise
Tweet

iPhone 3G Lo scorsa settimana ho seguito, come molti, le vicende del iPhone 3G sbarcato finalmente, oltre che in Italia, in tutto il mondo! Devo dire di essere rimasto allibito da come, un semplice prodotto, possa creare un vero effetto valanga sui media. Quanti altri prodotti tecnologici hanno avuto un seguito mediatico così rilevante?
La cosa più strana, tra tutte, è stato sentire, ad ogni giornale radio che mi capitava di ascoltare mentre ero in macchina, delle avventure delle persone in fila per acquistare l’iPhone, sia in Italia che in Giappone. Oppure quando al telegiornale, intervistando i commercianti sul pessimo andamento dei saldi di fine stagione, uno di questi asseriva che:

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

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

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

Le mie testimonianze

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

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

Reality Distortion Field dell’iPhone

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

Gli eventi della follia iPhone

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

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

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

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

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

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

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

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

Tag:Apple, cellulare, giornali, iPhone, iphone-3g, iPod, ipod-touch, itunes, Mobile, rai, steve-jobs, Tecnologia, Wordpress
CONTINUE READING >
8 comments
Lug 9 2008

WordPress Plugin: Filter Badwords Comment

Posted by Antonio Troise
Tweet

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.

Badwords - Screenshot 1

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.

Badwords - Screenshot 2

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.

Badwords - Screenshot 3
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[ITALIANO]

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

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

English[ENGLISH]

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

  1. Download the plugin, unzip and upload in the directory of plugin of WordPress (wp-content/plugins/).
  2. Rename badwords_IT.txt or badwords_EN.txt in default DB file: badwords.txt
  3. Activate “Filter Badwords Comment” plugin from Manage Plugin in the Administration Area of WordPress
  4. Configuration: Options » Filter Bad Words Comment.
download Download filter_badwords_comment.zip 1.0.2
Size: 6.6 KB
Tag:Blog, censura, commenti, database, dizionario, download, Mysql, Php, Plugin, Wordpress
CONTINUE READING >
14 comments
Lug 2 2008

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

Posted by Antonio Troise
Tweet

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

Google AJAX Libraries API

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!

Prototype self hostes

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.

Tag:adsense, Ajax, api, backup, banda, bandwidth, blooweb, compressione, ftp, Google, google translator, Javascript, Php, Plugin, prototype, Wordpress
CONTINUE READING >
17 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
Tweet

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

iPhone Site Specs

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.

iPhone Site Specs

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
CONTINUE READING >
1 comment
Apr 8 2008

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

Posted by Antonio Troise
Tweet

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.

Wordpress Content-Encoding Gzip
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).

Tag:Ajax, banda, bandwidth, browser, compressione, cpanel, gzip, Javascript, Php, prototype, Web 2.0, Wordpress, wordpress 2.5
CONTINUE READING >
12 comments
Apr 4 2008

Eccomi di nuovo online: nuovo server, PHP 5 e WordPress 2.5

Posted by Antonio Troise
Tweet

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.

Tag:errori, Mysql, Php, Wordpress
CONTINUE READING >
6 comments
Gen 24 2008

WordPress Plugin: Respond to Author’s Comment

Posted by Antonio Troise
Tweet

Wordpress Plugin 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: “.

Wordpress Plugin: Respond to Author

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
  1. Scaricare il pacchetto, decomprimerlo e caricarlo nella cartella dei plugin di WordPress (wp-content/plugins/).
  2. Attivare il plugin “Respond to Author’s Comment” da Gestione Plugin nel Pannello di Amministrazione
  3. 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[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

download Scarica respond_author_comment.zip 1.5.2
Dimensione: 1.27 KB

English[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:

  1. Download the plugin, unzip and upload in the directory of plugin of WordPress (wp-content/plugins/).
  2. Activate “Respond to Author’s Comment” plugin from Manage Plugin in the Administration Area of WordPress
  3. Insert the function di “respond_comment()” in the file comments.php of own theme:
download Download respond_author_comment.zip 1.5.2
Size: 1.27 KB
Tag:Plugin, Wordpress
CONTINUE READING >
65 comments
Gen 11 2008

Inviare messaggi su Twitter e Jaiku attraverso la barra di ricerca di Firefox grazie all’uso degli OpenSearch Plugin

Posted by Antonio Troise
Tweet

Oramai esistono decine di risorse su internet che permettono di postare su Twitter e Jaiku in differenti modi: installando estensioni per Firefox, eseguendo client per Windows, Linux e Mac OS X oppure usando le tante applicazioni web che permettono di automatizzare gli inserimenti come dei veri e propri bot che possono prelevare le informazioni da siti web i feed rss.
Quello che voglio spiegare oggi è come rendersi indipendenti dalla piattaforma che si usa, creando dei plugin di ricerca per Firefox (chiamati OpenSearch Plugin) modificati in maniera tale da essere usati per postare, direttamente dalla barra di ricerca di Firefox, le vostre idee su Twitter e Jaiku. Nulla vieta, ovviamente di poter adattare questi script per qualsiasi altro sito web che disponga, condizione necessaria, un form che funzioni col metodo POST o GET!

OpenSearch Plugin: menu a tendina

Per iniziare a creare questi script, prenderò spunto da questo OpenSearch Plugin per poi mettere a disposizione il codice XML per creare i plugin desiderati.

I vantaggi

Il vantaggio di questo metodo è che non bisogna installare nulla sul proprio PC e non occorre registrarsi a nessun servizio web, visto che la barra di ricerca è presente di default di Firefox, che essendo multipiattaforma, è anche possibile ritrovarlo sul qualsiasi sistema operativo.

Il bello di questa soluzione è quello di poter sempre disporre di un form universale per qualsiasi servizio di microblogging e sempre in primo piano, qualunque sia la pagina web che state visitando.

Inoltre, sfruttando la funzionalità di questo browser, è possibile addirittura, postare in uno dei due servizi di microblogging, il testo selezionato di una pagina web, senza dover necessariamente prima copiarlo e poi incollarlo.

Per ultimo, il fatto di poter padroneggiare il codice sorgente (che altro non è che semplice XML) è un vantaggio indiscutibile a favore della sicurezza dei proprio dati personali.

L’unica nota di attenzione è che, perché i plugin di ricerca funzionino correttamente, occorre già essersi loggati almeno una volta sui rispettivi siti web di Twitter o Jaiku, ma non credo che questo costituisca un problema se siete assidui frequentatori di queste realtà web 2.0.

Tag:browser, firefox, jaiku, search-plugin, twitter, Web 2.0, Wordpress, Xml
CONTINUE READING >
0 comments
Gen 9 2008

Come visualizzare un maggior numero di Bozze su WordPress

Posted by Antonio Troise
Tweet

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:

Wordpress Manage Posts

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:

http://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.

Tag:Php, Plugin, Wordpress
CONTINUE READING >
2 comments
Gen 5 2008

Dove scaricare i framework Prototype compressi per WordPress per risparmiare banda e velocizzare il caricamento delle pagine

Posted by Antonio Troise
Tweet

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.

Prototype Ajax

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.

Tag:Ajax, bandwidth, Javascript, prototype, Wordpress
CONTINUE READING >
3 comments
SeguiPrezzi - Risparmia con Amazon.it

Categorie

Commenti Recenti

  • Antonio Troise on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Fioredicollina on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Antonio Troise on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Emanuele on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Luca on iDatabase: la valida alternativa di Bento per macOS e iOS per i database personali
PREV 1 2 3 … 8 NEXT

Meta

  • Accedi
  • Entries RSS
  • Comments RSS
  • WordPress.org

Friends Link

  • GamerTagMatch
  • SeguiPrezzi.it – Risparmia con Amazon.it
  • Trendy Nail

Seguimi su:

  • facebook
  • twitter
  • rss
Creative Commons License
Levysoft by Antonio Troise is licensed under a Creative Commons Attribuzione-Non commerciale 2.5 Italia License.
© Copyright 2004 - 2014 - Levysoft by Antonio Troise