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?

jQuery

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:

function load_my_scripts() {
    wp_deregister_script( 'jquery' );
    wp_enqueue_script( 'jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js', false, '1.11.1' );
}
add_action( 'wp_enqueue_scripts', 'load_my_scripts' );

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.

PHP Short Tags

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.

; This directive determines whether or not PHP will recognize code between
; <? and ?> tags as PHP source which should be processed as such. It's been
; recommended for several years that you not use the short tag "short cut" and
; instead to use the full <?php and ?> tag combination. With the wide-spread use
; of XML and use of these tags by other languages, the server can become easily
; confused and end up parsing the wrong code in the wrong context. But because
; this short cut has been a feature for such a long time, it's currently still
; supported for backwards compatibility, but we recommend you don't use them.
; Default Value: On
; Development Value: Off
; Production Value: Off
; http://php.net/short-open-tag
short_open_tag=Off

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!

Improperly or Partially Localized Code

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:

jQuery("#mydiv").append("Hi there!");

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 “<plugin directory>/assets/js/myscripts.js”. Loading that file in your plugin or theme will look something like this:

function load_my_scripts() {
    wp_enqueue_script( 'myscripts', 'assets/js/myscripts.js', false, '1.0.0' );
}
add_action( 'wp_enqueue_scripts', 'load_my_scripts' );

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

function load_my_scripts() {
    wp_enqueue_script( 'myscripts', 'assets/js/myscripts.js', false, '1.0.0' );
    wp_localize_script( 'myscripts', 'myvars', array(
        'greeting' => __( 'Hi there!', 'myplugin' );
    }
}
add_action( 'wp_enqueue_scripts', 'load_my_scripts' );

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:

jQuery("#mydiv").append(myvars.greeting);

Tada!

Poor Function Naming

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.

function caption_off() {}

function fetch_new_posts() {}

function get_dip() {}

function get_out_now() {}

function add_me() {}

function form() {}

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!

In Closing

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!

Show Full Content
Previous After Action Report: WordCamp Tampa 2014
Next After Action Report: WordCamp San Francisco 2014

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Newsletter


I don't like spam either.
Your email address is secure.

Featured Posts

Close
Close