`.is-layout-flex` broken

jeffpaul commented 2 years ago

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

Screenshot 2022-11-02 at 9 50 00 PM

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 commented 2 years ago

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 commented 1 year ago

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

ndiego commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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

DAreRodz commented 1 year ago

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 commented 1 year ago

Another instance of this issue reported here.

andrewserong commented 1 year ago

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 commented 1 year ago

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

threadi commented 1 year ago

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

andrewserong commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

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

ockham commented 1 year ago

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.

oandregal commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Update: I've now posted the above message to

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

oandregal commented 1 year ago

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 commented 1 year ago

Hello, just wanted to chime in:

I run a custom theme and had the issue with the left aligned buttons after updating to 6.1.1 from 6.0.3.
I checked my theme setup, I do not have the global-styles-inline-css removal implemented.
I deactivated all caching plugins to no avail.
I switched to the twenty-twenythree theme and alignment was correct.
I switched back to my theme and alignment was wrong again
I installed the Gutenberg Plugin and alignment was correct in my theme.
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

kathrynwp commented 1 year ago

Also reported in this forum thread: https://wordpress.org/support/topic/gallery-block-only-shows-one-column/

They have added custom CSS to work around the issue in the meantime.

User's theme:

Astra Pro Version 3.9.3

User's plugins:

Astra Widgets Version 1.2.12 Better Search Replace Version 1.4.1 Duplicator Version 1.5.1 Free Gifts for WooCommerce Version 8.7 Ilmenite Cookie-tillåtelse Version 3.2.0 Imsanity Version 2.8.2 Loco Translate Version 2.6.3 Print Invoice & Delivery Notes for WooCommerce Version 4.6.5 Smash Balloon Instagram Feed Version 6.1 Spectra Version 2.0.16 WooCommerce Version 7.1.0 WooCommerce Blocks Version 9.0.0 WooCommerce Mondido Payments Gateway Version 4.4.1 WooCommerce Weight Based Shipping Version 5.3.26 WP Mail SMTP Version 3.6.1 WPCode Lite Version 2.0.4.4 Yoast SEO Version 19.10

Inline CSS

One odd thing to note: as a test, they created a full copy of the entire site via the Duplicator plugin. On that fresh copy of the site, the related lines of inline CSS are not missing and their galleries look fine. This adds fuel to the idea of this being caching-related.

They have not yet activated the Gutenberg plugin as they have some concerns that it might affect the site if uninstalled, so I don't know if the potential fix there would work for them.

EdithAllison commented 1 year ago

I'm seeing the same issue. In production, hosted on a dedicated nginx server with caching the flex layout is not applied, the inline style for "is-layout-flex" and "is-layout-flow" are missing from frontend.

The same site / code downloaded to "Local" by Flywheel on my Mac works. This points to a hosting-specific issue unrelated to theme or plugins.

Theme: custom child theme of Storefront Hosting provider: BigScoots (dedicated nginx) Plugins: it's a super long list, but as the same page works fine on Local by Flywheel on my Mac I doubt it's the plugins

Missing on production site:

body .is-layout-flex {
  flex-wrap: wrap;
  align-items: center;
}
body .is-layout-flex {
  display: flex;
}
body .is-layout-flex {
  gap: 24px;
}
body .is-layout-flow > * + * {
  margin-block-start: 24px;
  margin-block-end: 0;
}
body .is-layout-flow > * {
  margin-block-start: 0;
  margin-block-end: 0;
}

ironprogrammer commented 1 year ago

Thank you, all, for your reports on this issue 🙌🏻

If you have experienced this issue on your site, please read on... 👀

If you are comfortable testing a hotfix plugin to address this apparent caching issue, please see this plugin testing info in Trac. The plugin can be tested on sites before or after upgrade to WordPress 6.1.1.

Feedback regarding the hotfix is much appreciated! How it works in various environments will help decide how soon a permanent fix is shipped.

ja-sk commented 1 year ago

@ironprogrammer thanks for the fix! I have several affected instances so I was able to do some testing

https://core.trac.wordpress.org/attachment/ticket/56970/wp-hotfix-56970.zip only works while it is installed, as soon as I uninstall it the buttons are again left aligned

https://core.trac.wordpress.org/attachment/ticket/56970/wp-alt-test-56970.zip seems to work permanently even if I uninstall and delete it after. Retestet after 5 minutes in incognito session and still works.

github-actions[bot] commented 1 year ago

Hi, This issue has gone 30 days without any activity. This means it is time for a check-in to make sure it is still relevant. If you are still experiencing this issue with the latest versions, you can help the project by responding to confirm the problem and by providing any updated reproduction steps. Thanks for helping out.

JiveDig commented 1 year ago

Using WP 6.1.1, our hybrid theme (uses blocks but not theme.json) still sees this issue... CSS is missing for is-layout-flex and similar classes.

https://core.trac.wordpress.org/attachment/ticket/56970/wp-hotfix-56970.zip fixes the issue while active.

