A significant player in my decision to go to work at Crowd Favorite around 5 months ago was their value of and commitment to Open Source Software, especially the platforms they work with most often.  WordPress is predominantly that platform.  Four and a half months later, my first patch has landed in WordPress trunk and will be included in the stable release of WordPress 3.5.

It is somewhat minor, but fixes some illogical behavior that has potentially forced some to create nasty workarounds.

I came across this when using a custom taxonomy to create walled areas of content within a site to give slightly different “look & feel”, menus, and layouts to each area.  Essentially creating miniature subject specific blogs that leverage a single WordPress backend for content entry and organization.

The final piece was to add the page post type to the taxonomy registration. So in my own sandbox I started playing with the custom taxonomy registration and found what I thought was a problem.

If you register a custom taxonomy for a few post types like this…

function register_custom_tax() {
	register_taxonomy('my-custom-tax', array('post', 'page'), array(
		...
	);
}
add_action('init', 'register_custom_tax');

Then proceed to add post/pages to the registration, they all show up in the archive listing and everything is fine.  Now you decide you don’t want that taxonomy applied to ‘pages’.  So you remove it from the registration.

function register_custom_tax() {
	register_taxonomy('my-custom-tax', array('post'), array(
		...
	);
}
add_action('init', 'register_custom_tax');

At this point I assumed that pages would no longer show up in the listing, and I was wrong.  Even though you removed the post type from the registration, items of that post type that were previously had your taxonomy attached still show up in the listing.  Ok, so now we go and remove the taxonomy from those items, and everything is fine right? Wrong again!  When you remove the post type from the registration, the UI piece that lets you control that taxonomy disappears from the post type edit screen.

If no specific post_type is filtered in, query.php assumed 'any' post_type.  My patch instead does an inclusive search for all post types that are registered to queried taxonomies in this situation. So if you do a query for a given taxonomy, it will default to the registered post types instead of 'any'.

[the changeset]

Follow me on Twitter ( Follow @jondavidjohn ) or subscribe via RSS ( ).