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

Content with only "More" block reloads as invalid #4038

Closed
aduth opened this issue Dec 15, 2017 · 3 comments
Closed

Content with only "More" block reloads as invalid #4038

aduth opened this issue Dec 15, 2017 · 3 comments
Labels
[Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f [Type] Bug An existing feature does not function as intended
Milestone

Comments

@aduth
Copy link
Member

aduth commented Dec 15, 2017

Issue Overview

When saving a post with only the "More" block, reloading the post reveals multiple invalid blocks.

Invalid

Steps to Reproduce (for bugs)

  1. Navigate to Posts > New Post
  2. Insert a More block
  3. Save the post
  4. Reload the page

Expected Behavior

The post is shown as it did prior to reload.

Current Behavior

The post is shown with multiple invalid blocks.

Possible Solution

This appears to be a conflict with autop behaviors. Specifically:

wpautop( '<!--more-->' ) === '<p><!--more--></p>';

The Gutenberg content parser treats this as three blocks:

  • Freeform block with innerHTML <p>
  • More block
  • Freeform block with innerHTML </p>

The two freeform blocks are marked as invalid because reserializing will restore the missing closing / opening tags respectively.

A few options here:

  • The "More" tag, if considered a proper block, could be exempted from wpautop as other blocks
  • The grammar could be made more lenient to consider <p> wrapping tag for a More block
  • The grammar could be made more strict to not consider More block if wrapped by <p>
@aduth aduth added [Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f [Type] Bug An existing feature does not function as intended labels Dec 15, 2017
@bobbingwide
Copy link
Contributor

bobbingwide commented Jan 15, 2018

I got the same problem when selecting a post that was created in the Classic Editor. Switching to the Code editor reveals the changed source. There were no p tags in the original.

<p>Same problem happens when there's content.

<!--more-->

No line feeds here.</p>

Saving the above leads to even more confusion the next time the post is edited.

@aduth
Copy link
Member Author

aduth commented Jan 16, 2018

Related: #4005

Switching to the Code editor reveals the changed source.

With the above #4005, this will produce a slightly different result, but still not quite right:

<p>Same problem happens when there's content.</p>
<p><!--more--></p>
<p>No line feeds here.</p>

@karmatosed karmatosed added this to the Merge Proposal milestone Jan 25, 2018
@mcsf
Copy link
Contributor

mcsf commented Mar 6, 2018

Should be fixed by now (see #5061).

@mcsf mcsf closed this as completed Mar 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

4 participants