WordPress.org

Make WordPress Core

Opened 8 years ago

Last modified 4 months ago

#19343 reviewing enhancement

Allow Quick Edit to be Disabled for Custom Post Types

Reported by: Jick Owned by: nacin
Milestone: Priority: normal
Severity: trivial Version: 3.3
Component: Quick/Bulk Edit Keywords: nacin-likes
Focuses: Cc:
PR Number:

Description

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?

Attachments (2)

19343.patch (416 bytes) - added by GunGeekATX 5 years ago.
register_post_type, added show_quick_edit, defaulted to true
19343.2.patch (1.3 KB) - added by GunGeekATX 5 years ago.
Updated single_row() and inline_edit()

Download all attachments as: .zip

Change History (24)

#1 @mikeschinkel
8 years ago

  • Cc mikeschinkel@… added

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

#2 follow-up: @Jick
8 years ago

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.

#3 in reply to: ↑ 2 @mikeschinkel
8 years ago

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?

#4 follow-up: @Jick
8 years ago

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.

#5 in reply to: ↑ 4 @mikeschinkel
8 years ago

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

#6 follow-up: @jane
8 years ago

  • Keywords needs-patch added

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.

#7 in reply to: ↑ 6 @mikeschinkel
8 years ago

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.

#8 follow-up: @Jick
8 years ago

  • Severity changed from normal to trivial

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.

#9 in reply to: ↑ 8 @MikeSchinkel
8 years ago

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.

#10 @nacin
8 years ago

  • Keywords nacin-likes added

:-)

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

#11 @sc0ttkclark
7 years ago

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

#12 @sc0ttkclark
7 years ago

  • Cc lol@… added

#13 @knutsp
7 years ago

  • Cc knut@… added

@GunGeekATX
5 years ago

register_post_type, added show_quick_edit, defaulted to true

@GunGeekATX
5 years ago

Updated single_row() and inline_edit()

#14 @GunGeekATX
5 years ago

  • Keywords has-patch added; needs-patch removed

#15 follow-up: @nacin
5 years ago

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.

#16 in reply to: ↑ 15 @helen
5 years ago

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.

#17 @GunGeekATX
5 years ago

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.

#18 follow-up: @wonderboymusic
4 years ago

  • Keywords has-patch removed
  • Milestone changed from Awaiting Review to 4.4
  • Owner set to johnbillion
  • Status changed from new to reviewing
  • Type changed from feature request to enhancement

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

#19 in reply to: ↑ 18 @DrewAPicture
4 years ago

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.

#20 @johnbillion
4 years ago

  • Owner changed from johnbillion to nacin

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.

This ticket was mentioned in Slack in #core by sergey. View the logs.


4 years ago

#22 @wonderboymusic
4 years ago

  • Milestone changed from 4.4 to Future Release
Note: See TracTickets for help on using tickets.