Allow Quick Edit to be Disabled for Custom Post Types

[Jick]

For some custom post types, quick edit doesn't make sense, and it's not easy to disable the quick edit code. You can use CSS to hide it but that still requires the code to be sent to the browser when it's not even needed.

The only other solution is to extend the WP_Posts_List_Table class and set the inline_edit() function to return nothing. Something like this:

if(!class_exists('WP_List_Table')) {
	require_once(ABSPATH . 'wp-admin/includes/class-wp-list-table.php');
}

if(!class_exists('WP_Posts_List_Table')) {
	require_once(ABSPATH . 'wp-admin/includes/class-wp-posts-list-table.php');
}

class My_Posts_List_Table extends WP_Posts_List_Table {
	function inline_edit(){}
}

function my_admin_head() {
	$wp_list_table = new My_Posts_List_Table();
	$wp_list_table->prepare_items();
}

add_action('admin_head-edit.php', 'my_admin_head');

Clearly, that is a lot of code to accomplish something so simple.

So, it would be nice if there was some way to disable quick edit. Maybe it could be a feature you could disable via the "supports" option when you register the custom post type?

[mikeschinkel]

@Jick: While I agree that it would be nice to maybe have a switch for this in register_post_type(), I think it is easier than you are thinking, unless I misunderstand what you are looking for.

Try this code; does it not do what you want?

// Use this for hierarchical post types
add_action( 'page_row_actions', 'yoursite_row_actions', 10, 2 );

// Use this for non-hierarchical post types
add_action( 'post_row_actions', 'yoursite_row_actions', 10, 2 );

function yoursite_row_actions( $actions, $post ) {
  if ( 'your_post_type' == $post->post_type )
    unset( $actions['inline hide-if-no-js'] );
  return $actions;
}

[Jick]

That simply removes the option in each row (visually). However, if you look at the source code you can see that a ton of code is still added for the Quick Edit form towards the bottom of the source. This is unnecessary extra code to be loading when it isn't actually being used.

[mikeschinkel]

Replying to Jick:

However, if you look at the source code you can see that a ton of code is still added for the Quick Edit form towards the bottom of the source. This is unnecessary extra code to be loading when it isn't actually being used.

But realistically, does code loaded in the admin that is never used really cause a problem?

[Jick]

No, it doesn't cause a problem. But it is pretty inefficient. I would think the goal would be to optimize things wherever possible. I doubt it would take much work to do this anyway. In fact, I could probably post a patch when I get some free time if nobody else can/will get to it.

[mikeschinkel]

Replying to Jick:

No, it doesn't cause a problem. But it is pretty inefficient. I would think the goal would be to optimize things wherever possible. I doubt it would take much work to do this anyway. In fact, I could probably post a patch when I get some free time if nobody else can/will get to it.

But inefficient how? Does it make any significant difference for page load time? Does it change functionality in a negative way? Does it create potential maintenance issues? Is it really important to address when there are so many other things to address that would add value in one of these ways?

Sorry, I'm not normally one to be negative about trac tickets but I see this as much ado about nothing (unless you can otherwise explain why it in fact really does matter.)

[jane]

It's always good to be more efficient, and for sites with a lot of traffic, even a little bit of cleanup can make a difference. That said, it's unlikely to be a priority/get much attention unless someone posts a patch and advocates for it.

[mikeschinkel]

Replying to jane:

It's always good to be more efficient,

That statement would only be true if time were frozen and development resources were infinite. Neither is true so instead you weight tradeoffs; i.e. what is worth worrying about and what is not? There are many other things to worry about. After all, "​premature optimization is the root of all evil."

and for sites with a lot of traffic, even a little bit of cleanup can make a difference.

I would agree for front-end pages, but very few if any sites get enough /wp-admin traffic that such a change would make any meaningful difference.

That said, it's unlikely to be a priority/get much attention unless someone posts a patch and advocates for it.

Exactly.

[Jick]

