Come direbbe Barney Stinson, la prima regola del buon backup è “Prova il tuo backup!”. In altre parole, non saprai mai quanto è buono il tuo backup se non provi a farci un ripristino.

Qualche tempo fa ho iniziato a installare sui siti basati su WordPress il plugin wp-dbmanager: rispetto ai classici plugin che si occupano del backup di mySql, questo offriva una serie di optional interessanti (ad esempio l’ottimizzazione programmata del database e la possibilità di eseguire query). Cosa potrà mai andare storto nel fare un banale dump di un database?

Oggi dovevo provare delle modifiche sul tema di un sito, per cui ho recuperato dalla mail l’ultimo backup e ho cercato di ripristinarlo in locale:

Tentativo #1: ripristina da phpMyAdmin, lettere accentate a ramengo.
Tentativo #2: prova ad aprire il file .sql in TextMate, il programma si addormenta sistematicamente dopo poche righe (e TextMate non rientra certo nella categoria dei software instabili). Con “nano” o “tail” si riesce ad aprire il file, a quanto pare crea delle righe interminabili di testo.
Tentativo #3: prova l’importazione da riga di comando forzando il charset UTF-8, lettere accentate sempre a ramengo.
Tentativo #4: cerca sul forum di supporto del plugin o su Google, apparentemente nessuno ha questo problema. Il fatto che questo si verifichi con backup provenienti da Aruba, DreamHost e da un server dedicato mi fa pensare che il problema non sia dalla mia parte.
Tentativo #5: butta via il plugin e installa wp-db-backup, tutto liscio al primo colpo (e nessun problema aprendo il file con TextMate).

Morale della favola: verificate sempre i vostri backup.

Visto che negli ultimi due mesi ho perso svariate ore su queste cose, qualche appunto in ordine sparso (che l’età avanza).

Se siete su DreamHost, il sistema di backup di database e siti funziona molto bene (ancora una volta, parlo per esperienza diretta). Questo non vuol dire che non dobbiate garantire l’incolumità dei vostri dati con soluzioni di backup alternative. Ad esempio potete crearvi dei batch shell ed eseguirli tramite il pannello di controllo (sezione Goodies) o crontab. La sintassi per fare il backup di un database è

mysqldump NOME_DATABASE > dumpdatabase.sql -u UTENTE -h HOST -pPASSWORD
La sintassi per il ripristino

mysql -u UTENTE -h HOST -pPASSWORD NOME_DATABASE < dumpdatabase.sql
Se dovete utilizzare in locale il backup del database di un sito, un modo rapido per correggere i riferimenti può essere questo (non è probabilmente la soluzione più sicura o elegante, ma funziona).

cat dumpdatabase.sql | sed 's|www.esempio.it|localhost/esempio|g' > dumpdatabase_locale.sql
Nello specifico tutte le occorrenze di “www.esempio.it” nel file dumpdatabase.sql vengono sostituite con “localhost/esempio” e salvate in dumpdatabase_locale.sql, risolvendo il problema dei parametri in wp_options ma anche di eventuali link all’interno dei post.

 

Tag Technorati: backup, wordpress

L’antichissima regola del blogger: non si può essere contemporaneamente intelligenti, soddisfatti e su Splinder, al massimo due cose alla volta. Riconosciuta questa verità, molti splinderiani negli anni hanno aperto un blog su WordPress (su un loro spazio web o su wordpress.com), e tutti si sono scontrati con lo stesso problema: come faccio a importare qui i vecchi post? C’è stato Spleender ma non c’è più, c’è stato il plugin di Terenzani ma non va più neanche quello. Al momento il modo più semplice per recuperare post, commenti e categorie consiste nell’aprire un blog su IoBloggo.com, importare da Splinder su IoBloggo, esportare da IoBloggo in formato CSV, importare il CSV in WordPress con un apposito (e vecchio) plugin che vi costringerà ad utilizzare WordPress 2.1, infine aggiornare WordPress all’ultima versione (e se avete saggiamente lavorato in locale, anche esportare e reimportare in remoto). Se non vi sembra abbastanza difficile, sappiate che per motivi troppo lunghi da spiegare vi toccherà suddividere l’esportazione CSV in blocchi più piccoli, tipo da un anno o due, e per farlo dovrete cancellare a mano da IoBloggo i post degli anni che non vi servono, poi esportare, poi reimportare tutto, poi passare al blocco successivo, eccetera. E che importando da Splinder vi ritroverete tag e commenti html dimmerda sparsi nei titoli e nei post che dovrete poi togliere a manina dal database di WP.

