My project involves a custom post type for real estate and in this post I’d like to show you some tricks on:

• Working with custom post types and permalinks (a.k.a the 404 issue)
• Using WP_Query to find your custom-typed post
• Adding custom meta boxes to your edit post screen

We’ll deal with more code than images today so get a clean copy of WordPress 3.0 (Nightly build) to experiment upon. We’ve seen the register_post_type function already which is clearly explained in the Codex and even more clearly in the source code so I expect you read those bits if you haven’t.

Permalinks with Custom Post Types

This is one side of the feature which is not thoroughly explained in the source code, and I’ve seen many people end up with 404 pages while their permalinks point correctly. The trick here is in the rewrite and _builtin part. The _builtin parameter simply tells WordPress that the new post type we’re registering is built in. Most of us specified it as true (and I did too in my previous post) as part of the code was just copied from the core part where Posts, Pages and Attachments were being registered, and those are built-in. Built-in post types are handled differently by the core, so make sure you switch that option to false.

The rewrite parameter is not too tricky if you went through the sources, it’s simply an array to specify how would you like your permalinks to look like for this specific custom post type. Let’s look at an example:

register_post_type('property', array(
	'label' => __('Real Estate'),
	'singular_label' => __('Property'),
	'public' => true,
	'show_ui' => true, // UI in admin panel
	'capability_type' => 'post',
	'hierarchical' => false,
	'rewrite' => array("slug" => "property"), // Permalinks format
	'supports' => array('title','author')
));

Straightforward. Now if you registered your custom post type this way, your edit post screen should show you the correct permalink, i.e. /property/post-name which now gets handled by the core rewrite module so you’ll be able to see the contents of your post if you click on View Page. There, no more 404 errors!

One other way around this would be to use the add_permastruct function of the $wp_rewrite object and manually define what kind of permalink structure you would like to use for your custom type posts. Don’t forget to filter post_type_link if you do.

So how about using different templates for custom post types? Well, you could do that somewhere inside your theme, but I like to hook to the template_redirect action, so here it goes:

add_action("template_redirect", 'my_template_redirect');

// Template selection
function my_template_redirect()
{
	global $wp;
	global $wp_query;
	if ($wp->query_vars["post_type"] == "property")
	{
		// Let's look for the property.php template file in the current theme
		if (have_posts())
		{
			include(TEMPLATEPATH . '/property.php');
			die();
		}
		else
		{
			$wp_query->is_404 = true;
		}
	}
}

Note: It has become much easier to use templates with custom post types with WordPress 3.1 and especially 3.2. Take a good look at the new Template Hierarchy ;)

What we did here is looked for our custom post type and redirected it to property.php located in the currently active theme (assuming it’s there of course). This part may be done in several different ways and mine’s not the best, but it gives you an idea of how to capture custom posts requests. Let’s move on to querying.

WP_Query and Custom Post Types

This is easier than you think, there’s absolutely no tricks in here, and it’s all straight forward. Just like you used to search for posts and pages, you search for your custom post name, in my case it’s property:

global $wp_query;
$wp_query = new WP_Query("post_type=property&post_status=publish&posts_per_page=5");

That’s it. Custom post types are handled pretty much the same way in WordPress loops, this means that you’re free to use template tags such as the_title(), the_permalink() and so on.

Metaboxes for Custom Post Types

Metaboxes are just as easy as queries. Just take a look at the $page parameter of add_meta_box. That’s where you have to clearly state which screen should hold your metabox. In my case it’s property, so here’s what I got:

add_meta_box("my-property-meta", "Property Options", "my_property_meta",
    "property", "side", "low");

function my_property_meta() { echo "Boo!"; }

Awesome, isn’t it! It’s also a good idea to fire add_meta_box in the admin_init hook ;) Here’s a sneak preview of what we’ve got:

I’m not sure where all this is going, but I see people getting excited about this. I see other people who don’t care and say they could do all the same stuff in the edit post page, then extend all the stuff using custom fields. That’s true, until you got a say not very computer literate client. I’d like to see somebody explain custom fields to those types ;) I didn’t manage to, maybe I haven’t got the skills, but hey, isn’t it easier to click, drag & drop, etc? I mean you do use your mouse, don’t you?

Anyways, let’s see where this goes. I’ll be working on the real estate type for some time but I’d like to hear out your ideas and perhaps some written examples of how we (the themes and plugins developers) could benefit from custom post types and make our clients a tiny bit more happy. Cheers!

Working Example: Podcast 3.0

Here’s something I’m working at and will hopefully finish this in time for WordPress 3.0. You can look through the source code to see how the Podcast custom post type is registered, the way a meta box is added to it, and the way custom taxonomy is used together with the custom columns in the edit post screen.

There’s a template_redirect action which fires a theme file called podcast.php which would be the template used to display podcasts so you’ll get an error if you don’t create such a file in your theme. Feel free to use the standard template tags inside the file, it goes as an ordinary WordPress loop.

Download: Podcast 3.0 (update:outdated) for WordPress.

The WP_Rewrite article in the Codex pretty much explains everything, except that it’s pretty difficult to add custom rewrite rules to .htaccess via WordPress, as even wp_query object’s non_wp_rules is handled like this:

