.is-layout-flex broken

[rsmith4321]

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.

[brookedot]

Hi @rsmith4321 is this on the front end within your Theme or somewhere in the WP-Admin? Could you provide a screenshot and if possible steps to replicate to help us track this one down?

[rsmith4321]

Screenshot

[rsmith4321]

It's on the front end. It's possible it's something with my theme, but I believe the .is-layout-flex class is part of the standard buttons block. I will include a screenshot, you can see the display: flex is added to the block, but that is with my custom CSS. If that weren't added the buttons would not be centered and would not be flexbox. I've fixed the issue on my site, I just thought it would be something to check.

[sabernhardt]

Thanks for the report!

The .is-layout-flex class selector is in global styles. I tried disabling the global styles in functions.php (with the classic theme Twenty Sixteen), and then the Buttons block did not have display: flex.

function wptrac_remove_global_css() {
	remove_action( 'wp_enqueue_scripts', 'wp_enqueue_global_styles' );
}
add_action( 'after_setup_theme', 'wptrac_remove_global_css' );

Did you disable the global styles, too?

[kvizas]

I'm experiencing the same problem. It seems that some of the global styles classes do not load after the update.

These are my current global styles which of course do not include is-layout-flex.
​https://prnt.sc/HKMIa7Z2Ypcc

Why is that? Is it necessary to add our own styling or can it be fixed in some other way?

[ryankienstra]

Thanks for opening this, we've had multiple users see this.

[webfactoryuk]

Query Loop block grid layout seems to be broken with the same error. I have also seen the gallery block displaying as a single column being reported but I haven't been able to inspect the page to see if its the same issue. I would assume it is!

[chatty gardener]

My galleries are displaying as a single column after the upgrade to 6.1. Is there an easy fix?

[rsmith4321]

I've actually noticed a lot of other issues after first opening this. It seems like certain blocks like columns and buttons are just missing their default css styles after the update. Hopefully this will be fixed soon.

[ChadUM]

I'm having the same issue with galleries. Single column, and none of the images are clickable. And on all post images, there's no longer padding between them.

[poena]

I am still unable to reproduce this issue. It would be good to have detailed steps for how to reproduce it.

In 6.1:

1. On WordPress 6.1, activate a classic theme, for example Twenty Twenty version: 2.1. No plugins are active.
2. Create a new post.
3. In the post, add a gallery block.

In my case, the gallery block is set up to display 3 images that I selected from the media library. I did not make any changes to the gallery settings. The images are also not linked. Two of them has captions.

4. Confirm that the images are shown in 3 columns in the editor.
5. Save the post and view it on the front of the website. Confirm that they show in 3 columns on the front.

The figure that wraps the gallery has the class is-layout-flex and the CSS is added to the block with

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

body .is-layout-flex is added inline on the page inside
<style id='global-styles-inline-css'>

Upgrading from WordPress 5.8.6 to 6.1:

• Theme used: Twenty Twenty-One version 1.7.

In 5.8.6, the display:flex is directly on the .wp-block-gallery on the <figure> element as well as on the blocks-gallery-grid class on the inner <ul> element.
The gallery with 3 images is displayed using 3 columns in the editor and the front.

After upgrading to 6.1, when I open the post with the same gallery in the block editor, the gallery has been updated to the new version of the block that uses images as separate inner blocks.
The gallery with 3 images is displayed using 3 columns in the editor and the front.

The figure that wraps the gallery has the class is-layout-flex and the CSS is added to the block with

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

body .is-layout-flex is added inline on the page inside
<style id='global-styles-inline-css'>

---

• I am using nginx and PHP version is 7.4.1,
• I have set define( 'WP_DEBUG', false ); but setting it to true makes no difference, both buttons and gallery are displayed correctly.

[chatty gardener]

I'm afraid I don't understand code but this is a link to a post that was displaying properly when I published but is now showing a gallery in single column format: ​https://thechattygardener.com/gardens/eking-out-summer-at-cerney-house/

Replying to poena:

I am still unable to reproduce this issue. It would be good to have detailed steps for how to reproduce it.

In 6.1:

1. On WordPress 6.1, activate a classic theme, for example Twenty Twenty version: 2.1. No plugins are active.
2. Create a new post.
3. In the post, add a gallery block.

In my case, the gallery block is set up to display 3 images that I selected from the media library. I did not make any changes to the gallery settings. The images are also not linked. Two of them has captions.

4. Confirm that the images are shown in 3 columns in the editor.
5. Save the post and view it on the front of the website. Confirm that they show in 3 columns on the front.

The figure that wraps the gallery has the class is-layout-flex and the CSS is added to the block with

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

body .is-layout-flex is added inline on the page inside
<style id='global-styles-inline-css'>

Upgrading from WordPress 5.8.6 to 6.1:

• Theme used: Twenty Twenty-One version 1.7.

In 5.8.6, the display:flex is directly on the .wp-block-gallery on the <figure> element as well as on the blocks-gallery-grid class on the inner <ul> element.
The gallery with 3 images is displayed using 3 columns in the editor and the front.

After upgrading to 6.1, when I open the post with the same gallery in the block editor, the gallery has been updated to the new version of the block that uses images as separate inner blocks.
The gallery with 3 images is displayed using 3 columns in the editor and the front.

The figure that wraps the gallery has the class is-layout-flex and the CSS is added to the block with

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

body .is-layout-flex is added inline on the page inside
<style id='global-styles-inline-css'>

---

• I am using nginx and PHP version is 7.4.1,
• I have set define( 'WP_DEBUG', false ); but setting it to true makes no difference, both buttons and gallery are displayed correctly.

[JeffPaul]

Without clear (or really _any_) steps on how to reproduce this will likely get punted out of the 6.1.1 milestone tomorrow to Future Release. So if someone is able to reproduce, then please provide details on how to do so... thanks!

