Your WordPress site is constructed in a programming language called php and the php code, in turn, creates the HTML that is the main building block of all web sites. This code is being run on your server where it performs all of the actions necessary to create the HTML that is delivered to your site when a page is requested.
jQuery is a standard library that removes this problem and gives developers a single, unified syntax for all browsers. At the same time it add all sorts of graphic tools to make performing smart and interesting displays and Ajax tasks easer and more reliable. The jQuery UI library adds a consistent set of graphical ‘widgets’, like the popup dialog box, that save developers a lot of time and wasted code.
Simple:Press makes extensive use of jQuery and the jQuery UI so it is imperative that these libraries are loaded on your website and if they are not, Simple:Press loads them for you.
This is where it starts to get complicated but without diving too much into code-speak, another popular library that performs a similar task to jQuery is one called ProtoType. This too is used by many plugin authors. The problem comes in that both jQuery and ProtoType sadly share the same method of calling them from your code. So a basic call to the jQuery library may well be interpreted as a call to the ProtoType library and visa versa. This leads to disaster and chaos.
To overcome this, the jQuery developers make available what is called ‘no conflict’ mode that allows jQuery to be called in a more unique way. Because the WordPress development team understand that there are plugins available that use both libraries, WordPress officially provides jQuery in this special mode and all theme and plugin authors who wish to make use of it should write their code using this special method.
To overcome this, WordPress developed a clever method called ‘enqueuing’ which, if used properly and consistently by all themes and plugins, ensures that only the one instance of a library is ever loaded no matter how many plugins may want to use it. In other words, when everything sticks to the rules – everything gets what it needs without trampling everything else in the process.
This is a great solution for normal websites but not such a good idea for a website where the actual content and code being loaded is unknown – which is the case with a WordPress site where no plugin author has any knowledge of the other plugins the website owner may also be loading.
There are two main issues with this. The first is that when loading jQuery from the Google CDN, the developer has to select a specific version. As WordPress releases updates and supplies the most up to date version of JQuery and other jQuery support libraries, the version a plugin and theme is loading from the Google CDN can get easily and quickly out of date. Other plugins also wishing to use jQuery can start to break. Experience shows that a very large number of themes and plugins are not automatically updated by their authors with every new WordPress release and this can become a cause of serious conflict.
The second problem associated with sourcing these libraries from the Google CDN is that they are not compiled in the ‘no conflict’ mode. Many plugins – like Simple:Press – that do stick to the WordPress rules, can then fail to operate correctly as their jQuery calls result in errors.
In all fairness most theme and plugin authors who source jQuery libraries from the Google CDN do use the WordPress enqueue API. This at least forces just the single version to be loaded although we have seen many instances where this is not the case. We have seen as many as four versions loaded on a single site before now.
Maybe marginally. But we are talking milliseconds here. These libraries are already on your server. They are compressed and will also be cached by your users so even if there were a the saving it is only likely to be the first time a user accesses you site. There are many who argue – like we do – that in reality there is nothing tangible to be gained from using the Google CDN on a WordPress site.
Possibly but most probably not. And Simple:Press is not the only plugin that can have issues. Any plugin written to support the official WordPress API might and possibly will have issues.
Open up your website and load a page. A Simple:Press page is a good test. Somewhere in your browser menus will be a command to ‘View Source’. Load the source code. This is the HTML and script that is generated on your server and is the code behind the page you have just loaded.
Using the search function – which may be different all in all browsers – search for ‘jquery’ or just for ‘.js’. Then examine each entry.
If it is being loaded from WordPress the main library will have the file name of ‘jquery.js?ver=X.X.X‘ where the X’s refer to the version. For example – WordPress version 3.3.1 loads up ‘jquery.js?ver=1.7.1‘ for the main library and ‘jquery.ui.core.min.js?ver=1.8.16‘ for the UI library. You would normally see both entries as:
If – instead of ‘your-domain‘ they are coming from Google or instead of ‘wp-includes‘ they are coming from a different location on your server – such as a plugin – then there is possibly a potential problem.
Also check for duplicates. Search all the .js file being loaded. If you stumble upon more than one copy of the same library – even if it has a slightly different name (like ‘jquery.ui.core’ and ‘query-ui’ for example) then either your theme or plugin is also not using the WordPress enqueueing API to load scripts safely.
Initially we would strongly recommend that you contact the theme or plugin author and explain to them what is needed. If a paid-for theme – and experience shows that these can often be effected – then their support should be able to accommodate the request as it is not unreasonable and enables the plugin or theme to be more widely usable.