Run registerBlockType hook over deprecated settings

[talldan]

Description

Alternative attempt to fix #16328. Unfinished and unlikely to be the right fix, but this PR should hopefully generate some discussion about the right way to fix the issue.

Background
After some digging into the above issue, I discovered that the supports settings for blocks relies on the registerBlockType filter. This filter adds an extra anchor attribute to blocks that support anchors.

Unfortunately the registerBlockType filter only runs on the main block settings, not deprecated block settings. When falling back to an older deprecation the attribute is not present and is never sourced from the HTML. In the case reported in the related issue, this caused a validation issue.

Other supports settings (e.g. align) also don't work with deprecations, but don't cause validation issues since data- attributes are ignored by the validator.

The fix here is to also run the registerBlockType filter over each object in the deprecation array.

How has this been tested?

Screenshots

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[talldan]

Not sure this is the right thing to do as it might have undesired consequences for other implementors of this filter (e.g. for plugins).

[youknowriad]

Should we remove the filter after the test to ensure it doesn't mess with other tests?

[talldan]

It's already handled in an afterEach on line 317.

[aduth]

Not sure this is the right thing to do as it might have undesired consequences for other implementors of this filter (e.g. for plugins).

Might be worth doing a look over keyword matches from the plugin repository using wpdirectory.net.

Example: https://wpdirectory.net/search/01DESKYX62AMYKSZE8KJ5FBQKF

[talldan]

Might be worth doing a look over keyword matches from the plugin repository using wpdirectory.net.

Example: https://wpdirectory.net/search/01DESKYX62AMYKSZE8KJ5FBQKF

Thanks for the link @aduth. It mostly looks ok, there's quite a bit of minified code, though.

There were a couple of plugins that use the filter to completely replace/enhance a block. For example, Jetpack:
https://github.com/Automattic/jetpack/blob/4c63a49fc0139c3296248e09ee69dedb537e024f/extensions/blocks/videopress/editor.js

This change would result in a bunch of properties being added to the deprecated settings that would go unused (deprecated, edit, transform). Probably not harmful, but perhaps it'd be better for the code in this PR to pick just supports, save and attributes from the filter return value?

Will also add an issue for Jetpack on how they're setting that deprecated value. If the video block is deprecated in core, that could cause some issues!

[youknowriad]

Let's ship this. The plugin releases will allow us to detect any potential issue with it we might have missed.

[talldan]

👍