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

Handle unrecognized blocks without modifying their markup #1735

Closed
nylen opened this issue Jul 5, 2017 · 5 comments · Fixed by #2513
Closed

Handle unrecognized blocks without modifying their markup #1735

nylen opened this issue Jul 5, 2017 · 5 comments · Fixed by #2513
Assignees
Labels
[Feature] Blocks Overall functionality of blocks [Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f
Projects
Milestone

Comments

@nylen
Copy link
Member

nylen commented Jul 5, 2017

While developing a demo plugin for #1619 and renaming blocks as their desired implementation becomes more clear, the user experience of blocks that are no longer recognized is quite bad. They are turned into core/freeform blocks on saving, without any indication of what is going on.

We need to find a way to show in the UI that an "unrecognized" block was detected, and avoid modifying it.

@nylen nylen added [Feature] Blocks Overall functionality of blocks [Priority] High Used to indicate top priority items that need quick attention [Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f labels Jul 5, 2017
@nylen nylen added this to the Beta 0.5.0 milestone Jul 5, 2017
@nylen nylen changed the title Handle unrecognized or invalid blocks without modifying their markup Handle unrecognized blocks without modifying their markup Jul 5, 2017
@ellatrix
Copy link
Member

ellatrix commented Jul 8, 2017

See also #1394, which also helps avoiding modifications and adding classes.

@dmsnell
Copy link
Contributor

dmsnell commented Jul 10, 2017

Also see #1175 for some additional context to this problem. That issue wasn't intended on turning into a discussion about using post_content but rather as a way to address the lifecycle of the post before, during, and after edit sessions.

The fact that we forget about the document structure when we save could be seen as a positive and negative at the same time I think. The worst bit is what you point out: we are way to jumpy on turning things into freeform blocks.

Instead of this behavior I would love to "preserve the broken structure" and give the author the choice when the author decides to edit it. That means, for the sake of rendering the post in the editor we can treat it as if it were a freeform block and maybe even indicate that it's broken (some kind of graying? a warning indicator?).

Once we enter into that block to edit it we can present the choice: "We had a problem determining how this block should be edited…(a) maybe there is a plugin missing to handle the pizza/margherita block - [open the repository]…(b) the recorded format differs from our expectations - [manually fix and see examples]… (c) an unknown problem occurred when reading it - [undo to latest known working state]… (d) go ahead and edit and lose the rich information encoded in the block - [edit at own risk as freeform]"

the problem extends beyond block type but also to attributes. for example, if we leave out the quotes on the JSON attributes then the whole set of attributes will be wiped out.

@aduth
Copy link
Member

aduth commented Jul 20, 2017

Some effort toward this goal at #1929

@nylen
Copy link
Member Author

nylen commented Jul 26, 2017

The same mechanism as #1929 can work here, but it's not working yet. To verify, create a post with this content:

<!-- wp:core/not-implemented-yet /-->

<!-- wp:core/not-implemented-yet -->
abc
<!-- /wp:core/not-implemented-yet -->

Edit it in Gutenberg, and see that the empty block is removed and the other one changes to a freeform block:

<!-- wp:core/freeform -->
abc
<!-- /wp:core/freeform -->

(This also happens without the post being marked as dirty, which seems less than ideal but may be a separate issue.)

@nylen nylen reopened this Jul 26, 2017
@mtias mtias removed the [Priority] High Used to indicate top priority items that need quick attention label Jul 28, 2017
@mtias mtias modified the milestones: Beta 0.7.0, Beta 0.6.0 Jul 28, 2017
@mtias mtias modified the milestones: Beta 0.8.0, Beta 0.7.0 Aug 7, 2017
@kopepasah kopepasah added this to Backlog in Blocks Aug 9, 2017
@kopepasah kopepasah moved this from Backlog to In Development in Blocks Aug 9, 2017
@mtias mtias modified the milestones: Beta 0.9.0, Beta 0.8.0, 0.10.0 Aug 14, 2017
@mtias
Copy link
Member

mtias commented Aug 18, 2017

Related #2126.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Blocks Overall functionality of blocks [Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f
Projects
No open projects
Blocks
In Development
Development

Successfully merging a pull request may close this issue.

5 participants