Addressing Concerns and Commitment to Improvement – WooCommerce 8.5 Release

On Jan 9, 2024 we released WooCommerce 8.5.0. Quickly thereafter, we began receiving reports about issues, which brought into question the quality control for this release. 

We want to acknowledge and address the challenges and concerns raised by the community following the release of 8.5.0, and subsequently 8.5.1. The feedback is invaluable to us, and we appreciate your candid insights.

The 8.5.0 release introduced breaking changes that affected our users. While we swiftly addressed the initial issues with the release of 8.5.1 on January 15th, subsequent reports have brought to light a myriad of problems that have understandably caused frustration and concerns among members of the WooCommerce community, from merchants to developers. 

What happened?

8.5 produces a fatal error on upgrade:

On December 20th, 2023, a PR was merged which meant to activate the new Marketplace react-based UI by default, removing the option to disable it manually. Unfortunately, the PR caused a fatal error when the Marketplace feature flag was enabled. Despite being merged in time for the 8.5 code freeze, the release was scheduled for January 9th, with a skipped release on December 26th due to the holiday.

The issue was present in the Beta cut, and Kathy Darling, a frequent contributor, caught the issue and submitted a PR, which was reviewed and approved by the engineering teams, but was never merged, in part because of some persistent build related issues. A separate PR was created when working on the 8.5.1 fix release. 

Ultimately, the issue was overlooked, and the 8.5.0 version was released with the affected code present.

The default web application firewall (WAF) rules on some hosting providers were not compatible with 8.5, causing some stores to unexpectedly become inaccessible [1, 2]. This resulted in a number of WooCommerce stores running on certain hosts that have rules in their Web Application Firewall to experience 403s when the sbjs_first cookie is set by Sourcebuster as part of the Order Attribution feature.

We received issues [1, 2] alerting us to this problem on GitHub. 

Compliance issues 

We were alerted that members of our EU community may have become non-compliant as a result of Order Attribution tracking being enabled by default. 

With the release of 8.5.1, many new scripts were added to sites with WooCommerce, causing understandable concerns around performance and possible errors from the community. 

What we plan to do about it

During the aftermath of this issue, we have identified different points where we could have mitigated some of these issues, as well as steps we are taking to course correct. 

8.5 produces a fatal error on upgrade

  • Testing of the initial PR had room for improvement. Although we have an existing PR review process, which includes rigorous testing, we will be reinforcing the need for better testing. 
  • We will be more rigorous in writing and enforcing clear testing instructions in PRs, including explicit directions for new features or changes.
  • We plan to strengthen our communication channels for issue triage, with a focus on timely and broad communication so that when issues like this one are present, we can make the appropriate call as to how to proceed with a release. 
  • A more robust automated notification system may have alerted us to this error earlier on in our release process, which is why we are exploring the implementation of such a system to help us catch these issues sooner. 
  • We are working to reach out to some of the WAF ruleset providers like Comodo and OWASP to have all Sourcebuster cookies allowed.
  • Modify our forked Sourcebuster library to use values that don’t cause issues. Simply changing the delimiter from ||| to || no longer matches the WAF rule, for example.

Compliance issues 

As a globally used product, we are committed to ensuring the best possible experience we can for all of our users.

As a result, we will be adding the question of whether each release is GDPR-compliant to our release checklist. 

We have created an issue and are working on a fix to remove unnecessary bloat from the platform. 

We will implement monitoring of asset payload size and impacts on performance both during development and as a part of our release process.  

Thank you

We want to iterate our gratitude in the time the community has spent surfacing and even investigating some of these issues. We are committed to having open communication with the community and being increasingly responsive during situations like this one. So we appreciate your candor and feedback, as a way to help us improve our processes and ultimately this platform. 


