WordPress table_prefix Variable Isn’t Just for Prefixing Your Tables

Had a fellow developer contact me today who was running into an issue.  He was in the process of migrating his sites from one server to another, and upon finishing the move and attempting to login, discovered his administrator account no longer had permissions to do anything, and appeared to have a subscribe  role.  My first thought was possibly a cookie issue, so he tried deleting cookies, and using a different browser.  No progress.

My second thought was that perhaps his user IDs got messed up when he migrated the database and that the IDs from *_users no longer matched up to to the user_id field in *_usermeta.  He sent me a screenshot of his record from *_users and matching records from *_usermeta to show me that they all matched.  That’s when I noticed that the meta_key foo_capabilities wasn’t wp_capabilities.  “Is your $table_prefix variable still set to ‘foo’?” I asked. “Oh, no. I changed it to ‘bar’, but I changed all of the table names when I migrated the database.”

I had him change the meta_keys from ‘foo_capabilities’ to ‘bar_capabilities’ and ‘foo_user_level’ to ‘bar_user_level’ and BOOM! Everything started working again.

So it turns out $table_prefix, despite the variable’s name, is used for more than just prefixing the database tables.  It’s used for several meta_keys in the *_usermeta table:

  • *_capabilities
  • *_user_level
  • *_dashboard_quick_press_last_post_id
  • *_user-settings
  • *_user-settings-time

And it’s also used in option_name *_user_roles in the *_options table.