I never intended for this to be seen as a pressing matter. Just something that would be nice. That's why it's a "feature request" and not a "bug". I guess I could have set the "Severity" lower to help get that idea across.

But, just because it's not a super huge needed-by-everyone feature, doesn't mean it doesn't have merit. Especially if someone is willing to work on it. My understanding is that open source means it's open for anyone to contribute anything.

Either way, I don't mind working on a patch for it myself when I get the time. Just caught up with other things at the moment. I can't imagine how a good patch for this would be turned down just because it's not super important at the moment.

Obviously, this wouldn't go in until at least the next major version of WordPress anyway.

[MikeSchinkel]

Replying to Jick:

Either way, I don't mind working on a patch for it myself when I get the time. Just caught up with other things at the moment. I can't imagine how a good patch for this would be turned down just because it's not super important at the moment.

Patches have to be tested, and they can potentially break WordPress itself, or one of the 16000+ plugins in the repository or one of the thousands of themes. So patches that don't provide a significant benefit rarely (if ever?) get picked up.

Of course I'm just looking in from the outside too, so maybe the core devs think this would be important? Who knows, until they comment.

[nacin]

:-)

I'll follow up on this come 3.4. I have some broader ideas relating to post type support.

[sc0ttkclark]

I'm sad panda this got missed, 3.6 then?

[GunGeekATX]

register_post_type, added show_quick_edit, defaulted to true

[GunGeekATX]

Updated single_row() and inline_edit()

[nacin]

I know I've articulated my bigger idea here somewhere before, but I can't find it. Here it is:

The main problem with 'supports' is we can't take existing things (like quick-edit) and suddenly require that they be specified in the supports argument.

Instead, we need something more forward-thinking, like 'disables' => array(). This would allow us to do things like 'post-date' (it would then hide that column, Quick Edit, and publish box field), 'quick-edit' and such. It would tie into add_post_type_support() and remove_post_type_support() transparently.

[helen]

Replying to nacin:

Instead, we need something more forward-thinking, like 'disables' => array().

I know we've talked about this, but also can't find the venue. Might have been IRC. I explored it a little in early patches on #21391.

[GunGeekATX]

If you'd like, I can take a stab at implementing it via nacin's suggestion. I've also found times where turning off quick edit would be handy for custom post types, and turning off columns via the manage_edit-post-type_columns filter can be tricky.

[wonderboymusic]

@johnbillion - does show_ui => false turn off Quick Edit too?

[DrewAPicture]

Replying to wonderboymusic:

@johnbillion - does show_ui => false turn off Quick Edit too?

I'm not John (though sometimes I want to be be) ...

Seems like disabling it might be a reasonable expectation, considering the recent behavior change. I suppose we'd have to add an argument to turn it back on, but I think there would be cheers of joy if it could be turned off for a post type as suggested here.

I'm interested in @nacin's suggestion, because as we're already seeing with the other fine-tuned UI arguments, the selective disabling/enabling could get unwieldy pretty fast as we introduce new arguments and change behaviors.

[johnbillion]

If show_ui is set to false, then access to the post type listing screen is disabled completely, so yes, Quick Edit is disabled in this situation.

[SergeyBiryukov]

In 56611:

Quick Edit: Allow Quick Edit to be disabled for custom post types or taxonomies.

Some custom post types or taxonomies may not need the Quick Edit functionality, in which case adding hidden fields and rendering the form with the data to edit would be redundant.

This commit introduces two filters for more granular control:

• quick_edit_enabled_for_post_type
• quick_edit_enabled_for_taxonomy

Follow-up to [8857], [9083], [9098].

Props garyc40, sabernhardt, mukesh27, costdev, oglekler, wyrfel, peterwilsoncc, faguni22, robinwpdeveloper, webcommsat, johnbillion, azaozz, hellofromTonya, GunGeekATX, Jick, mikeschinkel, jane, nacin, helen, wonderboymusic, DrewAPicture, SergeyBiryukov.
Fixes #16502, #19343, #57596.