Haven’t done any formal targeted testing, but given what I know we do with the plugin, I am hard pressed to say anything from 4.8 will have directly affected it. At best, some visual details in the WP admin would be the biggest potential incompatibility.
Thread Starter
Jay
(@uscore713)
Well, that’s what we were expecting. However, the net result is that it’s as if the BPRO plugin isn’t even installed/activated.
Given that we do a lot of other things surrounding registration and login–and this isn’t the first time I’ve raised an issue about the plugin, only to find the problem existed outside the BPRO plugin–we are ardently debugging the situation now.
Thanks for getting back to us so quickly.
I guess my first question, if it seems like our plugin isn’t doing what it should be, is if our user meta is being assigned upon successful activation. If it is, and then people are still getting through to other areas they shouldn’t, then something MAY be up. At the same time though, I would wonder if our template redirect callbacks aren’t getting reached. Perhaps something else is bypassing that and thus they’re getting through.
Nonetheless, let us know what you find, so that we can try to help prevent similar situations for others.
Thread Starter
Jay
(@uscore713)
Thanks, Michael. Examining the BPRO code seems to indicate that BPRO doesn’t hook into the Login process to fetch the meta data and preclude login…or did we miss something?
We’ve never, that I’m aware of, been involved in the login process. We’ve always been post-login and checking where the user is. We rely on “is_buddypress()” and “is_bbpress()” to check and redirect as appropriate. We’ve also never prevented the account creation, just what they can do afterwards.
Thread Starter
Jay
(@uscore713)
I never meant to imply that BPRO is involved in preventing account creation, but expected it to be involved in checking whether the user has been approved during the Login process.
The essence of handling account approbation revolves around BPRO handling the BPRO-specific metadata key “_bprwg_is_moderated”, right? Doesn’t everything hinge around the fetching and setting of this User-specific metadata? Or do we have that wrong?
If the metadata assumption is correct–but BPRO is not directly hooked into the Login process–then how does BPRO keep a user from being logged in?
Sorry if we’re being dense here. 😉
As I mentioned before, this plugin is absolutely essential to the operation of our website, so we don’t mind contributing to the effort by tracking down any possible bug that keeps BPRO from being WP 4.8-compatible.
No offense taken, just letting it be known how we handle things. We are only set up to disallow in certain areas: BuddyPress or bbPress, as best we can.
Correct, that’s the meta key we use. We set that upon account activation, and check it’s value when determining if the user should be allowed to see an area, or how much. If set to be a private network, and the meta key there returns that they should be moderated, we redirect the user to their profile when they try to access a restricted area. If the users should just be moderated but NOT private network, then we try to cover as much as w can to make the BuddyPress/bbPress areas “read only” with interactive UI removed. No commenting, posting, liking, etc.
That’s probably what gets most people, we don’t prevent from logging in. The user, at least from our target goal, should still be able to go visit the blog and leave a comment, or visit the woocommerce shop and make a purchase. Once they eye that community section though…they need to be vetted. So, we’re not a WordPress site protection plugin, we’re just a specific section protection plugin.
Thread Starter
Jay
(@uscore713)
Thanks for the clarification. Now I’m a bit baffled how your plugin (when running under 4.7.5) ever worked for us in the first place, given you don’t hook into the Login process.
You have given me important info to help in our researching of the issue, most notably the fact that you hook into the activation process, and that’s an area we also hook into, namely, to perform auto-activation. However we did it in 4.7.5 seemed to work just fine, but something must have changed in 4.8 to make this break.
However, suffice to say, whatever has broken is not likely due to your fine plugin.
Hopefully this info will help others. 😉
