At my recent WordPress Developer Meetup, the topic of shortcodes came up as a point of discusion. When talking about it, I realized that I’ve never actually talked about them here on the blog, so I thought it might be worth bringing up for discussion.
For those of you who have seen any of my plugins, you see that none of them include shortcodes despite the fact that people have requested functionality offered by them.
For the most part, I dislike WordPress shortcodes. I think they are unintuitive, difficult to use for the average user, and go against much of what the core functionality of WordPress aims to offer.
But the challenge is that there’s not yet a suitable alternative.
On WordPress Shortcodes (It’s Just Higher Level Markup)
Shortcodes are essentially a higher level form of markup, right?
I mean, there’s very little difference between:
<input type="text" name="gallery" value="123" />
The reason that I take issue with this is that people use WordPress – or other CMS’s for that matter – specifically because they aren’t developers.
Yet, when there’s certain functionality that users want to accomplish that a user interface element doesn’t afford, we default to using shortcodes.
“Then Use an Alternative.”
For the most part, when you’re drafting a post with text, images, links, and so on, there’s a 1:1 to correspondence with what the user sees in the post editor and on the public-facing side of the site. We can even improve this using
But this is the point of tension: Despite the fact that people have experimented with various ways of preventing users from having to enter shortcodes, we aren’t there yet.
On Using Galleries
Case in point: When you insert a gallery into a WordPress post, you’re essentially having WordPress generate a shortcode for you, but instead of displaying the shortcode, it displays a blue region in the post editor.
For anyone who has built products for others using WordPress that, then you recognize that this in and of itself requires a level of education because this breaks what the user sees in the post editor to what the users sees on the public-facing side of the site.
On Custom Shortcodes
There are a number of plugins that I maintain that others have requested that I introduce the ability for them to place their features throughout the post rather than at the very beginning or at the very end.
In the context of WordPress development, this is obviously a problem that can be solved by shortcodes. The thing is, I don’t want to educate users on having to write meta-language to use the plugin. I’m not sold on the idea that people want to use a WYSIWYG editor that isn’t quite, y’know, WYSIWYG.
So when it comes for me to introduce these features, I end up feeling like I have to sacrifice some form of personal philosophy.
Well, What Are Our Alternatives?
One of the problems that I dislike about posts that criticize features of existing systems is that that they don’t often offer alternative solutions. I don’t want to be that guy, so I’ll try to share some ideas in hopes of at least getting the discussion going.
Back To The Gallery
I’ll admit, although the gallery functionality isn’t true WYSIWYG, I think it’s certainly a step closer – or an improvement – to using shortcodes.
- It allows users to build their galleries using an interface
- It drops a significant user interface element in the post editor that indicates to the author that something other than basic text, anchors, or images exists
The only thing is that there’s still a bit of a gap between what the user sees in the editor and what they see on the homepage, and despite the improvements in WordPress 3.5, some people still have a hard time grokking it.
Another option that I’ve seen implemented (and that I’ve actually done in client work) is to introduce a new button in the TinyMCE toolbar that introduces a prompt or dialog for users to use an interface to select what they want to display or where they want to position something.
This, like the gallery functionality, dynamically builds the shortcodes then inserts it into the post.
I still see this as a bit of a half-baked solution. No, users aren’t having to write any shortcodes, but they are having to see it – or a placeholder – in the post editor that is still preventing them from seeing what their visitors will see.
Go Full-On WYSIWYG
This seems like the most obvious option, right?
For example, with Single Post Message I only give users the option to display the message above the post content or below the post content.
The truth is, I could give users the ability to place it anywhere within the post content that they like; however, I also believe that there’s something to be said about constraints, but I digress (that’s content for a whole other post).
So if I were to do that, I would need to provide an element that allowed users to edit the content of the message, place it in the content where they like, and make sure it displays exactly as it would on the front end.
With text, it’s not too bad, but something as complex as a gallery? It’s a bit more of a challenge.
First, we’re limited by the functionality of the TinyMCE editor. Secondly, we have to ask if it even makes sense that users should be able to interact with a gallery in their post editor. Perhaps there’s more middle ground of showing a shot of what they gallery would look like rather than a large blue box.
Even then, there’s the challenge with third-party add-ons. Take, for instance, JetPack – if you end up displaying a slideshow, a carousel, or a mosaic, then you’ve got to handle those cases in the post editor, as well.
As such, this results in an entirely new set of features developers must introduce when building their shortcode-enabled plugins.
But this raises the question: how “interactive” should something like galleries be within the post editor?
Should they work exactly like galleries do on the front end or should they be more-or-less a static screenshot?
If it’s the former, then you move into territory of completely managing galleries inline. If it’s the latter, you’re still leaving a gap of what the end user will see from what the editor is working on.
Where Do We Go From Here?
Obviously, I’m leaving this open ended – although I’ve tried to layout a few scenarios, I obviously don’t have a clear answer.
I imagine that if I did, I wouldn’t be the first come up with one. The fact is, if it were that simple, it would already be part of core.
But that doesn’t mean I don’t spend time thinking about it, and I don’t think developers should stop thinking about it, either. There’s clearly a need to improve the experience, but how we go about doing it is obviously up for debate.
There’s also the issue of whether or not we sacrifice our own philosophical stances on shortcodes if we opt to introduce them into our work despite our misgivings, but I’ll talk more about that later.