phpmyadmin | Rev0lut1on 2.0 of my mind engine

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

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

	Scarica wp-includes-WP-2.6.5.zip
	Dimensione: 13.5 KB

Tag:database, Mysql, Php, phpmyadmin, query, revisione, Wordpress

5 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

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.

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:

define(‘WP_POST_REVISIONS’, false);

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):

DELETE FROM wp_posts WHERE post_type = ‘revision’;

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:

SELECT * FROM wp_posts WHERE post_type = ‘revision’

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:

define(‘AUTOSAVE_INTERVAL’, 60);

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

17 comments

Lug 6 2007

Risolvere il problema della visualizzazione errata dei caratteri accentati su WordPress cambiando il charset da ISO-8859 a UTF-8

Posted by Antonio Troise

Il problema della codifica UTF-8 del testo presente nel database WordPress mi ha sempre assillato. In tutti i cambi hosting che ho fatto (tre in tutto) ho sempre riscontrato difficoltà con la visualizzazione dei caratteri accentati, tanto da doverli modificare a mano (o con dei search/replace sull’export del DB).
Il problema si presenta sopratutto nei cambi di hosting da sistemi Windows a quelli *unix (infatti, per esempio, Tophost usa server Windows mentre ~~UpsHost~~ BlooWeb usa server Linux), dove è necessaria la conversione del charset di WordPress da ISO-8859 a UTF-8 per visualizzare correttamente i caratteri accentati.
Ebbene, finalmente qualcuno ha trovato la soluzione e non posso quindi esimermi dal suggerirla anche a voi.

Per automatizzare la conversione, è sufficiente scaricare lo script PHP di Markus Tacker e seguire i seguenti passi:

Fare il backup del vostro database con il comando mysqldump –opt DB_NAME oppure utilizzando phpMyAdmin
Copiate lo script nella cartella wp-content del vostro blog (ad esempio: http://vostrosito.com/blog/wp-content/convert-encoding.php )
Accedete via browser allo script

Ecco alcuni suggerimenti di Davide, utili allo scopo:

per far funzionare lo script bisogna innanzitutto eliminare la riga die(’Please follow the instructions in ‘ . $_SERVER[’PHP_SELF’]);, rimuovendo la quale si accetta automaticamente la licenza ad inizio script (nel quale sostanzialmente l’autore si solleva da ogni responsabilità per eventuali danni al vostro database)
per convertire il set di caratteri, lo script va eseguito solo una volta, e subito dopo cancellato (per sicurezza)
se dopo la conversione (tramite la funzione mb_convert_encoding) compaiono nei titoli carattere non-ascii non validi come “fÃƒÂ¼r” (cosa che nei titoli dei feed incontro molto spesso, purtroppo) allora bisogna modificare una riga dello script scrivendo $decode = true; anziché $decode = false; e poi lanciare di nuovo lo script, poiché nel database ci sono dei caratteri utf-8 che vanno decodificati (tramite la funzione utf8_decode), e non convertiti.
lo script modifica sia la collation del database che i valori interni allo stesso
alla fine, viene visualizzato il seguente messaggio
Remember to remove this script!
giusto per non fare pasticci (che il backup potrebbe sempre sistemare)

Peccato che tempo fa, bonificai quasi tutti i post del DB con un metodo di ricerca e sostituzione iterativo; procedura un po’ più lunga di questa ma pure sempre funzionale.

Tag:backup, charset, db, font, Mysql, mysqldump, Php, phpmyadmin, set_di_caratteri, utf-8, Wordpress

11 comments

Feb 2 2005

Oops, ho dimenticato la password di Admin di WordPress

Posted by Antonio Troise

Dimenticare la password Può capitare che, per qualche grave disattenzione, ci si dimentichi della password di amministrazione di un sito come WordPress, PhpNuke, PostNuke e non si riesca più ad entrare. Se queste applicazioni hanno un sistema di recovery della password attraverso l’invio di una email allora siamo fortunati, ma spesso questa funzione viene disabilitata per l’utente ‘admin’.
A questo punto occorre hackerare il sistema in un modo molto semplice.