My Short Rant Regarding Shortcodes

I just gave the post ‘Shortcodes Should Never be Included With Themes. Period.’ by Leland Fiegel at ThemeLab a read (as should you) – and I started thinking about prior and active projects, and how I’ve been using shortcodes. Within the wide variety of use-cases – surely there was something in that array of projects that necessitated the use of shortcodes in a theme.

I found that, in almost every case, I kept shortcodes in a plugin. I prefer, through learning best-practice from developers more experienced than I, isolating specific bits of functionality from themes whenever possible, especially when working with a bloaty marketplace theme.

A responsible, modular, future-proof structure.

However – in a note by Brian Krogsgard on the awesome new, Brian said “…I think Leland’s broad brush statement is a bit dangerous” – and it got me thinking in the opposing direction: Is there a valid use-case for using theme shortcodes?

Yep, absolutely. Informed usage. The user of the theme just needs to know. That’s really all that needs to be done. “Hey, look, before you install this theme, know that every time you use a shortcode that’s bundled with it, you’re creating future development work, should you choose to ever switch themes. This is something you’ll have to pay a developer to do.”

Here’s something I’d like to see when a customer buys a theme that contains many shortcodes:


There are also countless use-cases when looking at WordPress as an extensible CMS or application framework; projects may be so highly customized that the typical structure of a theme, as well as whether or not shortcodes are a part of that theme are entirely irrelevant.

Many times, in cases such as those, the theme is the site.

I’m of the belief that it comes down to marketplace development standards vs. custom development environments.

A Race To The Bottom

If you’re selling a theme over and over in a marketplace, I get it. It’s a race to the bottom. The uninformed theme-buyer sees two similar themes: one has 21,000 included shortcodes, and another has 25,000 included shortcodes.

Which do they buy? They buy the biggest, bloatiest thing available – because all they see is that it looks nice, and has more options.

In a sense, they’re getting duped.

So authors keep bundling more and more crap into their themes. Theme developers keep one-upping each other with ‘features’ to ridiculous proportions. And why not? You’re not compromising the customers’ server, encrypting your code, or anything else considered over-the-top evil. The client is happy. The marketplace is happy.

So what if the large majority of WordPress developers detest working with your themes?

It’s a question, then, of ethics, and coding standards. Again, why do you care? You’re not obligated to do anything beyond meeting the marketplace requirements. And you’re not committing a crime, to be sure.

I’m getting snarky. My bad. Here’s why:

There’s a catch. That model will bottom out.

Sure, you might’ve purchased your first house (or second house) with bloaty-theme blood money, but one day, things will change. You’ll alienate more and more colleagues. Customers that want to change their theme will ask for support. Some will be less than polite to you or your support staff.

Folks will squint their eyes at you in anger at WordCamps. You’ll start seeing comments in your themes that’ve been modified by others, like:

// Alright, the stuff below I've commented out and pushed to a plugin with an exists check to the theme, due to poor coding standards in (your_theme_name_here).

A New Hope

Things are already slowly heading in that direction.

A month or two ago, I made a small site called WP Bloat (site link) (related article on this blog) (related article on WP Daily). Notice a familiar name on the showcase page? Japh, WP Evangelist at Envato.

If you’re a developer of one of these nightmarish, million-dollar themes, c’mon. Be a sport. Take some of that blood-money, and maybe even outsource the theme-clean-up! You can do it. Leave a legacy you’ll be proud of.

I’ll close with a snapshot of what the shortcode tab looks like in the bundle of themes I’m currently working on:*

Screen Shot 2013-07-13 at 11.54.17 PM

*They’re all GPL; no marketplace hanky-panky for me đŸ™‚

Disclaimer: It was a particularly long day of cleaning up shortcode madness. Forgive my candor. Also: this little alert box is a shortcode, but it's a plugin. An admittedly dumb, tiny plugin - but at least it'll keep on ticking when I re-design this site. If you'd like the plugin, you can grab it <a href=''>here</a>, but it's little more than wp_register_style and some some images. OR IS IT THE GREATEST PLUGIN EVER?

