1.7 update cleared all previous settings

Great news – 1.7.1 seems to do exactly what you say: it properly migrates widget options from the old format to the new format! ?? It even works properly with multiple instances of the widget.

Additionally, the use of the Widgets API lets it interact with more plugins, such as Conditional Widgets ( https://www.ads-software.com/plugins/conditional-widgets/ )

Also, all those warnings I’d been seeing are now gone ??

Please consider my earlier advice about WHEN to call the update function, but thank you very much for this great update ??

Hi
I just tried to update again this morning an lost all of my menu widgets on my Dev server.
Is it worth waiting for another update or should I go update and redo all my widgets?

Thanks in advance ??

k-d-taylor, you posted earlier that 1.7 cleared your settings. Once it’s cleared, it’s gone, no getting back (unless you have a database backup). 1.7.1 simply fixes the code so that the upgrade works correctly hereafter. 1.7.1 won’t recover back your old settings once it’s already cleared by 1.7. I’m sorry, but that’s the way it has played out.

If you think 1.7.1 still has a problem, please let me have a look at your site and your db. You can contact me at srinig.com at gmail dot com.

Jason Lemahieu, thanks a lot for your feedback and suggestion.

Yes, I did consider running the code to update the options at admin_init, but then consider this scenario: user doesn’t run the WP plugin updates, they simply overwrite the old files with the new ones, and they don’t immediately go to the admin. So, until such time they log in to the admin panel, the widget in the front end will show with the default options and not with the settings they defined previously.

Moreover, the options are set with autoload ‘on’, so the options are retrieved at once on wp_load_alloptions() and cached, so I hope there won’t be much of database requests. Let me know if I’m missing something here.

Thanks again!

The question of exactly when to do this type of update script is a complicated one for sure, and there are differing opinions. And actually, the situation is made a lot more complicated in MultiSite. See this: https://core.trac.www.ads-software.com/ticket/28694

We have over 100 plugins on some of our sites (many of these plugins are very VERY small, mind you), and if every single one of these plugins checked for updates on every single page request – the impact would definitely be noticeable.

Personally, I do this type of update operation on the Admin side only for performance reasons. Whichever you choose to do is up to you as the developer, and if you’re more comfortable with it on plugins_loaded, that’s totally fine ??

A plugin update hook would be fantastic, but the downside to that would be that the hook won’t work if the user simply copies the files and replaces the older version with the newer version, like this. That leaves us with checking the version number everytime and updating the options/database, or as we have done here, check the presence of the older settings and copy the options.

And in this case I’ve preferred plugins_loaded over admin_init for the reasons mentioned earlier, but if you do find out that this particular checking operation is causing a significant overhead in your multisite environment, let me know and I’ll see if I can do anything about it within the constraints we have.