- using protocol-relative URLS with WordPress >= 3.5
- use WordPress provided
is_ssl rather than custom check (only for
WordPress < 3.5)
- Detect if 'jquery' is a meta-script registration, and actual jQuery
is loaded as 'jquery-core' tag (WordPress 3.6 Beta).
wp_remote_head to query that the replacement URL is actually
hosted by google. If it's not, then the WordPress supplied version will be
- Using the Transient API to store the replacement URLS, rather than
recalculating and re-querying them every load.
- Added check for WordPress including non-standard versions of scripts (fixes
- Fixed incorrect case in HTTPS check.
- Reworked handling for cases where multiple js files are combined
into one on Google's servers. In the past this has been mostly a
non-issue because the dependencies took care of it, but due to changes
in the latest jQuery UI this stopped working as expected.
- Updated jQuery UI to work with WordPress 3.1rc1
- Re-disable script concatenation. Seemed to break widget admin page.
- No longer disable script concatenation when using WordPress 3.0 or
- Attempt to detect when another plugin or theme has called
'wp_register_script' and/or 'wp_enque_script' before 'init' and work
- Limited debugging output when WP_DEBUG is enabled.
- Hopefully fix issue with plugin loading for some users
- Added Incompatible Plugins and Incompatible Themes sections
to the README
- more https detection
- inline jQuery.noConflict()
- fix previous fix (whoops!)
- moved location of the Changelog section in the README
- Disables script concatenation in WordPress 2.8, since it seems to have
issues when some of the dependencies are outside of the concatenation.
- Persists flag to load scripts in the footer in WordPress 2.8
Implemented a pair of
from Peter Wilson.
- It should detect when a page is loaded over https and load the libraries over https accordingly
- It no longer drops the micro version number from the url. The reasons for this are twofold:
- It ensures the version requested is the version received.
- Google's servers set the expires header for 12 months for these
urls, as opposed to 1 hour. This allows clients to cache the file
for up to a year without needing to retrieve it again from Google's
servers. If the version requested by your WordPress install
changes, so will the URL so there's no worry that you'll keep
loading an old version.