(I've posted this on the normal stack exchange, but it was suggested that I put it here too. Glad to know this place exists... :))

So, I've been all over the internet trying to figure out what is going on with a couple of sites that I have, and I think I've finally been able to track it down...


I want to first make sure I'm doing everything correctly before going to Wordpress and suggesting that there's a small bug that is causing all sorts of annoyance to me and quite possibly a bundle of others.

The crux of the problem is that I have multiple Wordpress (WP 3.5.1) sites that have a custom post type "products" on them. I've defined the custom post type as follows:

/* Create custom Products taxonomy */
function create_custom_products_taxonomies() {
register_post_type( 'products',
        'labels' => array(
            'name' => __( 'Products' ),
            'singular_name' => __( 'Product' ),
            'add_new' => __( 'Add New' ),
            'add_new_item' => __( 'Add New Product' ),
            'edit' => __( 'Edit' ),
            'edit_item' => __( 'Edit Product' ),
            'new_item' => __( 'New Product' ),
            'view' => __( 'View Product' ),
            'view_item' => __( 'View Product' ),
            'search_items' => __( 'Search Products' ),
            'not_found' => __( 'No products found' ),
            'not_found_in_trash' => __( 'No products found in Trash' ),
            'parent' => __( 'Parent Product' )
        'public' => true,
        'hierarchical' => true,
        'menu_position' => 20,
        'publicly_queryable' => true,
        'query_var' => true,
        'rewrite' => array("slug" => "/products", "with_front" => false),
        'supports' => array('title', 'author', 'thumbnail', 'editor', 'excerpt', 'comments', 'page-attributes', 'common', 'custom-fields', 'revisions'),
        'register_meta_box_cb' => 'products_meta_box',
        'taxonomies' => array('products')
        'hierarchical' => true,
        'label' => __(ucfirst('products')),
        'show_in_nav_menus' => true,
        'rewrite' => array('slug' => 'categories')
add_action('init', 'create_custom_products_taxonomies'); // Create the necessary custom taxonomies for products

The problem comes in where I'm trying to access the listing page for that custom post type. The analogous page for posts is "Posts" in the admin sidebar on the left side of an admin page. The name of the page that I have for my custom post type listing is, appropriately enough, "Products". When accessing that page, it takes a literal AGE to load. Okay, so it's really something like 8-12 seconds from load to load, where any other page on the admin side will load in about 1-2 seconds. Additionally, the page will frequently time-out and throw the generic error about "Service being temporarily unavailable". (Not sure where this error is coming from. Apache, Wordpress, etc)

This aberrant behavior led me to try and debug the admin side of my site. I found the plugins "Debug Bar" and "Debug Bar Extender". Using these plugins in tandem, and after loading the appropriate page, I can view the query for that page, but the query arguments are the more important comparison in this case:

-- for the Posts listing page --


-- for the Products listing page --


In this case, the number of posts to display on the "Posts" page (set in the Screen Options tab at the top of the page) is set to 400. Looks good.

The number of products to display, however, (set in the same way, but on the Products page) has been set to 25. Regardless of this fact, the posts_per_page query argument for the Products page (shown above) is set to -1, which means Wordpress is grabbing ALL of the posts with my custom post type "products", but then only display the requisite 25. This happens in an identical manner for the multiple pages (pagination) associated with my list of products.

This seems bogus to me. Thus my question: Have I set up (registered) the custom post type incorrectly? I am seeing this same behavior when I disable all other plugins on my site, and I am only using the register_post_type function to set up this custom post type. If something wrong is happening here, (as it seems to me to be) I'll report it to Wordpress. If not though...I didn't want to "bug" them unnecessarily. :)

I've seen this behavior on multiple sites, but the reason that the admin page-load time stuck out to me on this site is because I have 3k+ posts with this custom post type, whereas on other sites employing my custom post type registration code only have ~300-400 products on them.

Thanks to anyone willing to help and/or comment.

  • 1
    Oddly, remove the hierarchical parameter, and the problem resolves itself.
    – vancoder
    Apr 16, 2013 at 23:38
  • Same issue (?) - no answer: wordpress.org/support/topic/…
    – vancoder
    Apr 16, 2013 at 23:51
  • The screen options value determines how many items to view on the administration page only, the value stored in the screen options is not used to determine how many items to view on that post type's given archive page.
    – t31os
    Apr 17, 2013 at 10:18
  • Nailed it, vancoder. New query arguments: post_type=products&posts_per_page=25 Thanks a bundle. Apr 17, 2013 at 16:15
  • 1
    Please add your solution as an answer to this question and accept it, otherwise the question will pop up every now and then.
    – tfrommen
    Apr 28, 2013 at 15:42

1 Answer 1


Removing the hierarchical parameter from the register_post_type function call did the trick, as per vancoder's suggestion. On the back end, looking at what the hierarchical option does (set the new post type to behave like the page post type) tells me that it probably shouldn't have been set in the first place.

  • Solved my problem! I had 13K posts of the CPT, and at that point it completely failed to load the posts in the admin panel. Looks like it is not possible (or at least, not without unnecessarily powerful hardware) to have a high number of hierarchical posts.
    – Pete
    Feb 19, 2015 at 17:13
  • omg... i dont understand why (and would love to) but it works! man... i searched the web using a 100 different search terms to find this
    – Sagive
    Apr 21, 2015 at 21:39
  • This is not really a solution to the problem, but removing the hierarchical makes the post type behave differently. There are valid scenarios where you want a hierarchical post type and a fast wp admin.
    – alpipego
    Nov 29, 2016 at 8:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.