Yoast SEO breaks form layout on Gravity Forms with WordPress 6.9

[Digitalspirit73]

• [x] I've read and understood the contribution guidelines.
• [x] I've searched for any related issues and avoided creating a duplicate issue.

Please give us a description of what happened

To Reproduce

Step-by-step reproduction instructions

1. WordPress 6.9
2. Gravity Forms - breaks layout, shows Honeypot
3. Disabling Yoast reverts issue

Expected results

1. Gravity Forms display as per 6.8.3

Actual results

1. Form layout a mess and showing hidden honeypot field

Screenshots, screen recording, code snippet

If possible, please provide a screenshot, a screen recording or a code snippet which demonstrates the bug.

Broken layout

How it should look (with Yoast disabled):

Technical info

• If relevant, which editor is affected (or editors):

• [ ] Block Editor
• [ ] Gutenberg Editor
• [ ] Elementor Editor
• [ ] Classic Editor
• [x] Other: Custom pages

• Which browser is affected (or browsers):

• [ x] Chrome
• [ x] Firefox
• [ ] Safari
• [x] Other: Edge, Brave

Used versions

• Device you are using: PC
• Operating system: Windows 10/11
• PHP version: 8.3.27
• WordPress version: 6.9
• WordPress Theme: Responsive Pro
• Yoast SEO version: Latest
• Gutenberg plugin version:
• Elementor plugin version:
• Classic Editor plugin version: 1.6.7
• Relevant plugins in case of a bug:

[aljeyoast]

Please inform the customer of conversation # 1337627 when this conversation has been closed.

[aljeyoast]

Please inform the customer of conversation # 1338163 when this conversation has been closed.

[fbentele]

This is also the case for NinjaForms based forms. The stylesheets for this 3rd-party plugin (NinjaForms) are not being loaded, if Yoast is active (WP 6.9, Yoast 26.5). I was not able to find a workaround or the causing code.

[YBOP84]

It's a big issue affecting numerous installations.

For Gravity Forms users this is a hack, forcing the CSS files to be loaded.

` add_filter( 'gform_disable_css', '__return_false', 1 ); add_filter( 'gform_disable_form_theme_css', '__return_false', 1 ); add_filter( 'gform_disable_standard_styles', '__return_false', 1 );

function force_gravityforms_styles() {
    if ( is_admin() ) {
        return;
    }

    if ( ! class_exists( 'GFCommon' ) || ! class_exists( 'GFForms' ) ) {
        return;
    }

    wp_enqueue_style(
        'gf-basic',
        GFCommon::get_base_url() . '/assets/css/dist/basic.min.css',
        [],
        GFForms::$version
    );

    wp_enqueue_style(
        'gf-theme',
        GFCommon::get_base_url() . '/assets/css/dist/theme.min.css',
        [ 'gf-basic' ],
        GFForms::$version
    );
}
add_action( 'wp_enqueue_scripts', 'force_gravityforms_styles', 20 );`

[maybellyne]

Please inform the customer of conversation # 1337642 when this conversation has been closed.

[josevarghese]

Hi @fbentele, @Digitalspirit73 and @YBOP84

Are you seeing any console errors when this occurs? Also, have you tried to check whether the filter mentioned over here helps to fix the issue or not?

add_filter( 'should_load_separate_core_block_assets', '__return_false', 100 );

[Digitalspirit73]

Can confirm adding below to functions.php resolves the issue:

add_filter( 'should_load_separate_core_block_assets', '__return_false', 100 );

[fbentele]

i can also confirm, this works and solves the ninjaforms issue on my site!

[maybellyne]

+1 https://wordpress.org/support/topic/v26-5-issue-with-wp-forms-and-livemesh/

[maybellyne]

+1 https://wordpress.org/support/topic/after-update-to-wp-6-9-yoast-seo-get-conflict-with-gravity-form/

[smdev0925]

Confirmed this resolves issues with both Livemesh and WPForms.

[enricobattocchi]

Hello everyone, we haven't been able to reproduce the issue so far with any of the plugin that have been mentioned. This probably means that there is some other factor needed to trigger the conflict, such as a caching solution, or some kind of theme (it's less likely that some other plugin is involved, since disabling that would solve that issue and some report would mention that). We're committed to investigate deeply to find a solution since the should_load_separate_core_block_assets filter is just a temporary workaround. Is there anyone that can provide further info about their setup, or even access to a staging copy? Thanks for all the help.

[fbentele]

@enricobattocchi we experienced it on multiple sites we take care of for our clients. i can send you a temporary account for one of our staging sites. can you provide me a direct messaging channel so I can send you the credentials?

[enricobattocchi]

Thanks! You can write at [email protected] if email is fine for you

[Digitalspirit73]

I'll drop you access to our staging site too @enricobattocchi

[enricobattocchi]

@Digitalspirit73 thanks! I was finally able to see the problem in action. I will add another comment to explain the context.

[enricobattocchi]

It turns out that there are several other reports (examples: 1 - 2 - 3) of similar issues, even without the involvement of Yoast SEO or the other plugins mentioned above.

A trac ticket for WordPress core has been created and they are aiming to release a fix in 6.9.1. In the meantime, the core committer who followed the ticket that probably introduced the problem has shared some instructions which I quote here:

As a workaround for sites experiencing this issue, I've just published a small single-file plugin that allows you to remain on 6.9 but opt out of loading separate core block styles. Naturally, the plugin is called ​Load Combined Core Block Assets. This plugin includes the ability for you to test loading separate core block styles via a query parameter. Once 6.9.1 is released with the fix, the plugin could inform you to re-test, so that the plugin can be deactivated and uninstalled at that time. If you added the following to your site via a theme or plugin:

<?php
add_filter( 'should_load_separate_core_block_assets', '__return_false' );

Please remove this, and instead install ​the plugin. This will help ensure you don't get stuck with loading the combined core block assets indefinitely. The use of combined core block assets means much more CSS is added to the page than is likely needed, and this can negatively impact page load time (e.g. FCP and LCP). By WordPress 6.9 ​loading separate block assets on demand, this also allows for ​small stylesheets to be inlined to further reduce render-blocking resources.

So our suggestion is to follow this instructions, remove the workaround and install the ​Load Combined Core Block Assets plugin while waiting for the release of WordPress 6.9.1.

On our end we'll carefully monitor the Trac ticket and other reports until the issue is solved.

Thanks for your patience!

[Digitalspirit73]

Thanks @enricobattocchi - As I'd already stripped the workaround code out so you could see the issue for yourself, I merely had to add the new plugin and test on staging and it does as described. Now running the same plugin on our live site.

[enricobattocchi]

Thanks for the update @Digitalspirit73! Let's hope that we get a fix soon.

[aljeyoast]

Please inform the customer of conversation # 1340740 when this conversation has been closed.