Raw handling: skip inline shortcodes

[ellatrix]

Description

This PR implements #3806 (comment).

Fixes #3806.

Only if the shortcode is preceded by a newline (or a plain paragraph tag from the Markdown converter), we should create a shortcode block. Otherwise we should like the shortcode alone as text.

I think this may be a bit too simplistic, but generally goes in the right direction. Maybe we should also check if the shortcode contains any HTML. If it does, maybe it should be "preserved" in a block.

How has this been tested?

See #3806 (comment).

Screenshots

Types of changes

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[ellatrix]

Also wondering if this should only happen if the transformer is added by the shortcode block. If there is any other block transforming the shortcode, we should probably just let it happens. I think the problem here is the catch-all. Cc @mcsf.

[ellatrix]

Maybe we come back here to something like setUnknownShortcodeHandlerName?

[mcsf]

Also wondering if this should only happen if the transformer is added by the shortcode block. If there is any other block transforming the shortcode, we should probably just let it happens. I think the problem here is the catch-all.

Good question, though I'm not quite convinced. I guess this specific handling of inline shortcodes is mainly in place for backwards compatibility, but also as a way to cope with current limitations of the block paradigm:

1. The goal, foremost, is to prevent breakage of inline flow when converting classic content to blocks. Even when dealing with new content, it's expectable that publishers may need to rely on "legacy" inline shortcodes for certain kinds of data or control (something that perhaps inline tokens will address in the future).

2. Well before Gutenberg, shortcodes have been employed both inline and as "blocks" (on their own line), but I don't see that choice as necessarily bound to the shortcode type. That is, I can see myself using certain shortcodes in both ways:

Inline	Block
Let's meet at [time]Tuesday, December 12, 2017 at 14:00 UTC[/time].	Meeting schedule [time]Tuesday, December 12, 2017 at 14:00 UTC[/time]

And, conceptually, when transitioning to Gutenberg, I'd expect the latter scenario to convert to wp:heading + wp:shortcode, but the former to remain wp:paragraph.

Does this make sense, or was I just rambling? 🙂

[ellatrix]

@mcsf That makes sense. So what do you think of the handling in this PR?

[aduth]

(or a plain paragraph tag from the Markdown converter)

Should the shortcode converter have knowledge of the Markdown converter? Can the shortcode conversion take place before Markdown-ification takes effect?

[ellatrix]

@aduth @mcsf We discussed this a few times, and I'm not sure what the right solution here is. Shortcakes and Markdown can conflict: [link](http://...). We could do a plain text check first, then make the shortcode parser ignore [] followed by (? Won't work for reference-style links though. This is the biggest issue.

[ellatrix]

Maybe we should only run one of these (markdown or shortcode) depending on the content, but I'm not sure what to look for. Shortcodes can also be found in plain text when pasting from the text editor.

[mcsf]

I'm sure we can fine-tune this in the future if we run into special cases. For now, this is a welcome fix for me.

[mcsf]

I'd add at the end of the sentence: , and thus skip conversion for this segment. Does it make sense?

edit: I've amended

[ellatrix]

Thanks for reviewing @mcsf!

[danielbachhuber]

@iseulde @mcsf Is there a reason there aren't tests for this pull request (and segmentHTMLToShortcodeBlock more generally)?

[ellatrix]

@danielbachhuber Yes. There's no module yet for the shortcodes, it's still a window global.