Io l’ho fatto. Non fatelo. Funziona ma è una fatica inumana se avete un blog longevo (il mio ha sette anni e io sono invecchiato di altrettanti nel tentativo). La buona notizia, comunque, è che ho fatto io un plugin. Un plugin di WordPress che permette di importare post, commenti, autori e categorie dal vostro sfigatissimo blog su Splinder. E visto che c’ero, ho anche modificato leggermente quello per importare da IoBloggo, che ora funziona anche con WordPress 3, nel caso qualche scriteriato ne avesse bisogno. Download e fondamentali istruzioni per l’uso nell’apposita pagina.

With version 3.0 of WordPress, the much anticipated feature of Child Themes was integrated or some might say it was improved, since it was actually possible to use it. I like to show you an example based on the new default Theme TwentyTen how you use it. Another example can be found in my WP Basis-Theme (SVN); currently not HTML 5 version.

The function of the Child Themes can be applied basically in every theme and the new features facilitate access and creation of a Child Themes. Before there were also possibilities to change a Theme without changing the actual files of the theme. With the support of Child Themes this is now completely independent and we can use a theme that can be updated without a problem, and you can still realize your own ideas.

Other blogs already mentioned Child Themes but I've found so far only posts where they just talking about the activation and modification of the style sheet. Therefore, I would like to comment this subject only briefly, which is quite simple and then show the different possibilities in terms of template files.

Advantages of Child Theme
More or less every administrator is trying to create an individual design for his WordPress system. This does not require to create a special theme from scratch. Very often, a free or commercial Theme is used and then adapted to your needs. Many Themes have different options but are not sufficient for customizing. If you want to adjust the individual design, such as the layout of a category, that requires some changes of the theme. No matter how extensive, an update of a Theme is no longer feasible without problems. Here the Child Themes come into consideration.

With a Child Theme, a Theme can be adjusted or you can use a Theme as a "Framework" and implement completely your own ideas. No matter how extensive, the real Theme remains intact and can undergo an update.

Disadvantages of Child Theme
Often "Framework" Themes are very comprehensive and with many features, sometimes it has a steep learning curve and customizing can cost a lot of effort and time. Even though with Child Themes.
A major disadvantage is also the performance, because WordPress have to look into two areas according to the template and get the according files.
Furthermore style sheets, if you build on them, are usually implemented via @-rule, which has disadvantages in performance.

In all the negative points, it depends on skill and knowledge of the developer and how the Theme or Child Theme is created. Thus you can weaken the negative arguments I pointed out. Important: The new function should be carefully considered before using it. But with Child Themes you don't have to touch the basic Theme and yet you can make adjustments easily.

Create Child Theme
Enough said, let's start with the example based on the Theme TwentyTen and create an adjusted Theme - I will call it TwentyTenJump

In the first step, a new folder is created in which we put all the template files, images, scripts and style sheets - what is principally needed for the Child Theme. In this example, the folder is twentytenjump. To create a Child Theme and make this apparent to WordPress, you simply need style.css within the new folder with several strings in a comment.

Within style.css it looks like this.

@charset "UTF-8";

/**
* Theme Name: TwentyTenJump
* Theme URI: http://bueltge.de/?p=1192
* Description: Child theme for the Twenty Ten theme. Realized for a small tutorial to child themes in WordPress.
* Author: Frank Bültge
* Author URI: http://bueltge.de/
* Template: twentyten
* Version: 0.1.0
*/

@import url('../twentyten/style.css');

Important are the key Theme Name and Template. The key Template points to the folder name of the Theme, which is considered as a basis - in that instance, the Theme Twentyten.

I now have the following structure within the installation of WordPress.

wp-content

themes

twentyten
(Basic Theme, including all template files)

style.css
index.php
...

twentytenjump

style.css (must satisfy these name convention: style.css)

Thus, the first requirements are in place and you can select the new Theme in the backend of WordPress.
Note: the reference to the Basic Theme is not very conspicuous, so that you might forget the dependency. So that's why you should always check before you delete a Theme. On the used Theme, there is no indication that a different Theme as a Child Theme is using this Theme.

