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: ramonjd <[email protected]>
Co-authored-by: andrewserong <[email protected]>
Co-authored-by: ellatrix <[email protected]>
Co-authored-by: talldan <[email protected]>

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

Flaky tests detected in e76d2a4.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/19220458596
📝 Reported issues:

• [Flaky Test] ensures List View global shortcut works properly #51533 in /test/e2e/specs/editor/various/list-view.spec.js

In terms of testing the 404 template, something I noticed in practice is that some themes can be a little granular when it comes to their use of patterns.

Thanks for testing @andrewserong

I'll try to track down a better example, but yeah there's going to be some variation. I guess so long as the metadata is added to the block, content only will kick in.

The unit tests prove it, but it'd nice to play with a real one!

Hol up!

I'll refactor this once the following is in:

• Revert: template activation #73025

I'll try to track down a better example, but yeah there's going to be some variation.

Might be a good one:

https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-content/themes/twentytwentyfour/templates/archive.html

Uses:

https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-content/themes/twentytwentyfour/patterns/posts-3-col.php

I'll test when I come back to rebase/refactor this on top of #73025

However, within that pattern it uses a twentytwentyfour/hidden-search pattern which does contain a single block.... a single Search block. Which behaves a little weirdly (see at the end of this video):

There was a discussion somewhere (can't find it now) about being able to mark some patterns so that we skip applying the patternName. Maybe this is a good example of that. It could be as simple as some metadata inside the pattern file (contentOnly: false?).

mark some patterns so that we skip applying the patternName. Maybe this is a good example of that. It could be as simple as some metadata inside the pattern file (contentOnly: false?).

Where's the best place to do this? Assuming the frontend, where there's already logic to detect content only blocks inside a section?

I like the idea of patterns being able to opt-out. That said, I was wondering the other day if we should infer it, something like if the pattern doesn't contain any content blocks, then we default to default editing mode for the pattern? But I imagine this is something we could play around with after this PR lands?

Might be a good one:

WordPress/wordpress-develop@trunk/src/wp-content/themes/twentytwentyfour/templates/archive.html

Before	After

Okay this is ready for a final test after the migration to filters.

Thanks for the help so far, folks!

Where's the best place to do this? Assuming the frontend, where there's already logic to detect content only blocks inside a section?

@ramonjd I don't think we need to detect content only blocks inside a pattern ... we'd skip adding patternName to blocks if the pattern is opted-out. So wherever patternName is being added would require the check.

I don't think we need to detect content only blocks inside a pattern

Thanks @talldan

I see you've already updated #73124 with a note 🙇🏻