`.is-layout-flex` broken

[jeffpaul]

Description

As originally reported in Core Trac#56970:

I notice after I updated to 6.1 none of my buttons that were set to justify center were centered. I inspected the CSS and noticed that the .is-layout-flex class is not applying display: flex to the block. I added in my custom CSS

.is-layout-flex {
	display: flex;
}

and that fixed the issue.

Step-by-step reproduction instructions

In reviewing during the 6.1.1 bug scrub on 10 November 2022, there were no clear reproduction steps nor ideas on the cause of the issue. As @hellofromtonya noted: "The tweak in Customizer is a workaround rather than a fix. The root cause may be in the global styles when working with classic themes. But not sure. Needs more investigation and likely more details." and as @sabernhardt noted: "I think the class styles belong in the block-library stylesheet, but I don't know why global styles do not always include these styles."

Screenshots, screen recording, code snippet

Environment info

• WordPress 6.1

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[Humanify-nl]

Same as utility classes for “is-horizontal”. In 6.0, they just didn’t work on rows.

I suppose this is coupled to the fact that group and row are variations of the same block. It is creating complexity that shouldn’t be there, and now in 6.1 there is again a new utility class. But the underlying problem is not solved.

For a major structural layout block, a setting that is used in every site I ever built with WP FSE, it is demotivating to again have unreliable layout blocks, making updating from 6.0 to 6.1 annoying.

I reported this in https://github.com/WordPress/gutenberg/issues/43665. One guy confirmed it, but then nobody else noticed this, nothing happened with it, and here we are in 6.1 with the same problem.

[t-hamano]

This is another ticket reported on the core track: https://core.trac.wordpress.org/ticket/57007

[ndiego]

The root cause may be in the global styles when working with classic themes. But not sure. Needs more investigation and likely more details.

@t-hamano has done some more investigation on this. See the latest comments here. It looks like this might be related to caching, perhaps related to the caching issues we tackled right before the release of 6.1. @Mamaduka @ockham any thoughts?

[Humanify-nl]

I looked through that thread, and indeed have the new separate asset loading.

I doubt however that this would interfere with the output of utility classes. It is also no classic theme.

[Mamaduka]

Was anyone able to reproduce this issue?

The themes can opt-out the base layout styles. I wonder if this is the case with the reports.

Cc @andrewserong

[chairmanbrando]

@Mamaduka That wasn't added until v6.1, and the original Trac thread came about because upgrading to v6.1 caused the issue. In my case, I didn't get .is-layout-flex because I'd removed wp_enqueue_global_styles() from wp_enqueue_scripts. My theme wasn't using theme.json, and up until v6.1 these "global" styles were seemingly generated from it -- or a bunch of unnecessary default colors and the like. After v6.1 was installed, important layout styles like .is-layout-flex suddenly landed in there as well. The naming schemes seem potentially problematic: Why are layout-related things in "global", and why would stuff generated from theme.json be called "global"?

[andrewserong]

Thanks for the ping. I haven't been able to reproduce the issue outside of dequeuing the global styles stylesheet.

The PR that introduced the change to where layout styles are output was https://github.com/WordPress/gutenberg/pull/40875. Prior to that PR, all layout styles were output at render time for each individual block, which resulted in duplicate and redundant styles (this issue: https://github.com/WordPress/gutenberg/issues/41434), particularly for posts with a large number of blocks. The base theme.json file and global styles were the most natural place to include base layout styles, as they are applied globally to all blocks that opt in to the layout support. In this way it shares a similar logic to having global styles output global font sizes, colors or spacing presets.

For themes that opt out (either via dequeueing or an explicit opt-out), they'll be responsible for providing their own layout styles. When using core blocks that depend on layout styles, my recommendation would be to not dequeue or opt-out, but rather either use the provided CSS as-is, or add a theme.json file that specifies just those values that are desired to be included in the output. For example, if default colors aren't required, they can be removed or filtered out from the theme.json file, rather than dequeuing the whole stylesheet.

[damian-c]

I am able to reproduce this issue using the core Twenty Twenty Two theme in 6.1.1.

[DAreRodz]

Hi, this question reported in the support forums seems to be also related.

