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

Supporting shortcodes #334

Closed
grahamarmfield opened this Issue Mar 27, 2017 · 7 comments

Comments

Projects
None yet
4 participants
@grahamarmfield

grahamarmfield commented Mar 27, 2017

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

This comment has been minimized.

Contributor

jasmussen commented Mar 28, 2017

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

@aduth

This comment has been minimized.

Member

aduth commented Mar 28, 2017

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

This comment has been minimized.

joyously commented Mar 28, 2017

@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

This comment has been minimized.

grahamarmfield commented Mar 29, 2017

@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

This comment has been minimized.

Contributor

jasmussen commented Mar 29, 2017

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

This comment has been minimized.

Member

aduth commented Mar 29, 2017

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

This comment has been minimized.

Contributor

jasmussen commented Apr 20, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment