Query: Add With Results block, the inverse of No Results

[vedant-ere]

What?

See #83029
Related: #53316

Adds a new core/query-with-results block — a container that only renders its inner blocks when the Query Loop it lives in has matching posts. It's the mirror image of the existing core/query-no-results block.

Why?

• Query Loop already has core/query-no-results for showing a fallback message when a query returns nothing — that part already works today.
• But No Results and Post Template are the only two blocks that actually know whether the query found anything. A Heading, Paragraph, or any other block placed alongside them has no such awareness and always renders, no matter what.
• So adding No Results alone still leaves an awkward result: a heading (or intro text) shows above an apology that there's nothing under it.
• The reporter's actual ask (Query loop: Add option "Hide loop when no results" or a "With results" block #83029) is to hide that surrounding content too, not just add a message — Option to add block to Query Loop Block visible only when query has results #53316 asked for essentially the same thing back in 2023 and never got picked up.
• There's currently no way for a non-query block to share the same show/hide behavior Post Template and No Results already have. This PR adds that.

How?

core/query-with-results reuses the exact same mechanism core/query-no-results already uses — same ancestor restriction (only insertable inside Query Loop), same per-instance query check — just with the condition inverted: it renders when the query has posts instead of when it doesn't.

It's a plain container, not a single-purpose message block, so it can hold a heading, Post Template, Pagination, or anything else together as one group. It defaults to Post Template + Pagination when inserted, since that's the common case, but nothing stops you from putting other blocks inside too.

This is purely additive: no existing Query Loop is changed or migrated. It's a new block available in the inserter for anyone who wants this grouping behavior.

Testing Instructions

1. Insert a Query Loop block on a page.
2. Inside it, search the inserter for "With Results" and add it as a sibling of the loop's other content (it comes pre-filled with Post Template + Pagination).
3. Add a Heading above the Post Template inside the "With Results" block, e.g. "Related posts".
4. Optionally add a "No Results" block as another sibling, with some fallback text.
5. Publish the page. With the query matching real posts, the heading and posts should show, and "No Results" content should not.
6. Edit the Query Loop's filters (e.g. set the Keyword/Search filter to something nonsensical) so the query matches nothing. Update.
7. View the page again — the heading and posts should be completely gone, and (if added) the "No Results" content should show instead.

Note: if you add "With Results" to a Query Loop that already has a standalone Post Template/Pagination sitting outside it, you'll get duplicate posts — both will render since they share the same query context. Move the existing Post Template/Pagination inside "With Results," or delete them and let its own default template take over.

Screenshots

Both screenshots use the same query (filtered to match zero posts). The only difference is whether the heading is wrapped in "With Results" or sitting as a plain sibling.

Before	After

Use of AI Tools

This PR was developed with Claude Code : research into the issue and prior work, and the automated tests listed above were AI-assisted.

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

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: vedant-ere <vedantere@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>

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

[github-actions]

🤖 PR meta 🤖

🏷️ Labels

This pull request needs exactly one label indicating its type, and has 0.

• Required: any label starting with [Type].
• Found: none.

Read more about Type labels in Gutenberg. If you cannot add labels yourself, a reviewer can do it for you.

[aduth]

Hey 👋 I wanted to give you a heads-up since this pull request is affected by recent validation changes for changelog files.

#83043 adds additional validation for changelog files. You'll note that this pull request is currently failing a "Required changes from trunk" check.

What you'll need to do: You will need to either rebase or merge the latest code from trunk. In addition, a cursory review of open pull requests identified this pull request as potentially failing under the new validation checks. You will want to double-check that any changes to CHANGELOG.md files follow the Maintaining Changelogs guidance, which has been improved as part of these recent changes.