The user has mentioned using the theme Hestia. Looking at the theme's code, I can't find where it could be "opting out" from base layout styles (neither 'disable-layout-styles' nor wp_dequeue_style).

Is there any other way to dequeue those styles?

---

EDIT: I couldn't reproduce the problem with that theme, and also, .is-layout-flex was not needed in the first place because display: flex was being applied by other classes (figure.wp-block-gallery.has-nested-images). The style for these classes was actually the one missing the first time ―it "magically" appeared later― so it could probably be related to some caching issue. 🤷

[ockham]

Another instance of this issue reported here.

[andrewserong]

Thanks for the additional reports folks (and please do continue to drop comments here when folks report the issue). So far I haven't been able to replicate this problem outside of manually dequeueing global styles, so at least at face value, it does sound like it could be a potential caching problem of some kind if the problem is appearing on themes that aren't doing that dequeuing.

I'll just ping @spacedmonkey and @oandregal for visibility in case this issue rings any bells with the recent changes to global styles caching? I personally don't have the best grasp of how the object caching and transients behave, but happy to help investigate as needed.

[ockham]

Another: https://wordpress.org/support/topic/images-showing-vertically-instead-of-in-a-column-of-3-in-pages

[threadi]

Another: https://wordpress.org/support/topic/gallery-block-working-inconsistently/

[andrewserong]

Update: I'm still unable to reproduce this in any of my environments. Based on the reports so far, outside of themes or plugins that explicitly switch off global styles output, I'm leaning toward suspecting that this is likely a caching issue of some kind. I see that there is currently work to adjust the caching of global styles over in #45679 and related PRs.

For visibility, I'll just ping some of the folks who worked on and reviewed that PR, in case folks can offer any insights into global styles caching, or caching invalidation that needs to be adjusted: @mmtr @spacedmonkey @oandregal @felixarntz @geriux @tyxla

To recap on the feature that is not outputting correctly in these reported cases:

• In WordPress 6.1, the core theme.json file was updated to include a set of layout definitions (here)
• The logic in the main theme JSON class was updated to include processing and output of base layout styles based on that set of definitions (here) — these styles get included in the global styles output

In the reported cases (outside of themes or plugins that switch off global styles), it sounds like the style output works when WP_DEBUG or SCRIPT_DEBUG is set to true, which seems to potentially point to the transient (or now object cache) logic for global styles (e.g. in gutenberg_get_global_stylesheet or the wp equivalent).

On my mind is that the core theme.json file, and the processing of it, changes in each Gutenberg and major (or minor) WordPress release, however it sounds like the caching logic might assume that the core theme.json and its output doesn't change.

Can anyone shed any more light on this? Unfortunately, I haven't been able to find anything more concrete than these suspicions based on inferences from the reports so far, and am unsure what else to investigate.

[oandregal]

Since WordPress 5.9, the global styles stylesheet has been cached for 1 minute. So, I suppose the following could happen:

• the site has a global styles stylesheet, and it is cached (certain layout styles live in the block stylesheet)
• the site is updated to 6.1 (hence, certain layout styles are moved from the block stylesheet to the global styles stylesheet)
• because the global styles stylesheet is cached, it takes 1 minute for the new styles to be recalculated properly

Is this what people are experiencing? If so, I'm sorry to say that I don't have much advice other than wait for a minute. Though judging by the reports it seems the issue is persistent?

The current state of caching the global styles stylesheet is unfortunate. Coincidentally, we have been working on fixing it. https://github.com/WordPress/gutenberg/pull/45679 has landed recently, and will be part of Gutenberg 14.7. It properly updates the styles upon certain events (core, plugins, or themes are updated, theme switch, etc.).

[ockham]

Though judging by the reports it seems the issue is persistent?

Yeah, it's definitely persistent, I'm afraid 😕

[ockham]

Let's maybe try to gather more information from the affected users so we have a better shot at reproducing this? I'm thinking e.g. which theme they're using, list of active plugins -- anything else?

We can maybe post a message like the following to the form threads:

Hey,

thanks again for reporting this issue. We're currently investigating it (https://github.com/WordPress/gutenberg/issues/45713), but we're having a bit of a hard time reproducing it. Would you mind providing us with some more information about the website where you've encountered the issue?

Could you share:
- The theme you're using
- The list of active plugins

