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 responses to “WooCommerce 7.2.1 Rollback”

  1. DanielSpain Avatar
    DanielSpain

    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

    1. 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.

  2. DanielSpain Avatar
    DanielSpain

    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…

    1. The rollback is not a requirement. You will safely be able to update from 7.2.1 to 7.2.2.

  3. 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

    1. 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.

  4. Thank you for ruining Christmas… a hardcoded database prefix… seriously?!

    1. 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.

      1. Thank you, I appreciate your comment and I apologise for mine. I was having a seriously bad day and servers crashing due to multi-gigabyte log files and database tables was just the icing on the cake.

Leave a Reply

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