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.

Core Committers: Use this line as a base for the props when committing in SVN:

Props scruffian, ramonopoly, talldanwp, mukesh27.

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

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

• The Plugin and Theme Directories cannot be accessed within Playground.
• 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.

@scruffian Address PHPCS and unit test issue

@scruffian Address PHPCS and unit test issue

Thanks for looking. At the moment this is really just being used to prototype an experience in Gutenberg. If we decide its a good idea then we'll need to return to the code and make it work in a more expected way, fix the tests and the PHPCS issue etc.

Trac Ticket Missing

This pull request is missing a link to a Trac ticket. For a contribution to be considered, there must be a corresponding ticket in Trac.

To attach a pull request to a Trac ticket, please include the ticket's full URL in your pull request description. More information about contributing to WordPress on GitHub can be found in the Core Handbook.

Added some unit tests in #10248 🤞🏻

This is testing well for me as well, I tested alongside the gutenberg contentOnly patterns experiment.

It was interesting to test some of the Starter Content / Full Page patterns. A concern I had is that they'd be inserted as a single pattern, but it actually works well. They tend to be made up of multiple root patterns (e.g. https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-content/themes/twentytwentyfive/patterns/page-landing-book.php), so patternName isn't added to the page pattern itself, but it is still added to each of the nested patterns, which feels like the correct behavior to me.

I still do wonder if we might need a way to exempt some patterns from contentOnly, but I haven't found any cases yet where that would be needed.

I still do wonder if we might need a way to exempt some patterns from contentOnly, but I haven't found any cases yet where that would be needed.

Do you mean based on pattern content? Or some opt-out mechanism?

I think, if there is to be a way to opt out, I think it should be editor-based since that's where the feature manifests itself. I don't know how that would look (user driven or using some logic based on the pattern/template itself).

The alternative could be an opt-out flag in the pattern object/metadata or theme.json, but I reckon that could lead us into the spider's web. E.g.,

• users need to be aware of not only the default behaviour but also what the key does
• if we later want to change the default behaviour, does that mean that everyone who didn't opt out is now implicitly opting into the old behavior?
• opt-out keys tend to accumulate
• config should make intent explicit, not require users to negate defaults

No need to consider any of these points, I'm just arguing with myself 😄

Do you mean based on pattern content? Or some opt-out mechanism?

An opt-out per pattern in the metadata. Maybe opt-out is the wrong term, but instead a way to skip applying the patternName to a pattern wrapper block.

An example use case, if any of those page patterns had multiple wp:pattern blocks wrapped in a single group, then the entire page would end up being a single pattern, and I don't think that would be desired.

I don't think there would be any issue with an opt-out like that, the result would be the same as for page patterns that have no single wrapper, the inner wp:patterns would each still become contentOnly patterns.

However, I think it's also too early to think about these things at the moment, and there are currently no examples of patterns that don't work, so best not to over-optimize.

Is it okay if we move this to #10248?

I've created tests and a trac ticket.

Closing in favour of #10180