I forgot my manners… please & thank you. 🙂
There’s a filter for that Patrick;
add_filter('autoptimize_filter_js_exclude','stripe_jsexclude',10,1);
function stripe_jsexclude($exclude) {
return $exclude.", Stripe.js";
}
Just at something similar to your plugin and all will be fine 🙂
frank
Hey Frank,
There’s close to 100 official payment gateways plus 700+ plugins tagged payment in the WordPress.org repo. Is there anyway to do this in such a way that we don’t have to write 700 pull requests? Is it possible to disable your plugin on the checkout page and let the user download all of the scripts individually?
that’s not a pull request, that’s a filter inside your own plugin 🙂
now if you want to exclude all JS that comes with your plugin, you can also do this (focussing on line 3 of the above code example);
return $exclude.", wp-content/plugins/pluginname/js";
or
return $exclude.", pluginname/js";
or
return $exclude.", pluginname/payment_gateways/";
lots of possibilities really 🙂
disabling AO on the checkout page can be done from within your plugin as well;
add_filter('autoptimize_filter_noptimize','checkout_noptimize',10,0);
function checkout_noptimize() {
if (strpos($_SERVER['REQUEST_URI'],'/checkout/')!==false) {
return true;
} else {
return false;
}
}
Let me know if you need more input!
kind regards (& have a nice weekend),
frank
Hey Frank,
I’m trying to say that we would have to update our ~100 gateways and the developers for the 700 other plugins on .org would also have to update. It’s problematic to make others develop around your plugin.
Is there someway to prevent it from working on specific pages? If so, we could update your plugin in one place and it could prevent issues on all of the affected plugins.
Does that make sense?
There are some conditional tags in WooCommerce which you could use to see if you’re on the checkout page. Ex.
@bftrick the WooCommerce checkout itself works fine with Autoptimize on it, in several installations I’ve used. Personally, as someone who actually uses this plugin, I’d prefer to keep it that way.
If you need a specific script omitted you can do that by adding it to the Autoptimize settings; no code changes required. I wrote this blog post a while ago, but it should still be mostly relevant:
https://snippets.webaware.com.au/howto/use-autoptimize-effectively/
You can also, from your plugin, add a data-noptimize attribute to your enqueued scripts to prevent them being swept up. See this SO topic for a quick how-to:
http://wordpress.stackexchange.com/a/38335/24260
Here’s some sample code (PHP5.3+):
add_filter( 'script_loader_tag', function ( $tag, $handle ) {
if ( 'your-script-handle' !== $handle )
return $tag;
return str_replace( ' src', ' data-noptimize="1" src', $tag );
}, 10, 2 );
cheers,
Ross
I (obviously) agree with @webawer on this topic
It’s problematic to make others develop around your plugin.
This is the way optimization works I’m afraid; if I would have to try to make AO work with all themes and plugins, I would have to cripple it until it’s almost useless. The settings-screen has 97% of what people need to fix any issue they might encounter (including e.g. excluding stripe.js) and the API covers everything else really. The FAQ (and these support forums) are the last piece of the puzzle, where a lot of info is available to help people optimize their stuff without breaking anything.
frank
@bftrick; fyi AO 2.1 (released last weekend) comes with new JS defaults (which apply to fresh installs):
* aggregated JS is not forced in head any more
* js/jquery/jquery.js is excluded
based on feedback here for example, these settings fix/ prevent stripe problems.
frank
Excluding jQuery is a good idea generally. It’s likely to be included on most pages on a website (if at all), so best to let it be loaded once and browser-cached separately to any other page-specific scripts. That leads to smaller page-specific scripts.
My old advice was to use the Use Google Libraries plugin to get jQuery from Google’s CDN, but that plugin isn’t kept up to date any more and sites with CloudFlare or other origin-pull CDN will work faster with jQuery pulled from the origin site anyway. Your change should be beneficial generally, not just in the circumstances described above.
cheers,
Ross
Your change should be beneficial generally, not just in the circumstances described above.
that’s the goal; have AO work on as many sites as possible without users having to configure things while limiting the performance sacrifices of those default settings (excluding jquery from optimization is a perf. sacrifice, but given the amount of times I had to tell people to do that I consider it worth it).
well @bftrick, in a typical case of advancing insights; the upcoming AO 2.2 will now have an option to enable/ disable optimization of cart/ checkout (currently for WooCommerce, EDD & WP eCommerce). if you want to test, the trunk version of AO on wordpress.org has those changes already 🙂
