Levysoft
  • Home
  • Portfolio
  • WordPress Plugin
  • Contattami

Dal 2004 il blog di Antonio Troise

RSS FeedTwitterFacebook
Apr 22 2009

Oracle acquista Sun: che fine faranno MySQL, OpenOffice.org, VirtualBox e NetBeans? Speculazioni su tutti i possibili scenari futuri

Posted by Antonio Troise
Tweet

Ieri si è definitivamente concluso l’accordo tra Oracle e Sun Microsystems che vede l’azienda di acquisire di Larry Ellison, in una “operazione amichevole”, Sun per la cifra di 5,6 miliardi di dollari al netto del debito, che saliranno a 7,4 miliardi di dollari poiché la Oracle si è fatta carica dei debiti della Sun (9,50 dollari per azione).
Se è ancora prematuro parlare del rischio occupazione per i lavoratori coinvolti (Sun occupa 33 mila persone, Oracle 86 mila) quello che è subito lampante è che con questa operazione Oracle ne esce nettamente rafforzata nei confronti di IBM, soprattutto perché Oracle è riuscita laddove il gruppo rivale non è riuscito nei giorni scorsi: acquisire Sun Microsystem con una proposta di “soli” 6,5 miliardi di dollari.

Oracle-Sun
Che fine farà MySQL?

Ma i primi dubbi cominciano a serpeggiare per la rete e Michael “Monty” Widenius, principale creatore di MySQL, dell’azienda MySQL, in seguito rilevata da Sun Microsystems, dal suo blog ha commentato la nuova mossa di Oracle, parlando liberamente alla comunità Open Source di quello che secondo lui potrebbe accadere a MySQL.
Secondo quanto scrive M.M. Widenius le possibili evoluzioni di MySQL a questo punto potrebbero essere tre:

  1. MySQL verrà abbandonato
  2. MySQL verrà venduto
  3. Oracle investirà in MySQL trasferendovi tutta la propria esperienza con i database

Certamente, la soluzione ottimale sarebbe l’ultima anche se ad oggi ancora non sono state fornite rassicurazioni sul futuro di MySQL, se non fosse che questo progetto viene citato in un documento pubblicato da Oracle, in cui cerca di rispondere ai molti interrogativi suscitati subito dopo l’acquisizione di SUN e in cui, oltre a confermare i contratti già stipulati da Sun e l’assistenza a tutti i clienti, si afferma che MySQL andrà a inserirsi nella gamma di database insieme ad Oracle 11g, TimesTen, BerkeleyDb ed il motore transazionale InnoDB. Se da una parte questo documento rassicura, dall’altra viene il sospetto che l’affermazione possa essere alquanto vaga e non si sa con precisione in che modalità possa proseguire il progetto.

In effetti anche se Oracle ha un business complesso (in realtà neanche Sun era un player puro open source), non si intuisce perché non dovrebbe tentare di affiancare alla sua offerta proprietaria anche un servizio opensource, in considerazione del fatto che all’offerta opensource potrebbe aggiungere pacchetti proprietari specifici. Poi, come noto, MySQL da tempo si stava muovendo in direzione Enterprise, per cui un avvicinamento dei due settori potrebbe essere più facile di quello che si possa pensare.

E’ comunque vero che, nessuno può essere il padrone di un progetto Open Source, ma al massimo project leader (quanti fork di progetti open source sono nati per assecondare le diverse visioni degli sviluppatori). MySQL è nato e ha raggiunto la gloria senza Sun per cui è molto probabile che il progetto andrà comunque avanti a prescindere dalle decisioni di Oracle; ma “Monty” vuole comunque rassicurare la comunità Open Source accennando ad una possibile ripresa dei lavori su MySQL nel caso questo venga abbandonato da Oracle.

Gli scenari futuri

