RFC: Remove shortcode parser in favor of thunderer/Shortcode

[Simon Erkelens]

Shortcode parsers are terrible to maintain if you ask me. Having an external library to do this for us, would save a lot of time and clean up the framework more to do what it is supposed to do.

I don't think parsing shortcodes is one of those things. Also I'm wondering, how often do people actually use the shortcodes? Since there's hardly any mention of it anywhere in the userdocs.

My suggestion is to swap the ShortcodeParser for https://github.com/thunderer/Shortcode. If I look at the commit history, it seems to be well maintained.

[off...@netwerkstatt.at]

We use shortcodes a lot on many projects. It’s easy to include e.g. galleries inside $Content, i also inject a list of latest events or of related pages (by tag) etc…

 

With https://github.com/sheadawson/silverstripe-shortcodable there is also a nice UI for inserting shortcodes.

 

And we also made shortcodes that contain shortcodes (risky, I know, we have to be quite carefully not to make a loop), e.g. a snippet with lastest events by location and some other text.

 

 

As long as it doesn’t break existing shortcodes I’m fine with replacing it with a better implementation.

 

It would be great if not just [shortcode] but <p>[shortcode]</p>  could be replaced, cause TinyMCE always wraps my shortcode in <p>s…

 

 

Cheers,

 

Werner

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Simon Erkelens]

Removing ShortcodeParser would break Shea's module. But then again, it's a major version and he can update it easily to use an external dependency. I've tried Thunderer, and it really is a piece of cake to add a shortcode.

Stripping out the p-tags, not so much. Sorry, that's a tinyMCE thing shortcode parsers do not handle.

(although, the p-tags do cause issues on multiple occasions, I agree)

[Jonathon Menz]

I use shortcodes from time to time, and think if the editing experience was more intuitive (like Shea's module but going even further) developers might use them a lot more often. Some thoughts on that here if you're interested Simon: https://github.com/silverstripe/silverstripe-framework/issues/4337#issuecomment-217745020

[Fred Condo]

We use shortcodes extensively, in many projects. Please don't break them.

[Shea Dawson]

+ 1.

I would be more than happy to update shortcodable to use a new parser and it should be doable in a backwards compatible way. Shortcodable currently uses the core ShortcodeParser and a custom ShortcodableParser. It was a while ago and I can't remember exactly why, according to my comments in the file it might have just been that ShortcodeParser had protected methods that I needed to call but couldn't. But I remember not having much fun working with the SS ShortcodeParser so yeah :)

[Hamish Friedlander]

There's heavy use of shortcodes in core SilverStripe 4 for all images, which adds to the use of shortcodes for links and oembed elements in SilverStripe 3.

I'd be happy to move to an external library. I wrote the current regex, and - well it works, but it is a regex.

However most of the code in SilverStripe's ShortcodeParser is actually to try and adjust the inserted content to still be HTML compliant, not actually parsing. (So if the shortcode tries to insert a p tag into an existing p tag it still works). It doesn't look like thunderer/shortcode attempts that - like most shortcode systems, it's content-type agnostic / ignorant.

(The initial use case, for those interested, was so a shortcode could insert a `<figure><img /><figcaption /></figure>' block which gets floated left or right - these need to be pulled out of any surrounding p tag or most browsers do the wrong thing).

Hamish Friedlander

[Sam Minnée]

I agree that a 3rd party library would be in line with the general principle we have of removing our reinvented wheels where feasible. I also second Fred's comment about retaining the functioning of existing shortcodes.

Since we use shortcodes in fundamental features (image and link insertion) I don't see it as being any more optional than HtmlEditorField. But making it a mandatory dependency to a 3rd party library is fine.

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Sam Minnée

CEO

SilverStripe Limited

[Sam Minnée]

It may be worth seeing if the special feature of our shortcode system that Hamish has described could be submitted as a PR to a 3rd party shortcode system.