xsamplex

Oh, so it was. While changing the layout, I peeked around at the WP tables and decided to ‘merge’ a couple of older MT-related categories with the appropriate ones. To my surprise, I noticed that the rowcount (or, the number of posts in a category) was actually stored in a separate field in the wp_categories table. I have no problems with that (usage of the count function is generally not recommended).

It looks like the WP bug I mentioned before, has everything to do with the ‘upload image/send to editor’ procedure: the bug is persistent when you specifically link an image to a page. For now, linking to an image directly will do.

Talking about burnt: it looks like WordPress is pretty much acting up with a couple of ‘SQL-errors’ on my side. They happen to appear around the time I press the ‘Save’ button. WordPress returns the following error:

UPDATE IGNORE wp_posts SET .... (and posting information follows).


I have the impression something goes wrong with escaping single quotes. I’m testing this right now.

Update 1: WordPress has problems with escaping of single quotes. A quick test of the previous entry seems to illustrate this.

Update 2: It’s a combination of sorts and version differences make it harder to see where it goes wrong. On my test server escaping or not escaping doesn’t throw an error at all (version: 4.0.24_Debian-10-log vs. Dreamhost 4.1.14-Debian_3-log) . Different versions PHP too: home runs 4.3.10-16, and Dreamhost 4.4.2. (if you’re not familiar with how to extract PHP info, you can run php -i > test.html for 4.4.x versions: php will generate an html file). I still think it’s a magic quotes issue (and probably a bug introduced in WP 2.0.1)

Update 3: Priceless comment about “magic quotes”. Developers, please escape your quotes (or convert those quotes to html entities).

Update 4: Thread to watch at WordPress.org

A quick guide to help you develop your ‘online site’ offline. Requirements:

• An offsite test server, preferably running Debian Stable (formerly ‘Sarge’).
• A good knowledge of MySQL, PHP and Bash
• Shell access to your online site.

Proceed with the following steps:

1. Create a tarfile that contains all the files on your server, including graphics, themes and that.
2. Create a mysql dump of the WordPress database that holds your blog data.
3. Copy these back to your local server (scp/ftp)
4. Create the same user/password/database on your local MySQL server. Check your wp-config.php file.
5. Untar the backup file. Use the same base directory, if possible. If your blog was at /arthur, you may just as well add a new directory /arthur in your local webserver’s document root.
6. Untar the SQL backup file. Import this in the database you created before. Grant access to the database for the newly created user. Warning: you may end up editing the SQL dump if you work on two different versions of MySQL. Additionally, using PhpMyAdmin for making dumps will generally not work thanks to the ‘magic quotes’ problem. And hey, since you’re a professional, you may just as well bite the bullet and work on your commandline skills.
7. You need to change a couple of WP options in your local WordPress database: most likely:
   
UPDATE wp_options SET
option_value= 'http://192.168.1.20/dude/wordpress'
where option_name='siteurl';
UPDATE wp_options SET
option_value= '/var/www/dude/wordpress/wp-content'
where option_name='fileupload_realpath';
UPDATE wp_options SET
option_value= 'http://192.168.1.20/dude/wordpress/wp-content'
WHERE option_name='fileupload_url';
UPDATE wp_options SET
option_value= 'http://192.168.1.20/dude'
where option_name='home';
Choose the IP address of your liking.
8. Consider upgrading to the latest WordPress version. Since you’re local copy is almost working, do so.
9. Consider install PHPXRef.
10. Point the database server to the local server in the wp-config.php file. Don’t forget this.
11. Log in to your local WordPress using the right user/password. Test the configuration.
12. Set!

There’s a small bug in Rebelpixel’s recent-links plug-in: clicking the monthly archive pages always appeared to return all the recent links, instead of the (selected) month/year. A quick look in the code tells me that it goes wrong between line 572 and 580 in the file rp_plugin_recent_links.php:


if (strlen(get_settings('permalink_structure')) > 0) {
$y = strval($_GET['y']);
$m = strval($_GET['m']);
} else {
$y = strval(substr($_GET['m'], 0, 4));
if (strlen($_GET['m']) > 4) {
$m = strval(substr($_GET['m'], 4, 2));
}
}


You may have noticed that I’m not a great fan of ‘clean permalinks’ (I have it turned off), which means that you can skip the True branch of the If condition. Obviously, there’s something not right in the ‘False’ branch. First of all, the $y variable gets the value of the $m variable. Second, there’s an extra IF condition to verify if the length of $m is greater than 4.

I presume that the function originally accepted values like ‘200601’ (for January of 2006) and that the programmer then decided to separate the GETs for month and year. The solution (when browsing through the code and confirming this behaviour) is simple: delete the whole if condition and replace it with:


$y = strip_tags($_GET['y']);
$m = strip_tags($_GET['m']);


Monthly Archives should work now.

I also readded the feed for the recent-links stuff: there’s something weird going on with the feed though. It doesn’t appear to be well-formed.

Update: There: that should do it

I upgraded to WordPress 2.0.1, which ended up taking shorter than the last time. This time there were however more individual files and directories to delete: I feel tempted to write a shell script to do this for me next time. It’s pretty annoying to go into a specific directory and delete a subdirectory. Or a specific file.

If you have shell access, this is a good way to become millionaire! Install and upgrade WordPress!

And oh: WordPress plug-in structure actually sucks. They should look into the way how the NucleusCMS guys do this.