David

I’m also dealing with this same problem where we’re interested in using this plugin, but since I can’t disable cookies until cookie consent is given (custom integration), I can’t use this plugin.

I tried the filter you’ve found ‘woocommerce_ga_disable_tracking’ and still had cookies loaded. It may be that the ecommerce tracking is no longer tracked, but the cookies are still loaded.

I also saw a load_opt_out() static function in class-wc-abstract-google-analytics-js.php and tried that code as well. But three cookies are still loaded without consent.

If you have a dev/staging version of the site, you could modify the code to declare HPOS compatibility. It should be safe since this plugin shouldn’t rely on order tables.

Get the code from here:
https://github.com/woocommerce/woocommerce/wiki/High-Performance-Order-Storage-Upgrade-Recipe-Book#declaring-extension-incompatibility

Here’s a code snippet you could add to your functions.php or create a plugin with the following:

You’ll need to see which UPS methods you use to find the IDs.

// Hat tip: https://gist.github.com/xadapter/c91282b9e1df7623085745fd9008bf1c
add_filter( ‘woocommerce_package_rates’, function( $shipping_costs) {
$shipping_method_min_cost = array(
// Shipping id => min_cost
‘ups:1:03’ => 11,
‘ups:1:12’ => 11,
‘ups:1:02’ => 11,
‘ups:1:13’ => 11,
‘ups:1:1’ => 11,
);

foreach( $shipping_costs as $shipping_cost ) {
$shipping_method_id = $shipping_cost->get_id();
if( isset($shipping_method_min_cost[$shipping_method_id]) ) {
$cost = (float) $shipping_cost->get_cost();
if( $cost < $shipping_method_min_cost[$shipping_method_id] ) {
$shipping_cost->set_cost($shipping_method_min_cost[$shipping_method_id]);
}
}
}
return $shipping_costs;
});

Thanks Austin! I appreciate the time you took for your answer. I ended up modifying the account download page to look at WooCommerce downloads and my own customer user meta. The output is a blend of both.

It is a change that happened in 4.0, but it only affected my development environment. I have a plugin that just adds a filter to prevent the secure_logged_in_cookie from being used, defaulting back to the non-secure one.

Again, the issue only existed on my development environment, so I wasn’t concerned about security.

function disable_secure_logged_in_cookie() {
	return FALSE;
}
add_filter( 'secure_logged_in_cookie', 'disable_secure_logged_in_cookie' );

The other solution you could do is create mod_rewrite rules to move all signed-in users to browse via https since the ssl overhead isn’t too bad. However, the problem is if the visitor closes their browser and comes back to your site via HTTP, then they see your site as no longer “signed in.” You could then also create a separate plugin to check on initial visit to check for a secure cookie’s existence while HTTP.

@peteratomic I had a similar problem prior, but I ignored it because going to the admin was sufficient.

@jeff I go to a custom login page behind HTTPS, and after logging in, I often go back to HTTP, but it is always the same domain.