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

Fix Shortcode—Markdown conflicts #5695

Closed
2 tasks
mcsf opened this issue Mar 19, 2018 · 3 comments
Closed
2 tasks

Fix Shortcode—Markdown conflicts #5695

mcsf opened this issue Mar 19, 2018 · 3 comments
Labels
[Feature] Raw Handling Related to the ability to convert content to blocks, paste handling, etc [Feature] Writing Flow Block selection, navigation, splitting, merging, deletion...

Comments

@mcsf
Copy link
Contributor

mcsf commented Mar 19, 2018

Spawned from discussion in #4944.

Issue Overview

By their respective syntax, Markdown and WordPress shortcodes are prone to conflict with one another. This is particularly visible in the examples below.

Links

When pasting the following:

This contains an [awesome] link to something. This here is even [better][awesomer].

[awesomer]: http://example.org

the ideal reconciliation would be as follows:

  1. [awesomer] is the identifier for a reference-style link
  2. [better] is the wrapped text for said link
  3. thus, let Markdown handle and convert the pair [better][awesomer] to a link (to https://example.org)
  4. [awesome] is a standalone tag with no link attached to it
  5. thus, let Gutenberg treat it as a shortcode — which for standalone shortcodes means converting to a shortcode block, and for inline shortcodes means leaving it untouched

Escaping shortcode contents

When pasting the following:

[my_shortcode]hello, _there_.[/my_shortcode]
**oh**, [another_shortcode]hello, _there_.

the ideal reconciliation would be as follows:

  1. [my_shortcode] is recognized as a shortcode with opening and closing tags and containing the string hello, _there_.
  2. thus, don't perform any Markdown conversion on the tag itself and on its contents
  3. [another_shortcode] is recognized as being a shortcode and not a link, but it is assumed self-closing
  4. thus, no escaping is due, and the fragments **oh**, and hello, _there_. will be rendered as <strong>oh</strong>, and hello, <em>there</em>., respectively.

Possible Solution

This comment of mine #4944 (comment) points to a Gist offering a working solution to get started.

Screenshots / Video

Related Issues and/or PRs

Todos

  • Tests
  • Documentation
@mcsf mcsf added [Feature] Raw Handling Related to the ability to convert content to blocks, paste handling, etc [Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... labels Mar 19, 2018
@mcsf
Copy link
Contributor Author

mcsf commented Mar 19, 2018

/cc @iseulde, since we chatted about this in #4944.

@youknowriad
Copy link
Contributor

A lot of things changed since this issue was opened. Is it still valid?

@mcsf
Copy link
Contributor Author

mcsf commented Jan 28, 2019

The only thing I could see as an enhancement would be paste-time support for referenced links, as opposed to inline links. For example:

Some text with [a link][1] and
another [link][2].

[1]: http://example.com/ "Title"
[2]: http://example.org/ "Title"

Aside from that, overall support seems pretty good, defaults are sane, and I don't think the issue surfaces at all as a priority. Will close.

@mcsf mcsf closed this as completed Jan 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Raw Handling Related to the ability to convert content to blocks, paste handling, etc [Feature] Writing Flow Block selection, navigation, splitting, merging, deletion...
Projects
None yet
Development

No branches or pull requests

2 participants