WordPress.org

Ready to get started?Download WordPress

Forums

Use Google Libraries
Please test Use Google Libraries 1.5b1 (16 posts)

  1. Jason Penney
    Member
    Plugin Author

    Posted 1 year ago #

    Hi,

    I've tagged version 1.5b1 so people testing 3.4 betas and release candidates can try it out. The big changes are:

    • queries Google's servers to see if google is hosting the script/version combo requested (this fixes the issue with 3.4 using a jQuery-UI not yet hosted by Google).
    • caches the replacement script registration data for up to 12 hours via the transients API, to avoid processing/querying on every load

    Please try it out and let me know if you encounter any issues. Please enable WP_DEBUG and check the debug.log when reporting errors.

    http://wordpress.org/extend/plugins/use-google-libraries/

  2. admintiger
    Member
    Posted 1 year ago #

    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.

  3. admintiger
    Member
    Posted 1 year ago #

    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.

  4. Jason Penney
    Member
    Plugin Author

    Posted 1 year ago #

    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.

  5. admintiger
    Member
    Posted 1 year ago #

    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.)

  6. Jason Penney
    Member
    Plugin Author

    Posted 1 year ago #

    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).

  7. admintiger
    Member
    Posted 1 year ago #

    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.

  8. Jason Penney
    Member
    Plugin Author

    Posted 1 year ago #

    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.

  9. Workshopshed
    Member
    Posted 1 year ago #

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

  10. Rand HOPPE
    Member
    Posted 1 year ago #

    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!

  11. Jason Penney
    Member
    Plugin Author

    Posted 1 year ago #

    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.

  12. Rand HOPPE
    Member
    Posted 1 year ago #

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

  13. Jason Penney
    Member
    Plugin Author

    Posted 1 year ago #

    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!

  14. nicollb
    Member
    Posted 1 year ago #

    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.

  15. Workshopshed
    Member
    Posted 1 year ago #

    Jason put a link right at the top of this post :)

  16. nicollb
    Member
    Posted 1 year ago #

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

    And it seems to have resolved the problem.

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic