OK, downgrading the plugin created more problems.
Upon re-activation of 0.5.3 it gave me a critical error. When I went into the database the plugin had created multiple ‘first_name’ & ‘last_name’ xProfile data fields.
I restored my site to a previous backup point prior to upgrading this plugin so I’m OK but something is broken in your upgrade. Sorry 🙁
Oh dear… sorry to hear this. I updated the plugin because I discovered that if it was network-activated, it would throw errors when importing content into a sub-site. The upgrade was intended to migrate the plugin options from being stored as blog options to network options. As you’ve discovered, downgrading is not an option because the options are no longer stored in the site, but in the network.
It would be really helpful to see the content of your *_bp_xprofile_fields table. I can be reached at [email protected].
Hmm, I have a feeling that the difference in my testing has been that I’ve simply replaced the codebase and reloaded. The WP repo process is seemingly different. I’m not sure at this stage, but it sounds like the deactivate hook is fired with the old code present, whilst the activate hook is fired with the new code in place. I’ll look into it.
Yes, I have always activated the plugin on a site by site basis.
In the mean time if anyone upgrades without backing up their going to be in for a long struggle when adding new members if they don’t know how to access their databases. I figure I got lucky 🙂
It is running perfectly now, I just tested by adding two new users and everything played as expected.
I wish I had more data for you but I was more focused on fixing than recording once I figured out what was happening.
No rest for the weary eh! 🙂
Thanks for all your help, this is a vital plugin for us. I’ll reach out to you on other fronts later…
I’m trying to figure out what’s going wrong with the process. What did you do differently this time?
Are you saying that you’re on multisite, but the plugin is only activated on the main site?
@VentureCore, I’m really sorry but I’m going to have to ask you to revert to the backup copy of your site pre-upgrade.
I cannot undo the damage that seems to be caused by the options migration in a reasonable timeframe whilst also supporting upgrades that may have failed. I’ve basically had to revert to the 0.5.3 codebase and hope you’re the only person who has upgraded.
Sorry again and fingers crossed.
Thank you Christian,
I did go back to the backup so all is good. I appreciate what you were trying to do for multisite systems, all of my systems are setup multisite even if I’m not using them all for that purpose.
I always activate plugins on a site by site basis unless they are only meant for multisite root. There are less problems this way all together for the long haul. Everytime I have activated programs like buddypress or the like on a network basis there are always problems that can’t be fixed on a localized basis. For me it is standard best practice this way.
I hope you figure it out but if you end up keeping it or forcing it on a site by site basis I think you will be OK.
What other work do you do? I’d love to keep in touch. We’re building out systems on a massive level and always looking for good talent!
Have a great day/night! 🙂
Thanks for the details of how you use the plugin. Much appreciated – and once again apologies for the hassle.
I’ve been reluctant to do it thus far (in order to keep things simple) but I think what I’ll do is to introduce an admin page for the plugin as a safer way to do this in future. There seem to be enough features now to justify one: to manage upgrades, set some options that have been requested and possibly to repair connections between “pre-deactivation” and “post-reactivation” fields.
My coding world largely lives on GitHub if you want to what I’m working on. My other plugins in the WP repo are listed on my profile.
Cheers, Christian
