WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 7 months ago

#18636 closed defect (bug) (wontfix)

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

Reported by: 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 4 years ago.

Download all attachments as: .zip

Change History (15)

@Viper007Bond4 years ago

comment:1 @Viper007Bond4 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

comment:2 follow-ups: @dd324 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..

comment:3 in reply to: ↑ 2 @johnbillion4 years ago

  • Cc johnbillion@… added

comment:4 in reply to: ↑ 2 @Viper007Bond4 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.

comment:5 follow-up: @nacin4 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.

comment:6 in reply to: ↑ 5 @Viper007Bond4 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'.

comment:7 @nacin4 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.

comment:8 follow-up: @ericmann2 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?

comment:9 in reply to: ↑ 8 ; follow-up: @nacin2 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.

comment:10 @wonderboymusic2 years ago

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

comment:11 in reply to: ↑ 9 @ericmann2 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.

comment:12 @ciobi2 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 2 years ago by ciobi (previous) (diff)

comment:13 @Viper007Bond2 years ago

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

comment:14 @gputignano7 months 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.

Note: See TracTickets for help on using tickets.