1

This question already has an answer here:

I have registered a custom Post Type via register_post_type(), and about 45 Custom Fields via add_meta_box() function, within the theme.

Custom Post Type Args:

    'labels'             => $labels,
    'description'        => __( 'Custom Post Type', 'hg' ),
    'public'             => true,
    'publicly_queryable' => true,
    'show_ui'            => true,
    'show_in_menu'       => true,
    'query_var'          => true,
    'rewrite'            => array( 'slug' => 'testtype' ),
    'capability_type'    => 'post',
    'has_archive'        => false,
    'hierarchical'       => true,
    'menu_position'      => null,
    'supports'           => array( 'title', 'editor', 'thumbnail' )

Everything works fine there, and a few tests by manually creating posts via the Admin Editor for this post type proves such.

I written a script to batch import about 20,000 or more into this custom post type and the registered custom fields. Before I go on, I wish to point out that I first ran this script with just 50 or so of the entries, and it imported and everything worked fine.

So, once the 20k posts of the custom post type were imported, I return to my admin and hit on the Custom Post Type via admin (Auto-generated Custom Post Type UX) - and I receive a blank page!

I have researched, and as a result increased PHP memory limit, WP memory limit, WP Max memory limit, and PHP execution time. After which, I now receive the generic WordPress 404 instead of just a blank page.

Here's what I added to wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '2560M' );
set_time_limit(120);

I have also concluded it is nothing to do with the theme or plugins. Once I manually remove all 20k posts from the database via phpMyAdmin, the edit.php page is back in working order. Is this a query overload?

Please help!

Thanks in advance!

marked as duplicate by birgire, Nicolai, Mayeenul Islam, Pieter Goosen, Community Dec 21 '15 at 14:09

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • The problem here is most likely that the cpt is hierarchical so the parent dropdown is loading all the 20k pages. – birgire Dec 21 '15 at 11:42
  • @birgire I totally forgot about that post, the worst part is that I even submitted an answer to that :-) – Pieter Goosen Dec 21 '15 at 13:19
  • hehe it's easy to forget - I've sometimes googled work related problems that I had already solved here, but had totally forgotten about it ;-) @PieterGoosen – birgire Dec 21 '15 at 13:33
  • 1
    @birgire hahahaha, now I don't feel alone anymore. Happens to me as well – Pieter Goosen Dec 21 '15 at 13:53
2

I do not think that there is any sane way to sort this issue with the amount of posts you have except than setting hierarchical to false. Setting hierarchical to true has huge impact on performance and aren't really meant for use in custom post types.

If you do not need a parent/child relationship between posts like the build-in post type page have, then you should really set hierarchical to `false. If you really need that relationship, then you are pretty much stuffed unfortunately. With the amount of posts you have I cannot see any viable solution to sort your issue

Just a tip, remember to flush your permalinks after setting hierarchical to false

  • That solves the load issue and allows me to use the UX, thanks. I've seen this solution to similar issues before but for some reason it went over my head and I didn't try it. Thanks again! – Joshua4550 Dec 21 '15 at 14:07

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