Delete a user's data

[shanebp]

There have been some calls in the forums for a way to delete a spammer's data.

I don't think that should be part of marking a user as a spammer. On large sites, imo, you want to still give moderators the option to unmark a user as a spammer. And then provide a separate option to wipe the user's data.

Since spammers seem to sign-up in bunches, I don't want to keep them in the wp-users table if their data is wiped. So I use a separate table (auto-increment id & email).

I'm sure you guys have your own thoughts on where / how this would be implemented.
I think it's a pretty simple task - just wanted to get queued for 1.7 (?).

Here are the functions I use in bp-custom.php to delete a user's data and 'ban' their email
​https://gist.github.com/2906736

[boonebgorges]

Thanks for the provocation, shanebp.

I agree that there should be a better method for taking care of this kind of cleanup. A few thoughts:

• What's the value of removing the spammmed users from wp_users? Just to make the table smaller? If so, and if you've already deleted all of their data, why not just delete all record of their existence? I'm not convinced of the value of a completely separate table for the purpose of recording deleted email addresses. (And in any case, it seems like something that should exist in WP, or maybe in a standalone plugin. I have a feeling that it'd be overkill for the majority of BP installs.)

• Our cleanup routine should be hook based:
  • At the end of the core user data deletion process, fire a hook (say, 'bp_deleted_user')
  • In each component, hook a function (eg bp_messages_delete_user_data()) that, in turn, calls some sort of cleanup method in the database class.
  This way we don't have to worry about bp_is_active() calls for each component.

• Deleting shared data is problematic. You don't necessarily want to delete every message involving a user - many of those threads may have legitimate messages from real users.

• You've got a buddybar implementation of the UI, but we'd need a WP Toolbar button instead.

• I'm thinking that the Delete User Data button should only appear in the UI when the user has already been "deleted" in the lightweight way. Alternatively, when the admin clicks Delete User, we could send him to a confirmation screen that asks whether to delete just the user, or all data associated with the user (along with some huge warnings). I'd be glad to hear ideas about this UX.

[shanebp]

What's the value of removing the spammmed users from wp_users? ... I'm not convinced of the value of a completely separate table for the purpose of recording deleted email addresses.

I agree that a separate table is overkill for the majority of BP installs.
We wanted spammers out of wp_users so they wouldn't show up in any search results.
And we wanted to retain their email to prevent new sign-ups from that email.
Leaving them in wp_users would seem to be the best default approach.

Deleting shared data is problematic.

True, if there are multiple recipients for a message. But, in our experience, we haven't seen any 'real' threads that include spammers that members want to retain. So it was safe to nuke 'that' thread and all recipients. But it would be a problem for sites that tend to send 'All Members' messages.
I suppose some elaborate 'Delete User Data' screen could show all the relevant threads and let the admin decide which to delete.

I'm thinking that the Delete User Data button should only appear in the UI when the user has already been "deleted" in the lightweight way.

Good idea. And then that button could send them to a confirmation screen that could include checkbox options re which data to be deleted. That would make it possible for plugins that create new 'connections' between members ( like recent_visitors) to included in spammer data purging.

[DJPaul]

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see ​https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: ​https://make.wordpress.org/chat/