Levysoft
  • Home
  • Portfolio
  • WordPress Plugin
  • Contattami

Dal 2004 il blog di Antonio Troise

RSS FeedTwitterFacebook
Nov 27 2008

WordPress e il Fatal error in Text/Diff.php: patch aggiornata alla release 2.6.5 di WordPress e il mistero delle revisioni che non si disattivano completamente

Posted by Antonio Troise
Tweet

Stavo aggiornando un vecchio articolo pubblicato qualche mese fa quando, al momento del salvataggio del post, mi si presenta una schermata con questo messaggio di errore:

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

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

Descrizione del problema

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

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

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

La soluzione del problema

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

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

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

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

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

Siccome i file modificati dal pacchetto sono:

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

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

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

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

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

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

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

Il mistero delle revisioni che non si disattivano completamente

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

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

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

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

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

Invece, lanciando la seguente query SQL da PhpMyAdmin:

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

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

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

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

Download Patch Fatal error in Text/Diff.php aggiornato a WordPress 2.6.5
download Scarica wp-includes-WP-2.6.5.zip
Dimensione: 13.5 KB
Tag:database, Mysql, Php, phpmyadmin, query, revisione, Wordpress
CONTINUE READING >
5 comments
Ott 28 2008

Le collisioni dell’HASH MD5: quando sono state create due firme digitali identiche. Ci sono pericoli per l’autenticazione e la verifica di originalità dei documenti?

Posted by Antonio Troise
Tweet

Su internet molto spesso veniamo a contatto con gli HASH MD5 senza neanche accorgersene. Nell’ambito informatico, la crittografia tramite algoritmo MD5 viene applicata in tutti i settori dell’informatica che lavorano con il supporto delle firme digitali o che comunque trattano dati sensibili, per cui una delle funzionalità più usate è quella di verifica di originalità di un documento, di una foto o di un file eseguibile, attraverso il rilascio di una firma digitale.

Ad esempio, la funzione di HASH come l’MD5:

  • viene utilizzata per controllare che uno scambio di dati sia avvenuto senza perdite, semplicemente attraverso il confronto della stringa prodotta dal file inviato con quella prodotta dal file ricevuto;
  • con lo stesso metodo si può verificare se il contenuto di un file è cambiato (funzione utilizzata dai motori di ricerca per capire se una pagina deve essere nuovamente indicizzata);
  • addirittura, anche nell’ambito P2P è molto usato per identificare univocamente i file che possono assumere anche nomi diversi.
  • Per finire è anche molto diffuso come supporto per l’autenticazione degli utenti attraverso i linguaggi di scripting Web server-side (PHP in particolare): durante la registrazione di un utente su un portale internet, la password scelta durante il processo verrà codificata tramite MD5 e la sua firma digitale verrà memorizzata nel database (o in unfile di dati). Successivamente, durante il login la password immessa dall’utente subirà lo stesso trattamento e verrà confrontata con la copia in possesso del server, per avere la certezza dell’autenticità del login.
Che cosa è la funzione di HASH?

Ma cosa è l’hash di un documento? Su Wikipedia, leggiamo che l’hash è una funzione univoca operante in un solo senso (ossia, che non può essere invertita), atta alla trasformazione di un testo di lunghezza arbitraria in una stringa di lunghezza fissa, relativamente limitata. In poche parole, l’hash altro non è che una particolare trasformazione matematica che, applicata al documento da firmare, ne genera la cosiddetta impronta, ovvero un “riassunto” costituito da un numero assai ridotto (e costante) di bit, che rappresenta univocamente il documento di partenza.
Tale riassunto, o più propriamente stringa, rappresenta una sorta di “impronta digitale” del testo in chiaro, e viene anche chiamata valore di hash, checksum crittografico o message digest.

La lunghezza dei valori di hash varia a seconda degli algoritmi utilizzati. Il valore più comunemente adottato è di 128 bit (MD5), che offre una buona affidabilità in uno spazio relativamente ridotto.

