Hi there,
If you simply update, the settings are not reset (the select boxes on the plugin settings stay the same)… however, FVM now purges all caches whenever you upgrade any plugin, theme, or wordpress core. It also purges the cache if you switch your theme and if you change certain settings on FVM.
That is needed, because when you update another plugin or your theme, the CSS or JS files may change, and then FVM should rebuild its files again to make sure the updates are reflected on the live site.
Always remember to purge your caches after an update, especially if you have it on the server level.
Hi @alignak,
Thanks for getting back. I think I didn’t make myself clear, I understand the thing about purging cache but what I meant was that whenever I update the plugin HTTP Headers section gets reset, I am not sure if it affects other sections as well. And I just found out that this also happens if I deactivate and activate the plugin again. Please take a look at this issue as it is important to not to lose those every time I update or deactivate the plugin.
Thanks
Hi @ashucg
When you deactivate and activate the plugin, all settings are reset by default.
The reasoning is that when the plugin is disabled, it deletes all entries from the database. When you enable it back, it sets the default settings.
In the past, FVM preserved the settings… so I can perhaps add an option to delete all settings from the database upon deactivation, rather than making it the default.
However, I don’t see the HTTP Headers info being reset.
# before update:
http://prntscr.com/lrc360
http://prntscr.com/lrc300
# updated
http://prntscr.com/lrc3be
http://prntscr.com/lrc3l2
If you are talking about the http headers “not being there” when you request it with curl after the update, that is also working fine: http://prntscr.com/lrc4jy
Are you perhaps using some cache plugin or something else affecting the headers?
Please send me the details, step by step, so I can reproduce it.
when the plugin is disabled, it deletes all entries from the database.
I think this should only happen if I uninstall/delete the plugin rather than on deactivation hook because it is common to deactivate such plugins while debugging, what do you think about it?
I was unable to reproduce the issue on a different environment, so it looks like something else is causing this issue, I will try to find more about it.
Thanks for your time, really appreciated!
That makes sense.
I added an option to 2.4.7 to choose if you want to preserve the settings, even if you uninstall. And if it’s not selected, it will only delete the options when you uninstall, however the cache is still purged.
I’ll push 2.4.7 today or tomorrow, once I check a few more things.
Thanks again