Thanks in advance!

Here's the list of forum threads and Trac tickets I've found referenced in this issue. I'll wait for feedback from y'all and will then post the message to those threads.

• https://core.trac.wordpress.org/ticket/56970
• https://core.trac.wordpress.org/ticket/57007
• https://wordpress.org/support/topic/gallery-blocks-show-vertical/
• https://wordpress.org/support/topic/gallery-block-images-are-stacking-instead-of-gallery/
• https://wordpress.org/support/topic/images-showing-vertically-instead-of-in-a-column-of-3-in-pages
• https://wordpress.org/support/topic/gallery-block-working-inconsistently/

[oandregal]

For the record, I tested with some of the themes I see people using (e.g.: poseidon), as well as other default themes. I tested with and without WP_DEBUG on. The only consistent result I could get was when the global stylesheet was not present (for example, due to the user disabling it through a plugin).

Some information that can be useful to share with people to gather information and pinpoint the issue is whether those sites have the global-styles-inline-css present:

• If it is not present, that's the core issue: there is something in the site that is deactivating it.
• If it is present, but they still have the issue persistently (refreshing the page after 1 minute), the root cause is different. Perhaps they can share the contents of that stylesheet for us to inspect and gather more info?

[andrewserong]

Thanks for the discussion, folks, and for re-testing! Great idea asking for more info from the users who report the issue:

I'm thinking e.g. which theme they're using, list of active plugins -- anything else?

Possibly which hosting provider they're using, if it's an okay thing to ask. Some managed hosts run a bunch of caching or MU plugins that are invisible to the user, and could potentially be doing things behind the scenes that could break things. For example, I wonder if it's happening on sites that configure their own object cache that gets used by get/set transient (though in theory you'd think the timeout would still be working in that case) 🤔

[oandregal]

For example, I wonder if it's happening on sites that configure their own object cache that gets used by get/set transient (though in theory you'd think the timeout would still be working in that case) thinking

That's interesting. If they don't respect the timeout, it can certainly be the case. If so, https://github.com/WordPress/gutenberg/pull/45679 (Gutenberg 14.7) will fix it. I don't presume we can ask people to use the plugin, but perhaps this issue warrants a strong argument to release a WordPress 6.1.2 with that PR?

[ockham]

Thanks @oandregal and @andrewserong! Here's an updated draft that I'll send out shortly:

Hey,

thanks again for reporting this issue. We're currently investigating it (https://github.com/WordPress/gutenberg/issues/45713), but we're having a bit of a hard time reproducing it. 

Would you mind providing us with some more information about the website where you've encountered the issue?

If you’re comfortable sharing the following, could you let us know:
- The theme you're using.
- The list of active plugins.
- Which hosting provider you’re using.
- If the page source of the site you’re having problems with contains a `<style id='global-styles-inline-css'>` tag. If yes, we’d also ask you to share it’s contents (i.e. after that tag and before the corresponding closing `</style>` tag).