Working on the style sheet
From now you can put any changes in your style sheet. Also, of course, you can remove the call to the style sheet @import url('../twentyten/style.css'); from the Basic Theme and you can build your own style sheet completely.

You use the template files, the structure and PHP know-how of the Basic Theme, in which case is Twenty Ten. You deal exclusively with the design. For example, this could be the simplest case, a change in color of the background and alternatively a completely separate design will be created.

Replace templates
The functionality of the Child Theme includes more than just changing the appearance. You can replace existing template files of the Basic Themes. WordPress looks first in the Child Theme and then in the Basic Theme for possible templates. WordPress runs through the hierarchy of template files.

At many points in your Theme you can intervene via Hook, which might be not very easy and complicated for some users. Thus not infrequently the output of title in head of a web site will be replaced with own functions or Plugins. You can either edit the title via Hook or control the output of a function. For example, the title should now be displayed with a function of a Plugin. In that case you have to adjust the header.php and so you must proceed as follows, so that the Basic Theme remains intact.

You only have to copy header.php, which is containing the head section of the Theme, into your own Child Theme and here it can be edited as you like. From now on WordPress pulls header.php and not the original file from the basic theme Twenty Ten.

Now you can integrate the mentioned function into the title, an example:

<title><?php
/*
* Print the <title> tag based on what is being viewed.
* We filter the output of wp_title() a bit -- see
* twentyten_filter_wp_title() in functions.php.
*/
if ( function_exists('seo_title_tag') )
seo_title_tag();
else
wp_title( '|', true, 'right' );

?></title>

The Basic Theme remains untouched, it can still be kept up to date via updates and from now on WordPress uses the header.php always of the Child Theme.

Like this small example you can replace any template and adapt to your own requirements. Nevertheless, you should bear in mind that you replace the template completely - in the example, we would not notice an update of header.php. So it may be helpful to use Hooks in various areas and have their own functions, more about this later.

Important: an exception is functions.php, I will talk more about it later.

Expand Templates
In order to meet your own requirements, it may be that you need new templates, template files didn't exist in the Basic Theme. For the purposes of the hierarchy you can extended forever. For example, Twenty Ten does not have home.php - you can simply place this file in your Child Theme and WordPress will use this file, if the state is_home() is true.

Using WordPress 3.0 there is another option outside of the template hierarchy to use your own templates - get_template_part().

This function is used consistently within Twenty Ten - so you don't have to create own templates for the complete call, but only for the section of the Loop.
For example, Twenty Ten uses for displaying the category archives the call get_template_part( 'loop', 'category' );. Thus it is possible to put a template in our Child Theme, which uses this loop. So it's only necessary to create a file loop-category.php and then save all necessary informations.

In the following example, I adjust the loop, if you are in one of the four categories. Other changes are possible, so you will have full control and flexibility.

if ( in_category( array(47, 37, 27, 45) ) ) {
query_posts( 'cat='.$cat.'&posts_per_page=-1&orderby=title&order=ASC' );
} else {
query_posts( 'cat='.$cat.'&posts_per_page=20&paged='.$paged );
}
while ( have_posts() ) : the_post(); ?>

Similarly, you might be able to customize the loop for index.php - Template file loop-index.php would be in the game.

Include Functions
Of course you can also bring in the Child Theme your own functions. If you put an own functions.php in your Child Theme, then it does not replace the functions.php of the Basic Theme!
The functions of the Basic Theme will always be used. You have to disable them via the Hook. The possibility is also explained in a documentation in the functions.php file.

add_action( 'after_setup_theme', 'my_child_theme_setup' );
function my_child_theme_setup() {
// We are providing our own filter for excerpt_length (or using the unfiltered value)
remove_filter( 'excerpt_length', 'twentyten_excerpt_length' );
...
}

Within the function my_child_theme_setup() you can disable the functions of the Basic Theme and bring in your own functions.

Other features belong into the functions.php of the Child Theme - the Basic Theme always remains untouched. In the following code example I disable the function of the Basic Theme Twenty Ten for the length of the excerpt, and load my own function twentytenjump_excerpt_length() and it includes a Widget.

