Shortcodes Should Never Be Included With Themes. Period.
ThemeForest recently updated their WordPress theme submission requirements to be more stringent and more inline with WordPress theme development best practices.
The guidelines require the use several of WordPress’ core features, standard theme hooks, and disallow PHP functions (like base64 and fopen) that really shouldn’t have ever had any place in a WordPress theme to begin with.
Basically, pretty much WordPress.org’s Theme Review policy, give or take a few things.
Overall, it’s a step in the right direction and moves to promote best practices on one of the most popular WordPress theme marketplaces on the net. There’s just one problem…
Admissible Shortcodes
One thing that particularly caught my eye, however, was how certain “admissible” shortcode functionality was allowed (i.e. by directly including them through the theme’s functions.php file). The ones listed as “admissible” included the following:
- buttons
- pricing tables
- image containers
- dropcaps
- lists
Inadmissible shortcodes include: maps, accordions and toggles, boxed contents, column, contact forms, charts.
The Problem with Shortcodes in Themes
I can’t really put it better than Justin Tadlock already has. One of the most noticeable issues, is that when a user changes themes, the shortcodes will no longer be parsed.
Let’s say “Super Awesome” theme had a shortcode feature that would output a big green button with a link when you typed out something like [button url="http://example.com"]Big Green Button[/button].
When you switch to another theme (let’s face it, people get bored of themes easily), there’s no more big green button. Instead, you see the unparsed shortcode in the post as if it were any other piece of content, like this:
[button url=”http://example.com”]Big Green Button[/button]
It looks ugly, confusing, and out-of-place, and it’s a pain for the user to go back and remove/replace all of them.
The Other Problem with Shortcodes in Themes
Something that Tadlock went over in his “Dealing with shortcode madness” article is, a lot of shortcodes are so simple and HTML-like, it might even be best to instruct users to write out a little (*gasp*) real HTML code.
The same [button url="http://example.com"]Button Text[/button] shortcode in my example above could be easily rewritten as something like:
<a href="http://example.com" class="button">Button text here</a>
While there may not be CSS code styling the .button selector in a new theme, at least a normal link will show up. Which is a big improvement over an unparsed [button] shortcode showing up in a post’s content.
Plus, I believe every WordPress user should have at least some basic understanding of HTML code. By teaching them, even in little bits (like how to construct a link), will help. If they can understand a shortcode, it won’t take much more to get them to understand basic HTML.
But The Users Don’t Care!
A common argument I see defending all sorts of bad practices when it comes to theme development is that the users simply don’t care. I mean, maybe they never want to update their theme, in which case, this shortcode issue would be a moot point.
The problem is, some users inevitably will want to switch themes some day. Some users will want to install a plugin that might conflict with some other poorly-thought-out code in a theme.
Then, they probably will care, and probably will wonder if the theme they bought with 100s of built-in shortcodes and other superfluous features was really worth it.
The Right Way to Include Shortcodes
Put it in a plugin. A really simple plugin. It doesn’t need a separate options panel. Just literally copy and paste whatever you were going to include via your theme’s functions.php file, and put it in a plugin instead.
It could even be bundled with something like TGM Plugin Activation to make it required on theme activation. Or not. A theme is still a theme without shortcodes.
This way, if the user changes themes, the shortcodes will still work, because that functionality is handled by the plugin that is still active.
Maybe the plugin could also enqueue styles for the shortcodes as well. This way, the big green buttons you included with the [button] shortcode will still be big green buttons, regardless of the theme used.
Why Did ThemeForest Allow “Admissible” Shortcodes?
It’s hard to say what exactly the reasoning behind this decision was. Japh Thomson, a WordPress evangelist at Envato (ThemeForest’s parent company) had this to say about it in a comment on WPMU.org:
Complex shortcode functionality really should reside in a plugin, not a theme. It also just makes sense when you consider most of our authors have multiple themes.
Obviously, he gets it. So it’s a mystery to me why there would be any “admissible” shortcodes at all. And yes, I realize he used the word “complex” in the quote above, and the admissible shortcodes do tend to be pretty simple ones (dropcaps, lists, etc.).
Simple as a shortcode may be, the problems I outlined above will still exist. ThemeForest has shown to be responsive to community feedback, so it’s possible this rule is amended in the future.
Conclusion
I realize this post seems a bit nit-picky, and these new guidelines are definitely a huge step in the right direction. But there’s really no reason any shortcode should be allowed in a theme, simple or not.
Can you think of a situation when a publicly released theme absolutely needs to include shortcode functionality via its own functions.php?
— Theme Lab (@themelab) July 9, 2013
Spoiler alert: Didn’t get any responses to that tweet with a real example of a shortcode absolutely needing to be included in a publicly-released theme.
That’s because it’s just not user-friendly for a user to go back and replace hundreds of button shortcodes after they switched to a theme that doesn’t have the exact same shortcode support.
Related posts:
- Why WordPress Widgets Vanish When Migrating to New URL
- Want More Retweets? Use the Official Tweet Button
- Dear Theme Devs, Stop Pasting Random Snippets of Code in functions.php
Posted in Theme Labs