Ma oltre a MySQL, Java e Solaris sono gli asset più golosi nel mirino di Oracle. Infatti, l’acquisizione di Sun Microsystem da parte di Oracle avrà un grande impatto su molti comparti dell’IT, dai desktop software, ai server, alle tecnologie così come avrà impatto sui segmenti di mercato, per le Pmi ma anche per le grandi aziende.
In particolare:

  • Database per le imprese: La piattaforma preferita per i database Oracle è Solaris, basata sull’architettura SPARC. L’acquisizione comporterebbe il consolidamento del predominio di Oracle in questo settore, perché sarà difficile per le aziende rivali (soprattutto Microsoft, con il proprio server SQL basato su Intel, e SAP) competere con una tecnologia database che contiene i know-how di Oracle e Sun combinati.
  • Database per privati: se Oracle manterrà lo sviluppo del database open source MySQL di Sun, ciò la porterà ad avere una maggior penetrazione nella fascia media di mercato, mantenendo comunque soluzioni robuste e affidabili.
  • Java e Sun: lo stesso Larry Ellison, fondatore e CEO di Oracle, ha dichiarato che sono stati proprio Java e Solaris i motivi principali che hanno spinto la sua società a volere fortemente la transazione. Infatti se Java sarà la tecnologia fondamentale sulla quale puntare per il successo nel settore del middleware, Solaris è sempre stato la migliore piattaforma su cui far girare il potente database di Oracle. La speranza è che Oracle mantenga Java open source e prosegua nella linea di ricerca della società acquisita, anche se è probabile che Java prenderà la via del settore enterprise.
  • Open Source: dopo l’acquisizione, è evidente a tutti che vi saranno numerose sovrapposizioni in merito all’offerta software delle due società, ed è probabile, quindi, che alcuni progetti open source prima supportati attivamente da Sun Microsystems subiranno un ridimensionamento. E’ il caso, per esempio, di OpenOffice.org che difficilmente troverà una collocazione all’interno della strategia di Oracle (anche se taluni pensano che Oracle, nota rivale di Microsoft, investirà su OpenOffice.org solo per portare via clienti a Microsoft Office), mentre è plausibile pensare che la tecnologia di VirtualBox vada a confluire in Oracle VM, o ne sia complementare.
  • Software proprietario: Oracle possiede già il suo ambiente di sviluppo Java proprietario che si chiama JDeveloper (e partecipa nella fondazione Eclipse), per cui è probabile che NetBeans di Sun verrà ridimensionato o, nel peggiore dei casi, ne verrà cessato lo sviluppo o ceduto a terze parti. Ovviamente la migliore delle ipotesi sarebbe prendere il meglio dei due prodotti e fare di NetBeans e JDeveloper un unico prodotto: peccato che tutto questo richiede investimenti che non sappiamo se Oracle avrà voglia di anticipare.
  • Hardware: Oracle è un’azienda che si è sempre ed unicamente occupata di software. Cosa farà della divisione di Sun dell’hardware, in particolare dell’architettura SPARC? Forse Oracle potrebbe differenziare l’offerta in base ai suoi clienti: grandi clienti Oracle + Solaris + SPARC. Piccoli clienti Linux + MySQL + AMD/Intel.
    Di certo la vendita di hardware sarà un valore aggiunto che Oracle sfrutterà per poter proporre soluzioni complete a prezzi più concorrenziali rispetto agli altri, anche se è forse difficile pensare ad una evoluzione del processore SPARC, a causa degli onerosi costi di ricerca e sviluppo nel campo delle CPU. E’ quindi probabile che i server SPARC rimarranno in commercio ancora per qualche anno, ma non verranno più sviluppati, puntando sui processori AMD/Intel (i cui costi di ricerca e sviluppo, sono a totale carico delle rispettive società).
Nuovi accordi in arrivo per le aziende rivali?

Secondo qualcuno, però, se per molti anni grosse case di hardware, prima tra tutti HP, erano stati partner privilegiati di Oracle, ora l’arrivo in casa Oracle di Sun (un accordo che darebbe un sistema hardware/software chiavi in mano) creerebbe una situazione di disagio a partner come HP che potrebbero allontanarsi non potendo trarre beneficio più dei privilegi. In altri termini, HP (e altri partner di minore impatto) potrebbero cominciare a orientare il loro interesse verso nuovi produttori di software. E, per adesso, l’unica vera grande alternativa è rappresentata da Microsoft che a questo punto potrebbe trarre grande vantaggio da questa acquisizione.