<?php
function twentytenjump_setup() {

remove_filter( 'excerpt_length', 'twentyten_excerpt_length' );
add_filter( 'excerpt_length', 'twentytenjump_excerpt_length' );

add_action( 'widgets_init', 'register_limited_catagories_widget' );
}
add_action( 'after_setup_theme', 'twentytenjump_setup' );

function twentytenjump_excerpt_length( $length ) {
return 10;
}

class limited_catag[…]

Ciao mi chiamo Napolux e ho un problema. Ho diversi blog Wordpress sparsi in giro su diversi hosting. Purtroppo Wordpress è un cazzo di ciuccia-ram e aggiungere plugin (per quanto utili) non aiuta di certo la situazione.

Ogni tanto infatti capita che qualcuno dei miei blog sputi fuori un messaggio come questo:

Fatal error: Allowed memory size of 1234567890 bytes exhausted (tried to allocate 1234567890 bytes) in file.php on line 1234

La mia vita da allora è diventata un inferno: ho cominciato a bere, a programmare in Visual Basic e a passeggiare per le strade di notte in cerca di banchi di RAM abbandonati.

Grazie all’aiuto dell’associazione “utilizzatori di Wordpress anonimi” ne sono venuto fuori però: non voglio che succeda ad altri, quindi racconterò qui come ho risolto il mio problema.

Le soluzioni possono essere diverse, a seconda di quanto permissivo sia l’hosting utilizzato.

1a soluzionePotete aumentare la RAM massima utilizzabile da PHP modificando il file php.ini. Un buon valore può essere 64M, ma se non basta potete provare 128M

La riga da modificare è questa:

memory_limit = 64M

Riavviate apache et voilà, avrete tutta la RAM in più che desiderate.

2a soluzioneSe non avete accesso al file php.ini potreste tentare questa via: create (o modificate) il file .htaccess nella root del vostro blog e aggiungete questa riga:

php_value memory_limit 64M

3a soluzioneSe le due precedenti non funzionano provate questa: aggiungete nel file wp-config.php del vostro blog questa riga:

ini_set('memory_limit', '64M')

Se ini_set() non è disponibile (probabilmente perché limitata dal vostro hosting provider) provate ad aggiungere questa riga, sempre in wp-config.php

define('WP_MEMORY_LIMIT', '64M');

4a soluzioneLe precedenti soluzioni non funzionano? Cambiate hosting!!!

Wordpress, che piaccia o meno, è ormai una delle più note piattaforme di Content Management; nato come piattaforma di blogging, col tempo ha incontrato un sempre maggiore numero di estimatori che lo hanno usato e lo usano anche come sistema di gestione dei siti, anche grazie agli innumerevoli plugin che la comunità sviluppa in tal senso. Questo stesso blog è realizzato tramite il prodotto della Automattic, così come il mio blog personale e tutti quelli che ho creato da quando mi interesso di questo modo di pubblicare contenuti.

Molti, moltissimi blog creati con Wordpress usano Google Analytics per tenere traccia di quel che accade sulle pagine, ma non tutti lo sfruttano al meglio. Ecco perché ho pensato a un post riassuntivo con alcune indicazioni che ritengo utili.

Usate un plugin per GA
Sembra banale, ma spesso leggo di persone che incollano a mano il codice nel file footer.php del template. Questa operazione ha solo svantaggi: innanzitutto se cambiate il tema dovrete ricordarvi di rifare l’operazione. Se avete un tema che si auto aggiorna è ancora peggio, perché dovrete reincollare il codice di GA dopo ogni update. Inoltre il codice così posizionato viene eseguito sempre e comunque, ovvero viene eseguito anche quando siete voi a visitare il vostro sito (mentre è noto che si dovrebbe evitare di conteggiare le proprie visite).
La grande forza di Wordpress sono i plugin, estensioni dell’applicazione che si occupano di un aspetto specifico che solitamente non è incluso nel prodotto originale. Mi sento di consigliarvi due possibili plugin, sebbene ne esistano una moltitudine:

Google Analytics for Wordpress di Joost de Valk. Ha tutte le opzioni che ci si aspetta da un plugin serio per Google Analytics, ed inoltre è sviluppato da una persona che si è sempre distinta nella blogosfera per essere un esperto di SEO, Google Analytics e Wordpress (ha realizzato anche altri plugin). Un plus fondamentale è che può tenere traccia di Google Images come fosse un organico invece di un referrer, e quindi di tracciare anche le keyword inserite lì.
Google Analyticator di Ronald Heft. E’ quello che uso io, e tra le altre cose permette di includere righe aggiuntive di codice direttamente dall’interfaccia; utile quando si devono aggiungere funzioni al codice di monitoraggio.