Quindi, come si è potuto capire, la forza di questo sistema consiste in 3 importanti fattori:

  • L’algoritmo restituisce una stringa fissa di un numero di bit fisso, a prescindere dalla mole di bit elaborati
  • L’algoritmo non è invertibile, ossia non è possibile ricostruire il documento originale a partire dalla stringa che viene restituita in output.
  • La stringa è, teoricamente, univoca per ogni documento e ne è un identificatore (ovvero è priva di collisioni)

Come è intuibile, il fatto che non sia possibile ricavare il documento da cui deriva una hash e il fatto che non sia teoricamente possibile che documenti diversi producano la medesima impronta (quindi che la firma sia “non invertibile” e “priva di collisioni”), rende la funzione di hash, a ragione, una candidato ideale per essere uno strumento essenziale che ha piena validità legale!

Le collisioni delle funzioni di hash

Il problema, però, sorge proprio sull’ultima caratteristica, forse la più importante, ovvero quella in cui l’hash è solo teoricamente univoco, mentre, come è facilmente intuibile, non lo è affatto. Infatti dato che i testi possibili, con dimensione finita maggiore dell’hash, sono più degli hash possibili, per il Principio dei cassetti (se n oggetti sono messi in m cassetti, e n > m, allora almeno un cassetto deve contenere più di un oggetto) ad almeno un hash corrisponderanno più testi possibili.
Quando due testi producono lo stesso hash, si parla di collisione, e la qualità di una funzione di hash è misurata direttamente in base alla difficoltà nell’individuare due testi che generino una collisione.

Tuttavia, ciò non deve trarre in inganno! Infatti scegliendo adeguatamente un algoritmo in modo che il numero di possibili impronte sia estremamente elevato, e dunque la probabilità di una collisione, voluta o casuale, sia ridotta tanto da diventare del tutto trascurabile., allora si può benissimo affermare che queste auspicate “impossibilità”, se intese in senso pratico e non teorico, siano praticamente reali.

Pensate che, con un’impronta di 160 bit, la funzione di hash è in grado di discriminare fra 2160 documenti, che equivale ad un numero con un 1 seguito da 48 zeri!

Naturalmente però non basta che la funzione produca un valore di questa lunghezza, occorre anche che essa effettivamente generi valori diversissimi tra loro al variare del documento in ingresso, e soprattutto che tali valori non siano “facilmente” riconducibili al documento di partenza. In pratica la funzione deve essere tale da far risultare “praticamente impossibile” sia creare ad arte un documento che produca proprio un determinato hash noto a priori, sia creare ad arte due documenti diversi che producano lo stesso hash (collisione). Se così non fosse, le conseguenze sarebbero davvero molto gravi.

Se infatti fosse possibile trovare facilmente collisioni nella funzione hash utilizzata in un dato sistema di firma digitale, allora un malintenzionato potrebbe “falsificare” un documento mantenendone apparentemente valida la firma, e per di più questa truffa non sarebbe rivelabile né tantomeno dimostrabile. Inutile dire che ciò, ovviamente, minerebbe alla base tutto il meccanismo della firma digitale.

Quando sono state create due firme MD5 uguali da documenti diversi

Per scongiurare questo rischio, le funzioni hash solitamente utilizzate nella pratica sono accuratamente progettate e controllate affinché risultino quanto più possibile prive di collisioni. Il che non significa che non ne possano produrre in assoluto: ma solo che la probabilità che ciò avvenga per caso sia infinitesimale, e che inoltre risulti estremamente difficile produrre collisioni in modo intenzionale.

Per sconsigliare l’utilizzo di algoritmi di hashing in passato considerati sicuri è stato infatti sufficiente che un singolo gruppo di ricercatori riuscisse a generare una collisione. Questo è quello che è avvenuto ad esempio per gli algoritmi SNEFRU, MD2, MD4 ed MD5.

