Make WordPress Core

Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#20054 closed enhancement (fixed)

No way to filter wp_terms_checklist() to prevent checked taxonomies jumping to the top

Reported by: husobj's profile husobj Owned by: nacin's profile nacin
Milestone: 3.4 Priority: normal
Severity: normal Version: 3.3.1
Component: UI Keywords: has-patch
Focuses: Cc:

Description

I frequently use categories and custom taxonomies.

By default when editing a post, any selected categories or hierarchical terms with jump to the top of the list.

I understand that in many scenarios this provides a better ui experience, but when you have a hierarchical taxonomy with multiple nested levels, it is actually a worse experience as the category jumps out of context and you cannot easily identify it's parent category.

This is particularly frustrating if you have subcategories with similar or the same name as another category - the often happens in ecommerce applications etc.

I'm not prosing that the default behaviour is change, but it would be nice to be able to filter the output at some point, probably in the wp_terms_checklist() function or Walker, to prevent selected categories jumping to the top.

Attachments (3)

20054.diff (652 bytes) - added by scribu 12 years ago.
20054.2.patch (637 bytes) - added by husobj 12 years ago.
20054.3.patch (470 bytes) - added by husobj 12 years ago.

Download all attachments as: .zip

Change History (25)

#1 @solarissmoke
12 years ago

  • Resolution set to duplicate
  • Status changed from new to closed

#2 @nacin
12 years ago

  • Resolution duplicate deleted
  • Status changed from closed to reopened

Re-opening. I agree a filter would be good here. #10982 and #3130 advocate a change in default behavior, this advocates a filter.

@scribu
12 years ago

#3 @scribu
12 years ago

  • Keywords has-patch added

#4 @husobj
12 years ago

Nacin, Thanks for reopening.
I think a filter is definitely appropriate for this rather than saying "it must work like this" as there are defintely a few cases when you may want to override.

Scribu, thanks for the patch.
I think it should also pass the $taxonomy so you could choose to only do this for certain taxonomies.

@husobj
12 years ago

#5 @aaroncampbell
12 years ago

  • Cc aaroncampbell added

I'm all for the filter. For flatter taxonomy structures or ones where parent category isn't important, floating to the top is fine.

#6 @scribu
12 years ago

  • Milestone changed from Awaiting Review to 3.4

#7 @nacin
12 years ago

For some reason, it feels like this filter isn't in the most appropriate place. This is modifying the behavior of a template function every time it fires, rather than at the point of where arguments are passed in to it, where it is called. Am I making sense?

#8 @scribu
12 years ago

Well, the alternative would be to filter all the arguments in the metabox handler, before calling wp_terms_checklist().

#9 @husobj
12 years ago

The wp_terms_checklist() function is called in the following places where you would probably want to be able to influence the output:

post_categories_meta_box()
wp_category_checklist();
_wp_ajax_add_hierarchical_term() - in ajax-actions.php
inline_edit() - in class-wp-posts-list-table.php

Last edited 12 years ago by husobj (previous) (diff)

#10 @scribu
12 years ago

Besides wp_category_checklist(), all of the other areas are hard to access, hence the filter placement.

I was mostly focused on post_categories_meta_box().

#11 @nacin
12 years ago

Okay. Would it make sense to then place a filter around the entire passed in $args?

#12 follow-up: @husobj
12 years ago

I suppose you could do. I can't really see that you'd want to filter the other $args but maybe it makes sense to provide that option.

For example, I suppose you could filter the $args['selected_cats'] value it you wanted to always check certain terms in certain situations, perhaps?

And I suppose the option of overriding the Walker could be quite fun too?

Last edited 12 years ago by husobj (previous) (diff)

@husobj
12 years ago

#13 @husobj
12 years ago

Something like 20054.3.patch?

#14 in reply to: ↑ 12 @SergeyBiryukov
12 years ago

Replying to husobj:

For example, I suppose you could filter the $args['selected_cats'] value it you wanted to always check certain terms in certain situations, perhaps?

Being able to set some default categories for a new post would probably make sense.

#15 @nacin
12 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from reopened to closed

In [20710]:

Add a filter to wp_terms_checklist() that wraps the function's arguments.

Mainly designed to allow checked_ontop to be turned off.

props husobj.
fixes #20054.

#18 follow-ups: @guar
11 years ago

It works, but I feel it might have been simpler if I could have set these arguments as part of the register_taxonomy() function.

As it is I have to add conditionals to a filter to choose which taxonomy this filter is applied to (assuming I want to set this on a taxonomy by taxonomy basis rather than all).

I'd be happy to submit a patch if others think this is a good alternative method.

#19 @knutsp
11 years ago

  • Cc knut@… added

#20 in reply to: ↑ 18 @SergeyBiryukov
11 years ago

Replying to guar:

It works, but I feel it might have been simpler if I could have set these arguments as part of the register_taxonomy() function.

Feel free to create a new ticket with that suggestion.

#21 @aaroncampbell
11 years ago

Honestly I don't see the need. The checks wouldn't be very expensive since the taxonomy is passed in the args.

However, this ticket was closed as fixed seven months ago. If you want to try to get traction for the change you should open a new ticket.

#22 in reply to: ↑ 18 @husobj
11 years ago

Replying to guar:

It works, but I feel it might have been simpler if I could have set these arguments as part of the register_taxonomy() function.

I guess that would be useful too, but the benefit of the filter is that it can be used to affect existing instances of register_taxonomy() in the WordPress admin and plugins, without having to hack and change the register_taxonomy() args.

Note: See TracTickets for help on using tickets.