Filter taxonomies available in quick edit

[hlashbrooke]

There are a number of use cases for hiding a taxonomy from the quick edit panel, but it is currently not possible.

In WP_Posts_List_Table::inline_edit(), the list of available taxonomies for the post type is fetched, but there is no way to modify that list. I propose adding a filter decide which taxonomies will be displayed. Because this is a filter it won't affect any existing functionality and will make the admin UI that much more customisable.

[hlashbrooke]

First pass at class-wp-posts-list-table.php

[helen]

Thanks for the patch! I definitely like the idea of being able to keep a taxonomy out of quick edit, especially given that we have better default support for custom taxonomy meta boxes now. If we go the filter route, I think it would probably make more sense to filter the entire array of $taxonomy_names right from the get go rather than within the foreach.

That said, I wonder if we should look into another arg in register_taxonomy(). If not that, maybe we should have the meta_box_cb arg make a smart initial decision in addition to a filter.

Also, big picture, quick/inline edit needs some love all around.

[hlashbrooke]

I agree that the whole thing needs some general love for sure, so if this patch doesn't fit into the bigger picture for quick edit then I'm happy to drop it.

My original idea was to filter the taxonomy array, but each element of the array is an object, which meant the filter received an array of taxonomy objects making it slightly more complicated to filter. There would be a similar problem with $taxonomy_names - it returns an array of names with a numeric index, so in order to filter the list you would need to loop through the array or use array_search() or something similar. By doing it in the foreach it means your filter function simply needs a quick conditional and a boolean result, which is much friendly for the end-user I think.

Adding a 'quick_edit' => true type of argument to register_taxonomy() might be a better option - I had considered that, but thought of going for a less intrusive approach for the first pass.

I'm open to any thoughts/suggestions :)

[DrewAPicture]

+1 for adding an argument to register_taxonomy(). @hlashbrooke care to give a second patch a go? :)

[hlashbrooke]

For sure - I'll attach the diff once I've worked out a good solution.

[hlashbrooke]

Second pass - adding 'quick_edit' arg to register_taxonomy()

[hlashbrooke]

New diff attached - it adds a quick_edit argument to the register_taxonomy() function, which is set to true by default. Then it checks that parameter in WP_Posts_List_Table::inline_edit() when it displays the quick/bulk edit panel.

[DrewAPicture]

Replying to hlashbrooke:

New diff attached - it adds a quick_edit argument to the register_taxonomy() function, which is set to true by default. Then it checks that parameter in WP_Posts_List_Table::inline_edit() when it displays the quick/bulk edit panel.

Nice. Had you considered defaulting quick_edit to null, similarly to how the show_in_* options are? Possibly even using show_in_quick_edit instead?

Setting those args null by default allows a sort of predictable fallback to the value of show_ui which falls back to the value of public. Just seems to fit a bit more logically with the show_ui group of arguments than standing it alone. Thoughts?

[hlashbrooke]

Renaming arg and defaulting to null

[hlashbrooke]

Replying to DrewAPicture:

Replying to hlashbrooke:

New diff attached - it adds a quick_edit argument to the register_taxonomy() function, which is set to true by default. Then it checks that parameter in WP_Posts_List_Table::inline_edit() when it displays the quick/bulk edit panel.

Nice. Had you considered defaulting quick_edit to null, similarly to how the show_in_* options are? Possibly even using show_in_quick_edit instead?

Setting those args null by default allows a sort of predictable fallback to the value of show_ui which falls back to the value of public. Just seems to fit a bit more logically with the show_ui group of arguments than standing it alone. Thoughts?

Done :)

Good point about the show_ui fallback - that hadn't occurred to me.

[DrewAPicture]

taxonomy_quick_edit2.diff​ looks pretty good. Now that you've got show_in_quick_edit defaulting back to to the value of show_ui, you can just check it by itself in the list table foreach:

<?php
if ( ! $taxonomy->show_in_quick_edit ) {
        continue;
}

You'll also need to add a line or two description to the register_taxonomy() phpdoc block explaining about show_in_quick_edit.

[nacin]

Moving this to Taxonomy as the focus has shifted to register_taxonomy().

Is it possible you want a taxonomy to be assigned to multiple post types but only appear in one situation? I think a filter is *also* warranted.