Dal punto di vista tecnico/legale una collisione del MD5 è davvero preoccupante perché il codice MD5 calcolato si fa portatore dell’integrità e correttezza della copia svolta su una memoria di massa e quindi se possono esistere due memorie dotate di contenuti diversi con lo stesso codice MD5 questo vorrebbe dire che la funzione non può dare alcuna assicurazione sulla certezza di non modificazione dei dati dopo il repertamento.

Dalla letteratura specifica è ben noto che MD5 è stato portato alla collisione ufficialmente nel 2005 da Xiaoyun Wang e Hongbo Yu della Shandong University cinese. Essi precisamente trovarono due sequenze diverse (ma molto simili) di 128 byte con lo stesso valore di MD5 associato:

d131dd02c5e6eec4693d9a0698aff95c 2fcab58712467eab4004583eb8fb7f89
55ad340609f4b30283e488832571415a 085125e8f7cdc99fd91dbdf280373c5b
d8823e3156348f5bae6dacd436c919c6 dd53e2b487da03fd02396306d248cda0
e99f33420f577ee8ce54b67080a80d1e c69821bcb6a8839396f9652b6ff72a70

e

d131dd02c5e6eec4693d9a0698aff95c 2fcab50712467eab4004583eb8fb7f89 55ad340609f4b30283e4888325f1415a 085125e8f7cdc99fd91dbd7280373c5b d8823e3156348f5bae6dacd436c919c6 dd53e23487da03fd02396306d248cda0 e99f33420f577ee8ce54b67080280d1e c69821bcb6a8839396f965ab6ff72a70

il cui comune valore di hash MD5 è 79054025255fb1a26e4bc422aef54eb4.

Se volete verificare voi stessi, potete calcolare l’MD5 di questa sequenza esadecimale con l’Online Hash Value Calculator (inserendo i valori nel campo di Hex bytes) o con un tool per Windows come HashOnClick.

Quello che il team di ricerca riuscì a dimostrare è di possedere un metodo generale per generare facilmente collisioni in alcune fra le più note e diffuse funzioni hash, in particolare quelle denominate MD5.

In realtà la funzione MD5 era già da tempo sul banco degli imputati: infatti già da diversi anni altri ricercatori avevano pubblicato dei lavori di analisi teorica che gettavano seri dubbi sull’affidabilità di tali funzioni, pur senza dimostrare in modo certo la loro effettiva debolezza. Inoltre la scarsa lunghezza dell’impronta da esse generata (128 bit per entrambe) era già da parecchio tempo giudicata insufficiente a prevenire efficacemente quegli attacchi “a forza bruta” resi ormai possibili dalle enormi potenze di calcolo dei moderni computer. Il team cinese, dunque, non ha fatto altro che produrre una prova pratica ed incontrovertibile di quanto già si sospettava, peraltro senza fornire alcuna descrizione del metodo di attacco da essi sviluppato.

