Enable adjustment of 'settings' values

[g-elwell]

What problem does this address?

We're currently only providing a UI for adjusting the 'styles' within theme.json.

We should be able to extend our existing architecture to support adjusting 'settings' as well, but first we need to determine some rules around this and decide on the UI for how we want to display these options to a user.

What is your proposed solution?

The theme.json schema currently supports the following settings, which can be applied either at the root site level, or on each block:

"appearanceTools": boolean,
"useRootPaddingAwareAlignments": boolean,
"border": {
  "color": boolean,
  "radius": boolean,
  "style": boolean,
  "width": boolean
},
"color": {
  "background": boolean,
  "custom": boolean,
  "customDuotone": boolean,
  "customGradient": boolean,
  "defaultDuotone": boolean,
  "defaultGradients": boolean,
  "defaultPalette": boolean,
  "duotone": array,
  "gradients": array,
  "link": boolean,
  "palette": array,
  "text": boolean
},
"custom": object,
"layout": {
  "contentSize": string,
  "wideSize": string
},
"spacing": {
  "blockGap": boolean,
  "margin": boolean,
  "padding": boolean,
  "units": array
},
"typography": {
  "customFontSize": boolean,
  "dropCap": boolean,
  "fontFamilies": array,
  "fontSizes": array,
  "fontStyle": boolean,
  "fontWeight": boolean,
  "letterSpacing": boolean,
  "lineHeight": boolean,
  "textDecoration": boolean,
  "textTransform": boolean
},
"dimensions": {
  "aspectRatio": boolean,
  "minHeight": boolean
},
"shadow": {
  "defaultPresets": boolean,
  "presets": array
},
"position": {
  "sticky": boolean
},
"background": {
  "backgroundImage": boolean,
  "backgroundSize": boolean
}

More information on what is supported and what each property does can be found in the live JSON schema - here

Input types

The majority of settings are boolean values to set whether different options are enabled, and can use simple toggle controls. The array options such as color.palette are going to require a 'repeater' UI which will allow users to add/remove items as required, and the UI for the items themselves are generally going to more complex but we should be able to construct them using mostly core WordPress components.

Site vs block level settings

Whilst it's technically valid in the theme.json schema to include any of these settings on any block, some will have no effect depending on what each block supports. Since we're focusing on providing a UI for editing the theme.json, we could begin this feature by supporting everything that is valid in the schema, or make a general decision on what to omit across all blocks. This may still mean we show some things that aren't supported on specific blocks currently, but it's probably best for us to lean towards providing options for whatever the schema supports, providing the overall UI remains clear.

UI placement

Since settings can be applied to both the site or on blocks, it may make sense to show them alongside the menu options, e.g:

Alternatively, we could add navigation options in the styles panel, but this would require an additional click to reach the settings view for each item, e.g:

Whilst it may be beneficial to include certain settings in the styles panel, ie colour or spacing settings alongside the related styles options, there are also many settings which don't correspond to a style, and ideally all of the settings should be grouped together and displayed in a single area for clarity.

For the actual display of the settings UI, we could consider whether to open this in a modal view, or navigate the styles pane to another route, which would have the advantage of allowing the settings to be shown alongside the preview which may be useful, e.g:

Other considerations

Some site settings dictate whether certain UI should be shown to a user. For example, setting border.color to false would disable whether a user is able to set custom border colours within the UI. However, this is intended to apply at the editor level, not the theme level.

Having border.color set to false whilst also having a default border color configured in the theme.json is valid, therefore we shouldn't need to consider hiding any of our styling UI based on changes to settings attributes.