Changing the database prefix: admin rights gone

  • Last night I went to hell and back with WordPress. I had to install a new site for a client. The problem was that he had only one database and there was already a WP instance running that was using wp_ as a database table prefix. I had been using that on the development site which forced me to change all table names from wp_something into maghreb_something.

    I set everything up, modified wp-config.php to reflect the new database prefix. Then the problems started. I logged on as admin and found that I had no rights to do anything. It was like I was just a registered user. I checked the options table to verify that my userlevel was 10. I even tried to register a brand new user and set it’s userlevel to 10 manually but not to avail.

    I Googled around and found some obscure message stating that changing the database prefix could result in this behaviour. I ended up letting WordPress install a clean database on the client’s site with prefix maghreb_ for the database. After that I manually created all tables and inserted the data from the development site while omitting the users table, the usermeta table and the options table. Then I manually inserted all options fields except for everything that WP creates at install to make sure I wouldn’t recreate the original problem.

    After this horror I could finally access my stuff as admin.

    My question is: Was there an easier way to fix this that I don’t know about and couldn’t find even after extensive searching and googling?

    If there isn’t I’m sure this post will help some people experiencing the same problem.

Viewing 9 replies - 1 through 9 (of 9 total)

  • well, im not sure where you got information that changing the db prefix could cause such problems. I have 4 or 5 wp installs in 1 database and can switch between them with NO similar issues whatsoever.

    The problems with switching prefixes to access another set of tables is that most times the home url and blog url isnt the same — THAT can cause problems.

    If I follow you correctly…

    >> I set everything up, modified wp-config.php to reflect the new database prefix

    So you renamed all the wp_ tables?

    Are you sure they were using the same db schema? That would be the first thing I would be wondering about.

    What you did was ass backwards, in all respect, if I’m reading right. If you’re installing wordpress and its a new site. Install wordpress. Use new tables. Use whatever prefix you want, but theres no need to manually do anything — you assign the prefix and let WordPress do the work.

    It is possible to have more than one wordpress install inside the same db — thats precisely what those prefixes are for.

    Thread Starter themarco

    (@themarco)

    That’s exactly what I did. I let WP create the tables. But I had to migrate a lot of prepared data from the test server to the live server which is why I couldn’t start fresh. There was a database full of posts on server A using wp_ as a prefix which needed to be placed on server B with prefix maghreb_ because wp_ was already in use on that server.

    Yes I renamed all tables, Yes they were using the same schema. I took care of the home URL, everything. I’ve done at least 10 custom WP sites so believe me, I know about the basics.

    I’m not the retard that you think I am. Or I wouldn’t have posted this story.

    Don’t know if this is your problem but please note that some of the rows (records) in your usermeta table use the database prefix when composing the meta_key values for a user’s capabilities and user_level.

    >> I’m not the retard that you think I am.

    You could have stopped after clarifying what you initially posted.

    I did say, “if I’m reading right”.

    Thread Starter themarco

    (@themarco)

    @whooami I apologize. I overreacted a bit.

    Thread Starter themarco

    (@themarco)

    @michaelh> That’s gotta be it! I never realized that would screw everything up. It may be worthwhile to mention that somewhere in the docs because I didn’t find it anywhere. I did see the key names when I was fiddling around but I never realized this actually needed to be ‘in sync’ with the prefix.

    TheMarco – any suggestions, where in the docs, comments about this should be noted?

    I have an issue with my admin capabilities. It seems as if there is no unfiltered_html capability under my admin (as viewed through role manager plug-in). I am wanting to use php in a post or page to stream rssfeeds there. I am not sure why i don’t have the capability to do this, except that I am not assigned unfiltered-html. When i try to add unfiltered_html, i get a few errors. When I refresh the page, the unfiltered_html assignment is added, but when I attempt to activate it, I get this error:

    Fatal error: Call to a member function add_cap() on a non-object in /home/clergyco/public_html/wp-content/plugins/role-manager/role-manager.php on line 143

    I’m lost. How do I get my unfiltered_html capability back for admin?

    Thread Starter themarco

    (@themarco)

    @michaelh I guess there’s several places where it would be handy. I suggest at least to put it here. It’s one of the pages I consulted when looking for answers on what went wrong.

    Furthermore, I don’t know if there is a page dealing with this but if there’s a page about what to do when you can’t login as admin anymore it would be good to list changing the database prefix as a potential reason as well, including telling people to check out the options table and change the keys according to the prefix change.

    Hope this helps!

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Changing the database prefix: admin rights gone’ is closed to new replies.