Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

theme.json v2: track changes #34349

Closed
oandregal opened this issue Aug 27, 2021 · 8 comments
Closed

theme.json v2: track changes #34349

oandregal opened this issue Aug 27, 2021 · 8 comments
Labels
[Feature] Themes Questions or issues with incorporating or styling blocks in a theme. Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json [Type] Task Issues or PRs that have been broken down into an individual action to take

Comments

@oandregal
Copy link
Member

oandregal commented Aug 27, 2021

Part of #20331

This issue is to track the changes we need to introduce in WordPress 5.9, which we should match to a new schema for theme.json.

@oandregal
Copy link
Member Author

In origin, we used the custom* prefix for things that had both a preset and custom colors added by the user. For example, color.customGradient means the users can't use the custom colors in gradients, they are limited to preset gradients. However, color.link means the users can't set link color.

We should remove the custom* prefix those properties that don't need it: spacing.margin, spacing.padding, typography.lineHeight.

@oandregal
Copy link
Member Author

oandregal commented Aug 27, 2021

cc @mtias @youknowriad @mcsf @jorgefilipecosta @gziolo @aaronrobertshaw @ramonjd

We can implement the migration from v1 to v2 for the properties above, as we did in the plugin when we introduced v1 (see), so in theme.json you'd use the name without the custom prefix.

I wonder how this affects the "internal" names: ideally, the names of the properties in the __experimentalFeatures passed to the client can be also updated as well as the store. I understand this may require 3rd parties that hook into the block settings filter to update their filters, if they modify these values. Is this a reasonable request? I think it is, because a theme.json v2 could introduce shape changes anyway.

@oandregal oandregal mentioned this issue Aug 27, 2021
82 tasks
@mtias
Copy link
Member

mtias commented Aug 27, 2021

We should perhaps leave the renaming for when we stabilize and remove the __experimental.

@annezazu annezazu added [Feature] Themes Questions or issues with incorporating or styling blocks in a theme. [Type] Task Issues or PRs that have been broken down into an individual action to take Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json labels Aug 31, 2021
@uniquesolution
Copy link

How about having multiple conditional theme.json files, so that one site can have multiple theme global styls for different pages conditionally? For example as we select page template is in page editor, how about having an option to also choose a different theme.json file ?

@mtias
Copy link
Member

mtias commented Oct 8, 2021

Multiple json files is indeed on the roadmap and conceptualized in the initial scope. The idea is it can be composed in a similar way to the theme hierarchy — so it can match a set of templates, or an individual page, etc. The idea is that template parts could also be theme.json providers, meaning you could overwrite or specify settings for ay template part in complex scenarios. Think a case where a sidebar might require a different set of color presets than the rest of the site.

Swapping theme.json files altogether will also be a good affordance for themes offering different schemes, etc. A dark theme could also be conceptualized under that model easily.

@uniquesolution
Copy link

Is this coming in Wordpress 5.9 ? Where we can see progress in this topic ? I would like see this particular topic progress and want to participate in suggestion if I find useful.

@oandregal
Copy link
Member Author

PRs to remove the custom prefix from existing v1 settings at #36154 and #36155

@oandregal
Copy link
Member Author

All tasks here have landed so I'm closing this. For reference, I'm porting the changes to WordPress core at WordPress/wordpress-develop#1808

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Themes Questions or issues with incorporating or styling blocks in a theme. Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json [Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
Development

No branches or pull requests

4 participants