Fields went missing

There are too many unknowns from this to answer what the possible causes would have been, but the plugin doesn’t write a new fields array if the existing fields array exists (i.e. it doesn’t remove/overwrite existing settings on upgrade).

To get fields back that you had, as long as the data still exists for the users (which sounds like that is the case), you just need to recreate your previous field settings using the same meta keys as were previously used. (Ideally, you’d want to create those fields as the same field “type” as previous as well – especially in the case of dropdowns or checkboxes).

Hope that helps.

It did, thanks! It made me understand how it works.

What I actually did eventually was to recover the value of wpmembers_fields option from a database backup. A bit adventurous maybe, but it seems to work well, and I needn’t configure all the fields again, trying to remember the exact setup.

What initially caused this problem is still a riddle though, and I see no way to find out exactly what happened.

Glad to hear you were able to recover.

What initially caused this problem is still a riddle though, and I see no way to find out exactly what happened.

Unfortunately, there’s not really a way to trace that.

One thought that I did have, however, is there is one possibility that I did not think of in my original answer. It’s a remote one, but you could possibly be one of the people who fits into it’s limited scope.

If you port the site – say from a dev setup to production – there is a possibility that the value for the stylesheet setting will no longer be valid. In that instance, the value of the serialized array in the wp_options table will be corrupt (suggesting an incorrect number of characters in the setting). In a server that has extremely strict interpretive requirements for a serialized array, that could return “false” instead of the plugin’s main settings array. That would lead the plugin to believe that install had not been run and it would run a script that would insert the default settings.

As I said – it’s a limited scope issue – and regardless of whether it affects you (or anyone else reading this later), the root cause is addressed in the upcoming 3.3.0 release as the stylesheet setting is being changed. But this is the only possibility I can think of where the plugin would overwrite existing settings of itself unintentionally and I’ve only ever had one single user where this occurred (which is how I found it in the first place).