Layout already exists further up in this array, so I think this line will override that earlier entry?

Does layout need to be null at the root of this array to support it being set to false?

If it's not in there it won't show up in the settings coming from theme.json, and when we get here the path is empty.

I don't think we have any other block supports that can be fully disabled by setting the whole thing to false but it would be a desirable feature to have for locking down style editing. Perhaps this needs to be looked at more holistically.

Do we know what overriding the earlier entry breaks for that matter? Content and wide sizes still seem to work for me locally 😅

Ah, gotcha!

Do we know what overriding the earlier entry breaks for that matter? Content and wide sizes still seem to work for me locally 😅

I don't think it'll break anything, as far as I'm aware. Just that now anything within layout will be treated as a valid setting (not just contentSize and wideSize). So long as the rest of our code is okay with that, I think that'll be okay, but it could be good to double check with folks that might have a deeper understanding of how this works. I'll just ping @oandregal in case he has any opinions when it comes to the settings.

In terms of this PR, I think it means we could likely keep the 'layout' => null, but we can also remove the above layout => contentSize, wideSize entry, since it gets overridden by the time the code executes? Here's what it's logging out for me (a single layout => null entry):

I don't think we have any other block supports that can be fully disabled by setting the whole thing to false but it would be a desirable feature to have for locking down style editing. Perhaps this needs to be looked at more holistically.

Actually, locking down styles was the first thing that theme.json settings supported 😀 Examples are color.custom (disables custom color for users) or typography.custom (disables custom typographies for users).

useSetting was created to abstract all the places where this info can be sourced from: a block ancestor, the own block instance, settings (merged theme.json), etc.

So, instead of creating a new key and accessing it directly, the recommended way would be using a sub-key of the existing layout key + accessing it via useSetting.

If we do go with enabled though, would it make sense as a global switch for other supports too? I think ideally they all should have a similar API.

Agreed, it'd be good to ensure whichever way we go, that it's consistent. As you mention, it could be quite handy for a theme to be able to disable a whole set of controls such as color. Also, it'd mean they could do that without worrying that in a subsequent release there might be additional controls added, which is often the case with typography, which keeps getting more features added.

I quite like enabled as a subkey for each block support, since it makes it explicit what's being set to false, however this is also a good point from Ramon:

A flag like enabled appears good: what does "enabled" mean though? Does it only relate to controls while keeping layout support (wide/content sizes) via theme.json?

If we like the idea of enabled, would it be worth implementing it across the board as a proposed shape for the API. That way, if it's documented in a consistent way for block supports, maybe that might help alleviate some potential confusion?

If we went with it for layout, maybe allowEditing could be added to other support types too?

Oh, I like it too! It's more specific than enabled

Sure, but there isn't a one-liner that removes a support altogether for a given block.

Ah, I see. I misunderstood. The point of using layout: false was intentional (not because you were unable to use a subkey). I like that approach, it's simple. However, it's problematic for supports that define presets. If we expand the same idea to color or typography we have:

{
  "settings": {
    "color": false,
    "typography": false
  }
}

And then, how would we define the color.palette or typography.fontSizes if we depend on the top-level key to be false to disable "all the features" of that block support?

Now that I understood the problem space you are exploring 😅 I remembered that there's an issue/PR somewhere that discussed the introduction of showInUI (perhaps a better name than enabled, though I personally like allowEditing more). The idea was similar to this: the features work, but are not shown in the UI.

We discussed making it a boolean, but also the ability to enable/disable features per editor, as in:

{
  "settings": {
    "layout": {
      "showInUI": [ "siteEditor" ]
    },
    "color": {
      "showInUI": [ "postEditor", "siteEditor" ]
    }
  }
}

I'm not sure how much appetite there is for this now that most of the tools can be locked down already (not via single switch, though). Back then, the rationale that supported introducing such a flag was that agencies/admins/etc. could be interested in doing it for an individual post while maintaining them enabled site-wide. Though a boolean to lock them in all would still be useful, so it doesn't hurt starting that way. Making the flag "future-proof" (meaning it'll affect all new features introduced in the future) sounds appealing as well.

Ooh interesting, I hadn't seen that work. Given that we seem to be moving in the direction of everything being editable through the site editor, it makes sense to start with a boolean; we can always revisit later.

Doesn't need to happen in this PR, but should we add a @since 6.4.0 line in the doc comment above this const?