Greenshift Container Blocks: Ability to read widths from Block Themes

We will add this for Greenshift theme. But not for other FSE themes because hundreds of them and we can’t add for all. Default values look good on most of themes because 1200px is standard

Tutorial about width is actual, but for Greenshift theme it’s not required to use Groups because it uses more modern approach which was added in WP 6.1 But if you use – nothing bad in this

Thanks for your answers! Only one thing surprised me and left me puzzled:

But not for other FSE themes because hundreds of them and we can’t add for all.

Why do you need to manually find and add them per each FSE-theme?

I thought that WP provides the widths set at: Inspector > Styles > Layout > Dimensions as standardized variables, which can be read out programmatically:

{
   "settings": {
       "layout": {
           "contentSize": "800px",
           "wideSize": "1000px"
       }
   }
} 

theme.json > settings > layout foresees contentSize and wideSize.

So these widths are at a standardized position and name of a block theme’s theme.json.

The Greenshift block could easily programmatically read them out from the currently active block theme. No need to manually curate a catalog of theme-widths. This can be read out programmatically for each standard-compliant block theme!

This doesn’t mean that this data is available in Inspector and editor. This requires to make heavy request and we try to avoid them

I’m no developer, just a UX designer with some frontend dev knowhow. But as such I doubt the “heavy request”. These two widths are available as CSS variables:

• var(–wp–style–global–wide-size)
• var(–wp–style–global–content-size)

So easily accessible at any time IMHO. You just would need to set your variable to any of the two adequate variables. And done. Anytime the theme widths change, the variable values will have updated too.

Editor in Gutenberg is using React. So it must get request from WordPress if theme is FSE theme and if it has support for content width values. We can’t set this to be global because most of themes don’t use these variables. I hope it’s clear now for you

I only thought of the Site Editor where it is implicitly clear that the theme is a block theme. But the Block Editor supports both classic and block themes.

And as your container blocks are available in both those Gutenberg environments, I now understand that you must first query “Is this a block theme?” and this is the lookup you want to avoid. Got it now.

• This reply was modified 1 year, 11 months ago by abitofmind.

Yes. If you check most popular WordPress themes, none of them use core WordPress width variables. We simply can’t enable this for all themes because this will make bugs

What you could do is offer a limited scope setting like “Use width variable of block theme (or else fallback to Boxed)”. Because for a block theme those variables are mandatory, hence this option would always return a meaningful value!

Someone using that setting, who switches between block themes only, is guaranteed that the block always adapts to the chosen theme. For all others themes the block would fall back to “Boxed” (or whatever other fallback values you deem meaningful, I do not know Greenshift well enough yet).

What do you think of this proposal?

• This reply was modified 1 year, 11 months ago by abitofmind.
• This reply was modified 1 year, 11 months ago by abitofmind.
• This reply was modified 1 year, 11 months ago by abitofmind.

We can add selector “Block theme” but there is no fallback option for this because there is no option to detect if theme is block theme or not. And even if such option will exist (I think it will be in 6.2), when you switch to regular theme, your content will still stay as early so it will use width from block theme.

this option potentially have much more problems than it solves. We can add Block theme option but without fallback

This option potentially have much more problems than it solves.

I trust your experience on this. I have dealt with WordPress intensively now. Nevertheless have no commercial and real life experience with it yet.

We can add Block theme option but without fallback

Isn’t a fallback implicitly necessary? If the function tries get width from block theme, and nothing is returned, because the chosen theme is not a block theme, then you cannot just crash, but must fall back to some kind of value. And that I thought would be “Boxed” then, or whatever is adequate. That would be the risk free thing I thought. You get a new option (which will work if you use block themes only) and if you switch to a non-block theme it will fallback to something safe. Flexibility gained, problems avoided. That’s how I imagined it.