WordPress 10th Anniversary Blogging Project

Dougal Campbell wrote a great post a few days ago. If you haven’t already, I recommend giving it a read – especially if you build things with WordPress.

It’s been ten years since WordPress was released, and although I’ve only been creating with it for half that time, it’s been an amazing ride so far.

My introduction to WordPress wasn’t as a development environment – it was as a way to blog. I started in this industry with freelance, static html website design. Incidentally, I also started a WordPress blog in October 2007. I’d been using a different platform before then, but many points of frustration lead me on a search that ended with WordPress.

Following that, I continued freelancing for a few more years, philosophically-powered by the principle that I’d never sell out to an agency, and never hire other people. I wanted to be my own boss, work my own schedule, and choose my clients. I was a magical internet man! Surely I could do whatever I wanted, forever, and make millions of dollars.

And it worked…for a while. I gained a local reputation for being very transparent, pleasant, and fast.

During my time freelancing, I was lucky to build a few hundred sites with WordPress. I saw the light and dark side of it – from the few-but-evil sketchy backdoor freemium plugins, and themes with encoded spam links in footers, to a plugin developer who lived half a world way, sacrificing his night helping me with code until I got my sites back up.

As things progressed, I found myself more frequently on the other side of those email threads, helping clients and other WordPress developers and designers until everyone was happy. I’d do maybe 3 or 4 cheap sites per month. I didn’t make a lot of money. But I loved the life, and I was helping people.

Then came:

The Great Drought of 2010

Things started to dry up. So I’d do pro-bono projects and consultations for non-profits, and a bit of networking here and there. It helped a bit, but I ultimately chose to re-think my ideals. Why am I against working for an agency? Is it all agencies I dislike working for? Eventually I figured out I just dislike feeling like I don’t matter. Big ad agencies, working my days away on snippets of anonymous code. Endless stacks of project managers and marketing heads above you.

I decided it’d be ok, as long as I didn’t work for an ad agency.

I applied to a few firms and was lucky to get a few offers, which lead me to one of my current jobs, at ArtComp, as lead dev.

What about the next ten years of WordPress?

WordPress may be entirely different by then. It may indeed be forked, as many are currently talking about. But not by me. There are two things I can count on – WordPress will always be GPL, and will always have a great community behind it. Most recently, I’ve become active on with some projects; and as intimidating as it can be to talk to your nerdy heroes in IRC, or have a core developer submit a pull request to my sub-standard code, it’s great.

WordPress Codex Adopt-A-Page Badge: Simple widget that shows a badge and links to your Codex page

Here is a plugin that shows a WordPress Codex Adopt-A-Page- badge in any widgetized area you choose. Just specify your Codex Username.

The plugin may change in appearance or function, or may be merged with another plugin, depending on if/how the docs community uses the plugin.

Download / fork on Github

Here’s a screenshot of the widget in its’ current state:


The two greatest WordPress plugins that every website NEEDS (not really)

I know what you’re thinking. Maybe Gravity Forms and Yoast SEO, right? Advanced Custom Fields? Possibly Something by the prolific Pippin Williamson? Wrong. Here are the two greatest WordPress plugins ever made, that every internets WordPress online SEO blog needs for reals:

1. Bloaty McShortcode Nightmare: Extra Plus Pro Edition

Comes with over 12,000 shortcodes! Some shortcodes even generate WordPress multisite installations, re-write .htaccess rules, and even add special extra spaces at the end of wp-admin/admin-footer.php!

Shortcode images use only one CSS spritesheet, for enhanced performance. That’s right! Only one 12mb .png.


2. Captain Conflict’s Ultimate SEO Slider 2: Pro Edition

Easily add your favorite images to a custom slider on any page. Comes with over 90,000 javascript and flash animations, so you have infinite possibilities! If you like this plugin, please consider donating! I have placed convenient download links in admin-footer, the dashboard, the plugin header, the admin bar, and the permalinks page. This image slider requires jQuery versions 0.9 through 1.8 for added compatibility. Here’s how we work the magic:

/js/jQuery.0.9.min.js" type="text/javascript">

'; }
add_action('wp_head', 'common_function_name');

On a serious note, here are some very well-written posts on the topics I’m referring to:

Assembling vs. Coding: My Purgatory

I begin this short rant by making something clear: I’m quite grateful that not only do I have a steady stream of great clients, but that they’re very vocal in recommending my services, and I haven’t had to advertise. Ever. This is, ultimately, a luxury problem to some, but is an important – perhaps even spiritual dissonance for me.

Say you’re a WordPress developer. If you’re reading this, chances are pretty high that you’re in some way experienced with WordPress. So let’s say you have this client. They say they need 8 complicated, conditional forms, the ability to accept and send query strings, and integration with…the Freshbooks API! Don’t even need a syntax editor for this one.

But how do you start?

Hand code every form, then abstract the static form structure into some type of accessible plugin UI in wp-admin? Hack it into Contact Form 7, essentially re-writing the entire plugin? Download the PHP API for Freshbooks from Google Code and brew a pot of coffee?


Fire up the sites’ dashboard, install Gravity Forms and get to work? Damn right.

As developer colleagues at my day job know all too well, I’m very strongly against willy-nilly installing WordPress plugins, for very good reasons. This isn’t about that, though. More clever folks than I have written on that topic to exhaustion.

I’m talking about assembling other people’s code. It’s time-consuming to audit someone else’s code, so whenever possible, I like to roll my own solution. However, end-users – site owners – when they grasp the power of the plugin repository, they go a little crazy, as you know, and then boom! You get the call; “I broke it, please help.”

So in that case, you’re dealing with bad code, and cleaning it up. But that’s a small part of it; there are many amazing plugins, of course.

But in the example of Gravity Forms, we all know it’s great. That team consistently builds new features, provides adequate deprecation notices, has documentation, backwards compat, etc. I know I don’t have to meticulously pick apart every update, check the solidity of every new hook – it’s all good. Install and build. I know that, at the very least, it’s going to work.

So now, say you get 30 or 40 of these projects in a row, of varying size and complexity. One is solved with Gravity Forms and a few custom functions. Another needed some WooCommerce single-product templates made. Maybe you had to throw create some shortcodes for a portfolio site.

Concerning development, what have we learned in these projects?


It’s the same thing, over and over. Sure, you’re communicative to the client, listen to them, and they’re happy.

Business-wise, things are fine.

They’re not aware of the deep, existential crisis that’s building within you as your career ages day after day, without you making contributions to any repos, or finishing that shortcode plugin you started last summer. And why would you? This is not a conversation to bring up to a client.

There’s no right way to say “Well, the practical thing to do is use [existing, cost-effective solution], but I’ve been bored at work lately, so I’d love to try out this [more expensive custom thing] instead.”

Lately, for the past 6 months or so, it’s been mostly that. Although every solution has involved a great theme framework, a great plugin, what I’m using them for is, essentially, fluff.

There’s little actual development that I’m doing.

So, what am I doing? I’m assembling.

Taking bits and pieces of code and putting them together, maybe customizing them a bit. It’s boring, and I learn nothing.

Many would count their blessings and move on, grateful for the ongoing work. But I’m faced with my own mortality in that regard:

Is this where my time is best spent?

Can I do this for another year? Two years? Five? Twenty?

If you’re not being challenged at your job, you will never grow. You will either slack off to work on cool stuff unrelated to your job – and eventually get in trouble (or lose business), or you’ll let it continue forever, deepening your embrace of the gray purgatory in which your mind now resides for every minute you’re at work.

Want to learn? Write code. Write it from scratch. Follow tutorials that really dig deep. Make mistakes, ask stupid questions. I do these things, especially the stupid questions, every day.

BOY do I ask some stupid questions.

As I steer the company toward a product-based source of revenue (instead of project-based), we still have to take these projects, and keep the money flowing in – so you have to give a little.

Always remember to learn. Or don’t; I’m not the boss of you.