Entrambi i plugin possono disabilitare con un solo click il tracciamento degli utenti loggati, cosicché i dati inviati ai server collettori di Google siano già “puliti” senza bisogno di filtri sull’IP o sul cookie.
Un altro plugin interessante è RSS link tagger, che aggiunge ai link presenti nel feed i parametri necessari ad essere tracciati come campagna (solo se non avete anche il plugin Feedburner Feedsmith)

Create un goal/obiettivo per i commenti
Non è detto che sia l’unico, ma indubbiamente un blog dovrebbe avere come obiettivo almeno quello di instaurare una discussione con i propri lettori, e di conseguenza Google Analytics dovrebbe tracciare il risultato ottenuto. Per fare questo ci sono due strade: la prima è quella di aggiungere un evento onSubmit alla form di invio dei commenti, che di solito si trova nel file comments.php, aggiungendo

onsubmit="javascript:pageTracker._trackPageview('/commenti/commentoinviato');"

L’obiettivo da configurare in GA avrà corrispondenza principale (ma anche esatta funziona all’uopo), nome Commento e valore 1.0, in questo modo:

L’altro modo è descritto da Liviu Taloi, un consulente ecommerce rumeno, ed è leggermente più complicato: si tratta di inserire una variabile all’interno dell’url che viene mostrato dopo aver postato un commento (oppure di scrivere un cookie per via di una funzione nuova di wordpress 2.7) e di modificare il GATC con delle condizioni in php che riscrivono il nome della pagina tracciata se è stato lasciato un commento.

Monitorate la ricerca interna
E’ una cosa fondamentale nei siti, lo è ancora di più per i blog: la ricerca interna è fonte di preziose informazioni sui contenuti che gli utenti richiedono e che - evidentemente - non sono facilmente reperibili. Per i blog aggiungiamo che per la conformazione cronologica inversa i post più vecchi sono sepolti nell’archivio e spesso anche a diversi click di distanza dalla pagina principale dell’archivio, e abbiamo compreso perfettamente quando sia importante capire cosa viene cercato tramite il motore di ricerca interno. Poiché non ha senso riscrivere un ottimo articolo, mi limito a segnalare il post di Simone Carletti, che dice tutto quel che va detto!

Analizzate le pagine 404
Alcuni temi hanno un file che si chiama 404.php, che serve a personalizzare la pagina che viene mostrata all’utente in caso di contenuto non trovato (codice di errore HTTP 404). Se il vostro tema non ha il file specifico, significa che l’errore 404 viene gestito come un caso particolare di pagina singola, ma se avete deciso di usare un plugin per iniettare il codice di GA, il mio consiglio è quello di crearne una. Non costa molta fatica, seguendo le istruzioni della guida ufficiale di Wordpress:
potete copiare la pagina 404.php presente nel tema di default e sperare di essere fortunati, oppure potete copiare il file index.php e rinominarlo 404.php, dopodiché cancellare tutta la parte relativa al loop dei post e inserire un messaggio di errore personalizzato. Il report relativo alle pagine non trovate si ottiene dal rapporto “contenuti per titolo” cercando “page not found”. Da lì sarà poi possibile effettuare segmentazioni e analisi mirate a capire da dove vengono le visite che finiscono in pagine di errore ed eventualmente a come rimediare.

Usate la riscrittura dei permalink e il dettaglio contenuto
Wordpress consente in maniera molto agevole di abilitare la riscrittura degli URL (url rewrite) dei link permanenti, tramite il menu Settings -> Permalinks. La struttura più usata è quella “day and name” che corrisponde ai parametri
/%year%/%monthnum%/%day%/%postname%/

ma nulla vi vieta di usarne una personalizzata. Con il permalink che ho indicato, ad esempio, gli archivi per anno e mese si trovano agli indirizzi www.dominio.it/2007 o www.dominio.it/2008/04 (aprile 2008). Tramite il report “dettaglio contenuto”, che vi ricordo raggruppa tutti gli url sotto una stessa cartella, sarà quindi molto facile confrontare le performance di tutti i contenuti sotto a cartelle anni o mesi differenti.
Lo stesso discorso può essere applicato alle categorie e ai tag, che vengono ugualmente riscritti nella forma www.dominio.it/categoria e www.dominio.it/tag e permettono di analizzare le performance globali di contenuti trasversali rispetto all’ordine temporale.