In questa ottica, quindi, sarebbe un grande errore, da parte di Oracle, abbandonare lo sviluppo dell’ambiente MySQL, poiché offrirebbe a Microsoft SQL Server un più ampio campo di opportunità, soprattutto in compagnie orientate al Web 2.0 dove, appunto, mySQL è ampiamente rappresentato (al momento MySQL vanta più di 11 milioni di installazioni).
In definitiva, è probabile che Oracle continui a sviluppare e puntare su MySQL proponendolo come soluzione entry-level, aggredendo così il mercato dal basso e lasciando ad Oracle Database 11g il segmento high-end.

Conclusioni

Queste sono solo alcune idee e speculazioni, che da ieri stanno circolando sul web. Ovviamente, in questi casi, solo il tempo potrà dire quali direzioni prenderà Oracle. Ma quel che è certo per tutti è che la società di Larry Ellison ha sicuramente fatto uno dei migliori affari della sua vita, perché da questo momento Oracle diventa, ancor di più, uno dei più importanti player dell’intero panorama IT, poiché potrà fornire soluzioni integrate comprendenti server, storage, sistema operativo, database, middleware e applicazioni, ponendosi così in diretta concorrenza con colossi come IBM, Dell e HP.

Termino con una perla di saggezza di Techcrunch che intitola così un suo articolo sull’acquisizione Oracle-Sun:

Oracle Wants To Be The Apple Of The Enterprise, But It Just Became IBM

che in italiano suona pressappoco così:

Oracle vuole essere la Apple del mercato Enteprise, ma è diventata solo IBM

Tag:database, hp, java, microsoft, Mysql, openoffice, opensource, oracle, server, sun, virtualbox
CONTINUE READING >
6 comments
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
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 7 2008

Automatizzare le operazioni del cPanel da shell unix con i comandi wget, ftp e curl: download automatico del DB Mysql e monitorare la banda disponibile

Posted by Antonio Troise
Tweet

Il vantaggio di possedere un computer con Mac OS X è quello di avere sempre a disposizione, perché inclusa nativamente nel sistema operativo, una shell unix completa, per i più esperti, o Automator, per i meno esperti. Quest’ultimo strumento è una applicazione davvero potente perché consente di creare in maniera visuale, grazie ad un diagramma di flusso (workflow) e trascinando le azioni una dopo l’altra (drag & drop), programmi di automazione davvero complessi e articolati.

Ma dopo aver lavorato anni sui sistemi unix, avere sottomano una potente shell unix, è una tentazione di cui davvero non posso fare a meno. Infatti, con la semplice concatenazione di comandi (pipeline) come grep, sed e awk (altri comandi utili possono anche essere sort, uniq tail, head, cut e wc) in una sola riga, è possibile estrarre (scraping) informazioni da pagine web. Infatti, struttando il fatto che le pagine html sono, anche se in misura minora ad un più ordinato e formattato file xml, strutturate con i TAG, con pochi comandi è possibile fare del sano Web_scraping.

WGET

Il comando più potente da riga di comando per scaricare una pagina web o inviare richieste GET o POST, con o senza autenticazione è, come noto, WGET.
Per scaricare un file è possibile usare una sintassi tipo:

Ma la vera potenza di wget risiede nella possibilità di realizzare, con una sola riga di comando, un mirror ad un sito web.
Quindi per scaricare un intero sito in locale basta scrivere:

mentre, per scaricare solo una pagina con tutti i link interni:

Il problema è che sui sistemi MAC OS X, wget non è installato di default e, quindi, per chi non volesse passare per la fase di compilazione (anche se in giro esistono versioni già compilate per Tiger e Leopard) o, comunque, ha semplicemente la necessità di scaricare solo una file o una pagina web, allora è possibile usare una delle due alternative preinstallate su Mac OS X: ftp e curl.

