Parsing: Replace server serialization by parsed outerHTML

[aduth]

Related: #2806
Relies on: nylen/phpegjs#3 (changes manually effected here, but will be lost in future parser revisions)

This pull request seeks to change the behavior of selective wpautop application, simplifying the behavior to preserving the original markup of block content returned from the parser, rather than reserializing the parsed block node. In particular, this will be necessary for block nesting since, as implemented, the server is not capable of reserializing blocks with nested blocks if the block's save behavior is implemented on the client.

Testing instructions:

Ensure that tests pass:

npm test

phpunit

Repeat testing instructions from #2806

[dmsnell]

This is good work and I can clearly see places where it's going to be useful.

Do we think the most valuable about put is the block contents plus the block delimiters themselves though? What are the reasons for leaving those comment in vs. just returning everything inside the delimiters? (I know one is that it's easier in the parser to return the entire match than just the inside contents)

[aduth]

Do we think the most valuable about put is the block contents plus the block delimiters themselves though? What are the reasons for leaving those comment in vs. just returning everything inside the delimiters? (I know one is that it's easier in the parser to return the entire match than just the inside contents)

Yes, part of the objective here is that we want to preserve block content as-is without serializing anything. In the latter case, we would still need to serialize the comment attributes again. Another example is that validation becomes stricter (in a good way), verifying not only the contents within the delimiters, but the delimiters themselves (a few flagged issues fixed in these changes).

If we were to just return everything inside the delimiters, what then would be the main difference between innerHTML and outerHTML? Just that the latter would reflect the raw markup including that of its inner blocks?

[dmsnell]

If we were to just return everything inside the delimiters, what then would be the main difference between innerHTML and outerHTML? Just that the latter would reflect the raw markup including that of its inner blocks?

Actually I'm curious about how this accomplishes our goals in creating and operating over blocks, not specifically in how to test Gutenberg's code. If innerHTML isn't sufficient for things like autop, what is better about outerHTML vs being able to operate over the contents?

On that note, why isn't innerHTML sufficient for autop? Seems like that is even better because I'm guessing we don't want things like shortcodes messing up block boundaries. To me, it feels like passing the block structure into WordPress core is asking to break down the safe boundaries those blocks have until now preserved.

This is an entirely separate question though from whether it's right to prevent WordPress from serializing and reprinting the blocks. It seems obvious to me that by making the client-side JavaScript necessary to operate on the post content we've been inviting trouble, and that to me is a bigger culprit here.

[dmsnell]

@aduth what do you need to keep this moving? are there updates that affect its relevancy?

[aduth]

@dmsnell Yes, this may no longer be the direction I want to take here, and rather move wpautop handling to occur in the client when loading an existing post, which has a few advantages:

• For all new or upgraded posts, autop can effectively be skipped, reducing server load for front-end display
• The server does not need to know how to mimic block serialization behaviors, and this can be handled entirely in the client
• This could tie into no-delimiter paragraph blocks (Text: handle legacy structures #589) if it's something we want to pursue
  • i.e. paragraph blocks get special treatment where comment delimiters are optional. Not sure how well this would pan out, but I know it's something @mtias has mentioned exploring.

[aduth]

Superseded by #4005