RewriteRule ^Pattern /Substitution [QSA,L]

With the trailing slash and “Query String Append + Last Rule” hard-coded in the WordPress core. Well here’s how I managed to do Permanent 301 redirects to absolute URLs.

First of all add an action and a filter. My plugin code is wrapped up in a class (and I encourage you to do the same for maximum compatibility):

add_action('generate_rewrite_rules', array(&$this, 'generate_rewrite_rules'));
add_filter('mod_rewrite_rules', array(&$this, 'mod_rewrite_rules'));

The generate_rewrite_rules action is the place where we will add some rules to non_wp_rules, then modify (or customize) in the mod_rewrite_rules filter. Here’s the generate_rewrite_rules function which I’m hooking to:

function generate_rewrite_rules() {
	global $wp_rewrite;
	$non_wp_rules = array(
		'simple-redirect/?$plugin_name' => 'http://google.com',
		'one-more-redirect/?$plugin_name' => 'http://yahoo.com'
	);

	$wp_rewrite->non_wp_rules = $non_wp_rules + $wp_rewrite->non_wp_rules;
}

I used the string ‘plugin_name’ in every rule just to make sure that I don’t edit anyone else’s rewrite rules further on. You’ll understand what I mean once you read the next part of the code. Also make sure you use single quotes as double quotes would make $plugin_name a variable.

function mod_rewrite_rules($rules) {
	$rules = preg_replace('/^(RewriteRule ^.*+/?$)plugin_name (/)(.*) ([QSA,L])$/im', '1 3 [R=301,L]', $rules);
	return $rules;
}

There you go, so the rules are modified using a simple regular expression, which in .htaccess will turn out to be:

RewriteRule ^simple-redirect/?$ http://google.com [R=301,L]
RewriteRule ^one-more-redirect/?$ http://yahoo.com [R=301,L]

The regex is not perfect though, just a sketch. I believe it will not work if the RewriteBase is not set to / but you get my point ;) The rules are written to .htaccess when you access or save changes in the Permalinks section in the admin panel or whenever wp_rewrite object’s flush_rules is called. Now be careful, you cannot call flush_rules anywhere outside the admin panel (although you may try to link with a few includes – wp-admin/includes/misc.php and wp-admin/includes/files.php before flushing) but in my case I’ll just go with the publish_post hook.

Anyways, that being said, after writing my post announcements to Twitter via Twitter Friendly Links some peeps shouted out that I was returning 404 errors on all of my short links. Strange, thought I, as I was able to see everything fine. Looking at the settings of the plugin I realized that I, as a logged in user, weren’t looking at cached pages, so I turned that off and guess what! I got those 404s. Creepy! After a little talk over Twitter and IM with the guys at W3 Edge, I started to look through the caching plugin code. It’s so well-written and I’ve actually learned a couple of techniques out there! Anyways, the reason I was getting 404s was because W3 TC looked at the $wp_query object and it’s $is_404 variable, which I don’t know why (Frederick from W3 Edge mentioned a redirection issue with WordPress) was returning true on all of my Twitter friendly links!

I figured out that the template_redirect hook (which is not documented in the WordPress Codex at all) didn’t quite do what I wanted it to. The easiest way out was adding a couple of lines before the redirect actually happened:

global $wp_query;
$wp_query->is_404 = false;

And guess what, it worked! This may be not the smartest decission but hey, it’s working! One more workaround would be adding a regular expression to the W3 Total Cache page settings, exclude “[0-9]+/?$” which would not cache any .com/1234 queries, but that’s not so reliable for a couple of reasons. First, why not cache if we can cache? And second, what if we’re using Twitter Friendly Links in alphanumeric mode? That would mean “[0-9a-zA-Z]+/?$” which would probably match for all the other top-level pages, thus we’re losing all the benefits from caching. Meh!

I guess this is not the only place where the template_redirect action would return a 404. Some plugins that define their own permalinks through the template_redirect hook (WP Polls for poll results for instance, not sure though) will also get 404s if they don’t set it to false in $wp_query. Many wordpress websites have profile pages which are not actual pages in the database, but are handled through the template_redirect action for .com/profile_name sort of permalinks which is indeed cool. I’m actually planning on using it with one of my upcoming projects and I’m really glad I sorted it out.

So the big shoutout goes to W3 Total Cache and the W3 Edge team!

$wp_multi = array(
    "example.org" => array(
        "DB_NAME" => "example",
        "DB_USER" => "example-user",
        "DB_PASSWORD" => "example-pass",
        "DB_HOST" => "example-host"
    ),

    "example-two.org" => array(
        "DB_NAME" => "example-two",
        "DB_USER" => "example-two-user",
        "DB_PASSWORD" => "example-two-pass",
        "DB_HOST" => "example-two-host"
    )
);
$server_name = str_replace("www." , "", strtolower($_SERVER["SERVER_NAME"]));
$wp_settings = $wp_multi[$server_name];

There. And we also got rid of an error we’d get if we typed eXamPle.org in the address bar.

I’m thinking of a way to wrap this up in some plugin or a little hack, or perhaps a super-short step-by-step tutorial, so that setting up multiple websites one a single wordpress bundle would be easier than ever. If you have any suggestions feel free to speak ;)