Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blocks: Preserve unknown block, remove freeform block comment delimiters #2513

Merged
merged 3 commits into from
Aug 29, 2017

Conversation

aduth
Copy link
Member

@aduth aduth commented Aug 23, 2017

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.

@aduth aduth added the [Feature] Block API API that allows to express the block paradigm. label Aug 23, 2017
@codecov
Copy link

codecov bot commented Aug 23, 2017

Codecov Report

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

Impacted file tree graph

@@            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.

@aduth aduth changed the title Blocks: Preserve unknown block comment delimiters Blocks: Preserve unknown block comment delimiters, remove freeform block comment delimiters Aug 23, 2017
@aduth aduth changed the title Blocks: Preserve unknown block comment delimiters, remove freeform block comment delimiters Blocks: Preserve unknown block, remove freeform block comment delimiters Aug 23, 2017
@aduth aduth force-pushed the update/preserve-unknown-block branch from 0591ae9 to 72eccbf Compare August 25, 2017 14:39
@aduth aduth force-pushed the update/preserve-unknown-block branch from 72eccbf to 44b8464 Compare August 25, 2017 14:57
@aduth aduth requested a review from mtias August 27, 2017 20:29
// If detected as a block which is not registered, preserve comment
// delimiters in content of unknown type handler.
if ( name ) {
rawContent = getCommentDelimitedContent( name, attributes, rawContent );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to manually preserve it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Block API API that allows to express the block paradigm.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Locked block: visualise instead of showing HTML Handle unrecognized blocks without modifying their markup
2 participants