Supporting shortcodes

[grahamarmfield]

Having used shortcodes extensively over the years when building sites for clients who have no markup knowledge, I have some concerns about how the editor will cope with shortcodes - especially 'enclosing shortcodes' which may contain multiple paragraphs, headers or other block level elements.

An example:

[faq-builder]
(h2)Question 1(/h2)
(p)Answer to question 1(/p)
(h2)Question 2(/h2)
(p)Answer to question 2(/p)
[/faq-builder]

As far as I can tell from codex this is a valid use of shortcodes. Will the editor treat the opening and closing shortcode as separate elements, and do you foresee any potential issues here?

[jasmussen]

Great discussion. @azaozz can you add some more context? Thanks.

[aduth]

Current discussion has led toward discouraging this sort of use of shortcodes in favor of defining block behaviors with a standard HTML output. We should still consider how existing shortcodes built this way would be supported moving forward.

The wp.shortcode object should give us the utilities to parse the shortcode string into a usable object. For our block API, the attributes function* allows the developer to define a function which accepts the raw content of the block. We could expect the developer to accommodate the case where a shortcode is passed as the raw content, parse it into an object shape, and then generate element variants with edit and save using the object structure.

We still lack anything that allows shortcodes (or even plain HTML) to be "upgraded" automatically to new block equivalents. I've roughly considered a block being able to include in its settings a set of matchers to a shortcode or DOM selector:

matches: [
	{ shortcode: 'faq-builder', attributes( shortcode ) { return /* ... */; } }
]

* I'm observing now that this isn't documented at all. I'll see to including this. Here's the current code implementation.

[joyously]

@grahamarmfield Is that the actual syntax you use or did you put parentheses for ease of typing in this environment?
It seems to me that it shouldn't matter what is enclosed in the shortcode, because that's for the shortcode to handle.

[grahamarmfield]

@joyously I did use that syntax for ease of typing in this environment. It meant to imply that I would have a series of headings - each one followed by one/some paragraphs of content (including images). All the shortcode does really is place all the content into a (div) with a specific class - that is then turned into an accordion setup with jquery.

@aduth The shortcodes I've built do indeed pull in the enclosed content and have various attributes. I know that ideally I would want to put a containing (div) directly into the page, but I'm building these constructs for site owners and admins that have no HTML knowledge. For these people the shortcode context is attractive and easier to understand.

I guess my concern with the new editor and enclosing shortcodes is twofold:

1. Will the editor present the opening and closing shortcode elements as separate page elements/blocks on a new line?
2. If so, will this result in empty paragraphs being added to the resultant content that is displayed to the site visitors - a problem that has caused issues in the past.

I also have some concerns around accessibility, but this thread is not the right place for those.

[jasmussen]

The shortcodes I've built do indeed pull in the enclosed content and have various attributes. I know that ideally I would want to put a containing (div) directly into the page, but I'm building these constructs for site owners and admins that have no HTML knowledge. For these people the shortcode context is attractive and easier to understand.

Regarding the support for shortcodes in the future, Andrew can provide a better answer than I can. But the problem you're trying to solve with shortcodes — making it easy to create advanced layouts for casual users who don't know HTML — is in fact at the very heart of what we're doing with the editor blocks. The goal for the blocks would be that instead of writing a shortcode to make this simple (where you'd still have to know shortcode syntax), you'd write a custom block to do the same. Instead of having to write shortcodes, your site owners would insert an Accordion block and fill out the fields. You can see some early mockups in #283.

I also have some concerns around accessibility, but this thread is not the right place for those.

Feel free to add to the discussion on #297!

[aduth]

To future compatibility, without adding explicit block support, I expect existing shortcodes will adopt behaviors of the text or generic blocks, so interacting should behave similar to as it does today.

The remarks in my previous comment were aimed at plugin authors who had taken this approach in the past and would like to provide backwards compatibility for those shortcodes while still taking advantage of newly implemented block best practices.

Another group of plugin authors may also have implemented their own behaviors with shortcodes using the existing mce-view.js. This is a less common case and it's not clear yet what (if any) compatibility the block editor would have with these views.

[jasmussen]

Closing as answered by Andrew here: #334 (comment)