When I upgraded my Wordpress installation recently, I ran into a chracter encoding problem. Long story short, it turns out that older Wordpress installations like mine tend to have been created in latin1, but the data is actually being saved in UTF8. If you update your wp-config file to a newer version, it adds a DB_CHARSET option, which will cause your site to puke, because the database character set doesn’t match the data that’s actually stored in it.
Thankfully, the fix is relatively simple, if a bit of a hassle:
- From your command line, use the
mysqldumpcommand to export your database inlatin1format. Since MySQL sees your database is already inlatin1format, it won’t re-encode it (which would break theUTF8data in the database). The command should look something like this:mysqldump -u username -p --add-drop-table --default-character-set=latin1 databasename > databasename.sql
Note: You must do this from the command line, because PHPMyAdmin doesn’t allow you to specify the characterset of the export file, so you will end up with re-encoded data, that will get scrambled and kill your database.
- Copy that dump file somewhere safe for a backup, in case something goes wrong.
- Using a text editor, open the MySQL dump file and replace all instances of
latin1withutf8. There should be one reference in eachCREATE TABLEline. - Import the database over the top of your existing one. Since you did a complete dump, with the
add-drop-tableoption, this will drop all your existing tables, and recreate them. And since you changed the character sets, this will effectively update your database toUTF8. The command will look something like this:mysql -u username -p databasename < databasename.sql
Now, if you’re anything like me, those instructions are terrifying. But trust me that there is relatively little risk. The very first thing you’re going to do is make a backup. If anything goes wrong, the worst case scenario is that you restore your backup, and you’re back to square one. I can’t tell you that it’s totally safe, but I can assure you that I did this to two of my databases, and it went off without a hitch.
I’ve split this site into two, a personal one and a professional one. Spaceninja.com will remain my professional blog, with an emphasis on front-end web production. I’ve set up a new blog on ScottVandehey.com that I will be using for more personal posts about Zoe and non-web-development topics. Thanks for your patience.
Friday will be my last day at Pop Art. I’ve been working there nearly four years, and deciding to quit was not an easy decision. I won’t get into all the details, suffice to say that it’s time for me to move on, and I’m ready for some new challenges.
Over the years at Pop Art, I’ve worked with a lot of great people, many of whom I would work with again in a heartbeat. I’ve learned a lot, and I also feel like I made a real difference. Together with other front-end developers like Libby Molina and Ryan Parr, we’ve shaped the production process and made top-notch standards-compliant code one of the things that Pop Art is known for. I’m proud of that legacy.
All in all, I’m stoked. It was definitely time for a change, and this feels like a really good one. I’m sure I’ll be posting more details soon, but in the meantime, wish me luck!
Long story short, Google released a plugin for IE 6, 7 and 8 that will run Google Chrome (which uses webkit) inside a frame in the IE browser. Now IE6 can be standards-compliant, and all versions of IE get blazing fast javascript and HTML 5 support. Sounds great, but there are some problems, as lifehacker points out:
“The (most) obvious question: Why would I install this plug-in rather than switch browsers to Chrome? The folks at Google point to IT lockdown that won’t allow users to install a new browser; Ars wonders whether such restrictive IT departments would be any more likely to approve this plug-in. If nothing else, it’s a pretty bold move on the part of Google.”
If you’re interested, Jim Ray dug into the details of how it works. Personally, I don’t think this will solve anyone’s IE6 problems, but it’s a fascinating development, and worth keeping an eye on.
“The irony here, as I see it, is that an old, insecure feature Microsoft built to try to beat Netscape is now being used by Microsoft’s biggest current rival to patch IE.”
Just so we’re clear, testing your website in an actual copy of IE7, and testing in IE8’s Compatibility Mode are not the same thing. Compatibility Mode does an acceptable job of imitating IE7, and for the average user who’s just trying to fix a site that looks broken under IE8, it’s good enough. However, there are lots of small differences, and if you’re only testing your client sites with Compatibility Mode, it could come back to bite you.
On the IE Blog, Tony Ross published a list of mostly technical differences between the two. Perhaps more useful for web developers is this article by Estelle Weyl outlining some of the presentation differences between the two, such as border handling and box model differences.
Why does this matter? Because I’ve heard some otherwise intelligent web developers (including Microsoft’s Expression Web team, which uses IE8’s Compatibility Mode for IE7 testing) claim that testing will be much easier now, since you can test everything in one place.
To be sure, tools like Expression Web or the old Stand-Alone IE installers are helpful, but don’t fool yourself into thinking that they are an accurate representation of a “clean” IE6 or IE7 installation. To test against those, you’ll still need to resort to more thorough measures like keeping separate machines around, or using the free Virtual PC images for IE6, IE7, and IE8.
I’m a