WordPress 2.5.1 added a really powerful feature to register_taxonomy(): automatic registration of permalinks and query vars to match the taxonomy. Well, theoretically it added that feature. It wasn’t working in practice. After some searching yesterday and today, I finally found the bug and worked up a fix. I made a diff and set off to open a ticket in Trac.

On the one hand I’m glad I searched first, because it turns out that a ticket on the very same issue was opened on May 16th and it already has a fix. On the other hand, it’s kind of a kicker to have lost my chance at reporting the bug and submitting a fix by only a few days.

The fix is committed for WordPress 2.6, but I’ve done a workaround for 2.5.1 (workarounds are easier to manage than core code changes). I’d say I wish I searched Trac first, but I wouldn’t have known what to search for if I didn’t figure out how to fix the bug first. And I guess I really can’t complain about a community that quickly finds and fixes bugs.

In a piece that will have some people eagerly looking for some Afro Celt Sound System, others singing Where Do They Make Balloons, and some people just shaking their heads, this fellow, apparently standing in his bathroom, introduces us to another guy and his balloon organ. Really. Check this for more homemade organ fun.

After reporting weirdness last week I finally sat down with a completely clean and virgin install of WordPress 2.3.2 and traced what happens when you make a permalink request for a non-existent URL.

Here are two sets of URLs to use as examples and context:

• These are valid URLs:
  • http://site.org/archives/101
  • http://site.org/page-name
• These are _not_ valid URLs:
  • http://site.org/archivezorz/101
  • http://site.org/favicon.ico

Valid URLs get parsed, the expected MySQL queries get executed, and the results are processed and returned to the browser. Normal. The problem is that invalid URLs that get sent through WordPress still result in a query like the following being executed on the database. What?

SELECT SQL_CALC_FOUND_ROWS  test_posts.* FROM test_posts  WHERE 1=1  AND post_type = 'post' AND (post_status = 'pub
lish' OR post_status = 'private')  ORDER BY post_date DESC LIMIT 0, 10

That is, even after a URL is sent through WP->parse_request() and found to be invalid/404, WordPress marches on to WP->query_posts() and hits the database with a generic request for the X most recent posts. And because this is executed for every 404, it actually results in a lot of database activity.

In most cases MySQL has cached the result, and so it poses a minimal load on the server. And even if the cache is stale, for most sites it’s not a particularly resource intensive query.

But, if you’ve got 350,000 rows in the posts table, it’s incredibly resource intensive to order all those posts on the post_date (datetime) column. I’ve seen hundreds of them pile up and take forever to complete after writes to the table. It’s sufferable if write activity on the posts table is very low, but that’s not something I want to hope for.

So my question to the wp-hackers community is: Do we actually want to execute that query for every 404 under normal circumstances? If not, is the following (or something like it) the stupidest solution?

In wp-includes/classes.php:

	function query_posts() {
		global $wp_the_query;
		$this->build_query_string();
 
		// return if the request URI is a 404
		if( $this->did_permalink && $this->query_vars['error'] == '404' )
			return;
 
		$wp_the_query->query($this->query_vars);
	}

The above works, but there’s probably a better way to write it.

Answers.com is throwing a bone to WordPress users with their new AnswerLinks plugin written by Alex King.

But wait, there’s an Answers.com API? A few pokes at the Google machine reveal nothing relevant, and Asnwers.com’s site is mum too. Taking apart the code, I get the following (modded enough to make it run-able if you drop it in the base of your WordPress install):

require_once('wp-config.php');
require_once(ABSPATH.WPINC.'/class-snoopy.php');
$snoop = new Snoopy;
$snoop->read_timeout = 5;
$snoop->submit(
	'http://alink.answers.com/link/xml'
	, array(
		'text' => “Put a long-ish string of meaningful text here, then look for interesting stuff in the print_r'd output.”
	)
);
print_r($snoop->results);

If the input string isn’t sufficiently long, the output will be empty (eliminating one of my potential uses for it), but it’s interesting to twiddle.

Answers.com, API, AnswerLinks, hacking, remixable, mashable

WordPress’s Pages open the door to using WP as a content management system. Unfortunately, Pages can’t be edited via XML-RPC blogging apps like Ecto. This might be a good thing, but I’m foolhardy enough to try working around it.

Here’s how:

Find a text editor you like and open up the wp-includes/functions-post.php file.

in the wp_get_recent_posts() function, change this:

$sql = “SELECT * FROM $wpdb->posts WHERE post_status IN ('publish', 'draft', 'private') ORDER BY post_date DESC $limit”;

to this:

$sql = “SELECT * FROM $wpdb->posts WHERE post_status IN ('publish', 'draft', 'private', 'static') ORDER BY post_date DESC $limit”;

Now, in the wp_update_post() function, look for this block of code:

// Escape data pulled from DB.
$post = add_magic_quotes($post);
extract($post);

and insert this block underneath it:

// XML-RPCs apps can't return “static” post status,
// so we have to work around it
$page_status = NULL;
if($post_status == “static”)
$page_status = “static”;

And follow that up by looking for this block:

// Now overwrite any changed values being passed in. These are
// already escaped.
extract($postarr);

and insert this block underneath it:

// set post_status static if this is a page
if($page_status)
$post_status = $page_status;

Fair warning: this works in my limited testing, but don’t blame me if you try it and it breaks something. You’d be a fool to mess with this on a live install, so don’t.

tags: blog, blogg as cms, blogg as content management system, blogging, cms, content management system, ecto, hack, hacking, hacking wordpress, php code, wordpress, wordpress hack, wordpress hacks, wordpress pages, xml rpc, xmlrpc

I want Wikipedia to have an API, but it doesn’t. Some web searching turned up Gina Trapani’s WikipedizeText, but that still wasn’t exactly what I wanted. A note in the source code, however, put me back on the trail to the Wikipedia database downloads, and while that’s not what I want, I did learn that they’ve got a table of just the article titles (over 1.2 million of them) in their downloads.

Some of this is related to my interest in making Wikipedia work better in an academic library context, but I’ve got other plans too. With luck, we’ll see a beta release this week.

tags: api, application programming interface, article titles, database download, free encyclopedia, hacking, rss, web services, webservices, wikipedia, xml

The MAKE: podcast pointed me to gumstix — really small computers built for hacking. Cool.

tags: gumstix, hacking, hardware hacking, linux, linux computer, make magazine, make podcast, tiny, tiny computer, tiny linux

From O’Grady’s PowerPage:

I have no interest in true hacking (i.e. rummaging through people’s private junk) although viewing random unprotected IP cameras around the world in public places and controlling their panning and zoom functions is kind of mind-blowing. There are a ton of fun GHacks out there – like spelling out words in pictures using Google image search, and the Google poetry generator, or the news map generator etc. Check out more than a dozen Google Hacks here.

Sort of related: put an “&btnI=I%27m+Feeling+Lucky” at the end of your query URL to invoke Google’s “I’m feeling lucky” option. This is incredibly useful when using Google to search WorldCat, like this.

tags: google, google hack, google hacks, google image search, hacking, ip cameras, powerpage