Finally — and only if you’re comfortable doing so; we don’t generally recommend it on a production site: Would you mind trying to install and activate the Gutenberg plugin? We have a tentative fix (https://github.com/WordPress/gutenberg/pull/45679) that’s present in the latest version, and we’d like to know if it fixes the issue. (If so, we’ll try to get it expedited into a WordPress 6.1.2 release.)

Thanks in advance!

[ockham]

Update: I've now posted the above message to

• https://wordpress.org/support/topic/gallery-blocks-show-vertical/
• https://wordpress.org/support/topic/gallery-block-images-are-stacking-instead-of-gallery/
• https://wordpress.org/support/topic/images-showing-vertically-instead-of-in-a-column-of-3-in-pages
• https://wordpress.org/support/topic/gallery-block-working-inconsistently/

I haven't yet posted it to the two Trac issues linked here, https://core.trac.wordpress.org/ticket/56970 and https://core.trac.wordpress.org/ticket/57007.

[ockham]

When skimming over 56970, I found this latest comment:

Another possible cause is a plugin or theme filtering 'safe_style_css' to include 'display' (sample code below). This will cause gallery blocks to display incorrectly as a stacked column or row in both the front-end as well as the editor.

add_filter( 'safe_style_css', function( $styles ) {
    $styles[] = 'display';
    return $styles;
} );

As an alternative solution, plugin/theme developers may replace the 'safe_style_css' filter with a <div> hidden attribute assuming 'display' is needed to set visibility to 'none'. If 'display' is needed for other purposes, then a different solution is required.

<div hidden></div>

Personally, I haven't been able to reproduce that that triggers the is-flex-layout issue, but maybe someone else can give it a try to confirm/reject.

[ockham]

We've gotten one reply so far: https://wordpress.org/support/topic/gallery-blocks-show-vertical/#post-16242639, answering all the questions we've asked. Highlight:

The topline news is that installing the Gutenberg plugin fixed the issue.

Based on that, we might want to come up with a plan to get a fix into Core and release a 6.1.2.

Since we haven't been able to reproduce ourselves, it'd be great if we could confirm that it's indeed https://github.com/WordPress/gutenberg/pull/45679 that fixes the issue. Maybe we can isolate that into a tiny plugin and ask folks to test that?

[andrewserong]

Another highlight from that one:

The global-styles-inline-css inline styles includes the rule :where(.wp-block-columns.is-layout-flex){gap: 2em;} which means that the code path for outputting (block specific) layout styles is being hit for this particular site. One (unverified) hunch for why the base layout styles might not be appearing, is that potentially during the upgrade process, it's possible that the new code path in 6.1 is being executed either before the core theme.json file is updated, or with a stale copy of the data within it. In the get_layout_styles method of the Theme JSON class, it performs a look up for the layout definitions from the core / merged theme.json data on this line.

So, from my perspective, this appears to be consistent with the idea that caching is the culprit. I've done a re-read of the layout code a couple of times, and nothing else appears to jump out at me so far.

[ockham]

Two more replies over at the Trac issue:

https://core.trac.wordpress.org/ticket/56970#comment:41:

Theme: CheerUp Plugins: The problem occurred also with all Plugins deactivated. My Webpage is self hosted on an own dedicated server.

https://core.trac.wordpress.org/ticket/56970#comment:46:

My theme is Poseidon. I also had the same fault with all the plugins turned off. My site is on Bluehost.

https://github.com/WordPress/gutenberg/issues/45713#issuecomment-1330329869 was also on Bluehost 🤔

[eric-michel]

My site had this issue temporarily. We had Global Styles disabled in our theme. After the WP update, I re-enabling Global Styles, but the is-style-flex class was still not being defined in the Global Styles output. This was on WP Engine.

It turned out I had to clear the server cache in a very specific way. The normal Clear all caches at once option was not sufficient. I also had to go to the Domains page and individually clear each domain's cache.

Just figured I'd share my experience in case that helps anyone!

[ockham]

Thank you @eric-michel, that's definitely helpful!

[oandregal]

The potential bugfix to this has now been prepared to backport https://github.com/WordPress/wordpress-develop/pull/3712

I understand the plan is still delivering in a plugin, first, and then make it to a potential WordPress 6.1.2.

[ja-sk]

Hello, just wanted to chime in:

1. I run a custom theme and had the issue with the left aligned buttons after updating to 6.1.1 from 6.0.3.
2. I checked my theme setup, I do not have the global-styles-inline-css removal implemented.
3. I deactivated all caching plugins to no avail.
4. I switched to the twenty-twenythree theme and alignment was correct.
5. I switched back to my theme and alignment was wrong again
6. I installed the Gutenberg Plugin and alignment was correct in my theme.
7. Since I do not need Gutenberg right now I disabled it and implemented the css fix body .is-layout-flex { flex-wrap: wrap; align-items: center; display: flex; }

Whats peculiar is, that on a different instance where I run the exact same theme, same plugins and even same server setup (they are literally in the same virtual server with all settings identical) the issue has not appeared after updateing to 6.1.1 ... the only thing that is different on this instance is, that the content was added while running 6.0.x and not earlier (some 5.x version) of wordpress.

EDIT: sorry, it is the other way around. The working instance has content that was added pre WP6, the non-working instance has content that was added while running WP6.x

Hope this helps.

Plugins I use: Accordion Blocks Borlabs Cookie MainWP Child Wayfinder WPML and Subplugins W3 Total Cache Yoast