https://core.trac.wordpress.org/attachment/ticket/56970/wp-alt-test-56970.zip does not fix the issue at all.

seamofreality commented 1 year ago

I can confirm the same result as @ja-sk

https://core.trac.wordpress.org/attachment/ticket/56970/wp-hotfix-56970.zip fixing issue while active.

https://core.trac.wordpress.org/attachment/ticket/56970/wp-alt-test-56970.zip fixes it even after deactivating it.

Bit of background: the bug occured with the installation of an old standing customer, the theme is from 2015 and hasn't been touched in years. So there's no theme.json and no theme support toggles for any global stylesheets or anything that came in the last two or three years, I'd say. The customer keeps WordPress and the plugins updated herself and noticed now that the styles are missing when using the galeries.

Thanks for the hotfix! 🤞🏻

markhowellsmead commented 1 year ago

Same problem here: CSS is missing for is-layout-flex and similar classes. Block editor and theme.json in use, but Site Editor isn't.

Turning on WP_DEBUG and reloading the page then does include the inline CSS rules; turning it off again reinstates the problem. I'm guessing something funky is cached and can't be/isn't updated.

ndiego commented 1 year ago

Just wanted to note that this issue should be resolved with https://github.com/WordPress/wordpress-develop/pull/3712, which is scheduled for 6.2.

markhowellsmead commented 1 year ago

Thanks Nick!

ndiego commented 1 year ago

Once 6.2 Beta 1 is out next week, we should retest this issue and confirm that everything is fixed. I will leave this issue open until Beta 1 is out, and everyone has had a chance to test.

Mamaduka commented 1 year ago

Hey, everyone 👋

The WordPress 6.2 Beta 1 was released this week. I wanted to check if you had a chance to retest and confirm the fix.

markhowellsmead commented 1 year ago

Rules for .is-layout-flex are part of the inline CSS with the current nightly core build.

~~I'm not sure what induces the need for .is-layout-flow, but this class is used in several places in the HTML of the page but there are no corresponding CSS rules assigned to those elements.~~

Never mind; I was looking on the wrong element. There are rules for .is-layout-flow > * + * in the CSS.

Mamaduka commented 1 year ago

Thanks for testing, @markhowellsmead 🙇

ndiego commented 1 year ago

It looks like we are all set on this one. I am going to close out, but if anyone continues to experience issues, please feel free to reopen. Thanks!

goodpenguins commented 1 year ago

Hey :) everyone,

WP 6.2. FSE. Own theme.

It works in the Site Editor but does not in the Post Editor - .is-layout-flex is missing. In the frontend all is well.

Deactivating all plugins and using the default theme does not solve the problem.

If I raise a new empty site - everything is in order.

Magic.

goodpenguins commented 1 year ago

I take back my words that everything is fine on the new empty site. Actually, no. .is-layout-flex css is empty when Editor Preferences: Use theme style is disabled.

Theme: clear Twenty Twenty-Three Plugins: no plugins Block: Group Mode: Row

