Add Block: Shortcode

[jasmussen]

Shortcodes work today. You just type a shortcode in a text block, and it works. This is in master today.

It would be nice, though, to add an affordance for shortcodes. A separate block instead of a text block, that uses a code font. Something like this, perhaps:

[swissspidy]

What about inline shortcodes? Should they continue to be used in a text block as usual?

[jasmussen]

What about inline shortcodes? Should they continue to be used in a text block as usual?

This would work today.

Long term we want people to build blocks instead of shortcodes. I don't think we need to optimize too much for the presence of shortcodes, so long as they work.

[j-falk]

Anyway to get a preview mode/tab for a block like this (I think the HTML block has it) so you easily could see how the shortcode is rendered when editing?

[kevinwhoffman]

This would be good to have even if shortcodes do work just fine in text blocks. I suggest leaving out the angle brackets next to Shortcode as they look very similar to the adjacent positioning controls.

[swissspidy]

Yes. See #1054.

[lkraav]

Shortcodes work today. You just type a shortcode in a text block, and it works. This is in master today.

@jasmussen this is a bit of a half-truth. As of 0.4.0, in a Text block shortcodes get unconditionally wrapped into a <p>, which may or may not be desireable depending on the specific shortcode. For example, full column layout shortcodes outputting a full blown <div> structures should not get any paragraph wrapping.

2018.07.31 EDIT this was later worked on in #3900

[Drivingralle]

@jasmussen Not all use cases for shortcodes are block-ish elements.

We use shortcodes for variables inside of paragraphs or lists. For example for a version number of a product, so the team maintaining the website don't have to edit a lot of pages and posts.

It doesn't make sense to create a block out of this vars.

[jasmussen]

Solid points raised in this thread. Keep the edgecases coming, so we can think of solutions.

Two quick things, though:

1. The block is an evolution of the shortcode, and long term it would be best to migrate shortcodes to blocks.
2. Shortcodes should work exactly as they do today in the "Classic Text" block, which is essentially the old editor in block form.

Keeping those two in mind, the best approach is probably to think of how to ensure shortcodes work well in the near term, but at the same time balance so we don't optimize for a feature that, long term, has a better interface in the block.

[justintadlock]

One of the most-used shortcodes I currently have in one of my plugins is to show/hide the content the shortcode wraps based on who's viewing it. This could be one word or multiple paragraphs.

An example:

[members_access capability="manage_options"]
The content contained here can only be read by people with the "manage_options" capability.

A paragraph.

* A
* List

A big image.

Another paragraph.
[/members_access]

Ideally, this sort of thing could be its own block in the future.

However, for compatibility, how will this shortcode fit in with Gutenberg's block-based system? That's probably my primary concern as far as shortcodes go.

[lkraav]

One of the most-used shortcodes I currently have in one of my plugins is to show/hide the content the shortcode wraps based on who's viewing it. This could be one word or multiple paragraphs.

We run a subscription membership site where the same thing is the concern. For @justintadlock's presented scenario where individual blocks could be blocked, I'd imagine a nested block #428, where the "protection" is a container block for the content blocks, with a configuration panel in the meta bar.

In our case, we usually protect full post objects, which can be a post level meta configuration box.

[swissspidy]

I don't think a nested block would be needed for this, just a new block setting for visibility / capability. Of course, there would need to be some kind of migration process for existing posts with these shortcodes.

[lkraav]

I don't think a nested block would be needed for this, just a new block setting for visibility / capability. Of course, there would need to be some kind of migration process for existing posts with these shortcodes.

You need crystal clarity about access policies when you're dealing with multi-block content protection situations. It would be terrible management UX to not have clear birdseye view of which blocks are protected by what policy. Only one block's meta panel can be visible at one time and it's not reasonable to check this block by block. Or did I miss something about your thinking quoted above?

[kevinwhoffman]

I don't think a nested block would be needed for this, just a new block setting for visibility / capability.

This was my initial reaction as well until @Ikraav pointed out that:

Only one block's meta panel can be visible at one time and it's not reasonable to check this block by block.

While the nested block approach adds one more step of complexity for those wishing to restrict a single block, that complexity is worth the clarity and simplification of restricting multiple blocks. I suspect most users wanting to restrict content will be restricting more than one block at a time.

To address @justintadlock's concerns, can we assume that existing post content will end up in a Classic Text block and therefore any shortcodes within them should "just work"?

[justintadlock]

I just wanted to note that the new shortcode block does not adequately address the shortcode issue.

Right now, the shortcode block is a text input. It does not account for shortcodes that allow paragraphs, for example, of content. A textarea is necessary.

[alicam]

Could we offer options? Could shortcodes corresponding to block-level elements or groups of elements be treated as blocks, while shortcodes for small inline elements could have some other mechanism applied to parsing/rendering?

I'm not sure the current varied/edge uses of shortcodes can be accommodated in one solution, and perhaps we need to offer options ;)

A

[aduth]

A textarea is necessary.

I'm not sure the current varied/edge uses of shortcodes can be accommodated in one solution, and perhaps we need to offer options ;)

This seems to be the primary challenge: How can the editor know what type of editable display is most appropriate for the specific shortcode?

One option could be to use an autosizable textarea which starts small, but wraps content and grows to accommodate.

[justintadlock]

One option could be to use an autosizable textarea which starts small, but wraps content and grows to accommodate.

I think that would work for all of the shortcodes I've built.

[aduth]

The shortcode block now uses a resizable textarea as of #3184.

[jayscodex]

Is it possible to align the shortcode block with the wide alignment? This would be a nice feature.