[chatty gardener]

I simply followed the usual method of inserting a gallery - choosing it as a block. Sorry, don't speak code! All previously perfect posts have now defaulted to single column.

Does this help? The code for one of the affected gallery blocks.

<!-- wp:gallery {"linkTo":"none"} -->
<figure class="wp-block-gallery has-nested-images columns-default is-cropped"><!-- wp:image {"id":17246,"sizeSlug":"large","linkDestination":"none"} -->
<figure class="wp-block-image size-large"><img src="https://thechattygardener.com/wp-content/uploads/IMG_7758.png" alt="" class="wp-image-17246"/></figure>
<!-- /wp:image -->

<!-- wp:image {"id":17247,"sizeSlug":"large","linkDestination":"none"} -->
<figure class="wp-block-image size-large"><img src="https://thechattygardener.com/wp-content/uploads/IMG_7761.png" alt="" class="wp-image-17247"/></figure>
<!-- /wp:image --></figure>
<!-- /wp:gallery -->

Replying to JeffPaul:

Without clear (or really _any_) steps on how to reproduce this will likely get punted out of the 6.1.1 milestone tomorrow to Future Release. So if someone is able to reproduce, then please provide details on how to do so... thanks!

[poena]

What was the WP version where it worked/was published?

Were all plugins deactivated when testing? If not, please try again without plugins.

[chairmanbrando]

As far as I can tell, the lack of style#global-styles-inline-css occurs when a theme (or plugin, I suppose) does this:

remove_action( 'wp_enqueue_scripts', 'wp_enqueue_global_styles' );

Why would a theme do this? Well, if they're not using theme.json, this block of styles previously only included fluff like unused default color, gradient, and font size declarations. Might as well drop them if all that's handled otherwise, right?

As of WPv6.1, now there are layout styles in there like these .is-layout-* classes. Is there a reason these new layout styles aren't in the compiled block library CSS file, added as inline per-block styles, or in style#core-block-supports-inline-css?

[poena]

There are 3 themes and 29 plugins in the official directories that uses wp_enqueue_global_styles and not all removes it.

I don't have access to searching other products but these are small numbers to generate so many reports from users, except one of the plugins is Autoptimize with 1m installs.

[chairmanbrando]

I had two hand-built themes running on WPv6.1 where one was getting the global styles and the other wasn't. It took a bit to find what was different between their setup, but it was the remove_action() call above. If I comment that out, style#global-styles-inline-css comes back immediately.

wp_enqueue_global_styles() is hooked in via wp-includes/default-filters.php without any conditional checks, so something relatively common must be removing it if this issue is getting reported a lot. Maybe it is Autoptimize, but in my case I was simply trying to remove default fluff from WP.

Which brings me back to my side issue that these layout styles being in this particular chunk of CSS perhaps isn't the right call if it's meant to be built up from theme.json. But Gutenberg changes way too often (and has broken live sites a half dozen times!) for me to keep up.

[OptimizingMatters]

Replying to poena:

There are 3 themes and 29 plugins in the official directories that uses wp_enqueue_global_styles and not all removes it.

I don't have access to searching other products but these are small numbers to generate so many reports from users, except one of the plugins is Autoptimize with 1m installs.

Autoptimize can indeed remove global styles if the "Remove WordPress block CSS" is active on the "Extra" settings tab. By default that option is off though.

[chatty gardener]

I have just tested putting a gallery into a post while every plugin was disabled and still got the images displayed in single column instead of side-by-side.

I am running WP 6.1. The site was working fine until the recent upgrade.

Replying to poena:

What was the WP version where it worked/was published?

Were all plugins deactivated when testing? If not, please try again without plugins.

[chatty gardener]

I don't use Autoptimize so that's not causing the problem with my site.

Replying to poena:

There are 3 themes and 29 plugins in the official directories that uses wp_enqueue_global_styles and not all removes it.

I don't have access to searching other products but these are small numbers to generate so many reports from users, except one of the plugins is Autoptimize with 1m installs.

[poena]

@chatty-gardener I installed the Poseidon theme version 2.3.9 on WordPress 6.1 without plugins and created a new gallery, and it displays in columns in both the editor and front.

I would like to help but I have reached the limit of what I can troubleshoot, I am out of ideas.

[chatty gardener]

I put the site into troubleshooting mode (using the Healthcheck and Troubleshooting plugin version 1.5.1) and created a post with a gallery. It displays correctly. I had not enabled any of the other plugins in this mode. However, as soon as I disable the troubleshooting, it reverts to a single column display.

What do you advise?

Replying to poena:

@chatty-gardener I installed the Poseidon theme version 2.3.9 on WordPress 6.1 without plugins and created a new gallery, and it displays in columns in both the editor and front.

I would like to help but I have reached the limit of what I can troubleshoot, I am out of ideas.

[chatty gardener]

I've also tried the test post with a gallery in troubleshoot mode and enabled each plugin, one at a time. All displayed correctly but as soon as I come out of troubleshooting mode, they revert to broken.

Replying to poena:

@chatty-gardener I installed the Poseidon theme version 2.3.9 on WordPress 6.1 without plugins and created a new gallery, and it displays in columns in both the editor and front.

I would like to help but I have reached the limit of what I can troubleshoot, I am out of ideas.

[imrazor]

Hi!

Had the same problem after V6.1 Update with the Theme "CheerUp".
The Support fixed the problem with following custom CSS:

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

Replying to chatty gardener:

I've also tried the test post with a gallery in troubleshoot mode and enabled each plugin, one at a time. All displayed correctly but as soon as I come out of troubleshooting mode, they revert to broken.

Replying to poena:

@chatty-gardener I installed the Poseidon theme version 2.3.9 on WordPress 6.1 without plugins and created a new gallery, and it displays in columns in both the editor and front.

