The issue:
When creating a custom taxonomy archive and you want to modify the posts_per_page setting. The first page works just fine, but subsequent pages will take into account the blog’s posts per page setting. This means that while the first page will show the number of taxonomy terms specified by the “posts_per_page” query_posts() variable, subsequent pages may return a 404 error or just mess up your pagination. This may only be an issue when using a page template such as taxonomy-{$taxonomy}.php

Why this occurs:
Specifically, I’ve no idea. Generally this is because the WordPress query is determining what template to show before it ever gets to the page template. The query takes the number of taxonomy terms to show for a given taxonomy, looks at the blog option posts_per_page and then determines what template to serve (404 or your custom one).

How to fix:
The solution I found was to filter the blog option posts_per_page if viewing the custom taxonomy. It’s pretty simple and looks like this:

[php]
add_filter( ‘option_posts_per_page’, ‘tdd_tax_filter_posts_per_page’ );
function tdd_tax_filter_posts_per_page( $value ) {
return (is_tax(‘custom-taxonomy’)) ? 1 : $value;
}
[/php]

The filter attaches to the posts_per_page filter hook. It then returns a “1” for one post per page if it’s the taxonomy archive I’m concerned about, otherwise it returns the default value.

This is a pretty advanced post, but it was causing me issues for about half an hour, so I thought I’d share quickly.

Here’s the deal: I wanted to add a submenu to an existing custom post type. Right away, when creating a custom post type with public or show_ui set to true, WordPress will create a new top-level menu item, with a submenu item of “Add .” I wanted to be able to hook into that, and add a new sub-menu item called “settings”

Already in the plugin, I had created a custom post type:
[code lang=”php”]
register_post_type( ‘tdd_beans’, ‘tdd_beans_register_post_type’ );
[/code]

The details of my beans post-type are unimportant. What is important is the handle. In all cases, it’s the first parameter that you pass to register_post_type() — in this case, beans.

[code lang=”php”]
function tdd_beans_menu(){
add_submenu_page( ‘edit.php?post_type=tdd_beans’, ‘Beans Settings’, ‘Settings’, ‘manage_options’, ‘tdd-beans-settings-menu’, ‘tdd_beans_view_settings’ );
}
add_action( ‘admin_menu’, ‘tdd_pb_beans_menu’ );
[/code]

The add_submenu_page() function takes these parameters:

1. $parent_slug: The magic is that it requires that whole edit.php whatnot in order to work. At least right now, although I believe that may be a bug in WordPress. Future versions may only require the slug (tdd_beans). In any case, it’s the slug for the parent page
2. $page_title: This is what goes between the <title> tags
3. $menu_title: What shows up in the menu (keep it short)
4. $capability: This maps to a WordPress capability that will be required to access this sub-menu. It should probably map to whatever the capability is for your custom post type. Sub-menus will continue to display even if their parent menu is unavailable due to permissions
5. $menu_slug: Put your own menu slug here for referencing this menu item elsewhere.
6. $function: Lastly, this is the function that will echo stuff to the page.

[code lang=”php”]
function tdd_beans_view_settings(){
echo ‘<div class="wrap"><h2>Hello World (inc. beans)</h2></div>’;
}
[/code]