[knowitallninja]

Hi Shane,

I went to follow your advice on the staging version of my website to find the issue didn’t exist there (despite being a 100% identical version of the site).

I contacted my host who looked into and discovered disabling redis object cache fixed the issue (my staging site doesn’t have redis object cache enabled).

Should this have been a problem? Or should I be able to use redis?

THanks

Dan

[knowitallninja]

Hi there,

Thank you that helped me to figure the issue out.

Kind Regards

[knowitallninja]

Hi @r-a-y

My apologies for responding so slowly. I didn’t get a response notification to my email for some reason.

As for Twitter. I’m not sure what they’re doing. I just know that Google Analytics are very clear that under GDPR no personally identifiable information should be passed in the URLs to Analytics and that usernames count as PII.

I had a look at that ticket. Unfortunately the code in there causes my member areas to not work. It does replace their usernames with their id numbers in the url, but the url isn’t functional.

So I guess my only option is to try that plugin to change all my users nicenames? That’s unfortunate. I really would hope the Buddypress developers would look into this as it is definitely an issue with Google Analytics conditions which I imagine many BP users do use.

I’ll give the nicenames plugin a go soon.

Thanks

[knowitallninja]

Hi @optimized,

I was having a somewhat similar problem, which was due to a coding problem with the latest version of buddypress.

Do you have the activity feature of buddypress disabled? If so, then this is probably the same error I had. You can try activating the activity feature, or you can changed the code as indicated here: https://buddypress.trac.wordpress.org/attachment/ticket/7870/7870.02.patch

I hope this helps.

Thanks

[knowitallninja]

Hi @r-a-y

That’s definitely the issue. I do have activity deactivated. I fixed the issue by commenting out lines 588-592.

It also fixed my other problem with the free trial, as when users signed up to a free trial it automatically adds them to a buddypress group.

So it was all down to that.

Thanks

[knowitallninja]

I have now tried everything except rollback.

I have uninstalled and reinstalled buddypress. I have deactivated every single plugin except buddypress and I have even switched to the twenty-seventeen theme, with no custom code or anything. I am still getting an error when I add a user to a group. The error in my log says this:

Call to undefined function groups_record_activity() in /wp-content/plugins/buddypress/bp-groups/bp-groups-functions.php:588

So it seems the error is certainly to do with buddypress itself, right? Anyone got any suggestions?

[knowitallninja]

Hi,

I just wanted to follow this up. @awpt that doesn’t do anything for my situation at all unfortunately. Are you saying it may be a custom theme problem?

I’ve noticed another issue, if adding users to a group, even in the backend, it also gives a 500 error.

I am going to try and roll-back to 2.9.4, though I am not sure I 100% understanding the instructions given here, but I’ll give it a go.

Thanks

[knowitallninja]

Hi djsteveb,

I do have a backup, could I copy the old buddypress folder over the new one?

Thanks

[knowitallninja]

Sorry for all the updates, I have found the problem. In bp-settings-actions.php there is a line in the default handling of a password change that says this: $_POST[’email’] = $update_user->user_email;

By commenting that line out, it fixes the problem and my code works. It’s not ideal though as whenever I update buddypress it’ll change back. So if anyone knows a way around that then that would be great.

Otherwise I have a working script. For future reference it’s here:

function action_bp_core_general_settings_after_save() {
$useremail = $_POST[’email’];
$userpassword = $_POST[‘pwd’];
$current_user = wp_get_current_user();

if(wp_check_password( $userpassword, $current_user->user_pass, $current_user->ID)) {
if ( $current_user->user_email != $useremail ) {
delete_user_meta( $current_user->ID, ‘pending_email_change’ );
$userdata = array(
‘ID’ => $current_user->ID,
‘user_login’ => $current_user->user_login,
‘user_email’ => $useremail
);
$result = wp_insert_user( $userdata );
}
}
};
add_action( ‘bp_core_general_settings_after_save’,’action_bp_core_general_settings_after_save’ );

[knowitallninja]

Just thought I’d add, if I don’t enter my password it does allow me to update my user details as the $_POST[’email’] does pass my new email through.

Obviously I don’t want the user to be able to change without confirming their password though. So I guess I need to validate their password first.

[knowitallninja]

Hi ckchaudhary,

Thanks for the advice. It was really clear and helpful. While I am not the best coder I decided to have a go at doing it. I think I am super close. I have one problem, which is quite a major one, but probably super basic. I was hoping you wouldn’t mind me asking.

Basically, I obviously need to know what the user actually wrote into the email input box. I thought this would be simple: $_POST[’email’]. However, this returns the users old email address, not the one they entered before pressing submit. Very strange!

Do you know what is going wrong here? Is there a different way to get what they actually entered?

I have added my code below as reference:

function action_bp_core_general_settings_after_save() {
    $current_user = wp_get_current_user();
    if ( $current_user->user_email != $_POST['email'] ) {
        delete_user_meta( $current_user->ID, 'pending_email_change' );
        $userdata = array(
            'user_email' => $_POST['email']
        );
        wp_insert_user( $userdata );
    }
};
add_action( 'bp_core_general_settings_after_save','action_bp_core_general_settings_after_save' );

moderator note: please use the code button when sharing code.