Tag Archives: date

Custom Post Type Archives Part 5

I certainly didn’t expect a part 5, but my monthly archive links suddenly stopped working! I hadn’t made any theme changes related to them so this was a most surprising problem.

First of all, I tried to find out which template file was getting called, but my debug statements in various files weren’t being called at all. Finally, a close look at the template hierarchy revealed that a 404 error goes straight to the 404 page, and there it was. This suggests that the query couldn’t find anything. Printing out the array of query variables made me realize that the URL segments were being mapped to the wrong variables.

This was most unexpected, and for some unknown reason, even reactivating the Custom Post Type Archives plugin didn’t work.

A lot of Googling revealed this discussion which suggests <domain>/2010/?post_type=cpt works. It was time to find out more about how URL rewriting works.

The Codex didn’t have much information about them, just some shallow user level instructions on what they look like and how to activate them. I did remember reading before that the rewriting was done by parsing the URL and giving everything to index.php to handle. Since I could get my custom post types to display with the right template file when using ugly URLs, getting the rewrite rules to work would be the key to the solution.

The code for rewrites is in wp-includes/rewrite.php, which is where the WP_Rewrite class is defined. Looking through the whole file gave me a better understanding of what’s happening. It seems that lots of rules are actually stored internally. These rules convert the pretty links into query variables which the rest of the WordPress framework can understand.

The function reference for WP_Rewrite explained the variables and the filters, which could be used to modify the rewrite rules. With this clue, I went through the source code of the plugin to find where it adds the rewrite rules. I then modified it to suit my own purposes.

The code is as follows.

function register_post_type_rewrite_rules($wp_rewrite) {

	$args = array('public' => true, '_builtin' => false);	//get all public custom post types
	$output = 'names';
	$operator = 'and';
	$post_types = get_post_types($args,$output,$operator);

	$url_base = ($url_base == '') ? $url_base : $url_base . '/';
	$custom_rules = array();

	$post_types = implode('|', $post_types);
		$custom_rules = array( "$url_base($post_types)/([0-9]+)/([0-9]{1,2})/([0-9]{1,2})/?$" =>
				'index.php?post_type_index=1&post_type=' . $wp_rewrite->preg_index(1) . '&year=' . $wp_rewrite->preg_index(2) . '&monthnum=' . $wp_rewrite->preg_index(3) . '&day=' . $wp_rewrite->preg_index(4),		//year month day

								"$url_base($post_types)/([0-9]+)/([0-9]{1,2})/?$"  =>
				'index.php?post_type_index=1&post_type=' . $wp_rewrite->preg_index(1) . '&year=' . $wp_rewrite->preg_index(2) . '&monthnum=' . $wp_rewrite->preg_index(3),			//year month
								"$url_base($post_types)/([0-9]+)/?$" =>
				'index.php?post_type_index=1&post_type=' . $wp_rewrite->preg_index(1) . '&year=' . $wp_rewrite->preg_index(2)	//year
							);

	$wp_rewrite->rules = array_merge($custom_rules, $wp_rewrite->rules); // merge existing rules with custom ones
	
	return $wp_rewrite;
}

add_filter('generate_rewrite_rules', 'register_post_type_rewrite_rules', 100);

First, get all public custom post types. This is explained in the function reference for get_post_types()

Next, add rewrite rules for year/month/day, year/month, and year URL permalinks to a custom array.

Finally, merge this array to the existing one and return the entire set of rules.

Once again, custom post type archives work like they’re supposed to. Phew!

Read about the next improvement to the custom post type archives widget at the Custom Post Type Archives jQuery Accordion post.

Custom Post Type Archives Part 4

Phew, custom post type archives are causing lots of problems. Three separate posts about them already, and the plugin was the one which broke WordPress 3.1. Well the updated version doesn’t. However, this led to a thought. Since it’s supposed to be built in, could I do it without using the plugin? After all, I was just after some very basic functionality. The answer turns out to be yes, well, almost.

Enabling the Feature

There is an attribute has_archive in the register_post_type() function which activates the archives feature, but it defaults to false. I added the code in to set this to true. This information was from Mark McWilliams, the same post also gave some hints on how the permalinks would look like.

Disabling the Plugin

The next step was to disable the plugin and see what stops working. Looks like the sidebar has some problems, which also prevents the admin bar from loading properly. The month listing from the custom widget wasn’t appearing at all.

Fixing the Widget

The widget depends on the custom get_post_type_archives() function, explained in Part 2, to do its magic.

Using a debug echo statement and commenting out suspect lines, I found the problem in one of the custom functions provided by the plugin. It returns the permalink of the post type. This can actually be generalized as

get_bloginfo('url') . '/' . $post_type . '/';

Now I get output with a link to the archives by date, but it wasn’t showing the correct number of months. Why??

Filter getarchives_where

Even the plugin just let the built in WordPress function wp_get_archives() do the hard work, so why did it work with the plugin activated? A closer look at the function itself, and the way it was used by the plugin, revealed that wp_get_archives() was insufficient to get archives by post type. It applies a filter to get the correct SQL Where clause. This was used by the plugin.

Since I only want that function, I copied the entire thing over to my own functions.php file.

function pta_wp_get_archives_filter($where, $options) {
	if(!isset($options['post_type'])) return $where; // OK - this is regular wp_get_archives call - don't do anything
	
	global $wpdb; // get the DB engine
	
	$post_type = $wpdb->escape($options['post_type']); // escape the passed value to be SQL safe
	if($post_type == 'all') $post_type = ''; // if we want to have archives for all post types
	else $post_type = "post_type = '$post_type' AND"; // otherwise just for specific one
	
	$where = str_replace('post_type = \'post\' AND', $post_type, $where);
	
	return $where;
}
add_filter('getarchives_where', 'pta_wp_get_archives_filter', 10, 2);

Now the archive links work and the correct number of links are displayed, depending on what the post type is!

Archive Templates

This approach led to my custom post types being displayed incorrectly as they now use the archive.php template file. It only displays the excerpts for archives, so the shortcodes and meta data no longer show up. As each post will be very short in length, I want the full content and meta data to show up, just like it does on the main page listings.

The solution to this was simply to copy archive.php to the child theme, rename it archive-{post-type}.php, and change the function call to the loop so that it calls my previously written custom loops.

Page Templates

{post-type}-template.php were previously used for both the display of the full listing as well as the archive pages. With WordPress 3.1, archives are handled by the archive template pages. Thus, the if-else conditions which handled query_posts() can be removed. The page templates will be used just for display of all the custom posts.

Conclusion

With all these changes, I can now use one less plugin and use more of the functionality available in WordPress Core.

Custom Post Type Archives Part 5