Fix deletion of custom block classes

[johngodley]

If you add a custom class to a block and then remove that custom class it will flag the block as invalid. This is because the custom class becomes part of the block attributes, and is then added back by the 'custom class name' filter. The expected HTML then doesn't match the current HTML, and a warning is triggered.

You can reproduce the problem as follows:

1. Create a quote block
2. Edit the HTML of the quote block and add another class in the <blockquote>:
   <blockquote class="wp-block-quote newclass”><p>fdsfsdfsdd</p></blockquote>
3. Tab out of the editor and notice that no warning is shown
4. Edit HTML again and remove the newclass
5. Tab out and trigger a validation failure, even though the HTML is the default

This may or may not be expected behaviour, but it seems like removing the custom class shouldn't trigger a warning, and so I've treated it as a bug.

This PR ensures the block contains the default class names + whatever classes are currently in the HTML, ignoring any custom ones in the block itself.

The unit tests have been beefed up to cope with several edge case situations

Fixes #8131

Note that I don't fully understand the context of this change, and I may totally have misunderstood the code. The change keeps the existing unit tests running while fixing the additional cases of removing classes. I'm not sure if this is the purpose of the code, so the fix may be misplaced.

How has this been tested?

Existing unit tests work, and additional unit tests have been added. Manual verification will show the problem in different situations:

• Add a custom class to a block without a default class and then remove it. To test, manually add a class to a paragraph block:
  <p class="test">paragraph</p>
  And then remove the class to trigger an invalid block warning
• Add a custom class to a block with a default class and then remove the class - explained above
• Add several custom classes to a block and remove one of them. To test, manually add several classes to a quote block:
  <blockquote class="wp-block-quote a b c"><p>fdsfsdfsdd</p></blockquote>
  Then remove class b to trigger an invalid block warning. A variation of above, but worth testing

Types of changes

This is a bug fix that changes some core block HTML code and so could potentially be a breaking fix.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[johngodley]

@aduth, sorry to drag you in but with your work in #7538 you may be best placed to comment on this

[aduth]

Thanks for the ping @johngodley . I agree this is a bug. I think there might be an easier approach here in retrieving the custom classes as simply the difference between innerHTML and the default block (i.e. a block serialized with a className attribute of undefined). I've done this in 1f2a7a1 . All tests still pass.

Let me know what you think. On my end, this is good to go 👍

[johngodley]

That's great, thanks! It seemed like there should be a simpler way but I wasn't entirely sure what happened beyond this code.

Merging.

[youknowriad]

It looks like this behavior regressed custom classes for dynamic blocks because they don't have any serialized content #9991