I moved my diary WordPress installation yesterday from an old WP1.22 installation to a brand new shiny WP1.5 database and URL. Here are the steps, in summary:

1. We don’t want to lose any comments so get into phpMyAdmin and shut down comments/trackbacks on the old blog, by running this SQL:
   UPDATE wp_posts SET comment_status = 'closed', ping_status = 'closed'
2. Then export the database, with Complete Data Inserts turned on. Get the dump down into a text file (there’s probably an automatic way, but I just copy/pasted into my preferred editor — Ultraedit)
3. Do whatever replacements are needed on the data. I replaced all the toxiccustard.com/diary URLs with danielbowen.com ones, for instance. Be sure to change the setting in wp_options that specifies the site (WP) URL, ‘cos you won’t be able to logon if you don’t — the logon code will throw you over to the old blog. There’s another setting called Blog address which will also need changing if you’re coming off WP1.5.
4. My export seemed to add extraneous escape characters in odd places. For instance a quote "e; in the database came out with two backslashes in front of it. I did some replacing to remove "e; with "e; — and similarly with single quotes, they all need only one
5. Create the new database, with whatever database user WP will be using, and plug the details into your wp-config.php
6. Run the export SQL into the new database, by copy/pasting into myPhpAdmin. I did it table-by-table so I could catch and correct any problems easily. I was especially wary of the wp_posts table, which had almost 700 rows, most with very long data. But as it turns out it all went very smoothly, with no problems whatsoever.
7. Time to upload all the WP files into the new web server. Because I was moving from WP1.22 to 1.5, there were some steps to follow first for migrating the old template. All pretty straightforward really. Then run the WP wp-admin/upgrade.php to make sure the tables are all up to date with the latest design.
8. Log onto WordPress and go through the config screens to make sure it’s all okay. Things to watch out for include the timezone (if different on the new server), setting your preferred template, activating any plugins you want, and setting the new file upload directory (on which you’ll need to set permissions).
9. Check out the Permalinks. Set it up, then copy what it tells you to your .htaccess file. (The WP1.5 version wouldn’t actually work for me. For now I’m still using the WP1.2 version until I figure it out.)
10. Check how the blog looks to the outside world. Post a test post and comment, just to check it all works. If not, go back and correct where applicable.
11. Re-enable (selected) comments on the new blog:
    UPDATE wp_posts SET comment_status = 'open', ping_status = 'open'
12. Insert an .htaccess redirect on the old site to point people over to the new:
    Redirect /olddirectory http://yoursite.com/newdirectory/

And presto! Done!

(Okay, I had some further hassles with some old HTML and broken image links mixing it up with WordPress, but that’s my problem, not yours!)

WordPress 1.5 came out overnight. Well actually it came out on Valentine’s Day, but they didn’t announce it until a few hours ago. From the sounds of it, there’s been a lot of work done on the template system, comment control, a way to make non-dated pages run in the system (ooh, getting more CMS-ey). All sounds rather good to me, and I’ll be checking it out and (all being well) implementing it on the blogs I run directly.

Today geekrant.org’s stylesheet was fading in and out of existance. Well, to be precise, the path to it got screwed up a bit, because somehow it thought it was in a directory called (deep breath):

http://www.geekrant.org/wp-login.php/wp-images/smilies/ wp-images/smilies/wp-images/smilies/wp-images/smilies/ wp-images/smilies/wp-images/smilies/wp-images/smilies/ wp-images/smilies/wp-images/smilies/wp-images/smilies/ wp-images/smilies/wp-images/smilies/wp-images/smilies/ wp-images/smilies/wp-images/smilies/wp-images/smilies/ wp-images/smilies/

rather than the much more succinct (and correct):

http://www.geekrant.org/

This appears to be caused by a bug in WordPress 1.21, where under some circumstances registered users go to login, and a particular browser/server configuration is present (looks like something to do with proxies) and it thinks the WordPress directory has moved, and tries to compensate. It’s detailed in the WordPress support forums, and if anybody’s having problems with it, the fix is to manually fix the siteurl setting in the wp_options table (it’s the first row) and to get into wp-login.php and comment out the two lines following

// If someone has moved WordPress let’s try to detect it

…because really, if someone’s moved it, they should have done it properly and updated the siteurl setting themselves.

See, not even WordPress is perfect. But it does have a strong user community, open source code that’s not too confusing to dabble in even for PHP-newbies like me, and a straightforward database structure holding all it’s stuff together. And that counts for a lot, I think.

I was asked to go step-by-step through how to protect WordPress from the current rash of spam comment attacks, so here it is. It’s fairly easy to get them to go into the moderation queue, but it’s a pain having to continually clear it out.

The way the current attacks (hold ’em poker and so on) are working is to attack a file called wp-comments-post.php which does the grunt-work of posting comments into the database… if this isn’t there, they can’t do it.

So first rename wp-comments-post.php to something else. Doesn’t really matter what, as long as it doesn’t clask with anything else. eg xyz.php. (It’s not ever seen by users so it really could be called anything without confusing people, though you might want to avoid confusing yourself if you later can’t remember what it is.)

Then you need to edit the files that call xyz.php, which are:

• wp-comments.php
• wp-comments-popup.php
• wp-comments-reply.php

Save all those files to your server, and make sure the original wp-comments-post.php file is deleted, and then you should be done. Post a comment yourself to make sure it works.

For now it seems to stop the spammers… no doubt in future they’ll figure out something more advanced (like scanning the <form> code to figure out the name of the post file), but it should stop them for a little while at least.