2

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?
1

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 '18 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 '18 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 '18 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 '18 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 '18 at 19:40

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.