WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#8614 closed defect (bug) (fixed)

With wp_list_categories child categories not excluded when parents are excluded

Reported by: marketingfm Owned by:
Milestone: 2.7.1 Priority: normal
Severity: normal Version: 2.7
Component: General Keywords: has-patch get_terms wp_list_categories exclude exclude_tree 2nd-opinion
Focuses: Cc:

Description

Please reference this thread as this problem is reproducible:
http://wordpress.org/support/topic/224867?replies=2

When excluding categories to show in WP 2.7 the code to exclude no longer works.

Attachments (2)

exclude_tree_terms.diff (3.4 KB) - added by filosofo 8 years ago.
exclude_tree_terms_back_compat.diff (3.6 KB) - added by filosofo 8 years ago.

Download all attachments as: .zip

Change History (16)

#1 @mrmist
8 years ago

  • Milestone changed from 2.8 to 2.7.1
  • Version set to 2.7

#2 @MichaelH
8 years ago

Thought I duplicated this report but can't seem to duplicate it now, so left contact message with marketingfm for further confirmation.

Summary should probably be amended to "Child categories not excluded when parents are excluded."

#3 @MichaelH
8 years ago

  • Summary changed from hiding categories using wp_list_categories no longer works to Child categories not excluded when parents are excluded

marketingfm confirmed problem child categories are not excluded even if the parent is excluded.

Mr. Boren suggests that exclude_tree might be the avenue to resolve this. See http://comox.textdrive.com/pipermail/wp-testers/2008-December/010848.html

#4 @MichaelH
8 years ago

  • Summary changed from Child categories not excluded when parents are excluded to With wp_list_categories child categories not excluded when parents are excluded

#5 @jhodgdon
8 years ago

Just as a note, in WordPress 2.6, if you did wp_list_categories(exclude=3) for instance, it would exclude category 3 and all its children. In 2.7, it just excludes category 3 and not its children.

#6 follow-up: @jhodgdon
8 years ago

This change apparently came from [9652]. This line:

if ( $child_of
$hierarchical ) {

was changed to

if ( $child_of ) {

(lines 729/756)

I did verify that if I put that
$hierarchical back in, wp_list_categories went back to its old behavior.

Hmmm... This came from #8087, which specifically had a reason for putting that change in.... So someone didn't think through all the consequences...

Not sure how to fix it, if #8087 was a valid bug...

#7 @jhodgdon
8 years ago

Ugh. Wiki formatting screwed that code up... there should be a boolean OR in a couple of places up there in that last comment. Hopefully you can figure out what it should have been...

#8 in reply to: ↑ 6 @filosofo
8 years ago

Replying to jhodgdon:

Hmmm... This came from #8087, which specifically had a reason for putting that change in.... So someone didn't think through all the consequences...

Not sure how to fix it, if #8087 was a valid bug...

Yes, you can blame me. The first bullet point in #8087 explains the bug that allowed this behavior.

I think Ryan has proposed the right solution in "exclude_tree," for which I've attached a patch. The previous behavior---while admittedly having the weight of precedent---also suffered from being ambiguous. In other words, I don't think one would expect that having the "exclude" argument by itself would exclude all descendants, had one not already observed this behavior. So "exclude_tree" provides the needed behavior along with clarity.

#9 @filosofo
8 years ago

  • Keywords has-patch get_terms wp_list_categories exclude exclude_tree added

#10 @jhodgdon
8 years ago

  • Keywords 2nd-opinion added

Yeah, but the problem is that people have themes that were using that behavior -- at least the people in the above linked support forum thread and me (a sample of a few at least).

So in my opinion, just putting in an exclude_tree option is not the right answer. The right answer, in my opinion, would be to keep exclude doing what it used to do in wp_list_categories, and add a new argument or combination of arguments that would exclude a category and *not* exclude its children (which I doubt is a very common usage anyway). That would be the option that would break the fewest people already using the function. Of course, since 2.7 already went out with this bug, anyone who upgraded is already broken...

#11 follow-up: @jhodgdon
8 years ago

I also don't agree with you about the expectations. To me, it seems more normal that excluding a category should exclude its children. The reverse idea seems odd.

#12 in reply to: ↑ 11 @filosofo
8 years ago

Replying to jhodgdon:

I also don't agree with you about the expectations. To me, it seems more normal that excluding a category should exclude its children. The reverse idea seems odd.


Please don't misunderstand me; I think your expectations are at least as valid as anyone else's---that wasn't my point. The problem is a matter of semantics and consistency.


Consistency, because that's not how page queries work ("exclude"-ing a parent page doesn't exclude its children), or categories in the Loop (using "category__not_in" will not exclude posts which are in child categories), or posts with children (see "post__not_in"). Semantics, because wp_list_categories rests on top of the terms, and terms can have an indefinite number of relationships or none at all, so "exclude"-ing one implies nothing about what should happen to others. The result is ambiguity.


Of course, since 2.7 already went out with this bug, anyone who upgraded is already broken...


I've attached a second patch that maintains backwards-compatibility for wp_list_categories, when hierarchical is true (the default).

#13 @ryan
8 years ago

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

(In [10275]) Add exclude_tree for categories. Make exclude behave like exclude_tree when hierarchical to restore < 2.7 behavior. Props filosofo. fixes #8614 for trunk

#14 @ryan
8 years ago

(In [10276]) Add exclude_tree for categories. Make exclude behave like exclude_tree when hierarchical to restore < 2.7 behavior. Props filosofo. fixes #8614 for 2.7

Note: See TracTickets for help on using tickets.