Props to @daisyo and @jffng for the massive amount of help in writing and perfecting this call for testing.
Important note: Compared to previous calls for testing for the FSE Outreach program, this is intentionally targeting a more developer-centric audience compared to site builders or end users in order to bring high impact feedback for theme.json, a new tool for extenders. You can read more about what to expect with upcoming efforts here.
Feature Overview
At the highest level, theme.json is a configuration file used to enable or disable features and set default styles for both a website and blocks. Rather than dealing with a ton of theme support flags or alternative methods, theme.json provides a consolidated and canonical way to manage it all. These settings include options like:
- What customization options should be made available or hidden from the user.
- What are the default colors, font sizes, etc available to the user.
- Defines the default layout of the editor (widths and available alignments).
This configuration file is a big part of what makes block themes so powerful as it allows for finer-grained control, and introduces the first step in “managing styles” for future WordPress releases. Here are a few of the top benefits of using this new mechanism:
- It allows themes to provide settings per block which wasn’t possible before since add_theme_support targets settings for the entire editor.
- Themes using theme.json will automatically get classes and CSS Custom Properties enqueued for the presets they declare instead of needing to handle this themselves. Plus, this means translations of preset names are also managed for them!
- Theme.json will coordinate core, theme, and user styles in a way that reduces the amount of CSS that needs to ship as well as help resolve specificity problems.
While block themes won’t work with WordPress 5.8 without the Gutenberg plugin due to some theme blocks being left out of the release that weren’t quite ready to ship, it’s still an important feature coming to 5.8 that needs testing and exploration. If you’ve been curious about the world of block themes or have started building your own, this call for testing is for you and should help you to continue to explore what’s possible with theme.json while giving you a chance to share what else you’d like to see.
You can read more about this feature in the documentation here.
Beginner Testing Steps
This section is for those wanting to get a sense of what theme.json can control and what the output will look like.
- Head to http://wayback.fauppsala.se:80/wayback/20210716144702/https://gutenberg-theme.xyz/. This is a tool that can help generate the settings section of the theme.json file.
- From there, try toggling on and off various theme supports. This will help you explore just a few settings that are possible to control with theme.json. For example, you can toggle on and off Custom Colors or Custom Link controls. Notice that the output in the browser changes based on your selection.
- Use the + button next to Palette, Gradients, or Font Sizes to explore adding customizations. Keep in mind that you can edit both the slug and specific variables, like color name or font size.
- Add a few customizations and review the output! If you want to go a step further and use what you’ve created, check out the intermediate steps.
Intermediate Testing Steps
This section is for those wanting to dig deeper into theme.json by writing their own file and exploring the various settings it can control.
Note: this mainly focuses on just theme supports and presets for blocks in the settings section of theme.json rather than Global Styles.
Set up your testing environment
- Create a Fresh WordPress Install.
- Install and Activate Gutenberg Plugin while using the latest version (10.9.0 as of writing this).
- Download and Install TT1 Blocks from the Theme Directory.
- Navigate to the TT1 Blocks Theme directory and open the theme.json file in a text editor or IDE.
- Replace the theme.json file with this gist before starting the next steps. It’s expected that this will really simplify what the theme looks like so don’t panic if you see a lot of options removed. This is intentional to simplify the settings you’re changing.
Generally speaking, please use the latest versions of each part of the setup and keep in mind that versions might have changed since this post was shared.
Layout
- Create a new post.
- Add a cover block with a solid colored background and several lines of content in an inner paragraph block to the post.
- Add another cover block with a solid colored background and several lines of content in an inner paragraph block. Set this block to “Wide Width”.
- Add a third cover block with a solid colored background and several lines of content to the post and set the block to “Full Width”.
- Publish Post.
- Load the post on the front end and note the width of the cover blocks.
- Change the
contentSize
value to a different pixel value in the layout section of theme.json. - Change
wideSize
value to a different pixel value in the Layout section of theme.json. - Load the edit view of the previously created post and confirm that new widths are reflected in the editor
- Load the post on the front end and confirm that the new widths are reflected on the front end of the site
- Extra Credit: Try setting the width values to something other than “px” such as “em”, “rem”, “vh”, “vw”, or “%”.
Typography
- Set the following typography settings to
true
in theme.json
: - customFontWeight (Heading Block)
- customFontSize (Paragraph Block)
- customLineHeight (Paragraph Block)
- dropCap (Paragraph Block)
- Test the visibility of typography settings in a paragraph block (font size, line height and drop cap).
- Test the visibility of typography settings in a Heading block (font size, font weight, line height).
- Test that each of settings apply to the block on the front end.
- Change the typography settings to false in theme.json.
- Confirm that each of the custom typography settings in the paragraph block are no longer present in the block editor (Note the typography settings applied previously may still apply to existing blocks).
- Extra credit: Add one or more font families and font sizes to the typography section of the theme.json file. Test your custom font families and sizes using a Button block.
Border
- Set the following border settings to
true
in theme.json
:"customColor": true
"customRadius": true
"customStyle": true
"customWidth": true
- Create a group block with an inner paragraph block with several lines of text.
- Test visibility of border settings in a group block (Style, Width, Radius, Custom Color).
- Test that settings apply to the block on the front end.
- Change the above border settings to
false
in theme.json. - Confirm that border settings in group block are no longer present in the block editor.
Color
- Set the following color settings for custom and customGradient to
true
in theme.json
:"custom": true
"customGradient": true
"link": true
- Add a cover block with a custom gradient background and several lines of content in an inner paragraph block to the post.
- Add a link to the paragraph block and set the link color to a custom color.
- Add another cover block with an image background and several lines of content in an inner paragraph block to the post. Set the cover background to use a duotone preset.
- Change the duotone colors for the background image to use custom colors for the duotone shadows and highlights settings.
- Extra Credit: Add one or more additional colors to the palette and duotone or gradient presets. For more information about CSS gradients check these resources from CSS Tricks and CSS Gradient. Keep in mind that for duotone presets, you’ll need to use RGB, Hex or specifically named colors when adding custom colors.
(Very) Advanced Testing Steps
This section is for those looking to create a more robust block theme using theme.json and who are experienced theme developers. This isn’t for everyone!
If you feel more comfortable with block themes and have ample time to dig into theme.json, try replicating a classic theme. Here are two options that should be fun to dig into but keep in mind any default theme should work well:
As you try to do this, write down what gaps remain, what proves to be the most difficult to do, and what feels surprisingly easy! Share in the comments below so we can learn from your experience. This is intentionally extremely open ended and advanced so don’t worry if you don’t feel up for the challenge. If you want to follow along while someone else explores doing this, check out @mkaz‘s exploration video on learning to create a block theme.
What to notice:
These questions are specifically for the Intermediate and Advanced sections:
- Do the colors added to the theme.json file appear with the assigned names visible on hover in the color palette for various blocks?
- Do the font sizes added to the theme.json file appear with the assigned names and sizes in the font size dropdowns in blocks?
- Do the colors and font sizes appear correctly when used with blocks in the editor?
- Do the colors and font sizes appear correctly when used with blocks on the front end?
- What did you find particularly confusing or frustrating about the experience?
- What did you especially enjoy or appreciate about the experience?
Leave Feedback by July 14th
Please leave feedback (questions, comments, concerns) in the comments of this post and be sure to note which section you followed. If you’d prefer, you’re always welcome to create issues in this GitHub repo directly for Gutenberg but, for this test, it’s unlikely you’ll need to. However, if you do leave feedback in GitHub, please comment below with the link.
Join a hallway hangout for theme.json testing on July 7th
To help those who might want to explore this test and theme.json in a group, @daisyolsen will be hosting a hallway hangout specifically for this exercise. If you have never attended a hallway hangout, you can read more about them here. Ultimately, they are meant to be casual and collaborative sessions to bring like minds together.
Hope to see you there.
#fse-outreach-program, #fse-testing-call, #full-site-editing
+make.wordpress.org/themes/
The theme.json I’ve followed closer than the Template Editor, but I wasn’t around for most of the creation and ideation cycle… so repeating the disclaimer that I’ve searched for these issues/discussion but have likely missed some things along the way.
Overall, from a developer perspective, the theme.json is the holy grail of what I’ve wanted in WordPress Theme Development for a long time. It’s a one-stop, unified config that sets (almost) all the things and mostly #justworks.
Test Site
http://wayback.fauppsala.se:80/wayback/20210716144702/https://daveryan.blog/theme-json-landia
Versions
Layout
No feedback, everything (including Extra Credit) works as-expected.
Typography
2. Font Weight was unavailable in the Paragraph Block. Other type settings worked as-expected.
7. While playing with additional font families, I modified tt1-blocks/assets/css/style-shared.css with an import’d Google Font. These styles loaded fine on the frontend, however, the style-shared.css was never loaded in-editor (directly or via load-style.php, confirmed via browser Network inspector and adding additional !important style rules that loaded on frontend).
Border
No feedback, works as-expected.
Color
No feedback, everything (including Extra Credit) works as-expected.
What to notice
Confusing or Frustrating
get_stylesheet_directory()
. I see this open issue, but having WP_Theme_JSON_Resolver only merge the active theme’s theme.json without merging the parent feels like a large omission (that’s also not a huge lift to address… as the JSONs are already merging with a Core copy). I realize there’s a brave new world with FSE where block-templates and block-template-parts start to chip away at the classic use for Child Themes… but especially for the theme.json, it seems particularly helpful in the scenario of a WordPress Multisite with one parent theme and each site extending/overriding Colors, Typography, etc without needing to entirely nuke/copy-pasta the parent’s theme.json file. In fact, I see one of the best benefits of the theme.json is providing a “preset” for another Theme that doesn’t require overriding templates (block or classic) but the child theme is a one-file override via theme.json.Enjoyable & Appreciated
add_theme_support( 'editor-color-palette' )
without a recourse for Users to override in a UI nor a reliable developer API or recourse short of messing with the $_wp_theme_supports global PHP variable.settings.custom
I will admit my gut reaction to using--wp--custom--{var}
was uncertainty. But having a unified standard, where the origins of a value can always be predictably traced to a specific location in the theme.json data shape no matter what theme is active… does seem an advantage to each theme setting up lots of unique vendor prefixes and has grown on me.@dryanpress thanks for diving into this more unique test and writing such comprehensive feedback. No worries about missing anything along the way – this is why feedback rounds happen!
Beautiful feedback.
Ah yes! Enqueueing stylesheets in theme.json directly has been discussed in this issue. I’m going to check in with some themers to confirm whether what you’re describing is expected behavior for now or a bug. I’ll follow up if there needs to be a new GitHub issue opened.
Ah! Thanks for spotting that. That’s expected. I should have removed that as it’s only for the Heading block right now.
Appreciate this larger perspective here. In the future, child themes as a concept likely won’t make a ton of sense as there likely won’t be much shared code between the two once theme.json is even more robust with what it supports. With that said, I do know some folks are working on creating a block parent theme for now with the work around Blockbase. You can read more about this approach here. Ultimately, Blockbase is meant for the community to use and tinker with in the meantime (be it by using it as a parent or by just using the build script to build their own parent) until we reach a future where parent/child themes aren’t as necessary. For now, I added your feedback to the open issue you linked to as I think it’s a great perspective to make sure is included.
Can you say a bit more here about the use case? For example, are you thinking this might be something worth exploring as part of if someone switches themes that might not have support for something they used previously, like drop cap? I want to understand the experience a bit more as the sidebar could get extremely cluttered if all of the disabled features are listed out. This also may be something where the global styles system will resolve this by providing a coherent way to manage user styles, theme styles, and core styles.
To follow up here 🙂 All editor stylesheets need to be individually added via
add_editor_style()
. As a result, you’d need to modifyadd_editor_style()
in TT1 Blocks’ functions.php to something like this in order for this import to work:// Enqueue editor styles.
add_editor_style(
array(
'./assets/css/blocks.css',
'./assets/css/style-shared.css',
'<-- Google Fonts URL -->'
)
);
Hopefully that helps clear things up.
Ah, thanks! I did try that, I was just surprised the import statement inside style-shared.css got stripped somehow. Seems like a good docs opportunity to prescribe an approach for a common use case.
On Parent/Child Themes
Huh, interesting. I’d been under the impression that it was the intention to make Child Themes work with Block-Based Themes. That
child-theme.json
is definitely an interesting idea and is good prior art for someone looking to implement something similar.In general, I think having the “block-based child theme mechanism” in Core would standardize how Theme Authors use it as opposed to in a parent theme always needing to create scaffolding for Child Theme support. In Core also means less code for the Theme Review team to parse, less code for Themers to parse and a 20-line JSON file (generated by a user, generated by a GUI) could have radical impact.
The one issue I see with
child-theme.json
as a naming convention is the likelihood of grandchild themes that @aristath called out on that issue. That naming convention could quickly get confusing with multiple layers.My main interest is keeping the barrier to entry for Child Themeing low (no build tools, avoid stylesheet inheritance, etc). Keeping things out of build steps and in JSON enables low-code/no-code Child Themeing.
On Disabled Feature Downgrading
The sidebar getting cluttered is absolutely a valid concern! And this “feature downgrading” has long been a pain point with Theme switching that isn’t new to Blocks or Block-Based Themes. With the theme.json, there’s now a way a Plugin could easily build a UI to toggle features on and off too. We’re already in better territory.
I guess the big difference I see is these controls are WordPress features, not Theme-specific features. So there’s more we can do about them. Now that Themes are going to be drastically easier to swap than they have historically, this feels like a UX pain point that will increasingly arise and that could be iterated on. I don’t know where this would fall into priorities, but it definitely feels like an opportunity to remove a confusion/friction point for site owners.
Few thoughts:
@annezazu I re-read your comment again and I guess I’d be curious if you could expand on this:
I guess one difference of opinion is, I see Child Themes becoming even more popular, just much less likely to override Template files and much more focused on the theme.json. Is there something I’m missing or I misread?
I didn’t go into tons of scenarios, but I think there are a bunch for Child Themes:
Everything you’re touching on here I expect to see as a big focus ahead of 5.9. Excellent thoughts and I deeply appreciate you sharing as getting the theme switching experience refined and clarified is incredibly important. In my recap for this call for testing, I’ll be sure to call this out specifically.
Gosh, expanding on this is tricky because this is truly early days and I can’t speak with certainty. After all, much of the future of themes will be defined in the coming months once the theme.json foundation is shipped in 5.8 and more folks are able to dig in. I love these thoughts and examples though. If you’re game, would you be willing to share directly on the issue I previously linked? While I could copy and paste what you shared, I think there’s great benefit in potentially opening up that discussion more and for those working on this mechanism to hear directly from you. This also seems like it would make for a great hallway hangout in the future, similar to the universal themes one. Some of what you’re describing will also be impacted by how theme switching itself works in general and what carries over from theme to theme. Regardless, I’m excited for more of these broader conversations to happen in the community and to see what people create with theme.json.
Re: Child themes. I’ve shared a couple of thoughts in issue 25612.
Thank you for doing that 🙂
Just thought I’d quickly add a comment here about a theme.json snag I’ve hit while working on a FSE theme recently (currently testing out some ideas for a preferred solution and will post a link to a Github issue once I’ve created one, too).
The layout preset
contentSize
is not exported as a custom property in the global styles CSS. This seems reasonable in the context of using Gutenberg’s native approach to layout presentation: max-width + left/right auto margins are used to centre children, with the parent container presumed to be full-width. Each block that supports layout has a style element following its markup containing CSS with custom values scoped to the block, if entered, or the defaultcontentSize
value.I’m working on a FSE theme that uses CSS Grid to manage the various alignments available for blocks. This makes for a different approach to layout, where the parent container is assigned a one-off default width of
contentSize
. However, as noted earlier, there’s currently no way to retrieve layout values set in theme.json to use with my CSS Grid syntax. Following the convention of other presets that are exposed in the global styles, ideally I’d be able to write the following CSS to use thecontentSize
value set in theme.json:[code]grid-template-columns: 1fr min(var(–wp–preset–layout–content-size), 100%) 1fr;[/code]
Currently I’m using a custom value in theme.json that duplicates the default value for
contentSize
, to allow me to use it in a CSS declaration, like this:[code]grid-template-columns: 1fr min(var(–wp–custom–layout–content-size), 100%) 1fr;[/code]
An extension to this relates to when ‘inherit default layout’ is active. Theme.json layout values are exposed in a style element scoped to a specific block, with CSS declarations presuming the approach mentioned earlier: max-width + left/right auto margin applied to each child of a container supporting layout. This is fine unless you want to use a different method for managing presentation layout, like CSS Grid. If custom Content and Wide values are set in a block’s Layout panel, it should be possible to manage the CSS provided for each block, to match the required syntax. Right now there’s no obvious mechanism to achieve this.
For example, if I set a custom layout size of 100 rem for the Wide value of a specific group block, the current style element will contain a declaration like this:
[code].wp-container-60dbd111c065b > .alignwide { max-width: 100rem; }[/code]
…whereas my CSS Grid-based layout requires:
[code].wp-container-60dbd111c065b.alignwide { max-width: 100rem; }[/code]
Ideally there would be a straightforward way to define the CSS declarations used in these style elements.
Last of all, it would also be useful to be able to enable/disable the Layout panel as it appears in block settings. There doesn’t seem to be a way to do this currently.
Hmmm, actually, please ignore the section starting “An extension to this…”, up to the end of the second-to-last sentence. Reading that back I feel it’s outside the scope of theme.json, since it relates more to custom values entered in a block’s Layout settings and not the default theme.json layout values.
It’s very exciting to hear you’re working on a block theme, @chthnc! Thanks for so clearly laying out the problem and your idea.
Reading this over, all I immediately wanted to see an issue created for wider discussion as it sounds like having
contentSize
exposed as a preset and generated CSS variable would be valuable. Would you mind opening an issue to discuss sooner rather than later to see if other folks could find it useful as well? If you want, happy to open it on your behalf 🙂I also might include this as a separate issue. Again, happy to open it but don’t want to overstep since it sounds like you’re already keen to start these discussions.
Either way, keep sharing what you find in GitHub as you go along with building your theme. It helps the folks working on building out theme.json know the pain points people want fixed and feature requests people are looking to have.
Chiming in to say that I agree with @annezazu that a start to a GitHub conversation around exposing the layouts as properties would be great. It seems like a natural addition to me but getting those with more in-depth knowledge of the technical aspects would be really valuable.
Done 🙂 http://wayback.fauppsala.se:80/wayback/20210716144702/https://github.com/WordPress/gutenberg/issues/33184
Looks like there’s already an issue open for this one: http://wayback.fauppsala.se:80/wayback/20210716144702/https://github.com/WordPress/gutenberg/issues/31980
Thanks so much for doing that!
Testing.
After adjusting the wideSize, I expected to be able to add a fullSize and change the Full Width width, but that did not work. I expect there to be consistency in the naming of various options.
Testing typography settings in the Paragraph and Heading blocks. Can I adjust controls per block type? So for instance having Line height only for Headings and not Paragraphs? Or only having colors for Paragraphs and not Headings etc.
Test the visibility of typography settings in a Heading block (font size, font weight, line height).
“Change the typography settings to false in theme.json.”
Can I turn off all typography settings? I assume you mean turn off the settings I just turned on.
“Add one or more font families and font sizes to the typography section of the theme.json file.”
I noticed this:
[code]”fontFamilies”: [
{
“fontFamily”: “Helvetica Neue, Helvetica, Arial, sans-serif”,
“slug”: “helvetica-arial”[/code]
How do I add a font family? I tried various things but it did not work.
I added border settings to the Group block. I could see the black border I added. In theme.json I took it from true back to false. I can still see the border settings even though I turned off the controls. I assume to remove the black border I have to turn the controls back on again. Remove the order and then turn off the controls. I turned on the customStyle and removed the border, and turned it off again.
I was able to add a new duotone and gradient by duplicating the examples and renaming these.
Questions and answers.
Do the colors added to the theme.json file appear with the assigned names visible on hover in the color palette for various blocks?
—> Yes.
Do the font sizes added to the theme.json file appear with the assigned names and sizes in the font size dropdowns in blocks?
—> Yes.
Do the colors and font sizes appear correctly when used with blocks in the editor?
—> Yes. I believe so.
Do the colors and font sizes appear correctly when used with blocks on the front end?
—> I had not tested this earlier and I am testing these now. Yes both appeared correctly.
What did you find particularly confusing or frustrating about the experience?
—> Not understanding how to add font family, as there was not example I could copy and paste already in the theme.json file. As I could duplicate pre-existing font sizes and colors.
What did you especially enjoy or appreciate about the experience?
—> Being able to control the Gutenberg experience externally is a lot of fun. It is a very powerful tool, prefect for customizing the environment with only showing controls and pre existing options directly made in the theme.json file.
Thank you for adding this test!
Thanks for your notes @paaljoachim! I read through everything and here are some responses to some of what you experienced –
I think the intention of fullWidth is always to be just that. There are only two adjustable widths declared. Perhaps this could be expanded more in the future. Might be worth starting a discussion about custom widths on GitHub if that hasn’t already happened.
Yes this can be done but it would be in the settings portion of theme.json for the Global Styles panel, we didn’t go into this for this particular cft but this would be a natural progression for a follow-up cft.
For now I think web-safe font families are the easiest thing to add. I have tagged adding a note to my “things to document” list to explain how to add google or other loaded fonts. This would be a great how-to or tutorial. Maybe even a workshop for learn 🙂
The theme.json settings control whether or not the sidebar controls are visible in the editor. The theme.json won’t affect already created blocks unless the values for a named property are changed with the same name. this is pretty much expected behavior from my perspective, at least.
Here’s my feedback for this call for testing on themes.json:
I enjoyed the beginner testing and the tool for theme.json generation.
Intermediate tests
Setup: Check, thanks for spelling it all out here!
Tested in both WP 5.7.2 and 5.8RC1
TT1 theme v0.4.7
Gutenberg v10.9.1
Layout
Worked nicely. I was able to test multiple widths and with multiple units and saw the edits reflected on both the front end and within the editor. Though I did find myself testing if thinSize or fullSize would work as well. Would be nice to allow more values here some way.
Typography
These settings worked as expected. I was a little confused seeing that some applied to paragraph while others applied only to headings. Consistency would be great here.
I also wanted to note that the font-weight and line-height were applied as inline styles while the others (size, dropCap, and even color) were applied via classes, so again consistency would be nice to have. Classes would be the preferred manner I would think. This can also get tricky when the font in use does not support or hasn’t loaded the various multiple font weights, and the browser will use the closest weight to match the style. I saw this in my testing, as my font weight properly set the font weight in the editor, it did not display on the front end.
I did test the font-family selection as well and am surprised that this is not exposed to other blocks too. Setting a custom font on a button seems slightly less useful than setting a custom font on a heading for example.
Border
Settings again worked as expected. I saw the settings in block panel and then updates in the editor when I made changes and saw the properties on the front end too.
I’ll note here too that I was surprised that in turning off the feature support in the theme.json that the values persisted. I understand that it’s because the classes (or inline style attributes) were applied. I half expected that since the theme didn’t support the feature anymore the styles for those classes would not be loaded either. This bakes in the styles as prescribed, but I know that’s a familiar debate when discussing utility classes like this, that it’s hard to change design in the future when all the visual styling is baked in as a verbose class or worse an inline style.
Color
Settings worked as expected. I am a huge fan of defining a color and seeing it display in all the color selectors. Huge win (not exactly new here, but defining it in one place in the theme.json and seeing it propagate as classes and all for color and background is slick!)
I was able to create custom duotones and defined a new one in my theme.json. Important to note that I expected to be able to use
white
along with a hex value to define a duotone and this worked in the editor, but on the front-end the duotone rendered black instead of white. I defined:[code]{
“slug”: “blue-and-white”,
“colors”: [
“#3575D3”,
“white”
],
“name”: “Blue and White”
}[/code]
It looks fine in the editor: http://wayback.fauppsala.se:80/wayback/20210716144702/https://i.ibb.co/P5yyrh5/Screen-Shot-2021-07-01-at-19-38-04.png
but I got something else on the front end: http://wayback.fauppsala.se:80/wayback/20210716144702/https://i.ibb.co/yX9hTCC/Screen-Shot-2021-07-01-at-19-38-23.png
Setting a custom duotone manually by selecting the white and blue worked, so then I tried with hex values for both blue and white and it worked fine both in editor and front-end. So, something to look into there. Not sure if the values both need to match by design or what.
Another tester found the same experience with colors(in this case gradients) displaying black on the front end. In that case it was a problem with the slug that was used. I don’t see an error in your code above other than curly quotes which could be just the work of this website and not from your actual code. If you want to work through troubleshooting that further feel free to reach out on the Make WordPress Slack (I’m DaisyO) and we can look at it more closely.
Similar case here but not limited to gradients. I’ll do a longer write-up on results so far.
While testing, I worked through the intermediate testing challenge. All went well except that a few settings that were styled well for the editor did not display on the published view. I have attached my screen recording, system info, zip of the entire site, and theme.json files individually. This was done using LocalWP
@courane01 Wow! Thanks for sharing the video, your site info, etc. Super helpful to debug this. I tried to replicate this using 5.8RC3 but wasn’t able to after using Global Styles in the site editor. In looking through your theme.json file too, I don’t see anything majorly amiss. Since I can’t replicate this right now, I’m not going to report anything but will keep an eye if others find similar items.
Testing: Intermediate testing (TT1 Block Theme) and some advanced testing (my own theme) in my local environment
WP: 5.8-beta4
Gutenberg: 10.9.1
Pluses
I really like the general intent/direction for this.
Some things that give me pause
Intermediate Testing
Colors
** when getting a fatal php error when the json syntax is wrong its a little hard to narrow down which thing is incorrect, just have to undo until you find it.
Borders:
– Setting the border-color to one of my color presets requires that I write the css to apply it? (The class is applied but there is no style for that)
Typography
Advanced Testing
I tried out some more advanced features relevant to a theme I am working on now and got a little confused… I realize this is well beyond what was asked for in the call for testing but these are the things I would expect to be able to do…
Its not clear from the documentation or the structure of the theme.json as to which settings can be applied to which block. It seems sort of haphazard.
I wasn’t able to get to the more advanced theme dev stuff, but the basic/intermediate features seem pretty solid! In case you want to peek over my shoulder during this session, I recorded it here:
There weren’t any huge bugs for me. Just a couple of notes along with timestamps if you want to jump around:
theme.json
file.@pattyok you raise some great points / feedback, and I just wanted to add some thoughts here and there 🙂
FWIW I’ve used the custom variables generated by theme.json for other values in the theme.json (particular in the styles declarations). So it helps a bit from a code quality perspective to consolidate where these variables are being declared and clarify what they are used for. And if I can use one less css import / sass partial for declaring variables, that’s nice too.
+1, chiming in on the issue here could be helpful: http://wayback.fauppsala.se:80/wayback/20210716144702/https://github.com/WordPress/gutenberg/issues/27107. In some themes I have worked on recently, I have tried to use “intrinsically” responsive values where possible, for example: http://wayback.fauppsala.se:80/wayback/20210716144702/https://github.com/Automattic/themes/blob/trunk/quadrat/theme.json#L232. Of course there will be cases where breakpoints are still necessary, and having some responsive system in theme.json would be useful.
I believe font sizes are overridden when you supply them. Though for color palettes, the issue is a bit more nuanced because there are instances where Gutenberg may rely on those values, in addition to the theme’s preferences. Lengthy discussion here on the default color palette, including the theme’s ability to override or extend them.
Hmm, you should be able to pass through style properties like this via the elements key:
[code]
“styles”: {
“elements”: {
“h1”: {
“typography”: {
“textTransform”:”uppercase”,
“letterSpacing”: “1px”,
“fontFamily”: “monospace”,
“fontSize”: “48px”,
“lineHeight”: 1.2
}
}
}
}
[/code]
Good points about the font-sizes – now with wider support for min/max/clamp that is something I can get on board with…
As for the h1, putting in code as you suggested only renders font-size and line-height, cant seem to get any additional properties in there…
This:
[code]
“styles”: {
“elements”: {
“h1”: {
“typography”: {
“fontSize”: “var(–wp–preset–font-size–gigantic)”,
“lineHeight”: “var(–wp–custom–line-height–page-title)”,
“fontWeight”: “var(–wp–custom–font-weight–normal)”,
“textTransform”: “uppercase”
}
}
}
}
[/code]
Renders this in the css:
[code]
h1 {
font-size: var(–wp–preset–font-size–gigantic);
line-height: var(–wp–custom–line-height–page-title);
}
[/code]
I don’t know if that is a bug or a feature?
For the Advanced Steps, rather than attempt to recreate Storefront, I chose to develop a new theme to replace the Genesis child theme on my personal site. I installed the theme on the live site in time for the WordPress Cambridge Meetup where I gave a short presentation entitled My Favourite Theme.
I still have to write up my notes about my experiences with theme.json. But in the mean time, here’s a video that demonstrates parts of the theme.
http://wayback.fauppsala.se:80/wayback/20210716144702/https://youtu.be/jodDZ7nn8jA
So far, theme.json is 250 lines of code.
style.css is 150
I primarily used style.css to implement some block styles for images, links and CSS grid and flex needed to allow blocks to flow
inline.
I’ve written up my notes at http://wayback.fauppsala.se:80/wayback/20210716144702/https://sneak-peek.me/2021/07/05/fse-outreach-experiment-call-8-thrive-with-theme-json/
TL;DR you need both theme.json and style.css
Per usual, thanks so much @bobbingwide for diving in and reporting back what you found. Your write up is a great snapshot in time of what’s current possible. As we chatted about the other night, with the current gaps in functionality right now style.css is still needed with the anticipation of removal as more functionality is baked into theme.json. This themeshaper post echoes the same sentiment:
To address some of what you raised, can you say more about what you were trying to do with “Style query navigation”? As for which block supports which customizations, I agree. I think documentation needs to be built out more to help clarify this. Can you also say a tiny bit more about “defaults”? Are you saying it’s confusing to manage from a user point of view or theme author? I want to be sure I’m understanding correctly 🙂
Thanks as always for your time and attention. Hope you have a lovely golf weekend!