Up until now Katie has been doing all the blogging and I thought it was about time I posted a few. What has spurred me on to write this article is the recent issues with a number of client sites that we manage through our maintenance package. We endeavour to keep in step with all WordPress updates which generally have not caused us too much grief.

Since version 2.3 WordPress has included a copy of jQuery. I see this as a very sensible approach as it should prompt plugin and theme developers to develop their front-end code using a specific version of jQuery. What should happen thereafter is that theme and plugin developers keep in step with subsequent WordPress updates to take advantage of changes to the WordPress core and also to be mindful of the fact that, from time to time, WordPress will release a newer version of jQuery with a WordPress update. For a list of jQuery versions versus WordPress take a look at jQuery version vs WordPress update.

Where this approach could potentially fall down is if a plugin/theme developer does not regularly update their front-end code to keep in step with the WordPress updates. This is often easier said than done, particularly if the front-end developer takes advantage (as they should) of a plethora of third party jQuery plugins.

I could go on but I hope by now you get the point. What have I done to fix this? In short I haven’t fixed anything what I have done is implemented a workaround until such time that the offending front-end code is fixed by the parent theme or plugin developer. As prompted by this post on the wordpress.org forum, I have rolled back the jQuery version, as it would appear others have, to the point where the WordPress site functions correctly. I stress again this is a workaround not the long-term solution for reasons I won’t go into.

The approach I took was simple and straightforward as others have pointed out. Within the child theme I added a new directory called js, into which I placed an earlier version of jQuery (jquery.js). Using the jQuery/WordPress version article previously mention, I systematically rolled back one version at a time until the point was reached that the site’s front-end functionality was fully restored.

To enable my jQuery version of choice, I deregistered the current jQuery version and then reregistered/enqueued the version that I had previously placed in the js directory. To achieve this I added the following code to the child theme’s functions.php file:

//Reverting jQuery to earlier version
if ( !is_admin() ) add_action( "wp_enqueue_scripts", "enqueue_older_jquery", 11 ); //Important don't use in admin area
function enqueue_older_jquery() {
    wp_deregister_script( 'jquery' );
    wp_register_script( 'jquery', get_stylesheet_directory_uri() . '/js/jquery.js' , false, false ); // re-registers jQuery
    wp_enqueue_script( 'jquery' ); // Enqueues the newly registered version of jQuery
}

It would appear that I’m not alone in having most of my jQuery compatibility problems with WordPress sites that have been developed using certain Themeforest themes (I found Brooklyn and Renova to be particularly problematic).

In summary these sorts of compatibility issues will always be around, myself and other developers will always endeavour to ensure that the code that we write follows the WordPress coding standards and that we try to, where possible, correctly use the jQuery version as supplied with WordPress.

On a final note, despite best endeavours “Murphy’s Law” will intervene when you least expect it, therefore it is always imperative that you have a good website backup regime. We have a saying in the office “always backup before you f@#$ up!“. At least then you can roll back to a version that works until such time that a fix is found.