Blocks: Preserve unknown block, remove freeform block comment delimiters

[aduth]

Closes #2126
Closes #1735

This pull request seeks to resolve issues where content parsed as block, but of an unrecognized type, is not preserved (specifically, its comment delimiters and serialized comment attributes). In the course of doing so, this pull request also removes the freeform comment delimiters from saved content, under the assumption that it would parse again into a freeform block at the next parse anyways.

Testing instructions:

Verify that posts with unknown types parse with the content respected. Try inserting the following in either the Gutenberg or current editor's Text mode:

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

<!-- wp:core/unknown /-->

Freeform

<!-- wp:core/unknown {"foo":"bar"} -->
a
<!-- /wp:core/unknown -->

Previously this would destroy the void unknown block, and convert the last unknown block to freeform block without comment delimiters.

When switching to Text mode or saving the post with the above content, note that subsequent reserializations respect the markup exactly as it is shown above.

Open questions:

Because Freeform renders a TinyMCE, it is very easy to mistakenly edit the content of an unknown block type. I'm wondering if we ought to either create a separate block representation for un-blocked content vs. block content of an unknown type (e.g. since-disabled plugins blocks).

Alternatively, or in either case, we may want to convey messaging to the user about the unknown block instead of providing them the option to edit.

[codecov]

Codecov Report

Merging #2513 into master will increase coverage by 0.06%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2513      +/-   ##
==========================================
+ Coverage    30.1%   30.17%   +0.06%     
==========================================
  Files         174      174              
  Lines        5288     5293       +5     
  Branches      907      908       +1     
==========================================
+ Hits         1592     1597       +5     
  Misses       3132     3132              
  Partials      564      564

Impacted Files	Coverage Δ
blocks/api/serializer.js	97.87% <100%> (+0.14%)	⬆️
blocks/api/parser.js	98.18% <100%> (+0.06%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fdb1158...44b8464. Read the comment docs.

[mtias]

Why do we need to manually preserve it?

[aduth]

The result of a parse doesn't include the comment demarcations. Take this example:

<!-- wp:core/unknown -->
Unknown block
<!-- /wp:core/unknown -->

Upon parse, this is passed to createBlockWithFallback with arguments: core/unknown (name), Unknown block (rawContent), { foo: 'bar' } (attributes). When it fails to find the block matching this slug, the name and behavior assumes that of the fallback block. Future reserialization will not know to save this as the core/unknown block. So the logic here re-adds the comments to the rawContent field, so even though this assumes the role of the fallback block, the fallback block's content includes the original block text, and since the fallback block no longer writes its own comment demarcation, it is saved exactly as it was originally.

Part of this assumes we want the freeform block behaviors to be made available for unknown blocks. The original pull request comment explores whether this is desirable, or if we'd want to just flag it as "unknown", leave it alone, and notify the user as such.

Because Freeform renders a TinyMCE, it is very easy to mistakenly edit the content of an unknown block type. I'm wondering if we ought to either create a separate block representation for un-blocked content vs. block content of an unknown type (e.g. since-disabled plugins blocks).

Alternatively, or in either case, we may want to convey messaging to the user about the unknown block instead of providing them the option to edit.

[mtias]

Thanks for the explanation. The previous behaviour would transform the unknown block to freeform but still retain the comment within it, hence my question.

[aduth]

The previous behaviour would transform the unknown block to freeform but still retain the comment within it

No, the problem was that it didn't retain the comment. The logic added here is what achieves this.