Editor: Conflict with Calypso and Gutenberg and paragraph tags

[mkaz]

Steps to reproduce

1. Create a new post in Gutenberg (Jetpack site)
2. Edit post in Calypso and Save.
3. View post and P tags are removed.
4. Open post in Gutenberg paragraph blocks are modified

What I expected

Calypso editor is stripping out the <p> tags, which in turn is breaking the Gutenberg blocks. The Gutenberg error of blocks being modified is correct, since Calypso is modifying the blocks by running removep filter over post content.

Solution

A potential solution would be for Calypso to detect if Gutenberg blocks exists and to not apply the autop filter if they do.

[mkaz]

I initially thought this was applied on API Side, which it still might be. However, looking at the API, the paragraph tags do not even reach the endpoint. This can be confirmed by adding in paragraph tags in HTML mode, and then switching to Visual and back to HTML and the tags are removed.

[austinginder]

I believe there is a conflict between Gutenberg 2.1.0 and Jetpack 5.8. Downgrading Gutenberg to 2.0.0 resolves. Also deactivating Jetpack 5.8 resolves. To reproduce:

• Installed Gutenberg 2.1.0 and Jetpack 5.8 and create a post with content blocks.
• Reload the editor and see the P tags removed.

See quick screencast walkthrough: https://vimeo.com/255795293/bd24079e24

[austinginder]

WordPress/gutenberg#3922

[mkaz]

@austinginder thanks, that issue was hopefully fixed in Gutenberg 2.3.0 which was released yesterday. Please try it out and let me know if it fixes the issue for you.

Here is the relevant Gutenberg PR WordPress/gutenberg#5288

[oandregal]

Not sure if related or not, but here's what I see when I try to edit with Calypso a post created with Gutenberg in a Jetpack site:

In Gutenberg everything looks like the published post:

In Calypso there are some formatting issues and some paragraphs are split

[kristarella]

I think this issue may be related: WordPress/gutenberg#10376

I'm closing the other as it seems to be calypso-specific

[gwwar]

A potential solution would be for Calypso to detect if Gutenberg blocks exists and to not apply the autop filter if they do.

Re missing p tags, @mkaz Isn't the issue that we're not running wpautop for the published view when published from the classic Calypso editor, and there is a html comment block tag?

How Paragraphs are Serialized

For more context, classic posts made in the WordPress wp-admin editor and Calypso, stores content in a simpler format:

Classic

On the server we'll see paragraphs noted by two line breaks:

My Paragraph 1\n\nMy Paragraph 2

When the editor loads, it runs content through this function which adds p tags:

this.editor.setContent( wpautop( initialValue ) );

And likewise before save on the client, we remove them again:

e.content = removep( e.content );

The server will also run wpautop:

So we'll see the following in the published view:

<p>My Paragraph 1</p>
<p>My Paragraph 2</p>

Gutenberg

But what do Gutenberg paragraphs look like? The client and server both show and store the following:

<!-- wp:paragraph -->
<p>My Paragraph 1</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>My Paragraph 1</p>
<!-- /wp:paragraph -->

The published view does not display these HTML comments:

<p>My Paragraph 1</p>
<p>My Paragraph 2</p>

[supernovia]

I also ran into this; wrote a post in Gutenberg wp-admin, edited in Calypso (because that's what the edit link leads to), then paragraphs were gone.

Only, if I view the HTML in the Gutenberg editor, the paragraph tags are all still there. :/ They don't show up in the revisions, though.

[lancewillett]

I've been running into this for weeks but assumed I was an early adopter. 😄 Right now I avoid it by only using one editor experience for each P2 post (not switching between contexts or editors).

[gwwar]

note to self: potentially related D18636-code

[gwwar]

Verified the issue. Also verified that removing all Gutenberg comments in the classic editor will re-instate the p tag behavior as expected.

[gwwar]

Folks can't reproduce on master anymore so, something must have fixed the issue in the last few days. Closing this out for now. If folks see other compatibility issues please file a new issue instead of resurrecting this one.

[vindl]

Just wanted to confirm that I wasn't able to reproduce this both for Simple and Jetpack sites on current master. We suspect that something in 4.1 update resolved it, but we are still not certain what.

[vindl]

Not sure if this is relevant yet, but there was an autop related change in 4.2 that might have caused a regression? D20219-code

[tyxla]

Possibly related:

https://core.trac.wordpress.org/ticket/45290
Automattic/jetpack#10634
Automattic/jetpack#10635

[jjchrisdiehl]

Just wanted to note that I am seeing this issue on the WordPress.com support theme, see: https://en.support.wordpress.com/wordpress-editor/blocks/common-blocks/

[gwwar]

@tyxla @jjchrisdiehl if folks are seeing new reports, can we please open new issues with specific steps? autop misbehavior will trigger in various ways, and this will help us fix specific cases.