So, I've been trying to delete the original user for a multisite installation. After removing the super-admin privileges and setting another user to the network admin, I noticed that hitting the delete button from the network user admin would just refresh the page.

I then proceeded to remove this user as the admin user in the General settings of each individual site. Still just a refresh when I try to remove.

This led me to dig into the Wordpress code to see why this was happening, and I see that WP is behaving exactly as intended, and that I am programatically prevented from removing the user with ID = 1.

Line 30 of users.php has the following conditional:

if ( $id != '0' && $id != '1' ) {

The delete code simply won't execute on this user. I can find a way around this, but seeing this baked into the code has me thinking twice about it.

So my question is twofold:

  1. Why is this restriction hard coded? If I've got other users with sufficient permissions to do everything, what unforeseen consequences will there be if this user dissappears?
  2. What's my best strategy for circumventing this? My first thought is just to delete that user's lines from the user and usermeta table. But it occurs to me I could also change the users ID to make sure the normal WP user removal processes complete. Or is there possibly another option?

2 Answers 2


Don't delete the user, just change the email, username(optionally) and password in the users table. you can insert a MD5 string in the password field of the users table and WordPress will salt and hash it to a more secure format the first time you log in.

  • But why? What will happen if I delete the user? I am also programatically prevented from changing the username. One way or another I'm working around hard-coded restrictions in the WP core.
    – dave
    Dec 17, 2018 at 17:14
  • there's only one was to find out! seriously though, I'm not sure why that's hard coded to ignore user id 1. user id 0 shouldn't exist so that makes sense (sort of) not sure about 1. Maybe clone a staging environment and test it out there
    – mrben522
    Dec 17, 2018 at 19:14
  • Yeah, I've got multiple environments and I've already deleted that user w/o apparent problems on my local copy. But the odd hard-coding of that user id has me wary that there might be some unanticipated side-effect.
    – dave
    Dec 17, 2018 at 19:17
  • I asked someone smarter than me and he said it's possible that new multisite installs create a reserved "recovery user" with an ID of 1 and that doesn't happen when you convert an existing install to multisite. In that case it's just bad code in core that you can ignore, which is not as uncommon as you would hope
    – mrben522
    Dec 17, 2018 at 19:36
  • 1
    I'm thoroughly convinced it's bad code already. Just trying to sort out whether it's bad code that stands alone, or bad code that is trying to cover for some other bad code elsewhere.
    – dave
    Dec 17, 2018 at 19:40

In order to delete any user (even the one with ID=1) and if clicking Delete won’t work, then select the checkbox (in front of its username) and then on bulk actions select "Delete" and proceed. It should ask you to transfer the posts to another user or "Delete all content.". After making the necessary changes click on "Confirm Deletion". That is it :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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