Not stable. Requires constant fixing and troubleshooting.

Which plugins are you having issues with? It’s been out long enough, I would have thought even the slow to update ones would have taken care of things by now.

> Oh – and if you have a test environment, you’ll need to purchase all extensions twice. We have a subdomain setup for our WooCommerce test environment and since 3.1 we can no longer have update it – because our production environment has the “active” subscription.

You don’t need a licence for the plugin to “work”. You can copy the updated plugins to your staging/dev site manually without auto-updates.

Hi Mike,

Thank you for your reply. Michael helped me with the test/production environment. For now, we will:

1.) Deactivate licenses for our production environment
2.) Activate licenses for our test environment
3.) Update and test in our test environment
4.) Deactivate licenses for our test environment
5.) Activate licenses for our production environment
6.) Update extensions in production and validate

We have had many problems with extensions. The difficulty is that we don’t want to ignore PHP errors and notices in logs because we don’t know what impacts they have.

Here are a few examples. We report them right away, and they seem to have been fixed, but it’s an ongoing thing. We are constantly finding these and reporting them.

[07-Jun-2017 16:31:19 UTC] PHP Notice: Array to string conversion in /web/sites/###/shop/wp-content/plugins/woocommerce-cart-reports/admin/cart_index_interface.php on line 318

[16-Jun-2017 20:38:11 UTC] PHP Fatal error: Uncaught Error: Call to a member function getOffsetTimestamp() on null in /web/sites/###/shop/wp-content/plugins/woocommerce/includes/data-stores/abstract-wc-order-data-store-cpt.php:124

[05-Jun-2017 03:09:46 UTC] The WC_Coupon::exclude_sale_items function is deprecated since version 3.0. Replace with WC_Coupon::get_exclude_sale_items.

[Mon May 08 20:20:48.088386 2017] [:error] [pid 2152] [client ##.##.##.##:49270] billing_email was called incorrectly. Order properties should not be accessed directly. Backtrace: require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’), do_action(‘template_redirect’), WP_Hook->do_action, WP_Hook->apply_filters, WC_AJAX::do_wc_ajax, do_action(‘wc_ajax_checkout’), WP_Hook->do_action, WP_Hook->apply_filters, WC_AJAX::checkout, WC_Checkout->process_checkout, do_action(‘woocommerce_checkout_order_processed’), WP_Hook->do_action, WP_Hook->apply_filters, WC_Mailchimp_Integration->send_order_data, WC_Mailchimp_API->subscribe_to_list, WC_Abstract_Legacy_Order->__get, wc_doing_it_wrong. This message was added in version 3.0., referer: https://www.###.com/shop/checkout/

[Wed May 03 18:19:01.260933 2017] [:error] [pid 26380] [client ##.##.##.##:59446] WC_Checkout->posted was called incorrectly. Use $_POST directly. Backtrace: require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’), do_action(‘template_redirect’), WP_Hook->do_action, WP_Hook->apply_filters, WC_AJAX::do_wc_ajax, do_action(‘wc_ajax_checkout’), WP_Hook->do_action, WP_Hook->apply_filters, WC_AJAX::checkout, WC_Checkout->process_checkout, WC_Checkout->create_order, WC_Order->save, WC_Data_Store->create, WC_Order_Data_Store_CPT->create, do_action(‘woocommerce_new_order’), WP_Hook->do_action, WP_Hook->apply_filters, AV8_Cart_Reports->save_order_id, AV8_Cart_Receipt->save_order_id, WC_Checkout->__get, wc_doing_it_wrong. This message was added in version 3.0.0., referer: https://www.site.com/shop/checkout/

WooCommerce used to be pretty low maintenance, but since 3.0 it has gotten much heavier to maintain – and more expensive and time-consuming for us.

3.0 was a major release, and with major releases comes deprecation: https://github.com/woocommerce/woocommerce/wiki/Deprecation-in-core

woocommerce-cart-reports looks guilty here. Are you on 1.1.17? If yes, I’ll chase up with the developer.

Hi Mike,

Thanks for the reply – again. No need to follow-up. I create tickets for each of these, sometimes WooCommerce support acknowledges the bug, sometimes support tries to blame something. Eventually, we get it figured out.

And yea, we understand the 3.0 was a big change, it doesn’t change the fact that WooCommerce has become much more onerous and time-consuming for us to maintain as a business. Other businesses may not have had the same experience, but it’s important to share our experience pros and cons with the community.

More issues. More issues.

It would be really great if we could get a premium support option – so we can get these issues resolved quickly. Also, I’m extremely worried that issues cause data problems or problems with payment processor status synchronization (e.g. PayPal has a subscription active but WooCommerce shows it canceled).

Don’t get me wrong, I’m still a big fan (not that it matters), but we want to provide our customers with a good experience. We also don’t want to frustrate our team, who needs to wait for me to get tech issues resolved (via WooCommerce tickets).

It looks like WooCommerce Order Status Control, WooCommerce Google Analytics Pro, Woocommerce Subscriptions, WooCommerce Social Login, and Woocommerce Memberships use WC_Order_Item_Meta which seems to be the cause of 8+ entries in our server log. Ticket created (#601100), but its… another ticket to track and follow-up on.

Then we seem to have customers who are getting billed for subscriptions that are set to canceled in WooCommerce. Another ticket created (#598822), replies/updates on the ticket are slow, while I’m sweating about more customers being impacted.

If I can help somehow, please let me know.

Deprecation warnings are not something to be too worried about, as I stated above. WC_Order_Item_Meta has been deprecated since 3.0 but does not break if used. More recent updates of those extensions remove usage.

Hi Mike,

The problem with PHP notices in logs is that they will eventually turn into problems. Once we know who “owns” the notice and will resolve it, it isn’t as big of a deal. Our first priority is always to figure out who will fix it.

The other problem with the PHP notices is that they clutter up the logs. We don’t want any errors in our error logs for any sort of time.

Hope that helps explain our problems with the PHP notices.

K

Of course, but we add them to the log for good reason. Deprecations are simply warnings “this will be removed at some point and needs changing”. Extension devs will resolve these. It’s much better to log things than fail silently.

With WC 3.2 we’re adding built in ‘fatal error’ logging so you won’t need to log all the warnings/notices if you don’t want to.