0

I am using the multisite setup of wordpress. My subsites are managed my administrators of other organisations.

Problem: When a user is deleted on a subsite by the administrator, its records still exist in the network user table. In turn when this user returns to the subsite where he/she was registered, he/she can still login. I guess because its records are still in the user database. So basically a deletion from a subsite has no use.

Possible solution: When user is deleted from a subsite it is also deleted from the entire network.

I looked at the codex but I cannot get it to work. The wpmu_delete_user function should be the one to go i guess. But the trick seems to be when to fire it. I thought of adding it to remove_user_from_blog but it is just not working.

This is the code atm, hope you can help!

add_action( 'remove_user_from_blog', 'remove_user_from_network', 10,2 );
function remove_user_from_network( $user_id ) {
    global $wpdb;
    $user_id = (int) $user_id;
    wpmu_delete_user( $user_id );
}
  • I guess part of the issue is that it's not possible to delete a user on a sub site, but you can remove a user from a sub-site. The 2 actions do not do the same thing. What is the actual problem? It sounds like you have a problem related to users who do not have any sites, but you're describing the problem in technical terms. E.g. it could be that when they log in a piece of code simply tells them they aren't a member of any sites and logs them out, but while that might be a solution, it isn't what you're asking for – Tom J Nowell Sep 19 '18 at 14:01
  • Main problem is that each subsite is private. It is a private academy with 150+ online courses. Only people that are allowed by the site admin should be able to log into this sites. Now if you have an account on a subsite you can log into every other site in the network. This is ofcourse not preffered at all. – Joris Sep 20 '18 at 8:26
  • Could you not just add code that redirects users to a main homepage if they aren't a member of that site? What you're asking for doesn't solve your problem, afterall any user can be logged in to any site, even if they are only on a single course and have not been deleted, so the problem is not restricted to those that have been removed from a course. Your problem is actually: "Users who do not have a role on a site are still able to visit the site when logged into the network", for which a redirect makes more sense. Otherwise you'll have users on multiple courses facing problems of deletion – Tom J Nowell Sep 20 '18 at 11:27
  • Or even worse, if a course is removed, any professors admins or teachers accounts will be destroyed when the course site is removed, causing massive amounts of damage to the rest of the install – Tom J Nowell Sep 20 '18 at 11:29
0

But the trick seems to be when to fire it.

This is correct! When remove_user_from_blog fires, the removal has not happened yet, rather it's about to happen and this is your chance to step in and do things beforehand, e.g. cleanup.

The wpmu_delete_user function should be the one to go i guess.

Yes, that would be my guess too

I looked at the codex but I cannot get it to work

The codex is great, but https://developer.wordpress.org is greater, and gives more information

Some Notes Before Tackling the Issue

  • That action receives 2 parameters, the second being the blog ID, you should check for that
  • There is no super admin check or the current user, you could accidentally delete yourself!
  • This code will need to be in either an MU plugin, or a network activated plugin. It's possible it could go in a functions.php but that would be very bad practice. It could also cause problems when removing users via WP CLI
  • You didn't provide any context, so whatever problem this solves, you should have asked about the problem, then proposed your solution as a possible one that you didn't know how to implement. That way an even better solution you hadn't thought of might have been given
  • If a user is a member of multiple blogs, this will remove them from all blogs once a user is removed from 1, which would be unexpected

But most importantly, deleting a blog will call remove_user_from_blog deleting every user, including yourself.

So, I would not recommend doing this.

Instead, what is the problem this is trying to solve?

The Hook and Infinite Looping

As mentioned before, the remove_user_from_blog event fires before the removal, so you can't delete the user on that hook or the rest of the remove_user_from_blog function will fail, and you end up with no cleanup or deletion taking place.

Worse yet, wpmu_delete_user calls remove_user_from_blog internally, so you would end up in an infinite loop where it tries to remove the user from the blog, but then your action calls wpmu_delete_user, which tries to remove the user from the blog, triggering your action yet again indefinitely

Sadly, there is no removed_user_from_blog action that we can hook into. I would recommend adding that via Core Trac for inclusion in the next WP release, it's a super easy patch, and you'll appear in the credits for the next WP version on the about page

Alternatives

I'm afraid, you will need to hook into every possible scenario that could remove a user from a blog. You would need to detect the form submissions and URLs for removing them on admin_init, the REST API DELETE calls for users, the WP CLI commands, etc

Put simply, there is no simple filter or action that will let you do this in a foolproof manner. It is not an easy trivial ask, and you will have to add to it as new situations arise, and account for all plugins as and when they change.

If that additional action was added to WP core however, there would be. But again, what problem is it that this is supposed to solve?

Edit: The Real Problem

Thanks to some clarifying comments it's now revealed that each site is an educational course.

I'm assuming that the check to see if content is visible does not use roles, but instead only checks is_user_logged_in().

So instead:

  • check that the user has the subscriber role or higher. Users who are logged in but aren't on the site have no role, so they will be unable to pass this check
  • Add a hook on init and admin_init to check if the current user is a member of the current site, and run wp_redirect( '...url...' ) exit; to send them to the root homepage, or a page that explains they have no access to that site
  • Use the same hook but combine it with a wp_die('you do not have access to this' );

Why Deleting The User is a Bad Idea

  • When a site is deleted, all the users are removed from it first, so they'd all be deleted across the entire network. This means any teachers or professors on multiple sites would be deleted, and the other sites they belong to would be broken
  • There's a high risk that you could self delete and loose the super admin account
  • There's a fundamental misunderstanding that you can delete a user from a specific site. It's not deletion, it's removal, it's an important distinction.
  • This does not fix the root problem. A user on site 1 can still log in, which means they are logged into the network, not the specific sub-site. If your check only relies on being logged in then that user can see all courses, as can every other user.

So just redirect the user to a place explaining they haven't got permission, and make sure the permission checks don't just check if they're logged in, but their role too.

  • Thanks for the clear layout. There comes a bit more to the plate than i imagined. Thing is that I do not want users in my network that are no longer registered in a blog. Atm when an admin deletes a user from its site, the user still exist in the network. Meaning that a user can still navigate to the site and login (as it is still part of the network). In turn the deletion has no actual effect. I will update the question and make it more clear – Joris Sep 19 '18 at 10:38
  • Yes but they have no capabilities, so all they can do is modify their display name and password. If you had made it clear from the beginning that this was a cleanup problem, then an entirely new set of solutions would have been possible, such as cron jobs, or handling logged in users that have no sites etc. But that's not what you asked. Still, I don't see how it's an issue as long as the subscriber role cannot do anything, neither should your role'less users – Tom J Nowell Sep 19 '18 at 14:00
  • @Joris I've extended my answer, and suggested some things. Fundamentally though, what you want is neither easy, nor will it fix your problem, and it introduces new problems that actively destroy your site – Tom J Nowell Sep 20 '18 at 11:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.