A seguito di questa scoperta sono state individuate metodologie per creare file ed eseguibili di lunghezza arbitraria che hanno lo stesso MD5 ma possono differire al massimo per 128 byte. Alcuni esempi sono disponibili in rete:

  • Sono stati creati due file .ps (PostScript) (file1, file2) con lo stesso valore di MD5 ma contenuti piuttosto diversi (rif. http://www.cits.rub.de/MD5Collisions/);
  • E’ stato realizzato un metodo mediante il quale è possibile costruire due programmi (es. prog1, prog2) con funzionalità molto diverse ma aventi lo stesso valore di hash MD5
    (rif. http://www.codeproject.com/dotnet/HackingMd5.asp).
La firma digitale è a rischio?

La funzione MD5, pur essendo da anni uno standard Internet (RFC1321) era già da tempo “sconsigliata”; essa dunque, benché ancora largamente diffusa ed utilizzata in molti ambiti, non viene praticamente più impiegata in applicazioni realmente critiche, come quelle legali e forensi.

Tali evidenti collisioni hanno preoccupato i matematici e gli studiosi di crittografia ma scarsamente coloro che normalmente si affidano al MD5 per le loro attività pratiche quotidiane. Sulle debolezze (relative) di MD5 e SHA-1 (un altro algoritmo di hashing) erano infatti tutti consci (sebbene la citata scoperta abbia ufficializzato la criticità). Ma affermare MD5 non è affidabile per la certificazione delle copie di memorie di massa non è esatto perché il metodo di generazione delle collisioni messo a punto dai ricercatori cinesi non potrebbe comunque portare a truffe come quella delineata in precedenza: esso infatti non consente affatto di produrre un documento di senso compiuto avente un hash desiderato, che è ciò che serve per “falsificare” una firma. Al contrario, esso permette solo di generare simultaneamente una coppia di documenti “privi di senso” (ossia costituiti da sequenze caotiche di bit) e per di più assai simili tra loro (con soli pochi bit di differenza situati in posizioni critiche predeterminate), i quali producono sì un medesimo hash, ma che non può essere in alcun modo essere scelto a priori. Ciò conferma ancora una volta come la scoperta dei ricercatori cinesi, pur assumendo un grande valore sul piano della teoria, non abbia praticamente quasi alcuna rilevanza su quello della pratica.

In effetti né Wang, Kaminski, Yu e tutti gli altri che hanno contribuito al grande risultato delle collisioni di MD5 e SHA-1 non si sono mai sognati di scrivere nei loro documenti ufficiali che in generale questi algoritmi non sono affidabili. Essi hanno solo dimostrato che in determinate particolari condizioni la struttura matematica di MD5 (e di molte altre funzioni hash ad essa simili) è intrinsecamente debole, e di questo si deve tenere conto nella progettazione delle nuove e future funzioni hash.

Come scoprire una password codificata in MD5

Esistono vari modi per decifrare un codice MD5:

  • Cercare in database di codici MD5 già decodificati.
    MD5()
    passcracking
    gdataonline
    MD5OnlineCracking
    Milw0rm
  • Usare il software Cain scaricabile all’indirizzo http://www.oxid.it/cain.html . Per comprenderne il suo utilizzo vi rimando a questo video http://www.irongeek.com/i.php?page=videos/md5-password-cracking

    Potete trovare un generatore di collisioni MD5 scritto in C nella sezione download di http://nerd.altervista.org

Tag:checksum, collisioni, hack, hash, Matematica, md5, p2p, password, Php, probabilità, Software
CONTINUE READING >
7 comments
Lug 23 2008

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

Posted by Antonio Troise
Tweet

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

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

Caricamento dinamico degli articoli

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

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

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

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

Bug

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

In conclusione

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

Tag:Ajax, Blog, Css, Javascript, Php, Plugin, template, Web 2.0, Wordpress
CONTINUE READING >
14 comments
Lug 21 2008

Come disattivare la revisione dei post di WordPress 2.6, cancellare le righe inutili delle revisioni dalla tabella wp-posts e modificare l’intervallo di tempo per i salvataggi automatici dei post

Posted by Antonio Troise
Tweet

Per i blog monoautore, l’ultima interessante novità introdotta con la release 2.6 WordPress, la gestione delle revisioni dei post (Post Revisions Tracking) per tenere traccia delle modifiche di ogni articolo e pagina, risulta essere inutile. Infatti, con questa nuova funzionalità è possibile vedere le modifiche che avete apportato e quando, a qualsiasi news postata, il tutto attraverso un interfaccia semplice, con la possibilità di ripristinare la versione precedentemente salvata.

Revisioni Post

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

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

Come disattivare la gestione delle revisioni su WordPress 2.6

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

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

Analisi delle modifiche apportate al DB per inserire le revisioni

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

post_type= “revision”
e
post_status = “inherit”

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

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

Pulire il database dalle revisioni salvate sino a quel momento

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

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

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

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

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

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

Tag:backup, Blog, database, Mysql, Php, phpmyadmin, query, revisione, Wordpress
CONTINUE READING >
17 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 27 2008

Python può essere considerato il nuovo Basic?

Posted by Antonio Troise
Tweet

Non so voi, ma quando andavo alle scuole superiori, il primo linguaggio di programmazione che ho imparato seriamente, perché lo usavo spesso nei vari esercizi di Sistemi, è stato il Basic. A dire il vero avevo anche iniziato a programmare in Pascal, ma solitamente era usato solamente per imparare i concetti della programmazione, mentre quando dovevo interfacciare un mio programma con qualche progetto elettronico, il Basic era, all’epoca, lo strumento principe (abbinato alla compilazione con Qbasic 4.5). Alla mia professoressa piaceva spesso asserire che lei aveva deciso di farci programmare in Basic, piuttosto che con il potente C o con il complesso e strutturato Java, in quanto, per i nostri scopi didattici, era abbastanza potente e la sua sintassi poteva essere imparata molto velocemente. Se avessimo, invece, dovuto programmare in C, data la sua complessità intrinseca, avremmo dovuto perdere almeno 1 anno affinché tutti lo potessero padroneggiare. Quindi, la scelta, era ricaduta sul pratico e flessibile Basic, perché, dai tempi del Commodore 64, aveva dalla sua la semplicità di programmazione.

Vi ho narrato questi eventi perché recentemente ho letto un interessante articolo che si chiede se il Python potrai mai essere considerato, prima o poi, il degno sostituto del Basic soprattutto nelle scuole: Python is the new BASIC. Secondo l’autore del post è proprio questo giovane linguaggio di programmazione il candidato perfetto, poiché ha una curva di apprendimento gentile, una sintassi facilmente comprensibile e, fattore da non trascurare, la prima frase che ognuno di noi impara a programmare (HELLO WORLD) si scrive, proprio come in Basic, in una sola riga!
Dovete infatti sapere che questo esercizio è per molti il primo impatto alla programmazione, e più semplice risulta essere, e più facilmente ci si avvicina alla comprensione del linguaggio.

Infatti, se in C dovremmo scrivere:

in Java sarebbe:

mentre in Basic è sufficiente scrivere:

e in Python:

Ovviamente il Basic e il Python non sono gli unici linguaggi di programmazione a poter redirigere l’output con una sola riga di comando, ma tra tutti gli altri sono effettivamente tra quelli più potenti e al contempo semplici da imparare.

In realtà, però, Python è anche più potente del Basic, oltre che molto più moderno. Usato da anni da Google e dalla Nasa (e preinstallato in qualsiasi computer con Mac OS X), chi impara a programmare con Python, data la sua scalabilità, può benissimo iniziare semplicemente con un output/input testuale, per poi passare gradualmente ad una programmazione orientata agli oggetti (comunque più semplice e chiara di tanti altri linguaggi), fino ad arrivare ad integrare toolkit GUI come pyglet, pygame, wxPython (non è raro trovare libri che spiegano come programmare i giochi con Python, come “Invent Your Own Computer Games with Python”, distribuito con licenza Creative Commons, che spiega come realizzare giochi in grafica ASCII in meno di 400 righe)

L’autore del post, passa poi in rassegna tutti i più famosi linguaggi di programmazione, dal Visual Basic, PHP, Perl, a Java e Flash, scartandoli tutti per il ruolo di successore del BASIC. Si sofferma però su Ruby, un altro nuovo linguaggio, molto simile a Python e che potrebbe ricadere nella lista dei successori se non fosse che Python ha, almeno per ora, una comunità e una tale vastità di librerie da non essere paragonabile a quella per ora disponibile per Ruby.

Per terminare, vi lascio alla visione di questo simpatico video che mostra la storia del progetto open source Python, dal 1991 quando Guido Van Rossum rilasciò la prima versione del programma ad oggi, riassunto in pochi minuti.


code_swarm – Python from Michael Ogawa on Vimeo.

Il video è stato creato grazie al progetto code_swarm di Federated Media, un software che permette di visualizzare in video tutti i cambiamenti e le modifiche che un software Open Source subisce. Se siete curiosi potete dare una occhiata anche alla storia visuale del famoso webserver Apache.

Tag:basic, java, Javascript, pascal, Php, programmazione, Python, Ruby
CONTINUE READING >
3 comments
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 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
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
1 2 3 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