tatutre

You should be able to fix it yourself by changing the %a to %s on the line 170 before the plugin author publishes the fix.

This notice could be related to the issue.

Uncaught TypeError: jQuery(…).select2 is not a function
at HTMLDocument.<anonymous> (parcelmachine.js?ver=5.3.2:13)
at HTMLDocument.dispatch (jquery.js?ver=1.12.4-wp:3)
at HTMLDocument.r.handle (jquery.js?ver=1.12.4-wp:3)
at Object.trigger (jquery.js?ver=1.12.4-wp:3)
at Object.a.event.trigger (jquery-migrate.min.js?ver=1.4.1:2)
at HTMLBodyElement.<anonymous> (jquery.js?ver=1.12.4-wp:3)
at Function.each (jquery.js?ver=1.12.4-wp:2)
at a.fn.init.each (jquery.js?ver=1.12.4-wp:2)
at a.fn.init.trigger (jquery.js?ver=1.12.4-wp:3)
at Object.success (checkout.min.js?ver=4.0.0:1)

I have the pull request in review process here https://github.com/woocommerce/woocommerce/pull/23687

I managed to create one possible solution to this issue by customizing the Woocommerce Session Handler. This is the customized version https://filebin.ca/4gsuHExl28R4/class-wc-session-handler.php

It now stores the original guest session key to variable in the init_session_cookie phase and this variable is used to destroy the guest sessions once the new logged in user based session is created to wp_woocommerce_sessions table by the save_data function.

What do you think? Is this viable solution? Based on my testing the guest user session gets deleted fine and the customer’s cart gets passed to the logged in session. Only thing is that after logging out the cart is empty. However, in our use case this doesn’t matter.

How to make this solution permanent so that it doesn’t get overridden when Woocommerce gets updated? Should I get this accepted to the Woocommerce core? Or would it be better if you could extend the WC_Session_Handler class and override the default behaviour?

Yes, definitely interesting issue. I’m not totally sure when this issue has started to occur. Currently running WC 3.6.2 and v3.08 of your plugin. It could very well be that this issue started with the new WC as based on this https://github.com/woocommerce/woocommerce/issues/8504 there was introduced new things related to the session handling.

It would nice if you can look into this as all our products have single quantities and this issue confuses a lot of customers who start shopping in guest role and then login during checkout process.

Thanks again!

Seems like the dompdf 0.8.3 is released now. Is this going to be included in your plugin sometime soon to improve the PHP 7.3 compatibility?

We are seeing the same problem after this latest plugin update to version 2.1.6. It seems that after the update there are some issues caused by this Mailchimp for Woocommerce plugin. The issues we are seeing is that trying to save any settings for themes or other plugins is not working and also changing plugins active/inactive doesn’t work in the backend. Also trying to use any CLI commands gives the error Shane mentioned: Error: Callable “Queue_Command” does not exist, and cannot be registered as wp queue

Only way to deactivate the Mailchimp plugin was changing the name of that plugins folder. After deactivating this plugin everything started working again. WordPress doesn’t seem to allow reactivate the Mailchimp plugin (I did change the plugin’s folder name back to original). If trying to activate it from the backend it doesn’t stay enabled and trying the activation from CLI gives the previously mentioned “Queue_Command” error.

I wonder if these errors are somehow related to the options autoload feature introduced in this version of the plugin. But clearly this should be fixed. Until then I think I’ll revert back to the previous version or just keep the plugin disabled.

Great, the filter addition would be perfect. I’ll watch the github issue you opened to see when this is ready.

Great job James!

I installed the github version. We have currently ~50 simultaneous visitors, 6 active carts. The original version of the plugin results about 8 seconds page load time for archive pages, the github version has 4s load time (so the new version effectively halved the loading time) and by using the selective load must use plugin I wrote the archive pages load in about 2 seconds. Product pages had about 1.577s load time before the github version and those average now 1.063s.

I think I will keep the selective plugin loader active for now as seems to give best results. We also have the object Redis object cache enabled, so we’ll see adjusting it in combination with the github version of the plugin could improve the results even more.

I used a few tutorials to build a mu-plugin that selectively disables the cart stock reducer on archive pages and some other pages. Mostly the cart stock reducer is now enabled only on product pages, cart and checkout. I’ve disabled the add to cart buttons on archive pages so the products can only be added to the cart through product page.

