Update shape of theme.json #30541
Update shape of theme.json #30541
Conversation
|
Size Change: -73 B (0%) Total Size: 1.31 MB
ℹ️ View Unchanged
|
|
The number of themes that uses v0 is low, is it necessary to allow both formats? What are the concerns? |
The idea is to remove v0 after a few releases and definitely before landing in WordPress core. By making the code ready to support different versions of the schema we're gaining confidence that we can make changes once the schema lives in WordPress core. |
|
It sounds like this PR is trying to do a lot in one go. Can we split it into smaller ones?
... |
oandregal
force-pushed
the
update/theme-json-elements
branch
from
862c86c to
0c4d08a
Compare
|
Progress today: got ready the bulk of server changes, the next step is to address the client changes. |
I'm looking into how to do this. For the server APIs, I already have a list of smaller changes that can be extracted to its own PR. I'm afraid that there's going to be some limits to what I can extract that keep things working, but, yeah, let's do that. |
oandregal
added
the
Global Styles
|
Extracted #30600 to land the v0 to v1 schema migration. |
|
Extracted #30610 to move the transformation of (legacy) editor settings to WP_Theme_JSON. |
oandregal
force-pushed
the
update/theme-json-elements
branch
from
0c4d08a to
3c7b6e1
Compare
|
Extracted #30801 to change how we iterate over the nodes. |
|
Extracted the sanitization at #30809 |
oandregal
force-pushed
the
update/theme-json-elements
branch
from
3c7b6e1 to
98c37c5
Compare
|
Rebased with latest changes and coalesced all commits into one so it's easier to do subsequent rebases. Once the latest two PRs land and this is rebased, the server changes required for this PR are contained to just path changes ― I don't plan to extract more PRs for the server code. Next step for this is adapting the data received by the client to the new data format. |
oandregal
force-pushed
the
update/theme-json-elements
branch
2 times, most recently
from
a615ee3 to
ef78b66
Compare
|
This has been rebased and the styles in front-end & post editor work. The site editor loads but styles don't work yet (can't change them via global styles sidebar and no proper styles are calculated). I'm thinking that a further server PR that could be extracted from this as an intermediate step would be to add elements to existing blocks (v0 format). It's an additional step that doesn't break anything and easy to do. It'll allow us to have that conversation separately. |
oandregal
force-pushed
the
update/theme-json-elements
branch
from
ef78b66 to
eb8f8bf
Compare
|
This has been rebased and made the site editor work as well 🥳 There're a few loose ends in the client such as cover the case in which the user data is not in the latest schema, process elements' styles, and formalize elements in the UI. |
oandregal
force-pushed
the
update/theme-json-elements
branch
from
65ec555 to
1b03c7a
Compare
|
Going to merge this one. These are the follow-ups we need to do (will list them in the tracking issue #20331 where appropriate):
|
|
We should try to include a paragraph about this change in 10.6 release post to help themes migrate and explain that the original format won't be in WordPress Core. |
|
Would it be viable to have a version of https://github.com/ItsJonQ/gutenberg-theme-creator with the new shape going for 10.6? |
|
I'm seeing this rule as a result of, I think, this PR:
The
In this case, I've set the text color of the navigation block to white, and all the nested items are meant to pick up that white color through a Edit: I can increase the specificity of the inherit rule in the nav block, but I'm not sure if that's the right approach? |
|
Created a fix for the nav block in #31495, but I'm not really a fan of it. I understand it might be necessary and the right approach, but would appreciate eyes. |
@jasmussen Yeah, it's from this one. The context is:
If we remove the negation it looks like we get back to the bug we fixed with #29557 Not sure what alternatives we have? 🤔 |
|
I see the headache. But the problem is that the not selector is almost certainly going to affect 3rd party blocks that rely on the |
|
Playing with #31497 |
|
Tested with a few themes and can't repro the original issue reported with buttons, so I'm going to go ahead with that one if I can get approval (need to fix some tests first). |
Sent a PR at ItsJonQ/gutenberg-theme-creator#2 |
|
I've updated the docs to reflect this change at #31507 and it's now live https://developer.wordpress.org/block-editor/how-to-guides/themes/theme-json/ |
|
One thing that stands out as undocumented is how the link color works ( |
|
More link color fun at #31755 |
Closes #29891
Related:
emptythemeEmpty theme: use new theme.json shape theme-experiments#251TT1-blocksTT1-blocks: use new theme.json shape theme-experiments#252This PR implements a new shape for the theme.json file. See #29891 for the rationale and details.
Implementation details
― Support for the old and new formats
This PR introduces a mechanism to migrate the current format to the new one, so themes have some time to adapt. The idea is to drop support for the old format when landing this feature in WordPress core.
By creating this mechanism we're more confident that this is ready to absorb future changes to the schema, which will need to support once they land in WordPress core.
Given that this is an interim mechanism, the migration was not implemented for user styles, hence they'll be discarded. In a follow-up PR, we'll introduce user-styles migration for changes that land in WordPress core.
― Selectors for elements
Elements can be defined at the top-level or as within a block and each element maps to a CSS selector:
aAt the top level, these selectors are included in the stylesheet as they are. When they come within blocks, they are appended to the block selector.
In the example above, the output would be:
Note that elements are being defined in the UI (global style sidebar, post editor sidebar, etc) and within blocks, so this PR doesn't add any UI for them. Users don't have access to them yet. See latest round of mockups.
― Link color becomes an element
There's no longer a
color.linkstyle property. Instead, themes should target the link element, which can target all the style properties (background color, typography, etc).Note that this PR doesn't modify how user styles work. Hence, it's still necessary that themes set the link text color to
link.color.text: var(--wp--style--color--link, <theme-color>).--wp--style--color--linkwill only be in scope if the user has selected a color for a particular block or globally ― the theme color will be used as a fallback if the user hasn't selected anything.― No block sub-selectors
Some blocks output different HTML depending on some attributes. So far, we've allowed themes to target these by using "block sub-selectors" such as
core/heading/h1,core/heading/h2, etc. The current iteration relies on elements instead to do this.Themes that want to target heading elements can do instead:
Output:
― How blocks can re-define the element's selectors (dropped from this PR)
This was dropped from this PR, see #30541 (comment)
While the default serialization mechanism for elements will work well for most blocks, there are a few for which "elements" need to be expressed differently. Take for example the following config for the
core/headingandcore/post-titleblocks.The default serialization mechanism won't work well for this blocks' markup. What we want is this output:
To be able to do this, blocks can express how certain elements should be serialized via a new key in their block.json. This would be the
core/post-titledefinition:Note the link element was not re-defined by the block, hence it'll use the default mechanism and will be serialized as
.wp-block-post-title a.― The order of styles
This is not something themes should worry about: it's managed for them.
This is also not something this PR modifies.
However, while working on this, I've noticed this wasn't documented anywhere and realized there were some differences between the stylesheet used in front (same as post editor) and the stylesheet used in the site editor ― these are now fixed. This is how it works:
.has-<value>-background-color, etc).Example:
How to test
With an existing theme (old theme.json format):
A theme with a theme.json in the new format
version: 1to your theme.json.Follow-ups