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.
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”.
@whooami I apologize. I overreacted a bit.
@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?
@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!
