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

[Viper007Bond]

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.

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

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.

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.

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

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.

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?

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.

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

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.

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.

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