During this years’ State of the Word address, WordPress founder Matt Mullenweg discussed a challenge he had given himself: write a blog post a day for 30 days. While some bloggers, such as the ever-popular Chris Lema can write a post a day with relative ease, I’ve always found it much more difficult to come up with quality content. As such, I’ve decided to take Matt’s challenge and put effort into writing a post a day for a month… who knows, maybe it’ll cure me of my perpetual writers’ block, and I’ll be able to write on a more consistent basis going forward. Kicking off my little challenge, I’ve decided to write my first post on the plethora of things I run into on a day-to-day basis as a WordPress developer that really get under my skin. So, what grinds my gears?

Ok, not jQuery itself; rather when people forcibly remove the default version of jQuery that comes bundled with WordPress and enqueue their version. For those who may not have run into this phenomenon before, it generally looks something like this:

This falls into the category of things that have been talked about before, and yet I routinely see developers doing this. Why?

There are a few reasons I’ve seen regarding precisely why developers seem to enjoy tormenting their users with this little snippet. Probably the most common and most frustrating reason is “the bundled version breaks my plugin.” Guess what; the bundled version is there for a reason! If your plugin requires an outdated version of jQuery, your plugin is most likely in need of an update!

But why is replacing the bundled jQuery version so wrong? First of all, WordPress loads jQuery in noConflict mode. Simply put, noConflict mode ensures that jQuery and the other JavaScript libraries loaded by WordPress don’t conflict. Natively, jQuery doesn’t do this, and conflicts will happen! For a much more detailed post on why overriding the native jQuery library is a bad idea, I highly recommend reading this post by Pippin Williamson.

Short tags actually do seem like a good idea, after all, fewer keystrokes are generally more efficient, right? Wrong. Well, maybe. Use of PHP short tags on a server without the short_open_tag option set to true is a very efficient way to horribly break your site.

You see, for a while, use of the <? tag was the standard in the PHP world. Unfortunately, this short tag suffers from one major drawback: they conflict with standard XML headers. This conflict has resulted in the addition of an option to the PHP configuration file which must be set to true for short tags to work.

As you can see, even the PHP documentation suggests that the use of short tags might be dangerous. But how can it cause problems when the default value of short_open_tag is ‘On’? Because while your development environment may use the default PHP configuration, the chances are that the hosted environments in use by your users won’t. Most hosts disable short tags given the inherent issues they present, which could very easily lead to sites trying to utilize them breaking in all sorts of fun ways!

Localizing a WordPress plugin or theme is pretty straightforward. Ok, the localization itself isn’t straightforward unless you’re bilingual, but prepping a WordPress plugin or theme for localization is dead simple. You see, in their infinite wisdom, the WordPress team has included some simple functions to facilitate localization!

I’ll admit that there have been a few plugins I’ve released which are not 100% translatable, but those precious few are the result of hard-coded data being returned by a third-party API. Ever since I discovered localization, every one of my plugins is built with localization in mind. So how do you localize your code? For starters, stop by the official Plugin Developer Handbook. It’s an outstanding reference.

That said, I’m going to nitpick one specific bad habit regarding localization; localization of JavaScript strings. Obviously (I hope), the WordPress functions used for translating strings are… well… PHP. And PHP can’t run from JavaScript. So how do you translate the strings in a .js file? Actually, that’s pretty simple too, though it might take you a while to stumble across the reference on your own. Let’s assume we’re working with the following jQuery script:

This one-liner finds an item on the current page with the ID “mydiv” and appends the string “Hi there!” to it. For this example, let’s assume that this script is in the file “/assets/js/myscripts.js”. Loading that file in your plugin or theme will look something like this:

Localizing the script requires the use of the wp_localize_script function, and looks something like this:

But what does all that mean? The wp_localize_script function takes three arguments; the handle of the script you want to translate (in this case, ‘myscripts’), the name of a JavaScript variable to assign the translated strings, and an array of localized strings to pass to the JavaScript. Once you’ve taken care of that little hurdle, implementing the localized code in your JavaScript is just as simple:

Tada!

The last quirk I’m going to cover is a twofer. As creative as developers can be, they all to frequently fail regarding naming. The following function names are all from actual WordPress plugins and are prime examples of naming fails. I’m not, however, going to identify the plugins these examples are taken from publicly.

Every single one of these functions suffers from at least one major problem if not two. First off, not one of these is truly unique. If you came up with the function name fetch_new_posts, it’s a safe bet someone else has too. Second, several of them are uniquely difficult to understand. I mean, what does a function called form do? Presumably, display a form of some sort? How about get_dip? Was the plugin developer hungry when he wrote this? Or was he alternating between the plugin and a shopping list and transposed a line?

Let’s pretend for a moment that the function add_me came from a Facebook plugin (it didn’t). In context it actually makes sense, but it could still conflict, and it’s still a bit vague. What if we renamed it to myplugin_add_me_on_facebook()? What are the chances that such a specific function already exists? Probably not too high!

Well, that’s all I’m going to mention for the moment. I’m sure I’ve missed some major ones, and I know that there’s a dozen more on my mental checklist that I don’t feel like writing up right now. But that doesn’t mean I don’t want feedback! So to all the developers out there: leave me a note and tell me what grinds your gears!