Match WP Formats Exactly

[kevinfodness]

Description

In certain cases, the output of this library results in some subtle differences vs. what WordPress produces natively. As with #19, this difference can cause rendering issues. We should set up our tests to ensure that this library produces markup that is identical to what WordPress produces, including the position of line breaks, for all blocks.

Ideally, this would be accomplished by installing the latest version of WordPress and having WordPress itself create the blocks, which would also serve as a regression test in case block formats change in a future version of WordPress. However, this may be complicated, as block markup is created using JavaScript but is being tested using PHP. As a first pass, we may want to update the existing unit tests with markup copied from a running copy of WordPress and fix any failures, then automate the "create the test blocks" functionality if possible in a future iteration.

Use Case

When a user uses this library to convert blocks, the resulting Gutenberg markup should match what would be produced if a user manually created the blocks in Gutenberg on a running WordPress installation.

[kevinfodness]

Frustratingly, the core function that this library uses, get_comment_delimited_block_content, does not work the same as its JavaScript counterpart. In particular, the PHP implementation doesn't insert line breaks after the opening comment tag or before the closing comment tag, which means that if you create a paragraph in the editor it gets saved to the database like this:

<!-- wp:paragraph -->
<p>Content to migrate</p>
<!-- /wp:paragraph -->

But if you create it in PHP using get_comment_delimited_block_content you end up with this:

<!-- wp:paragraph --><p>Content to migrate</p><!-- /wp:paragraph -->

There may be work to do here to ensure that generated blocks better match their modern Gutenberg counterparts, but the line break issue is a core bug, and ought to be fixed there.