WP 6.9.1still have issue with load block styles on demand in classic themes

[philip3524576]

Hi there,

We are running multiple websites on WordPress 6.9.1 using classic themes. Since WordPress 6.9.0, the Gravity Forms layout has been broken due to the change in “load block styles on demand” for classic themes introduced in 6.9.0.

As a workaround, we had to install the Load Combined Core Block Assets plugin to restore the Gravity Forms layout. We expected this issue to be resolved in WordPress 6.9.1, but after testing across multiple sites, the problem still persists.

Could you please confirm whether this is a known issue and if there is a planned fix?

Thanks in advance for your help.

[westonruter]

Hello. Thank you for the report.

The ticket for 6.9.1 which was intended to resolve the issue is #64354.

Nevertheless, there is also #64389 which I wasn't sure of whether it was a duplicate of that ticket or not. Since the issue persists in some cases, such as yours, it appears to not be a duplicate but that the issue is not fully fixed. However, it could also be that the Gravity Forms layout is assuming that all styles will always be printed on every page, which is not a safe assumption as it is not the case for block themes.

As requested in the other ticket, please provide specific steps for how the issue can be reproduced.

This may end up getting closed as a duplicate of #64389.

[philip3524576]

Hi,

I would like to add more details to this issue.

When we create a Gravity Form that includes a Name field or any Hidden field, the frontend layout loses its styling. This happens because the following stylesheet is not loaded:

/wp-content/plugins/gravityforms/assets/css/dist/basic.min.css?ver=2.9.26

This appears to be related to the following filter:

add_filter( 'should_load_separate_core_block_assets', 'return_false' );

Given this behavior, will WordPress Core ensure compatibility with plugins (such as Gravity Forms) when using Classic themes?
Specifically, is it possible for separate_core_block_assets to be enabled or handled differently by default so that required styles still load correctly in Classic themes?

Thanks

[westonruter]

@philip3524576 thanks providing a bit more detail on how this can be reproduced. Have you reached out to Gravity Forms support about this issue? Given that Gravity Forms is a commercial plugin it is difficult for me to investigate what is going on. I suggest that you get in touch with their development team to troubleshoot this. Make sure they see the relevant ​field guide section. If they can identify a problem in core that needs to be fixed as opposed to something in their plugin, I'd be happy to continue collaborating.

[westonruter]

Re-posting my comment from #64389:

I've just finished another pass at improving the preservation of classic theme CSS cascade when loading block styles on demand.

The PR description has been fleshed out with all the details, but in short:

1. Determining where to insert the styles hoisted from the footer has been made more robust by inserting placeholder inline styles. This simplifies the insertion logic since it doesn't have to hunt around for references for where styles should be inserted. It merely needs to replace the placeholders with the captured styles.
2. The CSS cascade is now improved for inline styles which had been added to wp-block-library. Now when loading separate block styles, any such inline styles get added after any of the separate core block styles.

Note: Do not have Gutenberg active when testing this, as the patch has not yet been applied to Gutenberg's forked version of wp_enqueue_global_styles().

Review and testing much appreciated: ​https://github.com/WordPress/wordpress-develop/pull/10875

I really hope to get this into the next beta.