I would like to help but I have reached the limit of what I can troubleshoot, I am out of ideas.

[chatty gardener]

Thanks. Don't understand coding at all. Where does that custom CSS go?

Replying to imrazor:

Hi!

Had the same problem after V6.1 Update with the Theme "CheerUp".
The Support fixed the problem with following custom CSS:

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

Replying to chatty gardener:

I've also tried the test post with a gallery in troubleshoot mode and enabled each plugin, one at a time. All displayed correctly but as soon as I come out of troubleshooting mode, they revert to broken.

Replying to poena:

@chatty-gardener I installed the Poseidon theme version 2.3.9 on WordPress 6.1 without plugins and created a new gallery, and it displays in columns in both the editor and front.

I would like to help but I have reached the limit of what I can troubleshoot, I am out of ideas.

[imrazor]

It is part of the customizer: Design -> Customizer -> the last item, I think it's "additional CSS" in English. I have a German installation. Just add the Code and publish it.

Replying to chatty gardener:

Thanks. Don't understand coding at all. Where does that custom CSS go?

Replying to imrazor:

Hi!

Had the same problem after V6.1 Update with the Theme "CheerUp".
The Support fixed the problem with following custom CSS:

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

Replying to chatty gardener:

I've also tried the test post with a gallery in troubleshoot mode and enabled each plugin, one at a time. All displayed correctly but as soon as I come out of troubleshooting mode, they revert to broken.

Replying to poena:

@chatty-gardener I installed the Poseidon theme version 2.3.9 on WordPress 6.1 without plugins and created a new gallery, and it displays in columns in both the editor and front.

I would like to help but I have reached the limit of what I can troubleshoot, I am out of ideas.

[chatty gardener]

So do you add it to every post or is it somewhere more general? Apologies for what are probably very stupid questions but I know nothing about code.

Replying to imrazor:

It is part of the customizer: Design -> Customizer -> the last item, I think it's "additional CSS" in English. I have a German installation. Just add the Code and publish it.

Replying to chatty gardener:

Thanks. Don't understand coding at all. Where does that custom CSS go?

Replying to imrazor:

Hi!

Had the same problem after V6.1 Update with the Theme "CheerUp".
The Support fixed the problem with following custom CSS:

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

Replying to chatty gardener:

I've also tried the test post with a gallery in troubleshoot mode and enabled each plugin, one at a time. All displayed correctly but as soon as I come out of troubleshooting mode, they revert to broken.

Replying to poena:

@chatty-gardener I installed the Poseidon theme version 2.3.9 on WordPress 6.1 without plugins and created a new gallery, and it displays in columns in both the editor and front.

I would like to help but I have reached the limit of what I can troubleshoot, I am out of ideas.

[chatty gardener]

Found it and it appears to work! Can't tell you how grateful I am. My blog is the finalist in my industry's awards - winner announced in two weeks' time - so it's really important that it looks good. Thank you.

Replying to imrazor:

It is part of the customizer: Design -> Customizer -> the last item, I think it's "additional CSS" in English. I have a German installation. Just add the Code and publish it.

Replying to chatty gardener:

Thanks. Don't understand coding at all. Where does that custom CSS go?

Replying to imrazor:

Hi!

Had the same problem after V6.1 Update with the Theme "CheerUp".
The Support fixed the problem with following custom CSS:

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

Replying to chatty gardener:

I've also tried the test post with a gallery in troubleshoot mode and enabled each plugin, one at a time. All displayed correctly but as soon as I come out of troubleshooting mode, they revert to broken.

Replying to poena:

@chatty-gardener I installed the Poseidon theme version 2.3.9 on WordPress 6.1 without plugins and created a new gallery, and it displays in columns in both the editor and front.

I would like to help but I have reached the limit of what I can troubleshoot, I am out of ideas.

[imrazor]

Great!
Good luck for your competition!

Replying to chatty gardener:

Found it and it appears to work! Can't tell you how grateful I am. My blog is the finalist in my industry's awards - winner announced in two weeks' time - so it's really important that it looks good. Thank you.

Replying to imrazor:

It is part of the customizer: Design -> Customizer -> the last item, I think it's "additional CSS" in English. I have a German installation. Just add the Code and publish it.

Replying to chatty gardener:

Thanks. Don't understand coding at all. Where does that custom CSS go?

Replying to imrazor:

Hi!

Had the same problem after V6.1 Update with the Theme "CheerUp".
The Support fixed the problem with following custom CSS:

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

Replying to chatty gardener:

I've also tried the test post with a gallery in troubleshoot mode and enabled each plugin, one at a time. All displayed correctly but as soon as I come out of troubleshooting mode, they revert to broken.

Replying to poena:

@chatty-gardener I installed the Poseidon theme version 2.3.9 on WordPress 6.1 without plugins and created a new gallery, and it displays in columns in both the editor and front.

I would like to help but I have reached the limit of what I can troubleshoot, I am out of ideas.

[chatty gardener]

Thanks. :)

Replying to imrazor:

Great!
Good luck for your competition!

Replying to chatty gardener:

Found it and it appears to work! Can't tell you how grateful I am. My blog is the finalist in my industry's awards - winner announced in two weeks' time - so it's really important that it looks good. Thank you.

Replying to imrazor:

It is part of the customizer: Design -> Customizer -> the last item, I think it's "additional CSS" in English. I have a German installation. Just add the Code and publish it.

Replying to chatty gardener:

Thanks. Don't understand coding at all. Where does that custom CSS go?

Replying to imrazor:

Hi!

Had the same problem after V6.1 Update with the Theme "CheerUp".
The Support fixed the problem with following custom CSS:

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

Replying to chatty gardener:

