Quick Edit / page-attributes for non-hierarchical custom post type

[s1m0nd]

I want to use Page Order to enable users to alter the display order for a custom post type; but I don't want parent/child relationships between the posts. I'm registering the post type (broadly) as follows:

register_post_type('feature',array(
	'label' => 'Features',
	'show_ui' => true,
	'hierarchical' => false,
	'supports' => array('title','excerpt','page-attributes'),
));

'Order' appears under 'Attributes' on the main edit screen, as it should; but doesn't then appear as a Quick Edit option.

If I change 'hierarchical' to true, I see 'Parent' and 'Order' on the main Edit screen, which makes sense. But in Quick Edit, I see 'Parent', 'Order' and now additionally, 'Template'.

[duck_]

Patch attached brings Quick Edit more inline with the attributes metabox. Order will show when 'page-attributes' is supported. Template choice is only shown for pages.

The difference between the main editing page and quick edit, even after the patch, is the display of the parent dropdown for hierarchical post types even when they do not support 'page-attributes'.

Edit: typo fix.

[scribu]

Altering the order of items by manually entering a number is likely the most user-unfriendly UI possible.

I don't think we should encourage developers to use it.

Alternative: Make the list table of that post type sortable; trivial to do using jQuery UI.

[duck_]

Replying to scribu:

Altering the order of items by manually entering a number is likely the most user-unfriendly UI possible.

I totally agree, but I don't think that warrants the closure of this ticket at this time. This is a bug fix for the current implementation which I think should remain open (and be applied) until there is a solid plan and/or patch for a better system of ordering.

Alternative: Make the list table of that post type sortable; trivial to do using jQuery UI.

Drag and drop or clicky arrows, both like the nav menu system, sounds like a good candidate for future work.

[scribu]

I meant that as something he could implement in his plugin.

Core doesn't really need ordering for pages, since we have custom menus.

Related: #14333

[s1m0nd]

I totally agree with duck_. Whether or not page ordering by inputting numbers is the optimal method in 2011, it's currently broken, and if it's so (relatively) trivial to fix, then shouldn't we?

I take your point, scribu, but fixing this defect won't encourage a single additional developer to use the function. It's just an annoyance for those of us who, for whatever reason (and I have my reasons), are already using it.

[simonwheatley]

+1 for fixing the current implementation.

(+1 for adding draggable sorting to core, FWIW, but let's make the fixes where we find them as we move towards that… there's a lot of work needed on the current list tables implementation, as we are all pretty well aware)

[nacin]

In [18527]:

Properly handle display of Order, Template, and Parent page attributes in Quick/Bulk Edit. props duck_, fixes #18352.

[duck_]

In [19929]:

Display menu_order value in quick edit for non-hierarchical post types. Props nikolay.yordanov. Fixes #19911, see #18352.