So far I haven’t seen any negative side effects. And now the page loads 5-6 seconds faster on product archive pages. However it would be nice if the performance could be improved without having to use this method. I wonder how the this feature is done in Prestashop because I’ve been told that there you have option to decide whether the stock is reserved/reduced at time of adding the product to cart or when order is done.

The mu-plugin code:

<?php

$request_uri = parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH );
 
$is_admin = strpos( $request_uri, '/wp-admin/' );

// add filter in front pages only
if( false === $is_admin ){
	add_filter( 'option_active_plugins', 'selective_plugin_disabler' );
}

/**
 * Filters active plugins
 *
 * @param array   $plugins An array of active plugins.
 */
function selective_plugin_disabler( $plugins ){
	
	$plugins_not_needed = array();
	
	// selectively disabled plugins
	$current_url   = 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'] . '';

	if ( strstr( $current_url, '/categories/' ) ) {
		$plugins_not_needed = array('woocommerce-cart-stock-reducer/woocommerce-cart-stock-reducer.php');
	} else if ( strstr( $current_url, '/blog/' ) ) {
		$plugins_not_needed = array('woocommerce-cart-stock-reducer/woocommerce-cart-stock-reducer.php');
	} else if ( ($_SERVER['REQUEST_URI'] == '/')) {
		$plugins_not_needed = array('woocommerce-cart-stock-reducer/woocommerce-cart-stock-reducer.php');
	}
	
	
	foreach ( $plugins_not_needed as $plugin ) {
	$key = array_search( $plugin, $plugins );
	if ( false !== $key ) {
	unset( $plugins[ $key ] );
	}
	}

	return $plugins;
}

But anyway, just like Chris said. Keep up the good work. Hopefully you can come up with ways to improve the performance. I’m happy to help with testing.

• This reply was modified 7 years, 1 month ago by tatutre. Reason: removed reference to unnecessary other plugin

Would there be any harm if the plugin was selectively disabled on product archive pages and have it only load in product pages, shopping cart and checkout? And if it doesn’t cause any harm how could this be achieved? Is there some hookable filter that could be used to disable the plugin in the archive page? I’ve been looking for some tutorials on how to selectively disable plugins and/or plugin filters through code but haven’t tried them yet.

Anyway the difference between having the plugin active/deactivated is quite big as you can see below. Hopefully this could be solved without us stopping the use of this plugin.

Plugin ‘woocommerce-cart-stock-reducer’ deactivated.
Success: Deactivated 1 of 1 plugins.
for i in {1..5} ; do curl -so /dev/null -w ” %{time_total}\n” -H “Pragma: no-cache” [product archive url]; sleep 1 ; done
2.154
1.719
1.722
1.729
1.832
Plugin ‘woocommerce-cart-stock-reducer’ activated.
Success: Activated 1 of 1 plugins.
for i in {1..5} ; do curl -so /dev/null -w ” %{time_total}\n” -H “Pragma: no-cache” [product archive url]; sleep 1 ; done
7.308
7.436
7.654
7.272
7.508

Excellent, that would be great. Thanks James!

The Webgrind profiling done by our hosting company indicated the line 998 in the class-woocommerce-cart-stock-reducer.php file as a cause for the slow page loading. They recommended that a good solution would be to perhaps implement some kind of a transient get/set feature for that part of the code. Maybe so that one could set the time for the transient caching in the plugin options.

And it also seems that disabling the plugin helps the archive pages load a lot quicker. With the individual product pages the load speed is good also with the plugin enabled.

oh, and this also:
[07-May-2017 15:45:00 UTC] PHP Notice: Undefined index: tag in /data/wordpress/htdocs/wp-content/plugins/ninja-forms/includes/Abstracts/MergeTags.php on line 45

Hi,

Is this really fixed? Because the error seems to still persist on v.1.6.1.

For example in the plugin file woocommerce.php lines 34-36:

$product_id = $product->get_id();

			$_product_cats = get_the_terms( $product->id, 'product_cat' );

So shouldn’t the line 36 be:

$_product_cats = get_the_terms( $product_id, 'product_cat' );