I've also tried the test post with a gallery in troubleshoot mode and enabled each plugin, one at a time. All displayed correctly but as soon as I come out of troubleshooting mode, they revert to broken.

Replying to poena:

@chatty-gardener I installed the Poseidon theme version 2.3.9 on WordPress 6.1 without plugins and created a new gallery, and it displays in columns in both the editor and front.

I would like to help but I have reached the limit of what I can troubleshoot, I am out of ideas.

[dvorak77]

Thanks, @imrazor, adding your custom CSS fixed that same issue for me, too. I'm using the Astra standard theme and also had all the multi-column galleries displayed in one column since upgrading to WP 6.1.

[helen2022]

Thanks @imrazor, adding this custom CSS has also solved the same problem for me.

I am using Neve 3.2.5 - I look after 2 other sites on the same version of Neve and neither were affected (although I did have the lack of padding mentioned by @ChadUM across all 3).

@poena The only significant difference between my sites is that I have woocommerce installed on the site where I had a problem, I don't know if this is likely to be the culprit?

[JeffPaul]

To see more / track this further, please subscribe to updates on ​https://github.com/WordPress/gutenberg/issues/45713.

[muaysteve]

Just wanted to report that the CSS code provided here solved the problem for me as well.

.is-layout-flex {

display: flex;
flex-wrap: wrap;

}

Thanks for this, though I hope they get rolled out in a patch too.

[dalesandro]

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>

[Bernhard Reiter]

We’re currently ​investigating the issue over at the Gutenberg repo, but we’re still having a hard time reproducing it.

Pinging everyone one this thread who has encountered this issue on their sites: @rsmith4321 @kvizas @ryankienstra @webfactoryuk @chatty-gardener @ChadUM @imrazor @dvorak77 @muaysteve

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 please 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 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!

[imrazor]

Hi Bernhard,

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

I habe to look up the further information you requested.

In my case a theme developer solved the problem with the posted custom CSS within minutes...
(so I think this was not s.th. special to investigate for him)

Replying to Bernhard Reiter:

We’re currently ​investigating the issue over at the Gutenberg repo, but we’re still having a hard time reproducing it.

Pinging everyone one this thread who has encountered this issue on their sites: @rsmith4321 @kvizas @ryankienstra @webfactoryuk @chatty-gardener @ChadUM @imrazor @dvorak77 @muaysteve

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 please 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 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!

[costdev]

For those who have yet to reproduce the issue, I just reproduced the issue with the following steps.

Testing Instructions

These steps define how to reproduce the issue, and indicate the expected behavior.

Steps to Reproduce

1. Create a new site using WordPress 6.0.
2. Navigate to Appearance > Themes and activate Twenty Twenty-One.
3. Navigate to Posts > Add New. Insert a Gallery Block with three images.
4. Save the post and view it on the frontend.
5. Upgrade the site (to WordPress 6.1.1 at the time of writing).
6. 🐞 View the same post on the frontend.

Expected Results

When reproducing a bug:

• ❌ The Gallery should display three images under each other.

When testing a patch to validate it works as expected:

• ✅ The Gallery should display three images beside each other.

Test Report Icons:
🐞 <= Indicates where issue ("bug") occurs.
✅ <= Behavior is expected.
❌ <= Behavior is NOT expected.

[Bernhard Reiter]

Replying to imrazor:

Hi Bernhard,

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

I habe to look up the further information you requested.

In my case a theme developer solved the problem with the posted custom CSS within minutes...
(so I think this was not s.th. special to investigate for him)

Thank you very much for sharing!

[Bernhard Reiter]

Replying to costdev:

