Please test Use Google Libraries 1.5b1

I just installed 1.5b1 at a WordPress 3.4RC1 test site that has 25,000 complex test pages and a wide assortment of other plugins installed. It seemed to function correctly until I optimized JavaScript code with YUI Compression using a customized version of the Autoptimize plugin, which caused web pages to no longer load. Of course, that doesn’t necessarily indicate anything is wrong with 1.5b1, but merely that there is an incompatibility with that combination.

I haven’t done any debugging yet to learn why that happens. I will do some troubleshooting and let you know what I find.

There are two compatibility issues using 1.5b1 with JavaScript compression (also called minification or minimization) plugins.

1) Autoptimize and various similar plugins not only compress JavaScript code, but also concatenate multiple JS files into single files to reduce the number of HTTP requests. The new method in 1.5b1 of querying Google’s servers and automatically obtaining files from Google as they become available invalidates those pre-compressed and concatenated JS files, which cascades to invalidating compressed HTML files (because JS file names change), and further cascades to invalidating files cached by caching plugins such as WP Super Cache. The server workload to re-create the invalidated files is enormous where a website has a large number of posts or pages.

2) 1.5b1 causes individual JavaScript files to be concatenated in an incorrect sequence, so JS dependencies are broken and web pages do not display correctly even after all those files have been re-created.

I haven’t had any problem using 1.5b1 with WP3.4RC1 without JS compression, but I think its use at sites employing JS compression and caching will cause problems. Of course, cached files also had to be re-created in the past whenever users updated to a new plugin version, but that could be timed to occur during periods of low activity. Furthermore, the previous design didn’t break dependencies in concatenated JS files.

Thanks for the feedback. I don’t think the issues you describe are 1.5 related. UGL is incompatible with concatenation, which is why it turns off the WordPress concatenation when enabled. Did that combo of plugins work with 3.3/1.2?

The querying doesn’t happen often and won’t cause constant change. Either Google has it or it doesn’t. The only change is between those two states, and would happen one time, since once they are there they stay there.

Yes, the same combination of plugins work fine with 3.3/1.2. I can easily modify 1.2 for compatibility with 3.4 if you decide to continue with the new method.

Autoptimize doesn’t use WordPress concatenation to merge sections of JS code together. That is done in its autoptimizeScripts.php file where individual JS code components can be selectively flagged to be moved, to not be moved, or to be moved last.

It is true that querying Google won’t cause constant change. Most UGL users won’t notice the difference, but on a site with more than 25,000 complex pages, like one of mine, cache rebuilding takes more than 30 minutes on a dedicated server. The site remains usable, but page load times increase from less than a second to many seconds during periods of high activity with many HTTP requests per second. It is best to do that as rarely as possible and to do it at times of low activity.

(I am referring above to the live site. I have been testing at an offline test site that except for having the beta version of UGL and WP 3.4RC1 is identical to the online site.)

I’m missing something.

The code to query Google would only run when a page is rebuilt, if it’s been 12 hours since the last time Google was queried (for any page on the site). That result of the query is cached for your entire site by UGL.

What are you using for caching? I would think that only when doing a cache rebuild would UGL even do the queries (and they are http HEAD queries, so they should be pretty darn fast). When you are rebuilding your cache, it should only run the queries once per URL (although with concurrent hits I suppose it’s likely to run a handful of times).

I am using wp-super-cache. My concern is not the time required to query. It is that if a query finds that a library file has become available at Google every cached page that uses that file will be automatically invalidated and rebuilt whether or not it happens to be a good time for that to occur.

I don’t think that will happen. The query won’t fire when the cached page is served. It won’t query until the cache is rebuilt for a given page.

Thanks Jason, I’m testing this against 3.4 nightly builds, currently RC2-21026

I had a problem with the Upload/Insert Add Media function on the post edit screen. Determined it was the Use Google Libraries plug-in, swapped in 1.5b.1, and it’s now working. FYI!

Since WordPress 3.4 is out, and Google apparently isn’t going to host jQuery UI 1.8.20 (although they are hosting 1.8.21 already), I’m going to tag this.

Sorry, I should have mentioned I was using 3.4…!

No problem, I figured you were. Don’t forget to vote that the WP-3.4/UGL-1.5 combo works on the plugin page!

How would I get 1.5b1?

The issue: WP 3.4, multisite: 5 sites in the network, using the same theme (a customized child of WooThemes Headlines, framework at the latest version): we are unable to add or change tags, or see what tags are in use in the admin screens when the plugin is activated. Other sites on the network are fine; a site where this theme is activated after the upgrade to 3.4, works fine.

so, I’m thinking there is some sort of caching issue. Not on my installation, because I had to turn off my caching plugin for other reasons.

Jason put a link right at the top of this post ??

Duh! (Dope slap to self) — thanks. Not sure how I missed it.
…

And it seems to have resolved the problem.