Categories
Developer Advisory WooCommerce Core

WooCommerce 7.2.1 Rollback

Developer Advisory:

For the sake of transparency, here is a detailed account of why 7.2.1 was rolled back and necessitated a 7.2.2 fix release:

The details

  • The WooCommerce 7.1.0 release updated the states for New Zealand to the CLDR standard. This introduced a bug as the database records did not get updated.
  • WooCommerce 7.2.1 fixed the issue with the New Zealand states by creating a database migration helper to convert the NZ states to the new standard. Additionally, it included the state update and migration for Ukraine.
  • The fix implemented in 7.2.1 inadvertently included a hard-coded table prefix for the migration. For sites with custom database prefixes (anything other than wp_), the update routine caused error messages to be logged which subsequently rescheduled the routine, filling the debug logs rapidly.
  • After realizing the severity of the issue, we began the work to release 7.2.2 and rolled back the 7.2.1 release entirely.

How can I tell if this affects me?

You will be able to quickly see if you are experiencing an issue by checking your log files. The bug produces the following error message: WordPress database error Unknown column ‘wp_postmeta.post_id’ in ‘where clause’ for query...

What action should I take?

Regardless of impact, if you are currently using WooCommerce 7.2.1, it is recommended that you roll back to version 7.2.0 until we have a fix available in 7.2.2.

WooCommerce 7.2.2 is now available.

10 replies on “WooCommerce 7.2.1 Rollback”

Thx for the info. My site wasn’t afffected by this issue(no errors in log, and new orders with no problems). Can i simply wait for the fix or is it dangerous to wait for 7.2.2? The 7.2.2 fix will make a database change? Thx

Like

The 7.2.2 release is coming quite soon. If you are not seeing any problems and there is nothing in the logs you are fine to wait for 7.2.2. The primary issue stems from sites using custom table prefixes so I am assuming your site is using the standard wp_ and thusly unaffected.

Like

Ok, yes… i don’t use custom prefixes in the db. I’m only asking in case i can’t rollback(and the update to 7.2.1 with the db change was successful in my case, no errors, no log messages), and i don’t know if the rollback is a prerequisite to update to the future 7.2.2 or the team is aware that are a lot of sites that updated with no problems and simple wait to 7.2.2 is easier if they check they’re fine…

Like

A better solution would be to re-release 7.2.0 as 7.2.2 so that everyone gets rolled back and release what was supposed to be 7.2.2 as 7.2.3

Like

An interesting idea. I do understand the logic behind this as it would be easier for people to identify the new update via the admin and choose that option versus manually having to roll everything back to a previous release. And had we not been so close with the 7.2.2 release (which just now has become available) we may have entertained this idea.

Like

Our teams work very hard to prevent such things from happening, but we’re human and some things slip through. Our aim is to be able to react quickly if/when things happen, notify the community, and resolve the issue as quickly as possible. On the other side, we make sure we learn from our mistakes and put in the necessary measures to not only prevent the same bug from escaping us, but determine how we can be better as a team in order to deliver a quality product to developers.

I hope we didn’t put too much of a damper on your holiday spirit.

Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.