Thanks a lot! I can confirm that I'm able to reproduce the issue by following these steps; however, if I reload the post about a minute later, it's back to normal. (As others have mentioned, there's a 60 seconds cache; however, people seem to be experiencing the issue permanently.)

[chatty gardener]

Thanks for looking at this.

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

Hope that helps.

Replying to Bernhard Reiter:

We’re currently ​investigating the issue over at the Gutenberg repo, but we’re still having a hard time reproducing it.

Pinging everyone one this thread who has encountered this issue on their sites: @rsmith4321 @kvizas @ryankienstra @webfactoryuk @chatty-gardener @ChadUM @imrazor @dvorak77 @muaysteve

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 please 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 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!

[Bernhard Reiter]

Thank you very much @chatty-gardener!

[ironprogrammer]

Reproduction Report

I am also able to consistently reproduce this issue on a temporary basis*.

Environment

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 12.6.1
• Browser: Safari 16.1, Google Chrome 107.0.5304.121, Mozilla Firefox 107.0.1
• Server: nginx/1.23.2 (via Laravel Valet)
• PHP: 7.4.33
• WordPress: 6.0.3 -> 6.1.1
• Theme: twentytwentyone v1.6

Actual Results

• ✅ After upgrade from WordPress 6.0.3 to 6.1.1, the Gallery block temporarily* renders as a single column.

* Additional Notes

• Before upgrade, flex styling is applied through an inline .wp-container-2 class in the #global-styles-inline-css style tag.
• After upgrade, the .wp-container-2 class is replaced with .is-layout-flex, the latter which does not include inline flex styling (only a separate gap style).
• After approximately 30 seconds, through reload or refresh of page, the Gallery block renders as 3 columns again.
• Flex styles for body .is-layout-flex... are rendered inline via #global-styles-inline-css.

Supplemental Artifacts

Immediately after upgrade to 6.1.1	30 seconds after upgrade

Trac ticket: https://core.trac.wordpress.org/ticket/56970

Backports the relevant parts of these PRs:

• ​https://github.com/WordPress/gutenberg/pull/45679
• ​https://github.com/WordPress/gutenberg/pull/46150

This PR:

• provides a fix to an issue reported for 6.1.1 (see trac ticket and ​gutenberg issue)
• backports part of the work of introducing object cache to theme.json APIs (​see)

Props @mmtr @felixarntz @spacedmonkey @aristath

cc @ockham @audrasjb @costdev @hellofromtonya @ironprogrammer @mmtr @felixarntz @spacedmonkey @aristath

[oandregal]

​https://github.com/WordPress/wordpress-develop/pull/3712 is a potential bugfix.

Sharing the context I know in case we want to test this in a plugin, first. This function is used in a couple of places:

• to enqueue the styles in the front-end (​script-loader)
• to provide the styles to the editors (​block-editor.php)

Gutenberg substitutes the front-end styles ​here and the ​editor styles here. I presume the test plugin should do something along those lines.

[ironprogrammer]

Thanks for the patch, @oandregal! Testing here in preparation of a hotfix test plugin that doesn't require quick file swaps to validate appropriately.

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/3712 👍🏻

Environment

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 12.6.1
• Browser: Safari 16.1
• Server: nginx/1.23.2
• PHP: 7.4.33
• WordPress: 6.0.3 -> 6.1.1
• Theme: twentytwentyone v1.6

Steps to Test

To test the patch:

1. Refer to Steps to Reproduce above.
2. Immediately after Step 5 completes, copy the patched files into wp-includes/. This will patch the corresponding newly installed 6.1.1 core files. E.g.

cp path/to/patched/wp-includes/default-filters.php wp-includes/default-filters.php
cp path/to/patched/wp-includes/global-styles-and-settings.php wp-includes/global-styles-and-settings.php

3. Then immediately load or refresh the frontend page containing the Gallery block (Step 6 above).

Actual Results

• ✅ Gallery images appear in 3 columns, as expected. Inline styles on the page contain flex rules for the body .is-layout-flex class.

Can we get some PHPUnit tests brought over from the Gutenberg PR(s)?

While ​https://github.com/WordPress/gutenberg/pull/45679 introduced a test for this behavior, it had to be removed later at ​https://github.com/WordPress/gutenberg/pull/45993 due to ​late-removal of a filter that enabled testing this. This is an ongoing conversation happening at ​https://github.com/WordPress/gutenberg/issues/45912 so, I'm afraid I cannot bring any test here.

[ironprogrammer]

Hotfix Based on PR 3712

[ironprogrammer]

Clear Global Styles alternate test plugin

[ironprogrammer]

Test Plugins

In order to assist both reporters and testers/contributors, two test plugins have been created that take different approaches at resolving this issue.

1. Hotfix Based on PR 3712: This ​hotfix plugin implements the proposed changes from ​PR 3712 (comment:50). It changes how global styles are cached. Download here: attachment:wp-hotfix-56970.zip​ 💾.
2. Clear Global Styles: This alternate ​test plugin clears the global stylesheet cache in 6.1.1. Download here: attachment:wp-alt-test-56970.zip​ 💾.

To install either plugin, first download, then in WordPress navigate to Plugins > Add New and click the Upload Plugin button. Click the Choose File button to locate the plugin ZIP file on your computer, and click Install Now. Once installed, activate the plugin.

(Manual installation instructions can be found in each plugin's repo.)

Note to Reporters

Reporters who have encountered this issue are invited to install either of the test plugins, upgrade to 6.1.1 if applicable, and provide feedback. Tests from different hosting providers may be especially helpful.

During testing, please make note of the following questions:

• Which of the two plugins was tested?
• What was the starting WordPress version (if testing an upgrade to 6.1.1)?
• Was the issue resolved? Was it immediate, or did it take some time?
• Did the issue return after deactivating one of the plugins?
• Do you have any other caching plugins installed/active?
• Are you aware of any caching by your hosting provider or DNS service (e.g. Cloudflare)?
• Is WP_DEBUG enabled on your site?
• Did you encounter any errors?

Please only test with one of the plugins active at a time.

Testing Instructions (Updated 2022-12-08)

For testing on new sites, please refer to these updated testing instructions. These are adapted from the original steps.

Steps to Test

1. Create a new site using WordPress 5.9 through 6.0.3.
2. Ensure that WP_DEBUG is not enabled. Debug mode causes caches to be skipped, so won't replicate the issue.
3. Navigate to Appearance > Themes and activate Twenty Twenty-One.
4. Navigate to Posts > Add New. Insert a Gallery block and add three images.
5. Save the post and view it on the frontend. Confirm that the images are displayed in three columns.
6. 👀 Make sure you have installed and activated one of the test plugins.
7. Upgrade the site to WordPress 6.1.1.
8. View the same post from Step 5, and confirm that it displays the images in three columns on the frontend.

Expected Results

• ✅ The Gallery should display three images beside each other.

Thanks for the PR @oandregal! Can we get some PHPUnit tests brought over from the Gutenberg PR(s)?

While I couldn't bring any test here for the reasons I've mentioned, I've added a new one at ​https://github.com/WordPress/wordpress-develop/pull/3712/commits/ef450b69ee5d0ddf33765ad5b206dd897a11f8dc. This is not perfect in that it does not test the cache, though it's still useful. When we ​settle on how to do this going forward, it is easy to tweak.

@costdev @azaozz @spacedmonkey @anton-vlasenko all feedback has been addressed. What's left for this to be merged?

Thanks for the updates, @oandregal! I've tested these latest PR changes from WordPress 5.9.5 and 6.0.3, and it looks good 👍🏻

In response to @oandregal:

all feedback has been addressed. What's left for this to be merged?

While local dev testing shows this to fix the stale cache issue with inline CSS, we should wait for reporters to install the ​hotfix plugin (or ​alternate test plugin) to determine if either resolves the issue in non-isolated environments.

Once more feedback has been received, it will inform us of next steps. In particular, it is important to understand how this plays with plugin or host-level caching.

[ironprogrammer]

As was done earlier, this is a ping to everyone on this ticket who has reported this issue on one of their sites: @rsmith4321 @kvizas @ryankienstra @webfactoryuk @chatty-gardener @ChadUM @imrazor @dvorak77 @muaysteve

Hotfix Plugin 🔥

If you are comfortable helping test a hotfix to this issue, please refer to the Test Plugins information above for info on the hotfix plugin, as well as questions to note during testing. You can test this plugin whether you are starting with WordPress 5.9 through 6.0.3, or if you've already upgraded to 6.1.1. Your feedback is immensely helpful and appreciated! 🙌🏻

It is typically recommended to test in a non-production environment, and make sure to back up your site files and database before testing this or any plugin. It's okay to pass on this testing if you are unsure.

Optional Alternate Test Plugin
And if you have time, testing and comparing the results between the hotfix plugin and the alternate test plugin may provide additional details on the most appropriate fix.

Feedback 📣

Please provide feedback here in the ticket, or feel free to reach out on the ​Make WordPress #core-test channel with any other questions.

LGTM too, just one typo (/** is reserved for docblocks).

In response to @mcsf:

@ironprogrammer: I appreciate the ​hotfix testing. How long do you estimate we should wait for feedback?

That's a good question, and maybe best addressed by one or more core committers. Maybe @azaozz or @spacedmonkey could share some thoughts?

My personal take: While we've seen a general vote of confidence in this from core contributors, we have yet to hear back from reporters. I think it's worth allowing another couple weeks for them to test and provide feedback, since the earliest this could ship is mid-January anyways -- that is, assuming it qualifies as a fix to changes introduced in 6.1.1, and isn't pushed to 6.2 (maybe March).

How long do you estimate we should wait for feedback?

...the earliest this could ship is mid-January anyways -- that is, assuming it qualifies as a fix to changes introduced in 6.1.1

Yes, there's some time until WP 6.1.2. This PR is a fix for https://core.trac.wordpress.org/ticket/56970 that most likely will be there. However thinking it can be committed to trunk (WP 6.2-alpha) now, no need to wait. That will also facilitate some more testing (in nightly builds).

If there's feedback that requires changes, it can be addressed in another ticket/PR.

@spacedmonkey Can you provide some more context on the performance regression? Is it just because the value was already in the object cache before?

Since it is now a non persistent cache, I'd say it's expected that it is now behaving worse than before on second load. However, a 1-minute transient is arguably a less proper solution than a non-persistent cache.

I'm onboard with the current solution, however I also think we should continue working towards an actually working _persistent_ solution to improve performance for sites that use a persistent object cache.

I'd like to provide more context on why I think this PR should be merged without waiting for the reports of the test plugin.

This was actually created to fix this other issue ​https://github.com/WordPress/gutenberg/issues/43914 (not sure if there's a trac report) with the 1-minute transient. While it may also fix https://core.trac.wordpress.org/ticket/56970 (if the test plugin confirms that's the root issue), the two things are independent in my view. What if we learn the test plugin does not fix the issue? Well, in that case, we need to continue investigating _why_ it happens. But this PR would still be necessary to fix the other issue.

That's why I'd vote to merge this as early in the cycle as possible. My goal when preparing the backport was avoid the same late-minute issues we saw on past cycles by backporting really late.

I'm onboard with the current solution, however I also think we should continue working towards an actually working persistent solution to improve performance for sites that use a persistent object cache.

:100: agree on this. Count me in to resume (actually, get back) that work after all the ​high-priority stuff is shipped.

In terms of performance, this PR is:

• 5ms faster than trunk (0.73% better) for themes with theme.json
• 0.23ms slower than trunk (0.06 worse) for themes without theme.json

I don't know how to calculate the statistical error of running the performance analysis using xdebug, though I presume these numbers are less than the statistical error, so they can be ignored.

I've tested this using the same mechanism I use for all performance work I've been doing, so we can actually compare the impact of each PR:

• I have loaded the "Hello World!" post as a logged-out user. Conducted the test 9 times and then calculated the median (​see data in spreadsheet).
• Compared this PR vs trunk at 1a8535075613b29e750a3b966db4e2004dfad48d (svn 54999).
• Using TwentyTwentyThree for theme with theme.json and using TwentyTwenty for a theme with no theme.json.

I'm also sharing the raw data I extracted (cachegrind files) so anyone can open them with their tool of choice and inspect the results. Feel free to DM me if you are interested in setting this up for running the test yourself or anything.

• Data for TwentyTwenty:
  • ​twentytwenty-pr-3712.zip
  • ​twentytwenty-trunk-1a8535075613.zip
• Data for TwentyTwentyThree:
  • ​twentytwentythree-trunk-1a8535075613.zip
  • ​twentytwentythree-pr-3712.zip

I strongly believe this fix should not go into 6.1.2. This is a big change to the code and should be part of a major release. As we are effectively removing this cache by making it none persistent. We should make this part of the 6.2 release and work on other performance fixes to make the impact less on performance.

I strongly believe this fix should not go into 6.1.2.

My understanding is that anything that goes to a patch release needs to be cherry-picked from trunk, and that conversation happens elsewhere (core slack channel, trac tickets for the patch release, etc.).

Is that how we do it? If my understanding is correct, what's the basis for the blocking this PR from being merged into trunk? Happy to learn how to unblock this.

I strongly believe this fix should not go into 6.1.2.

My understanding is that anything that goes to a patch release needs to be cherry-picked from trunk, and that conversation happens elsewhere (core slack channel, trac tickets for the patch release, etc.).

Is that how we do it? If my understanding is correct, what's the basis for the blocking this PR from being merged into trunk? Happy to learn how to unblock this.

Sharing some initial reporter feedback on the hotfix 🎉: ​https://github.com/WordPress/gutenberg/issues/45713#issuecomment-1354333397 (and ​their initial report).

This was actually created to fix this other issue with the 1-minute transient.

Generally having a 1 minute transient is not a good idea for sites without persistent cache. There transients are saved to the options table in the DB. Writing to the DB every minute from the front-end is generally considered a big bottleneck that slows down performance significantly. It also can exceed database usage limits which may result in the DB being locked down causing the site to stop working.

This is more of an edge case as sites without persistent cache usually don't get many visitors. The 1 minute DB writes may not be noticeable, or the slowness may be attributed to other factors. Similar problems have been reported before after the WP_Heartbeat API was introduced.

I strongly believe this fix should not go into 6.1.2.

Yea, I feel "uneasy" about it too, but fixing the front-end DB writes may also be needed if there are reports by the time 6.1.2 is finalized.

anything that goes to a patch release needs to be cherry-picked from trunk, and that conversation happens elsewhere (core slack channel, trac tickets for the patch release, etc.).

Yep, that's pretty much the workflow except the initial decision of what should be in the dot release happens earlier on Trac where the tickets are moved to the appropriate milestone. Of course all of these tickets are later reviewed, and patches are double and triple checked.

In any case I don't see anything that prevents this PR form being adding to trunk regardless of whether it will be in 6.1.2 or not.

I think if this goes into core, we also need to tackle some other performance issues. If we can offset the performance regression here with some other small tweaks, then I am good to commit. What I do not want for for a 6.1.2 to make performance worse. Point releases should not make performance worse, as less people read the dev notes and will not know what is happening.

I have highlighted these,

I wonder if porting ​https://github.com/WordPress/gutenberg/pull/46074 and ​https://github.com/WordPress/gutenberg/pull/46112 over first would help this issue.

But there are other tweaks like, ​https://github.com/WordPress/gutenberg/pull/46043

I've been peer-reviewing my own data analysis and realized I had missed setting WP_DEBUG to false. I fixed that and re-run the analysis. The updated data:

• themes with theme.json are 12ms slower (-1.70%)
• themes without theme.json are 1.79ms slower (-0.46%)

My conclusion is the same it was when this was a +5ms change. It's debatable this has any impact, it seems lower than the statistical error. I've added in the ​data sheet a set of fields that shows the variance between the faster and the lower test: it's up to 75ms in some cases. Updated ​the results above as well.

I've been a bit frustrated with the variability of the data extracted from xdebug profiler. Looking at profiles I had locally from many experiments (this PR and some others), I've seen variances up to 150ms using the same steps and context. Running 10 times the same experiment reduces this a bit, but still has so much variance built in that we need to be cautious with the conclusions we take out of them.

So. Instead of looking at the cost of the full request, I'd thought I'd look at the cost of the wp_get_global_stylesheet before/after, given all changes here are localized to it. The cost of this function is 0.03ms in trunk and 0.04ms in this PR (both for themes with and without theme.json). It confirms this does not have any impact on performance.

@spacedmonkey the screenshots ​you shared refer to the wp_get_global_settings method, which the changes in this PR do not affect in any way. It sounds like it may be just part of the variability of the xdebug profiles I mentioned above?

[whitneyyadrich]

Hi all - jumping in to say that we're experiencing this on the GB gallery block in 6.0.1 as well. I added bootstrap classes d-flex and flex-wrap to fix the issue for the time being, but if you remove those in Inspector you should be able to duplicate: ​https://truesociety.com/bridesmaid-dresses/

cc @JeffPaul

[JeffPaul]

As far as I was aware, this was something identified in 6.1; has anyone else here experienced this ALSO on 6.0?

[ironprogrammer]

Thank you for your note, @whitneyyadrich!

Would you please clarify if the issue began with the upgrade to 6.0.1 (and from what version), or if it existed prior? And also what remediations have been attempted apart from the addition of the Bootstrap classes?

In local 6.0.1 testing with TT1 and a custom Underscores theme (the base for the sample site's theme), I was unable to reproduce the gallery flex layout issue after upgrading from 5.9.5 or 6.0. 🤔

There is an expected inline CSS rule for the gallery block, .wp-container-x, that isn't being omitted on your sample site, but which appears following the #page div in my test Underscores site (or in the head on TT1). Apart from caching, could there be anything else affecting the markup emitted to the page?

@oandregal Is the Trac ticket reference on the PR description correct? Is this really for https://core.trac.wordpress.org/ticket/56970? Not sure I understand the relationship between the PR and ticket.

Which Gutenberg PR(s) is/are covered by this?

Are there changes in this PR that need to be backported to Gutenberg?

Is the Trac ticket reference on the PR description correct? Is this really for https://core.trac.wordpress.org/ticket/56970? Not sure I understand the relationship between the PR and ticket.

I added the second track ticket related to this work in the issue description https://core.trac.wordpress.org/ticket/56975

56970 is still relevant because (as far as the ​experiment go) this also fixes an issue with styles being cache forever in some hosts instead of one minute as it was intended with the transient.

https://core.trac.wordpress.org/ticket/56970

Feel like https://core.trac.wordpress.org/ticket/56910 is better.

@felixarntz @oandregal I have created a PR for making SVG function use this same caching. ​https://github.com/oandregal/wordpress-develop/pull/1

I believe we need to merge this as part of this change to close out. #56910

As @felixarntz pointed out, this PR needs a rebase and potentially a rebuild of the individual commits to remove what is no longer relevant.

That said, there's an open discussion still happening on the caching solution (due to fatal errors in the admin area) (See the Trac ticket https://core.trac.wordpress.org/ticket/56975). Until a solution is committed, might be best to wait on the rebase.

Rebased and removed the no longer relevant parts. Changes for src/wp-includes/load.php, src/wp-includes/ms-blogs.php, tests/phpunit/includes/abstract-testcase.php are still relevant here as they were reverted from core at ​https://github.com/WordPress/wordpress-develop/pull/3864

I was unable to reproduce the bug raised at https://core.trac.wordpress.org/ticket/56975#comment:32 in this PR. I'll need to go back there and see if I can have some testing steps. I want to understand how to reproduce to either introduce the fix in this PR directly or that we don't block this from landnig if it doesn't.

As I shared in other places, this week I'm unable to contribute for more than half an hour here and there. So, go ahead when you feel is ready and don't wait for my feedback. Or ping me via DM if there's something I must absolutely review.

@felixarntz @oandregal I have created a PR for making SVG function use this same caching. ​https://github.com/oandregal/wordpress-develop/pull/1

That's a good next step, thanks for working on it. As it is now, it is based on this PR. I'd recommend preparing a separate PR instead as they are unrelated changes (though, sensibly, going in the same direction). Ideally, that work happens in Gutenberg first, so it is tested by users before merging it into core.

Noting: Similar work is being done in wp_get_global_settings() in Trac 57502 and ​https://github.com/WordPress/wordpress-develop/pull/3789. That scope of work captures the latest conversations and consensus. I'm thinking it might be worth landing PR #3789 first, then rebasing and updating this PR to remove the duplicate code, and then copy the code patterns from it.

@felixarntz @spacedmonkey @oandregal Do you agree?

I see two blocking reviews, though I think I've addressed all the feedback. Please, let me know if I should look at anything to unblock this.

# Test Report

As @felixarntz notes ​https://github.com/WordPress/wordpress-develop/pull/3712#discussion_r1088143732, need to test the PR in the WP Admin area to determine if a fatal error happens from not having wp_cache_*() functions available when load-styles.php runs.

## Testing Instructions

• Step 1: Added the following constants to wp-config.php:

{{{php
define( 'CONCATENATE_SCRIPTS', true );
define( 'WP_DEBUG', false );
define( 'SCRIPT_DEBUG', false );
}}}

• Step 2: Pull or apply this PR
• Step 3: Start your localhost environment.

If using Docker, then do:

npm install
npm run build:dev
npm run env:start
npm run env:install

• Step 4: Log in and open the WP Admin area.

Does a fatal error occur?
Is the load-styles.css stylesheet loading?

If no, navigate through the screens. Does a fatal error occur?
If no, then this PR is not impacting load-styles.php ✅

## Testing Results

Env:

• Localhost: Docker with npm
• OS: macOS
• Browser: Chrome, Firefox, and Edge
• WP Version: trunk
• Plugins: none
• Theme: TT3

No fatal error ✅

Opened the Network tab in Dev Tools: yes, load-styles.php is being requested and has a 200 status ✅

Works as expected ✅

Does this cache need to be reset in wp_clean_theme_json_cache()?

@hellofromtonya

Does this cache need to be reset in wp_clean_theme_json_cache()?

Good catch, I missed that 🙃

Can you please add the matching wp_cache_delete call to that function?

Can you please add the matching wp_cache_delete call to that function?

@felixarntz done in ​https://github.com/WordPress/wordpress-develop/pull/3712/commits/d9c0909951b2a894d137324c1082a50167a2d114 ✅

Retested in WP Admin. No issues 💹

## Test Report
Tested with wp-config.php adjustments and steps outlined in ​https://github.com/WordPress/wordpress-develop/pull/3712#issuecomment-1405464211 above.

Patch tested: this PR since ​https://github.com/WordPress/wordpress-develop/commit/d9c0909951b2a894d137324c1082a50167a2d114.

### Environment

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 12.6.2
• Browser: Safari 16.2, Mozilla Firefox 109.0
• Server: nginx/1.23.3
• PHP: 7.4.33
• WordPress: 6.2-alpha-54642-src
• Theme: twentytwentythree v1.0
• Gutenberg: tested both enabled/disabled

### Actual Results

• ✅ No fatal errors occurred while navigating through or refreshing WP admin.
• ✅ Requests to load-styles.php returned successfully, and CSS loaded in WP admin.

Thanks @ironprogrammer for testing it!

@felixarntz should be okay to commit.

Thank you everyone for your contributions!

@peterwilsoncc Apologies, this feedback came a bit too late, I had already committed this in https://core.trac.wordpress.org/changeset/55148.

If it's crucial, we can do a follow up commit?

@felixarntz I think it should be fine without. I noticed my terrible timing ;)

Just FYI: ideally testing should happen when WP runs from /build as it is closest to "production" (concatenated and minified js and css, etc.). Docker/wp-env can be set to run from there. The testing instructions are slightly different:

1. WP_DEBUG and SCRIPT_DEBUG should not be set (or commented out) in wp-config.php.
2. In the terminal:
   • npm run build or just grunt. No need to do npm install as Grunt will run it if needed.
   • LOCAL_DIR=build npm run env:start to start from /build
   • npm run env:install only if this is the first time using wp-env here
3. Don't forget to do npm run env:stop at the end.

I was able to reproduce with the ​steps Tonya provided.

@azaozz I tried to use ​the steps you suggested, but npm run build doesn't work for me:

Running "verify:old-files" task
Warning: build/wp-includes/blocks/heading/editor.css should not be present in the $_old_files array. Use --force to continue.

Aborted due to warnings.

I tried a few things, including clearing the build folder or passing --force to the build command. None worked.

---

It seems this PR has been committed, so I guess it can be closed/deleted.

Thanks all for the additional feedback. No actionable change in terms of committing per the above, so I'll indeed close this for now.

tried to use the steps you suggested, but npm run build doesn't work

Uhh, sorry, this is a bug in core. Generally when you build to /src, it leaves the source in a "dirty" state. Trying to actually build to /build copies some of these left-over files and the build fails.

There's a ticket for that already, will try to fix it soon.