Major Critical Errors with Woo 8.5.1. Why the lack of response?

I suspect what’s on the forum is only the tip of the iceberg, Personally, my phone has been blowing up all day with people desperate for help with their dead WooCommerce site.

Also, I want to add that there is a problem with woocommerce analytics. There are just blank pages. And in the error console ReactDOM.render is no longer supported in React 18. Use createRoot instead. Until you switch to the new API, your app will behave as if it’s running React 17.

just take a look at shopify (SHOP) stock prices in the following days ??

This update took my site down, thankfully I was able to restore the woocommerce plugin directory and get back up and running.

I could see how sites with automatic updates are tanking.. This update needs the plug pulled immediately!

I will NOT be enabling autoupdates (which I was about to do)

If your site has gone down, here’s some helpful information I was able to find.

Here’s a step-by-step guide:

1. Deactivate WooCommerce: If you can access your WordPress Admin, navigate to ‘Plugins’, find WooCommerce, and click ‘Deactivate’.
2. Delete the Current Version: After deactivation, click ‘Delete’ to remove the current version of WooCommerce. Don’t worry, your data is safe.
3. If you can’t access WordPress Admin: Access your WordPress files with FTP/SFTP/SSH/File Manager and remove the directory: /wp-content/plugins/woocommerce
4. Download WooCommerce 8.4.0: Click this download link from the WordPress repository to download WooCommerce 8.4.0 file to your computer.
5. Install the Downgraded Version: In your WordPress Admin, go to Plugins > Add New > Upload Plugin. Upload the file you just downloaded and activate the plugin.
6. Check Your Site: Ensure that everything is running smoothly and that no data was lost during the downgrade.

(In my situation I had to manually remove the woocommerce folder, I was able to restore a backup of the folder) My path was htdocs/site/wp-content/plugins/woocommerce

All my broken sites are on Plesk using ModSecurity.

WooCommerce versions 8.5.0 and 8.5.1 BOTH trigger ModSecurity to block access with error 403 forbidden.

I’ve resolved this by adding an exception for (switching off) security rule ID 218500. (This rule is: SQLmap attack detected)

This can be done at either server level in Tools & Settings or on a site by site basis under the Web Application Firewall link.

Hope that helps.

• This reply was modified 10 months, 1 week ago by Steve.

HI Steve @thewebsmiths,

That’s interesting, I just disabled Modsec to test on 8.51 and still got the error.

Adding the exception to my Plesk, kept the site alive after the update, but my menu links were gone, just 404’ing.

Rolled back again to further check it out.

I think the new tracking cookies (sbjs) implemented in V8.5.x are the cause for triggering modsec. This results in fail2ban jailing. These tracking method should not be implemented.

Same issue, happening, even if I set the firewall rules, the issue is still there, had to rollback all the sites.

https://developer.woo.com/2024/01/16/woocommerce-8-5-1-issues-with-web-application-firewalls-modsecurity/

Thanks @sureshramasamy

For those still having issues, try option 3 below, it’s a quick and easy setting to test:

What action should I take?

• Plesk already has a help article targeting this issue, identifying Comodo rule with ID 218500 being false-positively triggered when Woocommerce 8.5 is in use. They recommend disabling the rule following the steps on their page.
• Check with your host to see if ModSecurity is enabled. If that is the case, you may ask your host to adjust the firewall rules to allow the cookies set by Woo’s Order Attribution feature. You can find more information about the cookies used by this feature in our documentation.
• If the above doesn’t work for you, disable the Order Attribution feature to prevent future users from seeing the 403 errors by going to WooCommerce > Settings > Advanced > Features and toggling the Order Attribution feature off.

Half of the fatal errors people are seeing have nothing to do with these security settings. They have to do with Woo’s own Stripe plugin. Updating that will fix half of these issues. Although I’m not doubting the other half of the issues people are experiencing. 8.5+ is a mess.

Hi there @flowsheff, thank you for reaching out!

We are aware of the issues caused by the new update. We also have some of these issues addressed in our blog here: https://developer.woo.com/2024/01/16/woocommerce-8-5-1-issues-with-web-application-firewalls-modsecurity/.

For further solutions, please refer to these steps below:

• Plesk?already has a help article targeting this issue, identifying Comodo rule with?ID?218500?being false-positively triggered when WooCommerce 8.5 is in use. They recommend disabling the rule following the steps on their page.
• Check with your host to see if ModSecurity is enabled. If that is the case, you may ask your host to adjust the firewall rules to allow the cookies set by Woo’s Order Attribution feature. You can find more information about the cookies used by this feature in our documentation.
• If the above doesn’t work for you, disable the Order Attribution feature to prevent future users from seeing the 403 errors by going to?WooCommerce > Settings > Advanced > Features?and toggling the?Order Attribution?feature off.

I hope this helps.

(@ckadenge) The main point that woo continues to deflect, and the question on everyone’s mind is: why was 8.5.1 even released to begin with?

Look at all of the responses in the last 72 hours. It’s an absolute disaster filled with endless bugs and bloat. What happened to quality control?

Does woo have plans to get rid of all of the code bloat anytime soon?

@