atmojones

@graydawn1234 I followed the instructions @r-a-y posted and tested on my staging site and it looks like it worked. From the page he linked (https://github.com/boonebgorges/buddypress-group-email-subscription/wiki/Migrating-to-3.9.0):

If WP-CLI is unavailable, the following script may be used to force the migration in a single pageload. On large installations, this operation may timeout, but can be run repeatedly until the migration is complete.

Put the following script into an mu-plugin: https://gist.github.com/boonebgorges/14c0d1042e85d263d48f3eaf7ca25b6d
As an admin, visit wp-admin/?bpges-force-migrate=subscriptions to migrate subscriptions, or wp-admin/?bpges-force-migrate=queued_items to migrate queued items.

Thanks for the quick reply. I tried running the db query you provided but it said 0 rows affected. I ran this query to see what other values might be present in the wp_options table: SELECT * FROM wp_options WHERE option_name LIKE “%ges%”.

Here is a screenshot of the results.

Let me know if you have any other ideas on how I can proceed.

Hi, thanks for the advice. That did resolve the issue of some user’s not appearing in search when they should.

The count is still off by one, and the user that is not being displayed in the results is the one that was labeled as a spammer. Is it possible that user’s flagged as spammers are being returned by Global Search for the result count, but not being displayed in the results?

Sorry for my lack of response. Got busy with other more important features.

I think I’ve figured this out. My posts do not have post_excerpt set in the database, the excerpts I was trying to alter were the auto generated excerpts. These are generated off post_content with shortcodes stripped rather than processed.

The easiest solution I have found is returning an excerpt generated from $post->post_content using the filter get_the_excerpt (because post_content has already had the shortcodes applied at this point, and then wp_trim_excerpt doesn’t do anything but return the excerpt you generated).

The problems with just sending another email saying “you’re approved, don’t worry about activating” is that 1) we don’t actually know if that is a valid email [they could have a typo during reg, it could be a fake email made by a bot] 2) The user is not assigned the default role that wordpress settings give to new users [the problem i’m experiencing that initiated this thread] 3) The user is not ever removed from the “Pending” list of the user section.

Issue 2 seems like the biggest problem and I will try to clearly track the issue through the code:

In your admin.php file on line 274 you call:

bp_core_process_spammer_status( $user_id, 'ham' );

That function can be found https://github.com/buddypress/BuddyPress/blob/master/src/bp-members/bp-members-functions.php. On line 650 it uses ‘ham’ to set $is_spam:

$is_spam = ( 'spam' == $status );

So, it gets the value 0, then on line 680 updates the wp_users table:

$wpdb->update( $wpdb->users, array( 'user_status' => $is_spam ), array( 'ID' => $user_id ) );

wp_users.user_status is now 0 and your user approval process finishes the rest of it’s code.

Then, the activation link in the email is used, eventually calling bp_core_activate_signup, which on line 1859 tries to update user_status to be 0:

if ( ! $wpdb->query( $wpdb->prepare( "UPDATE {$wpdb->users} SET user_status = 0 WHERE ID = %d", $user_id ) ) ) {

Because user_status is already 0, no rows are updated and the query returns 0 and the function returns:

return new WP_Error( 'invalid_key', __( 'Invalid activation key.', 'buddypress' ) );

Therefore line 1981 is never called:

do_action( 'bp_core_activated_user', $user_id, $key, $user );

which has attached to it:

bp_members_add_role_after_activation

So the user is never given a site role.

That is where the activation process conflicts with your plugins approval process. I am not thoroughly acquainted with buddypress or your code, so I don’t know the best solution here without potentially breaking something else, but without investigating or testing it seems like there are a couple possible solutions:

1) You could attach your code to a hook at the end of the buddypress activation process so admins aren’t notified about a user needing moderation and the user won’t appear in the moderation list until they have activated their account. But this might allow users to use the site without being moderated yet.

2) Add a column on the approval UI that displays if the user is activated. I think this could be checked by seeing if their user id has the activation_key meta key set in wp_usermeta. I believe once a user activates this meta key is deleted. This doesn’t really solve the problem so much as allow a competent admin to not cause the problem.

3) You could call the buddypress activation functions when a user is moderated as approved before calling the bp_core_process_spammer_status function. This has the problem of approving well crafted spam users and users that entered the wrong email. Although, I have only ever encountered 1 spam user that was not obvious.

4) You could just not call bp_core_process_spammer_status( $user_id, ‘ham’ );. Unless there is somewhere else in your code that would specifically mark a user as spam until this is called I feel like removing this and letting the user be marked as ham when buddypress/wordpress normally would might be a very simple solution.

I hope this is helpful, and I don’t mind doing some more investigation or testing if you need additional information. This is an issue that is occurring for me very often, I assume because activation emails are going to spam or because much of my user base is older and doesn’t understand the importance of activation.