FTP

Il comando FTP può essere usato anche per scaricare file HTTP.
La sintassi è molto semplice:

Come vedremo, in seguito, per i nostri scopi molto spesso il comando FTP è più che sufficiente per la maggior parte delle operazioni comuni.

CURL

CURL è un tool da riga di comando estremamente potente perché permette di scaricare in maniera molto flessibile ed automatizzata un qualsiasi numero di files da internet, secondo i protocolli HTTP o FTP, e di visualizzarli a schermo o di scriverli su disco.
La sintassi semplice, simile a quella dell’FTP, è:

In realtà la sintassi completa è:

Ma la vera flessibilità del comando nasce dalla possibilità di usare nella sintassi dell’URL le parentesi quadre per indicare una serie di URLs incrementali.
Per esempio una sintassi tipo:

creerà in modo automatico tutti gli URLs compresi nell’intervallo numerico specificato, e scaricherà in successione i file corrispondenti. Ai files sull’HD verrà assegnato il nome specificato dopo la flag -o, usando l’indice #1 per creare nomi univoci, incrementati allo stesso modo della sorgente.
In poche parole la singola riga di cui sopra equivarrà ad aver digitato in successione tutti i comandi:

Attenzione: il flag -O dell’ultimo esempio differisce dal flag con la o minuscola usato in precedenza, in quanto per nominare il file sul disco rigido usa lo stesso nome del file remoto.

