villekautto

@hgaugenot I have deactivated the plugin from all my sites for the time being. The fix I made worked for me in my use cases but it is not a proper fix so I can’t recommend it as it is. It is probably best to wait for a WordPress fix like @teckel said.

This turned out to be harder to fix than I expected.

The proposed change from the github issue doesn’t fix the issue as the check on line 38 is outside the init action and REST_REQUEST is probably not defined yet.

Also, I don’t think the ‘edit’ context will ever be true when saving a draft or updating a post. I did spot ‘view’ and ‘edit’ contexts when refreshing the editor and while editing though.

I then tried checking for only REST_REQUEST but that also failed when checked too early. It seems to fail even if checking right before ob_start(‘teckel_minify_html_output’).

It follows that the REST check needs to happen as late as possible.

So I did some logging to find out how many times the minify function runs and without any changes it looks like the minify function can run up to 10 times when refreshing the editor and 3-5 times when saving a post. Didn’t test without Yoast so that might contribute.

I then made a helper function that can be run in the init hook (to avoid buffering unnecessarily) and also again in the output buffer callback (to avoid minifying and when we do, only do it once):

function teckel_should_skip_minifying() {
  /* Bail if CLI */
  if ( defined( 'WP_CLI' ) && WP_CLI ) {
    error_log( 'BAIL - WP_CLI true' );
    return true;
  }

  /* Bail if admin pages */
  if ( is_admin() ) {
    error_log( 'BAIL - is_admin() true' );
    return true;
  }

  /* Bail if REST REQUEST */
  if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
    error_log( 'BAIL - REST request' );
    return true;
  }

  /* Bail if any context */
  if ( isset( $_GET['context'] ) ) {
    error_log( 'BAIL - context set to ' . $_GET['context'] );
    return true;
  }

  /* Nothing stopping us from minifying */
  error_log( 'teckel_should_skip_minifying() - return false' );
  return false;
}

I then call this helper function like this:

function teckel_init_minify_html() {
  if ( teckel_should_skip_minifying() ) {
    return;
  }
...

and:

function teckel_minify_html_output($buffer) {
  if ( teckel_should_skip_minifying() ) {
    return $buffer;
  }
...

Notably even now, just refreshing the editor, I still see in the logs that the plugin minifies at least once. This could be Yoast or something else doing something with the content. But at least the content is not converted to a classic block anymore.

All of those checks need to be separate or this doesn’t work. You will find all conditions printing something in the logs multiple times by just refreshing the editor.

I wish there was a cleaner fix but this finally seems to work. Let me know if you find a cleaner way.

I have tripped in that “bug” when solving another issue. I was going to suggest checking for REST_REQUEST but didn’t as I wasn’t sure if that would be a proper fix. I believe the semantics are something along the lines of “REST request is not part of admin pages, so is_admin() should return false” even though the request is made in admin pages.

Thanks for looking into this issue.

Here’s how I can make it happen 100% on a default install, default theme with nothing but Yoast SEO and minify HTML installed and activated:

1. Create a new post
2. Add cover block with a white background (any color will do)
3. Inside the cover block add a paragraph “Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque ut condimentum mi, et maximus eros. Donec eu fringilla dui, dapibus ullamcorper metus.”
4. Below the paragraph add buttons and justify center.
5. Save draft and preview (a new tab opens)
6. In the preview tab click Edit post
7. In the editor click Save draft
8. The content is converted to Classic block (gray bar with text “Classic” in it)

Notably without the preview step the issue may or may not happen. I did trigger it multiple times without previewing but not always. I can however always trigger it if I preview the new post first and then save the draft.

Here’s the markup in my test case (from editor Copy all blocks):

<!-- wp:cover {"overlayColor":"base-2","isDark":false,"layout":{"type":"constrained"}} -->
<div class="wp-block-cover is-light"><span aria-hidden="true" class="wp-block-cover__background has-base-2-background-color has-background-dim-100 has-background-dim"></span><div class="wp-block-cover__inner-container"><!-- wp:paragraph {"align":"center","placeholder":"Write title…","fontSize":"large"} -->
<p class="has-text-align-center has-large-font-size">Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque ut condimentum mi, et maximus eros. Donec eu fringilla dui, dapibus ullamcorper metus. </p>
<!-- /wp:paragraph -->

<!-- wp:buttons {"layout":{"type":"flex","justifyContent":"center"}} -->
<div class="wp-block-buttons"><!-- wp:button -->
<div class="wp-block-button"><a class="wp-block-button__link wp-element-button">Button</a></div>
<!-- /wp:button --></div>
<!-- /wp:buttons --></div></div>
<!-- /wp:cover -->

Classic block is what WordPress uses when it sees markup that it can’t recognize as block content, eg. a <p> without a preceding block comment. Classic block has a gray bar above the content with the word “Classic” in it.

My steps to reproduce do appear to be a bit flaky. I’ll see if I can make it 100% reproducible. I still have to emphasize that many dozens of my clients reported this issue and after deactivating minify HTML they all reported the issue is resolved.

Looks like the issue can be reproduced in WP 6.4.1 with these steps:

1. create a fresh site with default theme (I used Local)
2. install and activate minify HTML with default settings
3. install and activate Yoast SEO, you may skip/finish setup wizard, doesn’t matter
4. create a new draft post with a cover block and paragraph “test” inside
5. save draft
6. observe content converting to classic block

Given that Yoast SEO is a very common plugin this is probably something that should be investigated. The issue does not seem to occur without Yoast SEO when using the default theme. Sorry I can’t pinpoint the issue further.

Thanks for looking into it.

Hi, just wanted to add that I’m seeing the exact same issue when clearing the background color for an AB container. Here’s the error message in the console that appears only after leaving Gutenberg editor and coming back (only relevant bits here: the background-color):

Block validation: Block validation failed for 'atomic-blocks/ab-container'
Expected:
<div style="background-color:#fff;padding-left:0%;...

Actual:
<div style="padding-left:0%;...

Clearing the background color causes the validation to fail the next time the editor is opened. Actual styles do not have background-color defined (as it is cleared) but validation seems to expect it anyway.