One of the problems that the block editor was trying to solve was the way that shortcodes are handled in the editor.
There is an old beta plugin Shortcake that was a start at fixing this, but it didn’t help the user with existing shortcodes.
I was thinking of writing the missing piece for that, which would show which shortcodes are registered, but then found that one of my favorite plugin authors had just written
So, lately I was thinking that a fork and merge of these two with a little more focus on backward compatibility would help this community.
Goals would be:
make it easier to use shortcodes
provide a way to visualize the shortcode while editing
Hi @joyously,
It sounds like a good idea, and it would be great to have this as some type of ClassicPress officially supported plugin - all for it. But I see 2 challenges…
First, as a web agency, we get older sites to rebuild and redevelop. Quite often the shortcodes are particualr to some obselete theme, page builder, or abandoned plugin. Sometimes the content is gone as those eidotrs or pluigns use custom post-types. It creates a real mess for us when we rebuild, so we just copy the text.
Having said that, SiteOrigin and Elementor are no different - they use shortcodes too. In fact, I like the way Elementor templates have shortcodes, that can be dropped anywhere on site pages.
Second is UI/UX. A lot of those shortcode plugins are not user friendly. At least with Cakewalk it had a user friendly UI. I think that is important. Many of those old shortcode plugins were not user friendly. I think that is a key.
BTW
You might be interested to know SiteOrigin supports WP 4.7 and 4.9. So it might solve a lot of layout challenges and issues. Haven’t tried it with CP, but should work fine I would think. I have plans to test.
You point out some of the detriments to how shortcodes are currently handled. The question is: do you change how they are handled or help the user with tools?
I was just reading some of the issues that are in the Shortcake repo. There was a discussion summary that looks like it was the lead-in to Gutenberg. But I personally would come to different conclusions than they did.
I don’t think the editor needs to have the preview of the shortcode inline with the rest of the content. I would prefer a placeholder that can fetch a preview (via AJAX) if needed.
There could be a tool that checks for shortcodes that aren’t registered, with some sort of Search/Replace for the user to handle them.
OK, I’ve been playing with this today, and have a working version of supplying the shortcode attributes in the editor.
This is a first attempt and probably needs some more error checking and such. @james
You can find the modified CP at https://github.com/joyously/ClassicPress/tree/feature/shortcode-list
What you should see is in the editor, next to the Add Media button, a dropdown list of Shortcodes. When you select one, the shortcode with all its attributes and default values is put into the editor where your cursor was.
What needs work is the interface. Perhaps showing the attributes individually instead of throwing them all in there or something. Also, the script to handle shortcodes in the visual mode needs some way to interact with the attributes (not sure). I noticed that when in visual mode and I choose the gallery shortcode, it transforms into an image, even though there weren’t any images attached to the post I was editing. I’m not sure what that is about.
Also, it seems that one of the core shortcodes uses true as a default value, so that probably needs special handling.
I like this and I would find it useful. Just tried the plugin and although I can see a list of the shortcodes (including my own custom shortcodes), clicking on them doesn’t do anything for me.
Well, you have to use them together. It’s a proof of concept. I just used the plugin to get some interface in the editor, which I think can be improved. The trick to getting it to work is the core changes that the plugin calls.
I was thrilled to hear that you were exploring this further – a versatile shortcode builder would be fantastic. I’m eager to give this a go and will squeeze it in this coming week. Thanks for digging into this.
This is interesting, but the current approach is very hacky (relying on each shortcode calling shortcode_atts and using a combination of var_export and JSON to parse this unstructured data).
There should also be no need to modify core to get this to work, you can use the following filter:
This project did something slightly different - improved shortcode parsing to allow nested shortcodes, self-closing tags, etc without ambiguity. These two concepts could work well together as a building block for more advanced features.
Yes, it’s hacky. It’s proof of concept. I’m not sure why I didn’t want a loop; I just threw in a way to do it without a loop.
I figured if the shortcode doesn’t call shortcode_atts then it chooses to not participate.
I waffled on whether to return the array unchanged, but I didn’t want to leave it to the JS to do the work on an array with named keys.
At the time I was figuring it out, I thought I was doing all the shortcodes at once, and thought that filter would not work, because it is only called when the shortcode name is passed in.
I see now that I am doing one at a time, I can put my code in that filter and make sure I supply the tag so the filter is called. Hindsight is 20/20!
I have modified my plugin, and yes, I can get it done without changing core. I still think it belongs in core, though, with better JS to make it easier to use and to merge with the other shortcode JS.
@joyously a good next step for this would be to start a petition where you describe what it does and some of the things it can be used to achieve or build.
Ah, right. I thought it was either/or. Just tried the standalone plugin and it’s really good. Nice idea. If it doesn’t get included in core it might be a good candidate to go into the @anon71687268 enriched editor.
