Make WordPress Core

Opened 12 years ago

Closed 12 years ago

Last modified 9 years ago

#20329 closed defect (bug) (invalid)

Custom Post Type - 500 error when viewing list in WP backend

Reported by: rivkadr's profile rivkadr Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.3.1
Component: Administration Keywords:
Focuses: Cc:

Description (last modified by dd32)

This does not appear to be occurring under administrator roles; only for lesser roles that have been given edit privileges for the custom post type in question.

Appears to be the same as what has been reported in this thread here:

Important things to note:

  • adding &orderby=date to the end of the url allows the list to load
  • we have multiple installs of this database (dev, local, and live server). The loading of the list works on two of those installs, both of which contain only 250 posts in that custom post type. The one install that keeps throwing up the 500 error has 1500 posts in it. That's the only difference between the 3 installs (all users, permissions, and server settings are the same)

The custom post type was created using the following code:

$labels = array(
			'name' => _x('Sites', 'post type general name'),
			'singular_name' => _x('Site', 'post type singular name'),
			'add_new' => _x('Add New', 'site'),
			'add_new_item' => __('Add New Site'),
			'edit_item' => __('Edit Site'),
			'new_item' => __('New Site'),
			'view_item' => __('View Site'),
			'search_items' => __('Search Sites'),
			'not_found' =>  __('No sites found'),
			'not_found_in_trash' => __('No sites found in Trash'), 
			'parent_item_colon' => ''
		$args = array(
			'labels' => $labels,
			'public' => true,
			'publicly_queryable' => true,
			'show_ui' => true,
			'menu_position' => 5,
			'supports' => array('title', 'thumbnail', 'page-attributes', 'revisions'),
			'taxonomies' => array('post_tag','sitestatus', 'selection-status'),
			'hierarchical' => true,
			'capability_type' => 'site',
			'capabilities' => array(
				'publish_posts' => 'publish_sites',
				'edit_posts' => 'edit_sites',
				'edit_others_posts' => 'edit_others_sites',
				'delete_posts' => 'delete_sites',
				'delete_others_posts' => 'delete_others_sites',
				'read_private_posts' => 'read_private_sites',
				'edit_post' => 'edit_site',
				'delete_post' => 'delete_site',
				'read_post' => 'read_site',
		register_post_type('site', $args);

Change History (5)

#1 @dd32
12 years ago

  • Description modified (diff)

Cna you please check your PHP error logs to see what the error is that you're running into?

I believe it'll either me Memory usage, or timeouts, specifically due to the large number of items you have, and the many "parent dropdowns" present in the Quick Edit.. but without the specific error, it's hard to determine.

Version 0, edited 12 years ago by dd32 (next)

#2 @rivkadr
12 years ago

No errors in the PHP log.

And the number of items in the "parent dropdowns" doesn't make any sense -- why then does the page load fine if you add &orderby=date to the end of the url? It's the same data being loaded.

#3 @dd32
12 years ago

why then does the page load fine if you add &orderby=date to the end of the url?

Good point, I'm not sure about that.

You'll need to enable PHP Error logging then, or check the server logs, as it'll be somewhere. The 500's you're seeing won't be WordPress-generated, so you need to work out why PHP isn't being served by the server to give us any hope of working out the cause.

#4 @rivkadr
12 years ago

Okay, I discovered the issue -- it was a memory allotment issue (we increased the memory allotment in PHP, and all is fine). But it again begs the question -- why does it use more memory if there is no orderby=date in the URL?

#5 @SergeyBiryukov
12 years ago

  • Component changed from General to Administration
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.