La successione di URLs incrementali non deve essere necessariamente numerica, ma anche alfabetica, ad esempio [a-z]. Inoltre in uno stesso comando si possono combinare più indici incrementali (notate come nel nominare il file è possibile usare anche i due indici #1 e #2)

Monitorare la banda del proprio sito da riga di comando

Dati gli ultimi problemi di esaurimento della banda che hanno afflitto il mio sito, era evidente che una delle prime necessità che avevo era quello di monitorare costantemente la banda usata. Il problema è che, per farlo, dovevo ogni volta accedere al cPanel, il Pannello di Amministrazione del mio sito, dove, in un menu laterale, era possibile visualizzare la banda usata.

cPanel Bandwidth

Allora ho deciso di crearmi un semplice script che, scaricasse la pagina html del mio cPanel, andasse a selezionare, con il comando grep, la riga che conteneva la frase “Monthly Bandwidth Transfer” e attraverso due comandi awk (i file separator usati in Awk sono relativi alla mia pagina cPanel e potrebbero variare a seconda delle diverse versioni e configurazioni del pannello di controllo), estrarre la banda usata:

Come potete notare, per semplicità ho incluso, direttamente nella URL, lo username e la password per accedere al Pannello di Amministrazione. Questo è possibile solo perché il metodo di autenticazione del cPanel si basa su htpasswd ma ricordiamo che non è un metodo sicuro perché, oltre a lasciare memorizzati informazioni personali, nella barra degli indirizzi del proprio browser o nella history del terminale usato, si lasciano tracce anche nei vari proxy in cui si passa e nei log del webserver, oltre, come comunque avviene l’autenticazione classica se non passa per SSL, con un semplice sniffer.

Ci tengo a precisare che quello sopra illustrato è solo uno dei tanti modi per risolvere il problema: questo, in particolare, è il primo che mi è venuto a mente, forte delle decine di script shell realizzati negli anni. Ovviamente è possibile anche renderlo più complesso ed efficiente, parametrizzando username, password e url e, magari, notificando con una mail o con un messaggio a video (magari anche con Growl), quando la banda è prossima all’esaurimento. Il tutto ovviamente potrebbe anche essere inserito nel crontab di sistema in modo da girare ogni ora.

Per esempio, un metodo non ortodosso, sarebbe quello di visualizzare l’output non a video ma direttamente in TextEdit usando il comando open con le pipeline. Per farlo, ho riunito i tre comandi sopra elencati in un file bash di nome: monitora_banda.bash.
Quindi lanciando:

avremo questo risultato:

Output Textedit

Più in generale questo è il risultato del comando ‘open’ presente su Mac OS X.
Altri esempi, potrebbero essere:

Ma le possibilità, come vedete, sono infinite. Ma lo scopo di questo articolo era solo di illustrare alcuni metodi per automatizzare da riga di comando delle procedure. Il resto è lasciato all’inventiva di ciascuno di voi.

Download automatico del backup del DB Mysql

Il mio hosting non supporta il backup automatico del DB di Mysql perché non gestisce correttamente le schedulazioni di comandi da riga di comando. E’ per questo che ho realizzato un semplice script da inserire nel crontab, per scaricare quotidianamente il backup del proprio database.
Infatti, sempre nel cPanel, è presente una sezione “Backups” che permette di scaricare, manualmente e con un link statico, un full backup del sito, oppure un backup parziale del solo database Mysql o della sola home directory (il concetto esposto rimarrà comunque analogo per qualsiasi soluzione adottiate).
E’ evidente che, a questo punto, con un semplice comando, è possibile scaricare da terminale i backup:

Basterà quindi inserirlo (con il comando crontab -e) nel crontab (se non siete esperti potrete usare il Easy Crontab Creation Tool) in modo da fargli scaricare il backup del DB, per esempio, ogni giorno alle ore 11:30 del mattino:

Attenzione: come ogni comando da terminale, FTP (ma lo stesso vale se usate WGET o CURL) andrà ad operare nella directory corrente di lavoro, quindi se volete archiviare i file scaricati in una directory apposita, spostatevici preventivamente con il comando cd nome_directory.
Inoltre, dovete tenere presente che tutti i downloads andranno a scrivere lo stesso file e, quindi, ogni giorno ci si ritroverà con solo l’ultimo file scaricato. Se avete intenzione di tenere traccia di tutti i backup scaricati, dovrete rinominare il file, per esempio, aggiungendoci un suffisso come la data di download (realizzabile o con il comando curl o con uno script bash).

Tag:automator, awk, backup, banda, bandwidth, bash, cpanel, curl, database, download, ftp, grep, html, ksh, Mac os x, Mysql, password, sed, shell, unix, url, wget
CONTINUE READING >
5 comments
Giu 9 2008

Come ordinare correttamente gli indirizzi IP con la funzione INET_ATON di MYSQL e in quanti modi è possibile scrivere un indirizzo IP

Posted by Antonio Troise
Tweet

Quando si ha a che fare con tabelle Mysql che contengono valori come gli indirizzi ip, spesso il loro ordinamento, in maniera crescente o descrescente, è un problema gravoso. Infatti se si lancia il seguente comando SQL:

si otterrà un risultato simile a questo:

+—————+
| ip |
+—————+
| 67.10.151.113 |
| 68.88.231.1 |
| 68.88.231.10 |
| 68.88.231.2 |
| 68.88.231.22 |
| 68.88.231.23 |
| 68.88.231.24 |
| 68.88.231.25 |
| 68.88.231.26 |
| 68.88.231.27 |
| 68.88.231.28 |
| 68.88.231.29 |
| 68.88.231.3 |
| 68.88.231.30 |
+—————+

Come vedete, nonostante nella query SQL si sia esplicitamente dichiarato di voler ordinare il risultato della select per il campo IP in maniera ascendente, in realtà il risultato finale è parziale poiché alcuni gruppi di valori sono effettivamente ordinati tra di loro mentre altri sembrano essere inseriti un po’ alla rinfusa. Per l’occhio più allenato, è facile intuire che questo risultato è tipico di un ordinamento testuale.

Il problema, infatti, è che non esiste un tipo di campo adatto ad un valore come l’ip address e, quindi, quando si devono configurare i campi un tabella, si è costretti ad assegnare una proprietà TESTO sul campo assegnato all’indirizzo ip (visto che la proprietà numerica di un campi mysql, anche se a prima vista potrebbe essere la più adatta, non supporta, come ovvio, la presenza di più di un punto decimale). Il che comporta che l’ordinamento avverrà come qualsiasi campo testuale, ovvero rispettando la tabella dei codici ascii. Ciò significa ritrovarsi, per esempio, il valore con .29 finale che è sempre seguito dal valore .3!

Soluzione 1: Inserire gli zeri

Per tutti i webmaster, questo problema di formattazione è davvero ostico da gestire poiché si presenta per ognuna delle 4 parti di cui è composto un indirizzo ip e una soluzione rapida, ma davvero sgradevole dal punto di vista estetico (anche se perfettamente funzionale) è di inserire tanti zeri quanti ne servono per raggiungere le 3 cifre di ogni parte dell’indirizzo ip. Per cui, per esempio, il valore 68.88.231.27 diverrebbe 068.088.231.027.
In questo modo, il risultato della query SQL sarebbe:

+—————+
| ip |
+—————+
| 067.010.151.113 |
| 068.088.231.001 |
| 068.088.231.002 |
| 068.088.231.003 |
| 068.088.231.010 |
| 068.088.231.022 |
| 068.088.231.023 |
| 068.088.231.024 |
| 068.088.231.025 |
| 068.088.231.026 |
| 068.088.231.027 |
| 068.088.231.028 |
| 068.088.231.029 |
| 068.088.231.030 |
+—————+

In realtà, se questa soluzione non vi piace, per risolvere questo annoso problema, a venire in vostro aiuto esiste una comoda funzione Mysql di nome: INET_ATON (A.TO.N = Address TO Number), che consente di convertire un indirizzo IP nel suo corrispettivo decimale.

In quanti modi può essere scritto un indirizzo IP

Infatti, come noto, un indirizzo IP è in realtà numero a 32 bit che, convenzionalmente, è rappresentato (oltre che da una serie di 32 uno e zero) tramite una più mnemonica notazione decimale (decimal dotted notation), che si ottiene suddividendo il numero binario corrispondente all’indirizzo IP in gruppi da 8 bit e trasformando ogni gruppo di 8 bit nel corrispondente valore decimale, ottenendo, quindi, i quattro valori decimali , separati l’uno dall’altro per mezzo di un punto.

IPV4

Per rendere più chiaro l’esempio, facciamo un ping all’indirizzo di google.it

Pinging google.it [66.249.93.104] with 32 bytes of data:

Reply from 66.249.93.104: bytes=32 time=29ms TTL=242
Reply from 66.249.93.104: bytes=32 time=30ms TTL=242

Ping statistics for 66.249.93.104:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 29ms, Maximum = 30ms, Average = 29ms

ed otterremo il suo indirizzo IP: 66.249.93.104

In realtà, questo indirizzo IP, a seconda della notazione usata, può essere scritto in varie maniere.
Per esempio:

IP Dotted Quad: 66.249.93.104
IP Binary: 01000010111110010101110101101000
IP Hex: 42F95D68
IP Decimal: 1123638632

Ora sulla barra degli indirizzi del vostro brower preferito potete scrivere indifferentemente una delle seguenti URL (anche se corretta come conversione, in realtà la notazione binaria non viene interpretata dai browser o quando si deve fare un ping remoto) e vedrete, in ogni caso, la homepage di Google.it:

http://66.249.93.104
http://0x42F95D68
http://ob01000010111110010101110101101000
http://1123638632

I prefissi inseriti servono a dire al browser in che notazione è stata scritta la url; per cui 0x indica la notazione esadecimale (Hex), 0b quella binaria (Binary) e 0 quella ottale (Octal).

Soluzione 2: la funzione Mysql INET_ATON

Ora, dopo questa spiegazione, sara facile capire che una funzione come INET_ATON (A.TO.N = Address TO Number) in grado di convertire un indirizzo IP in notazione decimale è veramente molto potente. Infatti, sarà sufficiente lasciare inviariati i valori del campo IP e convertirli in decimale solo nel momento in cui si esegue la query per effettuare il corretto ordinamento.

In definitiva, lanciando una query del tipo:

otterremo finalmente il risultato sperato


+————+—————+
| bin_ip     | ip            |
+————+—————+
| 1124767601 | 67.10.151.113 |
| 1146676993 | 68.88.231.1   |
| 1146676994 | 68.88.231.2   |
| 1146676995 | 68.88.231.3   |
| 1146677002 | 68.88.231.10  |
| 1146677014 | 68.88.231.22  |
| 1146677015 | 68.88.231.23  |
| 1146677016 | 68.88.231.24  |
| 1146677017 | 68.88.231.25  |
| 1146677018 | 68.88.231.26  |
| 1146677019 | 68.88.231.27  |
| 1146677020 | 68.88.231.28  |
| 1146677021 | 68.88.231.29  |
| 1146677022 | 68.88.231.30  |
+————+—————+

Se invece, dovete eseguire l’operazione inversa, potete usare la funzione reciproca INET_NTOA (N.TO.A = Number TO Address) che, quindi, è in grado di convertire un numero decimale nel suo equivalente indirizzo IP.

Tag:binario, esadecimale, ip address, Mysql
CONTINUE READING >
0 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
Lug 17 2007

Come sostituire una stringa in un tabella di un database Mysql

Posted by Antonio Troise
Tweet

A volte potrebbe essere necessario dover trovare e in seguito sostituire una stringa presente in molte righe di una tabella di una database mysql. Potrebbe, infatti, capitare di dover sostituire il nome di un azienda con un altra, o correggere un errore di scrittura ripetuto più volte oppure cambiare la URL di un sito. Per fare questo è possibile utilizzare la comoda funzione di mysql, REPLACE(), la cui sintassi è:

REPLACE(testo, stringa_da_sostituire, nuova_stringa)

MySQL reference descrive la funzione REPLACE come una un’estensione allo standard SQL la cui funzione è quella di, data una stringa, sostituire i caratteri specificati con altri.
E’ importante tenere presente che la funzione è case-sensitive, ovvero fa differenza tra caratteri minuscoli e maiuscoli.

Ad esempio:

darà come risultato: www.php.com

La funzione REPLACE, però, è in grado di sostituire i caratteri contenuti nel testo di un campo di una tabella di un database mysql, con la semplice manipolazione dei comandi SELECT, UPDATE e REPLACE.
La sintassi è:
update NOME_TABELLA set NOME_CAMPO = replace(NOME_CAMPO, ‘trova questa stringa’, ‘sostituisci la stringa trovata con questa’);

Per esempio, per sostituire nel campo compagnia della tabella clienti il nome Microsoft con Apple, basterà scrivere:

Tag:Mysql, replace, Tips
CONTINUE READING >
6 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
Tweet

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:

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

Ecco alcuni suggerimenti di Davide, utili allo scopo:

  1. 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)
  2. per convertire il set di caratteri, lo script va eseguito solo una volta, e subito dopo cancellato (per sicurezza)
  3. 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.
  4. lo script modifica sia la collation del database che i valori interni allo stesso
  5. 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
CONTINUE READING >
11 comments
Mar 16 2007

Amministrare al meglio MySQL

Posted by Antonio Troise
Tweet

Il db administrator Baron Schwartz ha redatto una lista ragionata dei migliori programmi in circolazione per monitorare MySQL.
Per monitorare query e transazioni vengono analizzati mtop, mytop e innotop (realizzato dallo stesso Schwartz) tra i tool a linea di comando mentre tra quelli web based sono presi in considerazione phpMyTop e ajaxMyTop.
Per il monitoring delle risorse utilizzate su una Linux-box da MySQL sono descritti uno script perl di Giuseppe Maxia e mysqlreport. Per tenere sotto controllo il server e effettuare un check sulla sua attività l’autore consiglia invece Nagios.

[via ossblog]

Tag:db_administrator, linux_box, monitoring, Mysql, query, transazioni
CONTINUE READING >
0 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 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