//<style id='global-styles-inline-css'> body{--wp--preset--color--black: #000000;--wp--preset--color--cyan-bluish-gray: #abb8c3;--wp--preset--color--white: #ffffff;--wp--preset--color--pale-pink: #f78da7;--wp--preset--color--vivid-red: #cf2e2e;--wp--preset--color--luminous-vivid-orange: #ff6900;--wp--preset--color--luminous-vivid-amber: #fcb900;--wp--preset--color--light-green-cyan: #7bdcb5;--wp--preset--color--vivid-green-cyan: #00d084;--wp--preset--color--pale-cyan-blue: #8ed1fc;--wp--preset--color--vivid-cyan-blue: #0693e3;--wp--preset--color--vivid-purple: #9b51e0;--wp--preset--color--base: #F6F2EC;--wp--preset--color--contrast: #21251F;--wp--preset--color--primary: #5B4460;--wp--preset--color--secondary: #FCC263;--wp--preset--color--tertiary: #E7A1A9;--wp--preset--gradient--vivid-cyan-blue-to-vivid-purple: linear-gradient(135deg,rgba(6,147,227,1) 0%,rgb(155,81,224) 100%);--wp--preset--gradient--light-green-cyan-to-vivid-green-cyan: linear-gradient(135deg,rgb(122,220,180) 0%,rgb(0,208,130) 100%);--wp--preset--gradient--luminous-vivid-amber-to-luminous-vivid-orange: linear-gradient(135deg,rgba(252,185,0,1) 0%,rgba(255,105,0,1) 100%);--wp--preset--gradient--luminous-vivid-orange-to-vivid-red: linear-gradient(135deg,rgba(255,105,0,1) 0%,rgb(207,46,46) 100%);--wp--preset--gradient--very-light-gray-to-cyan-bluish-gray: linear-gradient(135deg,rgb(238,238,238) 0%,rgb(169,184,195) 100%);--wp--preset--gradient--cool-to-warm-spectrum: linear-gradient(135deg,rgb(74,234,220) 0%,rgb(151,120,209) 20%,rgb(207,42,186) 40%,rgb(238,44,130) 60%,rgb(251,105,98) 80%,rgb(254,248,76) 100%);--wp--preset--gradient--blush-light-purple: linear-gradient(135deg,rgb(255,206,236) 0%,rgb(152,150,240) 100%);--wp--preset--gradient--blush-bordeaux: linear-gradient(135deg,rgb(254,205,165) 0%,rgb(254,45,45) 50%,rgb(107,0,62) 100%);--wp--preset--gradient--luminous-dusk: linear-gradient(135deg,rgb(255,203,112) 0%,rgb(199,81,192) 50%,rgb(65,88,208) 100%);--wp--preset--gradient--pale-ocean: linear-gradient(135deg,rgb(255,245,203) 0%,rgb(182,227,212) 50%,rgb(51,167,181) 100%);--wp--preset--gradient--electric-grass: linear-gradient(135deg,rgb(202,248,128) 0%,rgb(113,206,126) 100%);--wp--preset--gradient--midnight: linear-gradient(135deg,rgb(2,3,129) 0%,rgb(40,116,252) 100%);--wp--preset--duotone--dark-grayscale: url('#wp-duotone-dark-grayscale');--wp--preset--duotone--grayscale: url('#wp-duotone-grayscale');--wp--preset--duotone--purple-yellow: url('#wp-duotone-purple-yellow');--wp--preset--duotone--blue-red: url('#wp-duotone-blue-red');--wp--preset--duotone--midnight: url('#wp-duotone-midnight');--wp--preset--duotone--magenta-yellow: url('#wp-duotone-magenta-yellow');--wp--preset--duotone--purple-green: url('#wp-duotone-purple-green');--wp--preset--duotone--blue-orange: url('#wp-duotone-blue-orange');--wp--preset--font-size--small: clamp(1rem, 0.924rem + 0.24vw, 1.125rem);--wp--preset--font-size--medium: clamp(1.25rem, 1.021rem + 0.73vw, 1.625rem);--wp--preset--font-size--large: clamp(1.375rem, 1.07rem + 0.98vw, 1.875rem);--wp--preset--font-size--x-large: clamp(1.75rem, 1.369rem + 1.22vw, 2.375rem);--wp--preset--font-size--tiny: clamp(0.875rem, 0.799rem + 0.24vw, 1rem);--wp--preset--font-size--normal: clamp(1.125rem, 1.049rem + 0.24vw, 1.25rem);--wp--preset--font-size--xx-large: clamp(2.125rem, 1.706rem + 1.34vw, 2.813rem);--wp--preset--font-size--huge: clamp(2.5rem, 1.966rem + 1.71vw, 3.375rem);--wp--preset--font-size--gigantic: clamp(3.375rem, 2.384rem + 3.17vw, 5rem);--wp--preset--font-family--dm-sans: "DM Sans", sans-serif;--wp--preset--font-family--ibm-plex-mono: 'IBM Plex Mono', monospace;--wp--preset--font-family--inter: "Inter", sans-serif;--wp--preset--font-family--system-font: -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",sans-serif;--wp--preset--font-family--source-serif-pro: "Source Serif Pro", serif;--wp--preset--spacing--30: clamp(0.625rem, 0.434rem + 0.61vw, 0.938rem);--wp--preset--spacing--40: clamp(1.25rem, 0.869rem + 1.22vw, 1.875rem);--wp--preset--spacing--50: clamp(1.875rem, 1.303rem + 1.83vw, 2.813rem);--wp--preset--spacing--60: clamp(2.5rem, 1.738rem + 2.44vw, 3.75rem);--wp--preset--spacing--70: clamp(2.813rem, 1.098rem + 5.49vw, 5.625rem);--wp--preset--spacing--80: clamp(3.75rem, 1.463rem + 7.32vw, 7.5rem);--wp--preset--shadow--natural: 6px 6px 9px rgba(0, 0, 0, 0.2);--wp--preset--shadow--deep: 12px 12px 50px rgba(0, 0, 0, 0.4);--wp--preset--shadow--sharp: 6px 6px 0px rgba(0, 0, 0, 0.2);--wp--preset--shadow--outlined: 6px 6px 0px -3px rgba(255, 255, 255, 1), 6px 6px rgba(0, 0, 0, 1);--wp--preset--shadow--crisp: 6px 6px 0px rgba(0, 0, 0, 1);}

ironprogrammer commented 1 year ago

Thanks for the update, @goodpenguins:

I take back my words that everything is fine on the new empty site. Actually, no. .is-layout-flex css is empty when Editor Preferences: Use theme style is disabled.

Would you please clarify if disabling theme styles in the editor affects the flex styling in the site frontend (as described in the issue)? This original report related to a frontend caching problem, but in my testing the frontend appeared unaffected by the editor preferences change noted here.

goodpenguins commented 1 year ago

Hey :). Thank you for your reply.

The problem only in the Post Editor, Template Editor and frontend are ok. I am sure the issue does not related to the cache.

WordPress / gutenberg