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?

@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;
}

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.

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?

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.

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.)

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.

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.

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.

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.

:-)

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

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