Tag: convert

Flock, extensions, and coComment [en]

[fr] Une adresse de site pour convertir des extensions Firefox pour utilisation avec Flock, qui est un excellent navigateur. J'étais déçue de ne pas pouvoir utiliser l'extension Firefox pour coComment avec Flock -- maintenant je peux!

My ex-collegue and now friend Gabriel introduced me to the Flock browser quite some time back. I mentioned it quite a bit on my other blog but I don’t think I talked about here much.

Anyway, it’s great. It’s Firefox, but with all sorts of nice bloggy, flickr-y, del.icio.us-y stuff tied in. I’d like to get coComment integrated in there too.
(Disclaimer: I work for coCo.)

One thing that makes coComment really nice to use is the Firefox extension. Once you’ve installed it, you don’t need to do anything, and it automatically records all the comments you make (as long as the blog platform is more or less compatible to show them on your user page. Here’s mine.

The thing that bothered me when I started using Flock again sometime back was that I had to revert to using the bookmarklet (which, let’s be honest, is a real pain — who remembers to click on a bookmarklet before posting each comment? not I!) Today, as I was starting on my tour of the blogosphere to see what people are saying about coComment I came upon another Flock user who regretted the extension wasn’t compatible.

So, I headed to our internal bug-tracker to find out what the status of my request for a Flock extension was, and saw that Nicolas (coComment’s Daddy!) was asking for more information on converting extensions. I googled a little and here’s what I came up with:

Well, I installed the extension in Flock, restarted my browser, and after a painful start (wouldn’t be able to tell you if it was because of the extension or just good ol’ Windows acting up) it was up and running. I now have Flock running the coComment Firefox extension!

Let me know how it goes for you if you try it, particularly on other platforms. And if you haven’t tried Flock yet, you should. It’s really neat!

Converting MySQL Database Contents to UTF-8 [en]

I finally managed to convert my WordPress database content to UTF-8. It’s easy to do, but it wasn’t easy to figure out.

[fr] Voici comment j'ai converti le contenu de ma base de données WordPress en UTF-8. C'est assez simple en soi, mais ça m'a pris longtemps pour comprendre comment le faire!

A few weeks ago, I discovered (to my horror) that my site was not UTF-8, as I thought it was. Checking my pages in the validator produced this error:

The character encoding specified in the HTTP header (iso-8859-1) is different from the value in the XML declaration (utf-8). I will use the value from the HTTP header (iso-8859-1).

In all likeliness, my server adds a default header (iso-8859-1) to the pages it serves. When I switched to WordPress, I was careful to save all my import files as UTF-8, and I honestly thought that everything I had imported into the database was UTF-8. Somewhere in the process, it got switched back to iso-8859-1 (latin-1).

The solution to make sure the pages served are indeed UTF-8, as specified in the meta tags of my HTML pages, is to add the following line to .htaccess:

AddDefaultCharset OFF

(If one wanted to force UTF-8, AddDefaultCharset UTF-8 would do it, but actually, it’s better to leave the possibility to serve pages with different encodings, isn’t it?)

Now, when I did that, of course, all the accented characters in my site went beserk — proof if it was needed that my database content was not UTF-8. Here is the story of what I went through (and it took many days to find the solution, believe me, although it takes only 2 minutes to do once everything is ready) to convert my database content from ISO-8859-1 to UTF-8. Thanks a lot to all those who helped me through this — and they are many!

First thing, dump the database. I always forget the command for dumps, so here it is:

mysqldump --opt -u root -p wordpress > wordpress.sql

As we’re going to be doing stuff, it might be wise to make a copy of the working wordpress database. I did that by creating a new database in PhpMyAdmin, and importing my freshly dumped database into it:

mysql -u root -p wordpress-backup < wordpress.sql

Then, conversion. I tried a PHP script, I tried BBEdit, and they seemed to mess up. (Though as I had other issues elsewhere, they may well have worked but I mistakenly thought the problem was coming from there.) Anyway, command-line conversion with iconv is much easier to do:

iconv -f iso-8859-15 -t utf8 wordpress.sql > wordpress-iconv.sql

Then, import into the database. I first imported it into another database, edited wp-config.php to point to the new database, and checked that everything was ok:

mysql -u root -p wordpress-utf8 < wordpress-iconv.sql

Once I was happy that it was working, I imported my converted dump into the WordPress production database:

mysql -u root -p wordpress < wordpress-iconv.sql

On the way there, I had some trouble with MySQL. The MySQL dump more or less put the content of all my weblog posts on one line. For some reason, it didn’t cause any problems when importing the dump before conversion, to create the backup database, but it didn’t play nice after conversion.

I got this error when trying to import:

ERROR 1153 at line 378: Got a packet bigger than 'max_allowed_packet'

Line 378 contained half my weblog posts… and was obviously bigger than the 1Mb limit for max_allowed_packet (the whole dump is around 2Mb).

I had to edit my.cnf (/etc/mysql/my.cnf on my system) and change the value for max_allowed_packet in the section titled [mysqld]. I set it to 8Mb. Then, I had to stop mysql and restart it: mysqladmin -u root -p shutdown to stop it, and mysqld_safe & to start it again (as root).

This is not necessarily the best way to do it, and it might not work like that on your system, but it’s what I did and the site is now back up again. Comments welcome, and hope this can be useful to others!