Custom post type – posts list – white screen of death

by

i am getting a weird error – white screen in the list of posts
for a specific Custom post type (just for that one)

  • tried deactivating all the plugins
  • tried checking for error (debugging = true)

Still nothing
the page just doesnt echos anything… (nothing in source too)

I am talking about such a url in the admin:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt

Here is register_post_type part i am using: 

function register_submodelcpt() {
    $labels = array(
        'name'                  => __('Sub Models', THEME_NAME),
        'singular_name'         => __('Sub Models', THEME_NAME),
        'add_new'               => __('New Model', THEME_NAME),
        'add_new_item'          => __('Add new Model', THEME_NAME),
        'edit_item'             => __('Edit Model', THEME_NAME),
        'new_item'              => __('New Model', THEME_NAME),
        'all_items'             => __('All Sub Models', THEME_NAME),
        'view_item'             => __('Watch Model', THEME_NAME),
        'search_items'          => __('Search Models', THEME_NAME),
        'not_found'             =>  __('No Models found', THEME_NAME),
        'not_found_in_trash'    => __('No Models found in trash', THEME_NAME), 
        'parent_item_colon'     => '',
        'menu_name'             => __('Sub Models', THEME_NAME),

    );

    $args = array(
        'labels'                => $labels,
        'public'                => true,
        'publicly_queryable'    => true,
        'show_ui'               => true, 
        'show_in_menu'          => true, 
        'query_var'             => true,
        'rewrite'               => array('slug' => 'submodels'),
        'capability_type'       => 'post',
        'has_archive'           => true, 
        'hierarchical'          => true,
        'menu_position'         => 5,
        'menu_icon'             => get_stylesheet_directory_uri().'/images/cpt/subcars.png',            
        'supports'              => array('title', 'thumbnail', 'revisions', 'page-attributes')
    ); 
    register_post_type('submodelscpt',$args);
}
add_action('init', 'register_submodelcpt');

Did anyone encounter such an issuse?
can you think of a reason this might happen?

Another weird thing
when i change this:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt

To this:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt&orderby=date&order=desc

The posts list loads correctly…

4 Answers
4

This is to extend your own answer:

It appears that when “hierarchical” is set to true, each post behaves like a page. I am quoting here so I don’t really understand why it matters but changing this line remove the problem.

Here is what the codex says about the hierarchical parameter

hierarchical

(boolean) (optional) Whether the post type is hierarchical (e.g. page). Allows Parent to be specified. The ‘supports’ parameter should contain ‘page-attributes’ to show the parent select box on the editor page.

Default: false

Note: this parameter was planned for Pages. Be careful, when choosing it for your custom post type – if you are planning to have many entries (say – over 100), you will run into memory issue. With this parameter set to true WordPress will fetch all entries of that particular post type, together with all meta data, on each administration page load for your post type.

When a custom post type is set as hierarchichal, its behavior will be same as the build in post type page. Like pages, WordPress tries to build a tree to display the correct hierarchical tree with parent-child relationships in the back end. As you might have noticed, pages are not sorted by date in the back end, but by this parent-child relationship. This behavior you can easily see when visiting the Page page in back end.

This operation is very expensive as WordPress needs to get each page ( or post from a hierarchical post type ) on every page load and then look for that specific page’s/post’s parent and child pages to build a the correct tree for that specific page/post. If you have a large amount of pages or posts in your hierarchical custom post type, the query simply becomes to big and exceeds memory limits or times out, which leads to a fatal error, hence the WSOD.

Non-hierarchical post types like the build in post type post don’t have such a hierarchy as non-hierarchical post type posts can’t have child posts. Because there is no need to build a parent-child relationship tree (for obvious reasons), WordPress simply queries 20 (IIRC) posts per page ordered by date in the back end and displays them in contrast to hierarchical post type posts where WordPress has to query all posts at once, build a tree and then display only an x amount on a posts grouped according to their parent-child relationship. You can check this behavior in the Post page in the back end

So setting a custom post type to hierarchical tells WordPress that it should build a list/tree of posts grouped by their parent-child relationship and return those posts in that configuration. Setting a custom post type to non-hierarchical, you are telling WordPress to skip the whole relationship thing and to just return an x amount of posts per page ordered by post date

I hope this make a bit more sense to you why you should avoid making custom post types hierarchical, and why that is also stated in the codex

Leave a Comment