[hlashbrooke]

Adding doc block comment and re-adding filter

[hlashbrooke]

@DrewAPicture I improved the use in WP_Posts_List_Table::inline_edit() and added the docblock comment, so that should be all set now.

Thanks @nacin - I agree that having a filter as well would help, so I added that back in. The flow now would be to set show_in_quick_edit to true for the taxonomy and then hide per post type using the quick_edit_show_taxonomy filter that accepts 2 parameters (taxonomy name and post type label) and should return boolean true/false. I'm happy to change that order if you think a different way would flow more smoothly.

[helgatheviking]

+1 for the filter in the quick edit! My plugin, Radio Buttons for Taxonomies, has to hack into the global $wp_taxonomies variable to prevent taxonomies from showing up in the quick edit.. and it is janky and prone to error. A filter would help immensely. Something like:

$taxonomy_names = apply_filters( 'quick_edit_taxonomies', get_object_taxonomies( $screen->post_type ), $screen->post_type );

in class-wp-posts-list-table.php function inline_edit(). I'd make a patch, but since trying to get the git mirrors working on my local setup, my git app has blown a gasket.

[helgatheviking]

While trying to find this ticket again tonight, it turns out that it is a duplicate of my old ticket: https://core.trac.wordpress.org/ticket/21840 I guess that's why it seemed to familiar! :)

I still really want this.. and I attached a patch in the other thread.

[hlashbrooke]

Replying to helgatheviking:

While trying to find this ticket again tonight, it turns out that it is a duplicate of my old ticket: https://core.trac.wordpress.org/ticket/21840 I guess that's why it seemed to familiar! :)

I still really want this.. and I attached a patch in the other thread.

Glad there's some more support for this - my patch here includes a filter like that as well as a new parameter for register_taxonomy() that will decide whether or not a taxonomy should show in the quick edit panel.

[DrewAPicture]

#21840 was marked as a duplicate.

[boonebgorges]

Looks good to me. I'm going to clean up the documentation and code style a little bit. Then let's do this.

[boonebgorges]

In 31307:

Introduce 'show_in_quick_edit' parameter for register_taxonomy().

Setting 'show_in_quick_edit' to false when registering a custom taxonomy will
hide the taxonomy when editing posts using Quick Edit.

The new 'quick_edit_show_taxonomy' filter allows this behavior to be filtered
on a finer scale, as when you want a given taxonomy to be hidden for one post
type but not for others.

Props hlashbrooke.
Fixes #26948.

[boonebgorges]

In 31308:

Fix 'quick_edit_show_taxonomy' filter so that can properly be used for overrides in all cases.

See #26948.

[meloniq]

Do not update taxonomy on 'inline-save' ajax action when 'show_in_quick_edit' is set to false

[meloniq]

Above patch disables also updating taxonomy on inline-save ajax action when show_in_quick_edit is set to false

[hlashbrooke]

So what's the next step here - @meloniq's additional patch is solid, so can it all be merged in from there? Or do you need a single patch that contains all the updates?

[SergeyBiryukov]

26948-inline-save.patch​ needs a duplicate hook comment (/** This filter is documented in ... */).

[boonebgorges]

The goal of [26948-inline-save.patch] is to block direct POST requests from saving forbidden taxonomy terms during the Quick Edit save routine. So I think the best place to put the block is in the Quick Edit save routine itself: wp_ajax_inline_save(). Fix coming up, with a unit test.

So what's the next step here - @meloniq's additional patch is solid, so can it all be merged in from there? Or do you need a single patch that contains all the updates?

The initial stuff was committed in [31308], so no need for more patches.

[boonebgorges]

In 31313:

Prevent terms in a show_in_quick_edit=false taxonomy from being updated by a faked AJAX request.

The UI for these taxonomies was hidden in [31308], but it remained possible to
send a direct POST request to the inline-edit endpoint to bypass the
restriction. The current changeset fixes this.

Props meloniq.
Fixes #26948.

[meloniq]

Thanks for:

• @hlashbrooke - carrying about this issue, and make it resolved!
• @SergeyBiryukov - reminder about doc blocks! (forgive me, was 4am :P )
• @boonebgorges - correcting patch, your filtering it in function that handles inline-edit seems more proper!