get_queried_object() returns null date archives and on homepage with blog on front settings

[bplv]

get_queried_object() returns null if permalink is plain.

[bplv]

Sorry this was a problem at my end.

[SergeyBiryukov]

Related: #29660, #27015.

[iflairwebtechnologies]

Fixes an issue where WP_Query::get_queried_object() returns null on valid queries.

This patch adds missing queried_object handling for:

1. Date archives (year, month, day)
2. Homepage when “Your latest posts” is selected

Returning null causes problems in:

• Themes expecting valid queried objects
• Breadcrumb plugins (Yoast, RankMath)
• Conditional templates using queried_object_id
• Custom theme frameworks relying on WP_Query consistency

This patch introduces lightweight stdClass objects for both cases, matching how post type archives and taxonomy queries work, without altering existing behavior.

[ellatrix]

@SirLouen why was the version deleted here? And @iflairwebtechnologies, why was the version set to trunk?

[wildworks]

As a general rule, I don't think the version number should be changed once it's been set, so let's change it back to what it was.

See: ​https://make.wordpress.org/core/handbook/testing/reporting-bugs/#:~:text=The%20Version%20field%20relates%20to%20the%20version%20in%20which%20the%20bug%20was%20originally%20discovered.%20If%20you%E2%80%99re%20seeing%20the%20same%20bug%20in%20a%20newer%20version%2C%20mention%20so%20in%20a%20comment%2C%20but%20please%20do%20not%20change%20the%20version%20number.

The Version field relates to the version in which the bug was originally discovered. If you’re seeing the same bug in a newer version, mention so in a comment, but please do not change the version number.

[SirLouen]

Replying to wildworks:

As a general rule, I don't think the version number should be changed once it's been set, so let's change it back to what it was.

See: ​https://make.wordpress.org/core/handbook/testing/reporting-bugs/#:~:text=The%20Version%20field%20relates%20to%20the%20version%20in%20which%20the%20bug%20was%20originally%20discovered.%20If%20you%E2%80%99re%20seeing%20the%20same%20bug%20in%20a%20newer%20version%2C%20mention%20so%20in%20a%20comment%2C%20but%20please%20do%20not%20change%20the%20version%20number.

The Version field relates to the version in which the bug was originally discovered. If you’re seeing the same bug in a newer version, mention so in a comment, but please do not change the version number.

Back in the day, after reading exactly these docs, I was setting to trunk pretty much every ticket I opened (because 99% of the bugs and issues I found were discovered while using trunk)

But I can't remember which long-standing committer (Peter, Aaron, or Sergey), told me that the version was meant to point out when the bug was introduced, not discovered. I think that these docs must be updated because they are misleading.

From that day, while triaging my components, I remove the version when I'm confident that it's not set to when it was introduced (but I have not dug into it deeper to find the exact moment when it was introduced).

So technically it was minimally introduced in 4.7 (broken by design).

cc @ellatrix

[SirLouen]

@wildworks @ellatrix, docs updated. Now it displays introduced. Just FYI 👌

The

If you’re seeing the same bug in a newer version, mention so in a comment, but please do not change the version number.

This was only meant because occasionally the right version was specified, but someone found it again in a newer version and updated the version.

But as a rule of thumb, if we are suspicious that someone opened the ticket adding a wrong version (discovery version), it should be removed or updated to the right one (the introduction version). I think this field is misleading and almost everyone set it wrongly when they come to Trac for first time (me including, I've seen that Aki has cleared half a dozen old tickets from mine, that I created with trunk and I forgot to update)