Remove amp-fit-text block setting

[pierlon]

Summary

Removes the amp-fit-text setting and related controls from the block panel and also removes the related block attributes from text blocks that had the setting enabled.

Fixes #4557

Checklist

• My pull request is addressing an open issue (please create one otherwise).
• My code is tested and passes existing tests.
• My code follows the Engineering Guidelines (updates are often made to the guidelines, check it out periodically).

[codecov]

Codecov Report

Merging #5729 (015bb11) into develop (ac8cfe9) will increase coverage by 0.08%.
The diff coverage is 7.69%.

@@              Coverage Diff              @@
##             develop    #5729      +/-   ##
=============================================
+ Coverage      74.14%   74.22%   +0.08%     
  Complexity      5498     5498              
=============================================
  Files            201      201              
  Lines          16653    16623      -30     
=============================================
- Hits           12347    12339       -8     
+ Misses          4306     4284      -22     

Flag	Coverage Δ	Complexity Δ
javascript	75.84% <7.69%> (+2.50%)	0.00 <0.00> (ø)
php	74.17% <ø> (ø)	0.00 <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ	Complexity Δ
includes/admin/class-amp-editor-blocks.php	67.44% <ø> (ø)	17.00 <0.00> (ø)
assets/src/block-editor/helpers/index.js	29.10% <7.69%> (+0.44%)	0.00 <0.00> (ø)

[github-actions]

Plugin builds for 015bb11 are ready 🛎️!

• Download development build
• Download production build

[johnwatkins0]

One minor suggestion.

[westonruter]

Testing with this post_content:

<!-- wp:paragraph {"ampFitText":true} -->
<amp-fit-text layout="fixed-height" min-font-size="4" max-font-size="172" height="172"><p>paragraph</p></amp-fit-text>
<!-- /wp:paragraph -->

<!-- wp:heading {"ampFitText":true} -->
<amp-fit-text layout="fixed-height" min-font-size="4" max-font-size="172" height="172"><h2>teasdasd</h2></amp-fit-text>
<!-- /wp:heading -->

<!-- wp:code {"ampFitText":true} -->
<amp-fit-text layout="fixed-height" min-font-size="4" max-font-size="172" height="172"><pre class="wp-block-code"><code>test</code></pre></amp-fit-text>
<!-- /wp:code -->

<!-- wp:quote {"ampFitText":true} -->
<amp-fit-text layout="fixed-height" min-font-size="5" max-font-size="73" height="90"><blockquote class="wp-block-quote"><p>quote</p></blockquote></amp-fit-text>
<!-- /wp:quote -->

Before the changes in this PR, it looks like this:

Non-AMP	AMP

Upon upgrading to the build in this PR, accessing the editor results in block validation errors for the Code block and the Quote block:

Interesting the Header block and the Paragraph block automatically strip out the <amp-fit-text> tags, but they remain for Quote and Code:

<!-- wp:paragraph -->
<p>paragraph</p>
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h2>teasdasd</h2>
<!-- /wp:heading -->

<!-- wp:code -->
<amp-fit-text layout="fixed-height" min-font-size="4" max-font-size="172" height="172"><pre class="wp-block-code"><code>test</code></pre></amp-fit-text>
<!-- /wp:code -->

<!-- wp:quote -->
<amp-fit-text layout="fixed-height" min-font-size="5" max-font-size="73" height="90"><blockquote class="wp-block-quote"><p>quote</p></blockquote></amp-fit-text>
<!-- /wp:quote -->

Is the presence of block validation errors expected? I suppose so. Attempting block recovery for those two blocks is successful:

<!-- wp:paragraph -->
<p>paragraph</p>
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h2>teasdasd</h2>
<!-- /wp:heading -->

<!-- wp:code -->
<pre class="wp-block-code"><code>test</code></pre>
<!-- /wp:code -->

<!-- wp:quote -->
<blockquote class="wp-block-quote"><p>quote</p></blockquote>
<!-- /wp:quote -->

And then the result is identical AMP and non-AMP, and no trace of amp-fit-text.

Is this all working as intended?

[westonruter]

Granted, there are probably no instances (or very few instances) of these blocks being used with fit-text.

[pierlon]

Is the presence of block validation errors expected?

No, it should be be able to deprecate gracefully without any errors. I'll take a look at the example you provided.

[westonruter]

Per #5729 (comment)

[pierlon]

I've fixed the issue in bdb65aa. The code and quote blocks were not being deprecated as expected due to an additional prop being added to the element after the block is saved. I've tracked it down to the core/generated-class-name/save-props filter which adds a generated className prop if the block supports the className feature (which all blocks do by default). The paragraph and heading blocks explicitly do not support the feature, which is why the issue did not occur on those blocks.

[westonruter]

Fixed indeed!

Input:

<!-- wp:paragraph {"ampFitText":true} -->
<amp-fit-text layout="fixed-height" min-font-size="4" max-font-size="172" height="172"><p>paragraph</p></amp-fit-text>
<!-- /wp:paragraph -->

<!-- wp:heading {"ampFitText":true} -->
<amp-fit-text layout="fixed-height" min-font-size="4" max-font-size="172" height="172"><h2>teasdasd</h2></amp-fit-text>
<!-- /wp:heading -->

<!-- wp:code {"ampFitText":true} -->
<amp-fit-text layout="fixed-height" min-font-size="4" max-font-size="172" height="172"><pre class="wp-block-code"><code>test</code></pre></amp-fit-text>
<!-- /wp:code -->

<!-- wp:quote {"ampFitText":true} -->
<amp-fit-text layout="fixed-height" min-font-size="5" max-font-size="73" height="90"><blockquote class="wp-block-quote"><p>quote</p></blockquote></amp-fit-text>
<!-- /wp:quote -->

Output:

<!-- wp:paragraph -->
<p>paragraph</p>
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h2>teasdasd</h2>
<!-- /wp:heading -->

<!-- wp:code -->
<pre class="wp-block-code"><code>test</code></pre>
<!-- /wp:code -->

<!-- wp:quote -->
<blockquote class="wp-block-quote"><p>quote</p></blockquote>
<!-- /wp:quote -->

No block validation errors:

[westonruter]

@pierlon Question: Is there a reason why you went with removeClassFromAmpFitTextBlocks in JS as opposed to using the existing ObsoleteBlockAttributeRemover?

[pierlon]

The ObsoleteBlockAttributeRemover service would not be applicable in this context as the block deprecation is handled on the client side and so the added class attribute will never be seen by the service until the post is saved, and by that time the "This block contains invalid content" notice would already be displayed.

[westonruter]

See also successful block migration messages: