Unapproved comment preview renders oEmbed URL differently from the approved comment

[johnbillion]

In a block theme whose comments are inside a pattern block (eg. Twenty Twenty-Five), a pending comment containing an embeddable URL renders as an oEmbed in the comment moderation preview, but as a plain link once approved. The preview does not represent what will be published.

Steps to reproduce

1. Twenty Twenty-Five theme, with comments set to require moderation.
2. Logged out, comment on a post with a YouTube video URL on its own line.
3. Observe that the comment preview shows an oEmbed of the video.
4. Approve the comment and view the post. Observe a plain link renders.

The correct behaviour is that a plain link is shown.

An AI agent tells me that the fix is to run autoembed() on the source before do_blocks() in render_block_core_pattern() and _wp_apply_block_content_filters(), matching get_the_block_template_html() and the the_content filter order. Needs confirming, needs tests.

[iamchitti]

Reproduced, and the suggested fix works - with one correction: autoembed() is already called in both render_block_core_pattern() and _wp_apply_block_content_filters(), just after do_blocks() rather than before. Moving it before do_blocks() resolves it.

One addition to the steps: the comment needs some text before the URL. The moderation notice is concatenated without a newline, so a URL on the comment's first line shares a line with the notice's </p> and autoembed never matches it.

Also worth noting the preview still won't match the approved comment after this - unapproved renders the URL as plain unlinked text, approved renders a link. That's the wp_kses( $comment_text, array() ) stripping in render_block_core_comment_content(), which looks deliberate.

I'm working on a PR for it.

## Description

render_block_core_pattern() and _wp_apply_block_content_filters() called WP_Embed::autoembed() after do_blocks(), so it ran over rendered block output instead of the source. the_content (autoembed at 8, do_blocks() at 9), get_the_block_template_html() and render_block_core_block() all autoembed the source only.

This moves the autoembed() call before do_blocks() in both functions.

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

## Testing instructions

1. Activate Twenty Twenty-Five and set comments to require moderation.
2. Logged out, comment on a post with some text, a blank line, then a YouTube URL alone on the last line. Leave the cookie consent box unchecked. The leading text matters — the moderation notice is concatenated without a newline, so a URL on the comment's first line never matches autoembed.
3. On the ?unapproved=…&moderation-hash=… preview, observe the YouTube player before the change and a plain URL after it.
4. Approve the comment and reload. It renders as a link in both cases.

## Screenshots

Before	After

## AI Usage

Model: Claude Code Opus 5
Used for: root cause analysis, the patch, and the unit tests.

[iamchitti]

Raised related Gutenberg PR here - ​https://github.com/WordPress/gutenberg/pull/82860

[talldanwp]

The PR looks good to me. I've approved and merged the gutenberg PR already.

I think we need to decide which release the PR / ticket targets.

A minor 7.1.x is possible as the _wp_apply_block_content_filters function was only introduced in 7.1.0.