[theme-reviewers] Fwd: Theme Lab - Shortcode

Sun Jul 14 00:42:12 UTC 2013

Hi guys,

I know that you don't like people passing on junk but I just got this in my
inbox and I feel that it hit the nail on the head about including
shortcodes in themes.

Enjoy :)

---------- Forwarded message ----------
From: Theme Lab <leland at themelab.com>
Date: Sun, Jul 14, 2013 at 10:18 AM
Subject: Theme Lab
To:

**
   Theme Lab <http://www.themelab.com>   [image: Link to Theme Lab]
<http://www.themelab.com>
------------------------------

Shortcodes Should Never Be Included With Themes.
Period.<http://www.themelab.com/2013/07/13/put-shortcodes-in-a-plugin/>

Posted: 13 Jul 2013 12:28 PM PDT

ThemeForest recently<http://notes.envato.com/news/announcement-wordpress-theme-submission-requirements/>updated
their WordPress
theme submission
requirements<http://support.envato.com/index.php?/Knowledgebase/Article/View/472/85/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<http://codex.wordpress.org/Theme_Review>,
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<http://justintadlock.com/archives/2011/05/02/dealing-with-shortcode-madness>.
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].

Big Green Button <#13fda8ae8947dbb9_>

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<https://codex.wordpress.org/Writing_a_Plugin>instead.

It could even be bundled with something like TGM Plugin
Activation<http://tgmpluginactivation.com/>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<http://codex.wordpress.org/Function_Reference/wp_enqueue_style>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<http://wpmu.org/themeforest-developer-guidelines/#comment-143884>
:

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<https://twitter.com/themelab/statuses/354662109273001984>

 *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.