• This reply was modified 5 years, 4 months ago by atmojones.
• This reply was modified 5 years, 4 months ago by atmojones.
• This reply was modified 5 years, 4 months ago by atmojones.

I agree that, in your scenario, everything works perfectly. The issue I’m encountering occurs when users do not activate their account immediately (either they don’t get the email right away, or get distracted, w/e) and the administrator approves their account through your UI. At that point the whole user activation process breaks. If your solution is that no user should ever be approved by an admin before the user has activated their account then I don’t think the user should appear in the “Member Requests” list of your UI until they have activated their account.

If I comment out line 274 of admin.php from your plugin

bp_core_process_spammer_status( $user_id, 'ham' );

then approve a user, the activation key from the email still works and the user is assigned a Role.

It seems that during the activation process user_status is checked and if it is already set then the error “Invalid Activation Key” is returned.

I just did a clean wordpress install. Installed Buddypress and BP Registrations options as only plugins. Turned on allowing users to register in wordpress settings, and set all users must be approved in BPRO settings. Registered a new user through the frontend form, approved them through BP Registration Options, then tried to use their activation key and I got “Invalid Activation Key” and the user does not have any site roles defined.

Is this the expected behavior?

• This reply was modified 5 years, 4 months ago by atmojones.

Sorry, I’m not fully understanding. You say that your plugin doesn’t prevent users from being able to go through the activation process, but once I approve a user through your plugin their activation key becomes invalid? Are you saying that behavior is actually a bug?

Thanks so much for the quick response. That was the lead I needed. It looks like buddypress has some filters that add rel=”nofollow” to all images in activity feeds, removing them with the below code has got it all working

remove_filter( 'bp_get_activity_content',               'bp_activity_make_nofollow_filter' );
remove_filter( 'bp_get_activity_content_body',          'bp_activity_make_nofollow_filter' );
remove_filter( 'bp_get_activity_parent_content',        'bp_activity_make_nofollow_filter' );
remove_filter( 'bp_get_activity_latest_update',         'bp_activity_make_nofollow_filter' );
remove_filter( 'bp_get_activity_latest_update_excerpt', 'bp_activity_make_nofollow_filter' );
remove_filter( 'bp_get_activity_feed_item_description', 'bp_activity_make_nofollow_filter' );

Thanks for looking in to this so diligently. Let me know if there is somewhere I can keep an eye this bugs resolution progress.

I’ve made an account for you on our staging site using that email, so you can be pretty free to examine that without worry of breaking anything. It autogenerates a password but I think the onboarding email allows you to reset that.

The most recent post on my activity page https://myfossil.staging.wpengine.com/members/mjones/ should demonstrate the issue.

If you run in to any issues with testing, please let me know.

Here is the javascript error log:

Uncaught SyntaxError: Unexpected end of JSON input
at JSON.parse (<anonymous>)
at Function.n.parseJSON (jquery.js?ver=1.12.4:4)
at Function.a.parseJSON (jquery-migrate.min.js?ver=1.4.1:2)
at Object.success (buddypress-edit-acti….min.js?ver=1.0.9:1)
at i (jquery.js?ver=1.12.4:2)
at Object.fireWith [as resolveWith] (jquery.js?ver=1.12.4:2)
at y (jquery.js?ver=1.12.4:4)
at XMLHttpRequest.c (jquery.js?ver=1.12.4:4)
n.parseJSON @ jquery.js?ver=1.12.4:4
a.parseJSON @ jquery-migrate.min.js?ver=1.4.1:2
success @ buddypress-edit-acti….min.js?ver=1.0.9:1
i @ jquery.js?ver=1.12.4:2
fireWith @ jquery.js?ver=1.12.4:2
y @ jquery.js?ver=1.12.4:4
c @ jquery.js?ver=1.12.4:4
XMLHttpRequest.send (async)
(anonymous) @ VM87:1
send @ jquery.js?ver=1.12.4:4
ajax @ jquery.js?ver=1.12.4:4
buddypress_edit_activity_get @ buddypress-edit-acti….min.js?ver=1.0.9:1
buddypress_edit_activity_initiate @ buddypress-edit-acti….min.js?ver=1.0.9:1
onclick @ (index):472

I will check the javascript console sometime today. But I should clarify that I can reproduce this on twentyseventeen theme with all plugins turned off except buddypress and edit activity using the post:

hello
@[username]

& nbsp;

The reason I mentioned visual editor at all was because this would not usually occur if someone was to put blank lines at the end of a normal post (they are stripped). You would need to type out & nbsp; randomly at the end of a post (whereas the visual editor converts trailing blank lines to this automatically).

Thanks for your thorough response. I’m not sure if this is an edge case because some other plugin is interfering with this plugin. Once I’ve checked the functionality on a clean install I will get back to you.