👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @alecgeatches! In case you missed it, we'd love to have you join us in our Slack community, where we hold regularly weekly meetings open to anyone to coordinate with each other.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

@ajlende Thank you for all of the great feedback! I've applied your guidance using *Complete definitions and figured out how to make these changes draft-04 compatible. Please see the updated issue description which has removed all of the draft-07 discussion and should match the behavior of the current code. Here were the main changes made to address your comments:

1. Added new *Complete properties to support nesting, covered by the new Nested styling changes section in the issue description.

2. Per your suggestion, changed the schema to only have nested settings for blocks that support inner blocks in 7749202. Here's the heuristic used to determine blocks with nesting:

   $ cd gutenberg
   
   # Find files recursively in packages/block-library/src that contain inner block usage
   # Pull out the block name from the path and add "core/" to the front
   # Remove duplicates and sort the results
   
   $ grep -rile '<InnerBlocks\|innerBlocksProps' packages/block-library/src | awk -F '/' '{print "core/"$4}' | uniq | sort
   core/block
   core/buttons
   core/column
   core/columns
   core/comment-template
   core/comments
   core/comments-pagination
   core/cover
   core/gallery
   core/group
   core/home-link
   core/list
   core/list-item
   core/media-text
   core/navigation
   core/navigation-link
   core/navigation-submenu
   core/post-comment
   core/post-content
   core/post-template
   core/query
   core/query-no-results
   core/query-pagination
   core/quote
   core/social-links
   core/template-part

   These probably need to be tweaked and could use a second look. The video at the bottom of the issue description has also been updated to show the new behavior for nestable/unnestable blocks in VS Code.

3. The validation code no longer uses an object to validate the schema. This ended up being trickier than expected. Your suggested code change using validate ran successfully, but did not report and strict errors on theme.json's schema. For example, I tried adding invalid properties like "test": "abc" to the schema which should fail Ajv's strictSchema, but no errors were reported. The only way I could get the meta-schema to be validated was by validating an actual data structure or using .compile():

   gutenberg/test/integration/theme-schema.test.js

   Line 19 in 7749202

   const result = ajv.compile( themeSchema );

   It's unclear from Ajv's documentation why .validate('.../draft-04#', $themeSchema) or .validate($themeSchema) weren't reporting errors. The best I could find was the documentation for compile() which mentions the meta-schema:

   The schema passed to this method will be validated against meta-schema unless validateSchema option is false. If schema is invalid, an error will be thrown. See options.

   It seems like the meta-schema is only validated during compilation, so the code has been changed to use that instead.

Wouldn't it make sense to put the definition of blocks inside "blocks", just like in the root level?

{
  "color": {
    "text": true
  },
  "blocks": {
    "core/child-block": {
      "color": {
        "text": false
      }
    },
    "core/parent-block": {
      "color": {
        "text": false
      },
      "blocks": {
        "core/child-block": {
          "color": {
            "text": true
          }
        }
      }
    }
  }
}

If we skip "blocks", people would need to learn that they need to use "blocks" at the root level but avoid it when they are nested.

And also, wouldn't that make the schema definition easier (as you just have to repeat whatever schema "blocks" has in the root)?

@luisherranz Thank you for the feedback! @ingeniumed and I have been discussing this. We agree it would definitely make the schema changes easier, but we’re not sure if nesting blocks is a cause for confusion:

If we skip “blocks”, people would need to learn that they need to use “blocks” at the root level but avoid it when they are nested.

From the perspective of the designer/developer in theme.json, we don’t think this would be problem. Block settings will go in settings.blocks, and all of the properties in there (nested or not) are block settings. This also sort of works like CSS/SASS in the current format - you just add a child “selector” block in a parent with new settings and you’re good to go. That seems conceptually easier to understand to us than repeating the blocks property.

Your suggested approach would be good for simplifying the schema changes by namespacing the new changes to a blocks property, but will add some more layers and we’re not sure if it’ll be an improvement. If we change the schema here we’d also need to make changes to theme.json parsing/block editor consumption in #43796 as well, so we want to make sure.

@luisherranz We’d love to hear any follow-up thoughts on this or if anyone else can add in as well. Thank you!

We’d also be interested in @dabowman’s opinion here on @luisherranz schema changes above from the designer perspective.

Sure. Let's bring more opinions: cc @mtias, @mcsf, @youknowriad, @oandregal, @jorgefilipecosta.

Given our chat with the Gutenberg IO team and @mcsf's comment here with a different approach, we're likely not going to need the schema changes for nesting. However, since the original test changes and schema fixes may provide some value, we're going to split that off into a different PR. We'll plan to keep this PR around for a bit until we're sure #43796 isn't going to be involved.

Thank you!

Please see #44252 for just the test changes to the existing schema. Thank you!

Closing this issue as the related nesting governance in #43796 has been closed, and the unit test changes from this PR were merged separately in #44252. @ingeniumed has created another (smaller) PR in #45089 to address governance within a plugin. Thank you!