Autoptimize by default uses WordPress’ internal logic to determine if a URL should be HTTP or HTTPS. But in some cases WordPress may not be fully aware it is on HTTPS, or maybe you want part of your site HTTP and another part (cart & checkout?) in HTTPS. Protocol-relative URL’s to the rescue, except Autoptimize does not do those, right?
Well, not by default no. But the following code-snippet uses AO’s API to output protocol-relative URL’s (warning: not tested thoroughly in a production environment, but I’ll happy to assist in case of problems):
add_filter('autoptimize_filter_cache_getname','protocollesser'); add_filter('autoptimize_filter_base_replace_cdn','protocollesser'); function protocollesser($urlIn) { $urlOut=preg_replace('/https?:/i','',$urlIn); return $urlOut; }
So AO 2.1 will (finally) support protocol-relative CDN URL’s 🙂
Exactly, I would prefer same. Why not I’d go with relative method.
Just, one thing I’d to confirm from you. Are relative URL support on all devices including low end to high end popular browsers? I’m afraid because, I guess may be some bots generates 404, etc..
apparently this has been supported by almost all browsers even back in 2011. I wouldn’t care about bots in this context really 🙂
Thanks for confirming. Despite relative URL feature , with curiosity, I tested the above filter to see how it’s work on my blog. I’m shocked, that as I added the code in snippet plugin, completely my AO aggregated CSS & JS disappeared from source code. Any guess? What could be possible reason
a stupid error in the snippet; the variable on line 4 should be $urlOut instead of $urlout (corrected now)! sorry Gulshan! 🙂
Oh sorry, by mistake typed.
Final: After adding the new snippet – Now relative URL come automatically in both scheme. Great!
Good info, buy you should also make a setting for opimizing css that are server via .php files
for example
yarpp.css.php?settings=12&…
they are not optimized.. also for js
test.js.php
that indeed is a known and very deliberate limitation medgolova.