One of the biggest problems with writing and maintaining themes and/or plugins in WordPress is the frustration that comes with having to track down JavaScript errors.

Pippin Williamson has discussed this extensively on his blog, we’ve covered it on WP Daily, and I’ve talked about this once before here.

But since I’ve seen this issue crop up several times since, I wanted to offer some additional thoughts on this particular topic that has stemmed from the recent discussions.

What Are WordPress jQuery Errors?

Simply put, I think it’s safe to define jQuery to any problems that arise when using a theme that are a result of something going at the JavaScript level.

Nine times out of 10, a plugin or theme will stop working because of a cryptic error message with jQuery.

If you’re a developer, it’s not that big of a deal to understand what’s going wrong, but from a user’s perspective, WordPress is broken. It could be the theme, it could be a plugin, but it doesn’t matter – they can’t get their work done because an error is blocking the rest of the functionality from happening.

On Dequeuing jQuery

Enough as been said about dequeueing jQuery, and I’ve even offered my two cents on WP Daily about the whole issue:

If we – as developers – are truly going to begin viewing WordPress as a foundation for application development, then we need to make sure we’re treating it as just that.

Removing core features from the foundation is not the way to go about following through on that perspective.

You take the tools that WordPress provides and then build your product. Regardless of how simple it truly is, removing core features of the foundation in replacement of your own is like a “mini-forking” of the codebase.

Don’t do that unless you’re ready to accept the backlash for breaking compatibility. Unfortunately, plugin and theme authors catch the flak for someone else’s action in doing this.

This is just a thought, but what if WordPress was to prevent developers from dequeuing certain libraries like jQuery to prevent this from happening?

Luckily, there is a ticket in trac that’s coming to mitigate exactly this. Anyway, I stand by this and that’s all I want to say about it in this particular post.

On Enqueuing jQuery

If it’s not clear from my comment above, I firmly believe in using nothing but the version of jQuery supplied with WordPress.

From there, there’s absolutely no reason a developer should ever need to use the noConflict method or get a reference to jQuery by their own variables (such as my$ = jQuery).

Instead, you can use the following boilerplate:

Essentially, this provides a properly loaded version of jQuery that uses the standard $ function reference to allow us to continue going about our work.

Note that the "use strict" statement provides the following:

Strict Mode is a new feature in ECMAScript 5 that allows you to place a program, or a function, in a “strict” operating context. This strict context prevents certain actions from being taken and throws more exceptions.

More info on that here.

And the actual document.ready function is optional, as well. Instead, you may wish to use $(window).load of whatever other functions of your choosing.

But the point is that there’s a proper way to handle jQuery in WordPress:

  • Use the version that ships with WordPress
  • Gain access to the $ function using proper JavaScript facilities

I’d argue anything else is wrong.