Adding an Admin User to Your WordPress Database

Ever locked yourself out of your WordPress installation? No, of course not – you always keep a secure copy of your passwords. But I had a situation last week where I needed to perform admin actions on a copy of a client’s site and only had non-administrative access.

I’d recommend strongly against hacking yourself an admin account on a client’s actual site – if you need admin access and they haven’t given it to you then ask them for admin access and explain why it’s necessary. Hacking your clients doesn’t always go down well. But if they’ve already given you a full site backup then you’re not going to break anything and it’s pretty clear they trust you, so go ahead and hack your local copy.

Of course you might also need to do this in the unlikely event that you DO forget your administrative password or you’re hacked and your administrative user is deleted.

There’s several how-to guides on the net that lay out the three minimum steps:

  1. add yourself a user ID in the wp_users table
  2. add a wp_capabilities entry for that user in the wp_usermeta table
  3. add a wp_user_level entry for that user in the wp_usermeta table

but one thing I noticed they all failed to emphasize & initially tripped me up when I did this myself, was the table names…

It’s recommended that you change your WordPress table name prefix from the default of “wp_” to something else (preferably during the install where it’s offered as an installation option… it’s kinda fiddly to do it after-the-fact – I recommend using a plugin such as WebSiteDefender to help). It doesn’t need to be a 12 character password-style prefix, just something different – “xyz_” for instance. This has several advantages:

  • it allows you to store multiple WordPress sites in a single MySQL database as different sites will have different prefixes so their table names don’t clash
  • it makes your site less vulnerable to automated SQL hacking attempts which will attempt to access your tables by their well known names

If you do this then your table names are now things like xyz_options and xyz_users rather than wp_options and wp_users. When you follow the how-tos to add your new admin user, the first step is to add yourself a new row in the users table, you’ll probably automatically go to the xyz_users table, even if the guide talks about the wp_users table. But what isn’t clear is that when you add rows to the wp_usermeta (or in our case xyz_usermeta) table, the values you enter into the meta_key field aren’t fixed as wp_capabilities and wp_user_level but are dependent on your table prefix. In our case we’ll be entering rows with a meta_key field of xyz_capabilities and xyz_user_level respectively.

If you’ve changed the table prefix and you haven’t spotted this step, you’ll get a “You do not have sufficient permissions to access this page” error when you attempt to login. This is because you’re a valid user (thanks to the entry in wp_users) but you’re not allowed to do anything (thanks to the apparent lack of applicable entries in the wp_usermeta table).

A shot of the wp_usermeta table. It goes without saying that this rather simple table rename isn’t the tables on this site!


1 comment to Adding an Admin User to Your WordPress Database

  • piracetam

    Note: If called with the “id” or “name” parameter, the constructor queries the wp_users table . If successful, the additional row data become properties of the object: user_login, user_pass, user_nicename, user_email, user_url, user_registered, user_activation_key, user_status, display_name, spam (multisite only), deleted (multisite only).