Post collegati:Usare Google Analytics sull’IphoneGoogle Analytics Social media metrics pluginfunzioni per usare le campagne senza i tag di google

A brevissimo uscirà la versione 2.7.1 di WordPress e ci sarà il primo aggiornamento automatico di massa.
Abbiamo già scritto molte cose su questo argomento.
Questo è lo screen cast, hostato su wordpress.tv, dove potete vedere il procedimento di aggiornamento automatico:

Per gli utenti Aruba Linux suggeriamo di apportare queste modifiche al wp-config.php :

define('FS_CHMOD_FILE',0755);
define('FS_CHMOD_DIR',0755);

Se invece non avete modificato il wp-config.php vi troverete un error 500, nessun panico entrate nel pannello di controllo del vostro dominio su aruba http://admin.tuodominio.quellocheè e ripristinate i permessi.

Articoli correlati

WordPress 2.8 versione beta (7)
Ancora su temi e aggregatori di temi (9)
phpDay 09 - Verona 15/16 maggio (5)
WordPress per iPhone 1.2 disponibile su App Store (2)
Temi infetti (34)

Questa informazione è molto importante per chi ha un blog wordpress installato su server aruba linux.

Aruba utilizza SuExec per gestire i permessi dei file e delle cartelle.

L’aggiornamento automatico provvedeva a cambiare i permessi dei file alla fine della procedura di aggiornamento mettendo permessi 0644 e cambiava i permessi delle cartelle a 0755, questo comportava il non funzionamento del blog dopo l’aggiornamento automatico.

Abbiamo discusso del problema con gli sviluppatori di wordpress e pochi minuti fa è stata trovata una soluzione tampone in attesa di una soluzione migliore che forse sarà rilasciata con la 2.7.1.

Dopo aver installato la 2.7 (dovrete seguire le solite procedure) dovete andare a modificare il file wp-config.php inserendo queste due righe:

define('FS_CHMOD_FILE',0755);
define('FS_CHMOD_DIR',0755);

Questa è la configurazione per Aruba ma, verificate se il vostro Hosting utilizza suexec e se lo utilizza chiedete quali sono i permessi corretti per file e dir e modificate di conseguenza le due linee che abbiamo pubblicato.

[Qui la discussione sul Trac]

Articoli correlati

Il Planet di WordPress in Italiano (4)
WordPress.tv (4)
Andy Peatling al WordCamp (4)
WordPress 2.8, dite la vostra (5)
WordPress 2.7.1 e 2.8 (12)

Proseguendo nella mia solitaria indagine sulle molteplici intrusioni in blog basati su Wordpress non aggiornati, ho esaminato, come ho già fatto qualche tempo addietro, gli effetti di un aggiornamento prima a Wordpress 2.6, poi alla versione 2.6.1, fresca di forgia.

Passando alla versione 2.6 l’unico indizio che ci sia qualcosa di poco pulito è il contatore degli amministratori nell’elenco degli utenti.

Come potete notare nella figura sopra, c’è un solo utente, amministratore, visualizzato nell’elenco, ma il conteggio ne riporta 2.

Disabilitando Javascript e ricaricando la pagina si svela l’arcano: appare immediatamente il secondo amministratore dal nome WordPress, nella colonna “Nome” mostra solo tre puntini. Esaminando il codice HTML della pagina si scopre lo script di “cloaking” dell’amministratore abusivo, di cui avevo già parlato.

Nessun altro indizio evidente mostra che il blog è compromesso ed in mano ad altri. L’unica possibilità è data da una accurata analisi di tutto quanto costituisce il blog stesso, database compreso, naturalmente sapendo dove e cosa cercare.

Aggiornando alla versione 2.6.1 le cose cambiano, ma non di molto. Solo la prima volta che si entra nella gestione dei plugin si ottiene il messaggio mostrato qui sotto:

