#37653 - Report the front page when the query was never parsed

[skikken]

A section or control whose active_callback is is_front_page never shows in the Customizer, because is_front_page() is false at the point the callback is evaluated.

The Customizer renders in wp-admin, and nothing there parses a front-end main query. $wp->main() only runs on the front end, from wp-blog-header.php, so $wp_query is still the bare new WP_Query() created in wp-settings.php. Because WP_Query::__construct() skips query() when the query string is empty, parse_query() never runs and none of the is_* flags are populated. They stay at their declared defaults of false, so every branch of is_front_page() falls through to false.

The same situation is already handled for a parsed query with an empty query string. parse_query() promotes is_page and demotes is_home when show_on_front is page, on the grounds that an empty query with a static front page is the front page. That logic is unreachable here only because it lives in the function that does not run for an unparsed query.

This tracks whether parse_query() has run and consults that in is_front_page(), so an unparsed query reporting a static front page is treated as the front page. It does not require a page to be selected, which is what 37653.2.diff gated on, and therefore also covers the intermediate state the Customizer can reach with no page chosen. That state is why the reporter said that patch did not work for him.

Scope notes:

• WP_Query::__construct() is unchanged. Making it always call query() was the reporter's own suggestion in query.patch, which he described as a hack; it would change behaviour for every bare new WP_Query() in core, about 20 call sites in src/ alone, and an unparsed query is a state core relies on.
• is_page() is unchanged. An unparsed query has no queried object, so there is nothing to match a page ID against, and a test pins that.
• is_front_page() returns the same value as before for every parsed query. The tests assert the negative cases as well as the positive ones, including that a parsed query for a different page is still not the front page.

Trac ticket: https://core.trac.wordpress.org/ticket/37653

Use of AI Tools

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

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @skikken.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.