10 responses to “Addressing Concerns and Commitment to Improvement – WooCommerce 8.5 Release”

  1. Adam Beecher Avatar
    Adam Beecher

    This is what happens when you focus on features *you* want, not features that your users want. The same could be said of WordPress and the editor debacle. I’m not sure anyone in Automattic gives a flying toss about users any more.

  2. Regarding the Sourcebuster cookies, I am appalled and question the ethics of Automatic at enabling these cookies without getting the permission of website owners and webmasters. The only way I discovered they were even on is because WAF rule 218500 blocked my site along with thousands of other sites hosted at WPMUDev. From the type of 403 page I knew immediately that it was WPMUDev’s WAF that was blocking my site so I disabled WPMUDev’s WAF so my site would function.

    Fortunately I run my site behind Cloudflare’s WAF and they did not block those cookies. And I also have WordFence running on my site too. So I wasn’t unprotected. Still, it was a shock to install a new version of WooCommerce and suddenly see 403 errors pop up on my site.

    This made me do some digging around with WooCommerce settings and I discovered that by disabling the new Order Attribution feature I was able to stop WooCommerce from creating these offending cookies.

    What galls me is that Automatic seems to have turned the Sourcebuster cookies on because it wanted the data from those cookies. It certainly didn’t bother telling webmasters what it was doing behind their back or how to use the data. Fortunately I do have “Allow usage of WooCommerce to be tracked” turned off or this information would have flowed to Automatic. Why Automatic needs this information escapes me, but it makes me wonder if Automatic isn’t selling the data it collects from WooCommerce sites when “Allow usage of WooCommerce to be tracked” is turned on. When you look at all the data that flows to Automatic when “Allow usage of WooCommerce to be tracked” is on, it is mind blowing. Why does Automatic need all this data? How much revenue are they generating from it?

    The programmers and managers at Automatic need to take some ethics courses and learn that not all our data or our customers’ data belongs to them. Some ethics courses on privacy and boundaries is required. Just because we use WooCommerce does not mean that you own our websites or have any business deciding what data we collect from our customers. Just because you can do something does not mean you should.

    WooCommerce emphasizes how the data is anonymized, but you don’t need a lot of anonymized data points to figure out who someone is.

    What Automatic/WooCommerce is in danger of doing is losing the trust of its users. If you want your business to succeed, you need your customers to trust you. Don’t ever forget that.

    1. Automattic lost my trust a long time ago. They define success now by constant profit increases, just like every other company that hits scale. They don’t believe in comfortable living, they all want to be Musk, completely oblivious to his journey towards Bond Villian idiocy. They still have time to turn it around, but I can’t see it happening. It’s time to look for alternatives; has been for a while.

    2. Hi Daniel, thank you for commenting, feedback like this from passionate merchants and developers gives us insight into the impact changes and new features have.

      As mentioned above, we have reached out to several WAF ruleset providers to ask them to update their rules to avoid the false positives, and have already begun to see some changes released.

      As for Order Attribution, it should be an entry-level feature for any ecommerce platform, giving merchants a better understanding of their traffic sources and helping inform decisions based on where their money is actually coming from. The Sourcebuster cookies are a core part of this new feature, used to determine visitors’ provenance and include it with any eventual order for the merchant’s reference directly in the WooCommerce dashboard. Based on feedback like yours, we are also currently looking into alternatives with fewer cookies or other strategies for capturing this information and making it available to merchants. Also, for full transparency moving forward, we will include any changes which might affect GDPR compliance in the release notes.

      Finally: we understand your data privacy concerns. Sharing basic data about WooCommerce usage ensures that more helpful features are developed, better documentation is written, and WooCommerce becomes a better platform. But, unlike with other closed ecosystems, WooCommerce users have complete ownership and control of their data, and sharing usage or any data with WooCommerce is fully optional. The settings to opt out are easy to find and configure if any merchant is concerned about it: https://woocommerce.com/usage-tracking/#how-to-stop-sharing-data

  3. I’m missing a big issue in this list and all of the support agents on the forum seem to refuse to see the bigger issue and repeatedly try to solve the topics as unrelated incidents without recognizing the problem. On some websites there’s an old setting or data, that causes a server to completely overload after an update to 8.5.x. The sites can even be rather small on a hosting package with more than enough resources and other WC sites on the same server are running without any issues.
    This issue is being tracked on https://github.com/woocommerce/woocommerce/issues/44093 after many support topics were created and stayed unsolved on the forum.
    But we’re already waiting for 2 weeks for an update from WooCommerce developers.

    1. Hi Jos, I’m following the issue on GitHub, and it looks like WC developers have been replying in the past hours.

      From the context of this issue, it seems like it would be related to the Blocks related bloat that we mentioned in this blog post, but I understand your comment in the issue around not being sure if the work being done to solve that will solve the issue you are facing. For the time being, I’ll monitor the ticket, which is being looked at by internal engineers.

      1. It’s not normal “bloat” that makes all sites a bit slower. There’s some kind of endless loop loading 1000x more CSS files over and over again and numerous database processes on a quiet website. This is compared to other sites on the same server that have no (severe) issues with WC 8.5.x
        So this is not an issue related to performance issues, but to totally blowing up a server caused by an overload.
        I don’t see any updates regarding the status of the investigation yet or any recognition of the issue. It’s not related to hosting, theme, plugins etc. It must be an old setting or data, that causes this overload. Sofar support people have only mentioned they couldn’t reproduce it, which of course is very logical if it’s site specific caused by an old setting or certain data.

    2. This has been affecting my store for a while now, and thank god I was not the only one. My performance tanked and I started getting CPU spikes so high it crashed my website so many times in the last few weeks.

      We tried everything, got in touch with the host provider, Woo Support (didn’t even bother to reply us), theme devs, no one had any clue for why the CPU and resources spiked. Now I have confirmation that this was indeed a WooCommerce issue.

      At least we know it may be fixed tomorrow, but I’ll update and see if something changes for the better.

  4. More and more of our clients are abandoning WooCommerce and heading to Shopify – they tell us Woo is slow, complicated to admin and has too many issues, too often. They accept they will lose some flexibility with Shopify, and the costs can mount – but this is more than offset by gaining much more practical functionality and being able to get a nice-looking, highly functional store up and selling quickly. It’s difficult to argue against this perception.

    1. Adam Beecher Avatar
      Adam Beecher

      I’m having the same problem. My 3rd biggest customer has been hovering over an exit for a couple of years now, and their patience is running very, very thin. I use InfiniteWP to manage updates on my client’s site, but I have to keep theirs separate to avoid catastrophes caused by the likes of the appalling recent releases. And, more generally, the performance issues and potential for problems created by the current plugin / theme system are making debugging incredibly difficult.

      As I said earlier, Woo is clearly focused very heavily on generating revenue for the last couple of years, and it’s to the detriment of the software. I don’t know if that’s being induced by shareholders or simple greed, but it’s destroying the platform ALL of that revenue hangs off. If they don’t refocus back to quality soon, it’ll be the end of WooCommerce.

      And of course the same goes for WordPress itself. The block editor debacle in particular, and the ridiculous amount of attention that goes into it to the detriment of everything else, is infuriating. If they had just done the sensible thing first day and acquired the likes of Elementor, we wouldn’t be where we are today.

      Your namesake, Matt Mullenweg, carries the ultimate responsibility for all of this. Matt, you should be ashamed of what you’re allowing to happen to WordPress and WooCommerce.

Leave a Reply

Your email address will not be published. Required fields are marked *