Version 3.0 upgrade warning (user modifications)

OK. My fault. I should have looked more closely at your update notes. I only looked at the first couple of notes and thought this was a small fix update. I didn’t read the 3.0 version notes.

Sorry for the rant.

Man, you need to put some clearer warnings about this type of change on the Upgrade notice in WordPress. I upgraded the plugin this morning and discovered it broke any user account with multiple addresses.

I am in the process of restoring from my backup, which is always a high-risk activity and royal pain. Plus, I will lose all of my morning work.

If you know your plugin can break things, make that very clear in the update notice!

• This reply was modified 1 year, 3 months ago by warrisr.
• This reply was modified 1 year, 3 months ago by warrisr.

@warrisr thanks for the clarification in your edit. Did you have any modifications on your site or find any errors of what was broken?

It is fair that while the note was bolded in the changelog we would have liked to make it more prominent. Since we’ve seen that a small percentage of sites are having issues with the new update we have decided to roll back the update to keep the 2.x version of the latest version and released a minor version to that which will include a more pomeninent note on the update page warning of the 3.x update when we push that back out later. If you are already on 3.x you should NOT downgrade to 2.x without rolling back your database as the migrated data will not downgrade. It is perfectly fine to keep running 3.x if you are in the majority where the upgrade went smoothly.

By doing this, we hope to work with those who have had issues to try and troubleshoot the issues with the upgrade so we can work to make improvements to better safely upgrade everyone we we re-introduce 3.x

is there any other strategy to roll back the plugin without database rollback as we have other activities like active woocommerce orders, ticketing data on the website which we dont want to risk loosing

The change did some serious breakage. Not only to the address book page in My Account, but it also did some weird things to the user account.

For example, while I was still unaware that the address book was causing problems, I was running some checkout tests. At some point, the email address of the account I was using for testing was actually removed from the account. I am not sure how that is even possible, but as a result, there were other problems. I finally traced all the issues back to the address plugin.

I decided the best approach would be to restore the entire site from my pre-plugin update backup. I did lose the morning’s work, but all is back to normal now.

Lesson learned. Read those changelog notes more carefully including all the previous versions.

We lost thousands of addresses when it upgraded. Might I suggest a process in cases like this, that doesn’t delete the old rows? It should be an option that allows you to remove those once you confirm your addresses have converted. In my case, on all three sites, it attempted to convert the addresses, but it failed – but it deleted all the old rows in the usermeta table. Thankfully I have just-in-time backups.

@nmanikon We have pushed out 2.6.2 which will allow you to roll back to the 2.x version. It will downgrade addresses from the 3.0 format back to the 2.0 format on demand if it finds any in that format allowing you to roll back. If any addresses were lost, then it will not recover them, but it will allow you to keep using the 2.x version of the plugin safely. The usermeta records for any user could be restored manually.

@warrisr I am curious to learn more about what went wrong so we can attempt to fix this. The more information we can get to try and reproduce the issue the easier it will be to solve. You can send us any information you have to [email protected] if you’d like to keep it off the forum.

@dwdonline We built it so the upgrade happens on demand per user account. So, it will only upgrade records as they are accessed for that one user. This was instead of a bulk upgrader that would have to run through addresses for every user. Doing a bulk upgrade on sites with hundreds of thousands or millions of users would require building it as a background job to do it on all of them. So, with this way, if the account is never accessed again, the data is left alone. I’d still like to learn what failed in the upgrade so we can improve it going forward. Each record should only be ever deleted once it was successfully saved in the new format (we are working on next building a verify step to make sure the saved record matches the old record before deleting it)

We went with the automatic delete on save otherwise there could be potentially millions of unused meta records leftover that would be hard to identify to purge. I suppose in retrospect, it could store a flag of which ones could be deleted and then prompt in the admin to delete them.. but with the on-demand upgrade as it works there would be new addressees upgraded every time an existing user comes back and makes a new purchase.

@matt-h-1 I appreciate the response. Thankfully, I had made a partial and complete backup of the sites before the change, so we only had a handful that couldn’t be recovered. In our case, we did modify the plugin to allow us to restrict custom-by-customer ability to add addresses, and for us to approve addresses before they are allowed to use them to checkout. So, I’m figuring that had a bearing on it the issues we faced. The upgrade created entries in the new format, but for some reason just made them mostly blank (would transfer one line). I’m going to do some further testing and will reach out with my results.