Make WordPress Core

Opened 13 years ago

Closed 13 years ago

Last modified 8 years ago

#18636 closed defect (bug) (wontfix)

is_tax() returns false when is_category() or is_tag() returns true

Reported by: viper007bond's profile Viper007Bond Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.3
Component: Taxonomy Keywords: has-patch
Focuses: Cc:

Description

Categories are a taxonomy and yet is_tax() only returns true for custom taxonomies and not for tags and categories.

is_tax() should return true for them and if people want the old weird functionality, then they can pass a taxonomy name to is_tax() or just make sure both is_category() and is_tag() are false.

The offending code looks to be in WP_Query::parse_query() where it loops over $this->tax_query->queries.

Attachments (1)

18636.patch (605 bytes) - added by Viper007Bond 13 years ago.

Download all attachments as: .zip

Change History (17)

@Viper007Bond
13 years ago

#1 @Viper007Bond
13 years ago

  • Summary changed from is_tax() returns false when is_category() returns true to is_tax() returns false when is_category() or is_tag() returns true

#2 follow-ups: @dd32
13 years ago

I believe this has been the case since is_tax() was introduced. To me it makes sense for is_tax to be true for any taxonomy request, however I'm questioning if there's a potential for back-compat breakage by changing this..

#3 in reply to: ↑ 2 @johnbillion
13 years ago

  • Cc johnbillion@… added

#4 in reply to: ↑ 2 @Viper007Bond
13 years ago

Replying to dd32:

To me it makes sense for is_tax to be true for any taxonomy request, however I'm questioning if there's a potential for back-compat breakage by changing this..

Indeed. I'm not sure either, but I also can't think of what could go horribly wrong. Currently is_tax() just means is_custom_tax() and if you're testing for that alone, then you're already doing something wrong.

#5 follow-up: @nacin
13 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

This has been its behavior since introduction. Often you may do:

if ( is_tax() ) {
  // do something
} elseif ( is_category() ) {
  // categories
} elseif ( is_tag() ) {
   // tags
}

This kind of construct absolutely appears in core in some manner in some places. Indeed, this would break the template loader, as is_tax() gets called before either of the others.

It's well-documented as current conditional tag behavior. Better to leave it alone.

#6 in reply to: ↑ 5 @Viper007Bond
13 years ago

Replying to nacin:

This has been its behavior since introduction. Often you may do:

If that was reversed to have is_tax() at the bottom, it wouldn't cause any problems. Just sayin'.

#7 @nacin
13 years ago

In core, absolutely. But how many plugins and themes who were doing it right will suddenly be doing it wrong? If core will break, surely so will other things.

#8 follow-up: @ericmann
11 years ago

  • Cc eric@… added

This is definitely an issue. Let's say, for example, you're trying to filter archive pages for all taxonomies (categories and tags included). Right now, you need to do some pretty hackish stuff to make sure your filter matches what it's supposed to:

class Demo {
  var $taxonomy = '';

  function __construct( $tax ) {
    $this->taxonomy = $tax;

    apply_filters( 'pre_get_posts', array( $this, 'pre_get_posts' ) );
  }

  function pre_get_posts( $query ) {
    if ( ($this->taxonomy == 'post_tags' && $query->is_tag()) || ($this->taxonomy == 'category' && $query->is_category()) || $query->is_tax( $this->taxonomy ) ) {
      // do something conditionally
    }

    return $query;
  }
}

Whereas if is_tax() treated categories and posts the same way, you wouldn't need the additional checks ... just:

  function pre_get_posts( $query ) {
    if ( $query->is_tax( $this->taxonomy ) ) {
      // do something conditionally
    }

    return $query;
  }

Considering categories and tags are taxonomies, why can't we revise this?

#9 in reply to: ↑ 8 ; follow-up: @nacin
11 years ago

Replying to ericmann:

Considering categories and tags are taxonomies, why can't we revise this?

Not to be dismissive, but I would start by reading comments 5, 6, and 7.

#10 @wonderboymusic
11 years ago

Related: #18614, #20767. Both have patches.

#11 in reply to: ↑ 9 @ericmann
11 years ago

Replying to nacin:

Not to be dismissive, but I would start by reading comments 5, 6, and 7.

No, I read those ... and I still don't see this as an issue.

This kind of construct absolutely appears in core in some manner in some places. Indeed, this would break the template loader, as is_tax() gets called before either of the others.

As Viper pointed out, swapping the order of calls there would alleviate the issue in core.

A quick search through core shows that it's already used in the right order in most places anyway. The only place I can see it breaking is the template loader:

...
if     ( is_404()            && $template = get_404_template()            ) :
elseif ( is_search()         && $template = get_search_template()         ) :
elseif ( is_tax()            && $template = get_taxonomy_template()       ) :
elseif ( is_front_page()     && $template = get_front_page_template()     ) :
elseif ( is_home()           && $template = get_home_template()           ) :
elseif ( is_attachment()     && $template = get_attachment_template()     ) :
    remove_filter('the_content', 'prepend_attachment');
elseif ( is_single()         && $template = get_single_template()         ) :
elseif ( is_page()           && $template = get_page_template()           ) :
elseif ( is_category()       && $template = get_category_template()       ) :
elseif ( is_tag()            && $template = get_tag_template()            ) :
...

And that can be fixed by reordering the conditional.

But how many plugins and themes who were doing it right will suddenly be doing it wrong?

I would argue that they weren't "doing it right" in the first place. I could (and would) make the argument that the fact that is_tax() behaves differently for tags and categories at all means that it's been doing it wrong from the beginning.

It's misleading to claim custom taxonomies are on-par with tags and categories when there's functionality like this in core. It's not clear from the documentation that these issues will come up (which can be addressed if we're never going to change it), and it makes new code harder to follow when you have flexible logic for all but 2 taxonomies and hard-coded logic to handle them specifically.

#12 @ciobi
11 years ago

  • Cc alex.ciobica@… added

I agree with @ericmann. This issue need to be addressed. It's not intuitive, and it hurts WordPress's reputation as a CMS.

If you can't bluntly change this for fear of breaking plugins, how about adding something else that works like it should. Maybe is_taxo or even is_taxonomy (been deprecated a while) and warn developers of deprecating is_tax in a few versions.

Last edited 11 years ago by ciobi (previous) (diff)

#13 @Viper007Bond
11 years ago

is_taxonomy() is an existing function that allows you to test if a taxonomy exists or not.

#14 @gputignano
9 years ago

After 22 months is there any news about this ticket? Let is_tax to return true also for tags and categories is very useful to generalize how wordpress works.

#15 @danieliser
8 years ago

Agree with @ericmann. Sorry @nacin but this is semantically and logically wrong as it stands now.

Based on your reasoning, get_taxonomies() should also exclude category & post_tags by default, yet it doesn't.

In regards to all the plugins & themes out there that may break, I disagree. In fact since they are already checking for is_category nothing would break.

Instead though this change would remove the requirement to check specifically for tag & categories.

If you are looping through all taxnomies using the core get_taxonomies method you currently have to check all 3 is_ functions, rather than simply being able to run is_tax( $tax ).

Just because its been that way for a long time is not a good excuse to not fix it for the future. This could easily be fixed in a backward compatible way, and still give plenty of notice to existing themes & plugins.

I would also argue if they wrote their code properly in the first place they won't see any breakage at all. I know my code wouldn't break due to this, but it sure would get simpler & easier to understand.

Last edited 8 years ago by danieliser (previous) (diff)

#16 @theMikeD
8 years ago

Agree with @ericmann FWIW

Note: See TracTickets for help on using tickets.