Per me e per chi ha dimestichezza con Wordpress questi messaggi sono il chiaro indice che qualcosa non va, ma per la maggior parte dei tenutari di blog probabilmente non hanno molto significato. Il problema è che i messaggi appaiono solo la prima volta che si entra nel pannello di gestione plugin del blog dopo l’aggiornamento, per non comparire mai più.

Ai fini dello sradicamento dell’intrusione non si ottiene la pulizia completa. Occorre ancora intervenire a mano, e non è sufficiente cancellare l’amministratore abusivo ed i plugin fasulli. Nel blog c’è sicuramente ancora roba nascosta, file modificati, residui nel database. L’incursore ha potuto leggere le credenziali di accesso al database stesso, in chiaro nel file wp-config.php, ed ha molte frecce al suo arco:

i file camuffati, inseriti ovunque, potrebbero essere shell remote, capaci di modificare a piacere i file dell’installazione, aggiungerne altri, cancellarli, ecc.
i file del tema e dei plugin potrebbero essere stati modificati per eseguire pezzi di codice PHP a comando
I falsi plugin sono ancora presenti, se il webmaster non li ha cancellati
nel database c’è ancora una copia di riserva della remote shell, e la cache dei link di spam

I primi tre punti sono porte aperte alla “reinfezione” del blog, l’ultimo è semplicemente fatica in meno per l’incursore.

Ho trovato almeno tre blog in rete (sì i proprietari sono stati avvertiti) aggiornati alla versione 2.6 che non mostravano più il comportamento di forgiare la pagina a seconda del visitatore (utente normale o GoogleBot), ma avevano centinaia di link spam nascosti in fondo ai post nella home page. Ipotizzo, cosa da verificare ma verosimile, che il proprietario abbia aggiornato ignorando di essere vittima dell’intrusione, ed i file corrotti dall’intrusione siano stati sovrascritti, cosa che ha fatto perdere al mentecatto la possibilità di inserire link spam a piacere senza intervenire direttamente sul blog. Naturalmente, il nostro amico non si è perso d’animo: ha immediatamente approfittato del proprio account amministratore abusivo ed ha modificato i post in prima pagina inserendo i link spam all’interno di un blocco HTML con uno stile utile a nasconderli ai visitatori umani (ad esempio con style="display:none", oppure con style="overflow:hidden;width:0;height:0"). Oppure, anche dopo aver perso anche l’amministratore abusivo, scoperto e cancellato dal webmaster più attento, potrebbe essere in grado di accedere il database MySQL dall’esterno e modificare a mano i post per accodare i link spam. Lo può fare perché ha potuto leggere le credenziali di accesso al database, contenute in wp-config.php. Non dovrebbe essere possibile farlo dall’esterno, i servizi di hosting non dovrebbero permettere l’accesso al server database a chiunque. Se però nel blog vi sono ancora i file modificati dall’incursore per eseguire codice PHP a comando, come mostrato qui, per il mentecatto è un gioco da ragazzi inserire un paio di righe di PHP da eseguire al volo per modificare il record nel database relativo al post ed aggiungere i link spam.

Il risultato è che, pur dopo tutti gli aggiornamenti, se avevamo il blog infetto e non abbiamo usato le maniere forti, saremo daccapo in poco tempo. Nel frattempo, il mentecatto non sta con le mani in mano e molto probabilmente sta correndo ai ripari: a breve l’aggiornamento a Wordpress 2.6.x potrebbe non essere più efficace per scoprire l’intrusione.

L’unica cosa che, ironia della sorte, potrebbe alla fine porre fine all’abuso del nostro blog da parte del mentecatto è il crescente numero di servizi di indicizzazione e motori di ricerca che adottano politiche di esclusione del siti compromessi. Quando il nostro sito verrebbe escluso da tutti (Google, Technorati, FeedBurner, ecc.), il mentecatto non saprebbe più cosa farsene, e lo lascerebbe al suo destino. Certo, a quel punto il nostro blog sarebbe un rottame: invisibile da Internet, non più indicizzato dai principali motori di ricerca e aggregatori, saremmo come la voce che grida nel deserto. O peggio potrebbe essere venduto a qualche organizzazione dedita al phishing, a cui non importa il posizionamento del sito nei motori di ricerca.

Uscire da quello stato di limbo non è molto facile, e molto tempo occorre per recuperare credibilità agli occhi degli innumerevoli siti di indicizzazione. E’ meglio intervenire prima possibile.