Possible integration with Gutenberg

[antek83]

Hi guys,

The Gutenberg editor will 'demote' shortcodes since blocks are the evolution of shortcoded it makes sense that in time all shortcodes will be converted into blocks.
The key concept here is IN TIME. As for today there are some stuff that are still better as shortcodes than blocks, one example is the SoundCloud player. With the standard Oembed you cannot customize the color or the player type Visual or Simple... This is one example but there are many that I could bring up.

Shortcodes work in Gutenberg but they do not have a UI or a preview and I don't think this it's gonna change.
There is a shortcode block in the works and @iselude is working on bringing all the current (I don't like to say old) editor functionalities, including custom TinyMCE buttons into the Classic Editor block.

One option, could be to call the Shortcake UI from a TinyMCE button instead of a media button, that way it could be easily integrated into the Classic Editor block but I do not think it could have a preview.

Another option could be to have a Shortcake Block that let you select the Shortcode you want to insert, shows the Editing Ui and, for example, displays the Shortcode icon in the preview, not as good UX as rendering the Shorcode but better than the square bracketed version.

Do you think any of the above could be doable?
I am willing to help if you want.

[szepeviktor]

A Gutenberg-shim?
(good-hill in German)

[antek83]

Kind of, at least that was the idea & thanx for correcting

[westonruter]

Copying some of my comments regarding Shortcake and Gutenberg from https://davisshaver.com/2017/07/15/playing-with-gutenberg-for-the-first-time/

Blocks implement previews as well. A shortcode block in Gutenberg could implement the same server-side previewing logic as Shortcake does today. Some widgets implemented as blocks will also require server-side rendering to display a preview. For more on the server-side rendering, see WordPress/gutenberg#780

Also, a shortcode block could also provide a UI for manipulating its attributes. In fact, I'd like to see Shortcake extend the shortcode block to port its fields API over to fields in the Gutenberg inspector. Shortcake could also actually provide the shortcode preview logic to Gutenberg as well. Server-side rendering of shortcode previews in the editor isn't going to be a priority in Gutenberg, since the constrict is legacy in favor of development focus being on blocks.

Gutenberg blocks doesn't support exactly the same field declaration syntax as Shortcake, though in effect the result is the same but just with different syntax: Gutenberg expresses in React components what Shortcake represents with nested associative arrays. That being said, it would be trivial to implement a React component that could take the array as defined in Shortcake to then map it to the corresponding set of React components automatically. This could also be part of a Shortcake bridge for Gutenberg. Also, there has been discussion about adding a fuller schema definition for a Block, and field annotations could potentially be placed there.

See also:

• Render shortcode previews within Gutenberg WordPress/gutenberg#1054
• Add Block: Shortcode WordPress/gutenberg#1709

[antek83]

@westonruter Thank you for your reply, I did not read the article on davisshaver before, very interesting.

Of course extending the Shorcode block to have attributes seems like the most natural way of doing the porting, this would require the Shortcode block to be 'extensible'.
With blocks, many shortcodes won't have anymore any reason to exist but, some others, like the SoundCloud player I mentioned in the original post, are still better handled with shortcodes.
At the end of the day blocks should improve both the user experience and allow users to create rich posts that look cool as well, same goes for the Vimeo Player..

A bit out of topic but not completely out of the ball park is the new className it accepts true or false but I could not find a way to 'hook' into it to define a set of predefined classes... This is something that I use Shortcake a lot for. As an example there is a block that creates a info box with some text in it, developers could pre-define the allowed classes like: red green and blue and they would display as a select box instead of an input field this would benefit both the UX and create a standard UI for doing something that is done by Shortcodes today.

I can also see many use case for storing the block as postmeta, anything with the google maps api for example.

[davisshaver]

@antekdesign @westonruter +1... Maybe we can see a Shortcake block and then figure out extending to any block -> post meta link later.

@antekdesign For the className question I think that's a Gutenberg question, My understanding is it would be possible to do pure React blocks through Gutenberg but in the case of Shortcake block I believe we'd be focused on porting PHP shortcodes.

[antek83]

@davisshaver you're absolutely right it the className thing is 100% Gutenberg related it just came out writing :)

Do you think, considering the current course of events, that Shortcake should have it's own block rather than extending the core WordPress Shortcode block to come?

[goldenapples]

I've started a shortcake-to-gutenberg shim plugin here: https://github.com/wp-shortcake/shortcake-gutenberg

This is very rough still - it takes any shortcodes registered with shortcode ui in the format defined by Shortcake, and registers Gutenberg blocks for them. The block content is the same as the shortcode - so there should be no special front-end rendering logic required beyond what's already defined with the add_shortcode callback. But the shortcode attributes are used as block attributes, and - like in the classic editor - there's a preview available in the editor, and clicking the preview brings up a form where each of the attributes can be edited.

As of now, all the attribute field types are basic rendered as text fields, but there are open issues to develop fields matching all of the existing field types (post select, attachment select, and so on). Many of those already exist as Gutenberg components and just need to be extended a bit for inclusion.