is_home() should be able to be true when is_feed()

[nacin]

is_feed() is a special query flag that can be combined with other query flags — for example, is_author() && is_feed() for /author/admin/feed/.

But it can't be combined with is_home(), because is_home() is the fallback that is only set to true when a lot of other things are true — including is_feed(). This appears to be incorrect — is_home() should still be able to be true despite is_feed().

I tracked this down to [1449]. What kind of breakage could occur with this?

[ocean90]

#22031 was marked as a duplicate.

[SergeyBiryukov]

Related: #11053

[wonderboymusic]

How this make you feel now - still needed?

[stevenkword]

Patch 20899.diff removes the is_feed check when assigning the value for the is_home query argument.

[stevenkword]

Related: #11053

[stevenkword]

Anyone have an argument against this?

[jubstuff]

The patch was not applying correctly anymore.

I refreshed it and added a unit test, even if I'm not sure about its location.

[johnbillion]

This smells like something that needs to go in earlier in the cycle, so we have more time to discover hard-to-spot bugs.

@jubstuff FYI, $this->assertQueryTrue() can be used for asserting conditional functions.

[swissspidy]

What about getting this into 4.7? I'll try to update the patch next week.

[swissspidy]

Feedback from @danielbachhuber:

I think this is going to break things
I've used is_home() a fair number of times to conditionally modify the main query where changing core's behavior would cause unintended behavior in the main feed

Source: ​https://wordpress.slack.com/archives/core/p1472220220006226

[jorbin]

@swissspidy if this is something you want to try, I think it needs to happen soon.

[swissspidy]

Regarding my previous comment, Daniel did not exaggerate.

20899.3.diff​ makes the patch apply cleanly against trunk again. As you can see from the changed tests, this affects a few queries.

So if anyone's simply checking for is_home() to modify the query or something, they would likely need to add an && is_feed() check to it. But we don't know without more testing, right?

Is anyone not comfortable with testing this in trunk to see how this affects things?

[swissspidy]

Punting as per discussion in yesterday's bug scrub.

[stevenkword]

Another possible solution would be to add a new set of keys to WP_Query. e.g.) is_home_feed, is_author_feed, is_archive_feed, etc.

[stevenkword]

I'm starting to think that is an even better idea than I did yesterday. See #39157

[stevenkword]

20899.4.diff​ builds upon a patch created in #39157 as an attempt to solve this problem by adding two new getter methods and modifying the wp_query conditionals. This allows for the ability to distinguish between a home page and a home feed as well as between a custom feed and a regular feed. This solution should protect against the regression mentioned by @danielbachhuber and @swissspidy above. Unit test pass as of 4.7.2.

[swissspidy]

Thanks @stevenkword!

The patch works as expected and makes sense from a logical point of view. Especially when used in combination with #30210. Because of backward compatibility, these query tags are a bit of an outlier and we'd need to make sure they're documented accordingly. No objections from me.

[stevenkword]

#11053 was marked as a duplicate.

[dlh]

Hi @stevenkword,

I tested 20899.4.diff​ and found it generally worked as expected, but I had a few questions and comments along the way. My apologies if I've missed previous discussions about these.

• Should is_home_feed() and is_custom_feed() be mutually exclusive? I ask because if I register add_feed( 'foo', 'do_feed_rss2' ), then my feed will be available at example.com/foo/, and I think I might then assume I was still looking at a "home feed."

• Should is_custom_feed() be true for invalid feeds? Currently it looks like it is. I suppose that's consistent with is_feed()?

• Along those lines, I was curious about the benefits of having an "is custom feed" conditional as opposed to "is bundled feed"? Not that "is custom feed" is unhelpful, but it seems like it currently assumes that something is a custom feed if it isn't a core feed. An "is bundled feed" conditional might be able to tell you roughly the same thing but with more certainty because it could test against a known list of core feeds.

• Currently, is_home() will be false when is_home_feed() or is_custom_feed() is true. I think this is expected behavior, but I'm noting it just in case.

• Lastly, should the new _doing_it_wrong() calls use 4.8.0 for the version?

[SirLouen]

There are a lot of questions open to @stevenkword that were never answered. Nothing to test here for now until they are resolved

The blog homepage feed could not be identified on its own. is_home() is false on every feed, and is_feed() does not say which feed is being served, so themes and plugins had no supported way to target the homepage feed specifically.

This adds two conditionals rather than changing is_home(). Making is_home() true on feeds was discussed on the ticket and rejected, because plugins that filter the main query with is_home() would begin matching on feeds.

is_home_feed() is true for the blog homepage feed and false for comment feeds. is_custom_feed() is true when the feed is not one of the bundled types registered in WP_Rewrite::$feeds (feed, rdf, rss, rss2, atom). That list is how a feed added through add_feed() is told apart from a bundled one, since add_feed() appends to the same list without marking the entry as custom.

## Use of AI Tools
AI assistance: Yes
Tool(s): Claude
Model(s): Sonnet
Used for: test cases, code review