Changed table prefix, got “(in)sufficient permissions” error.

Yes the table prefix is in the wp-config file.

Hum, I said “somewhere else.”

Of course I updated the wp-config.php file. I’m sorry; I thought that step was implied when I said “The entire site, browsing, etc, works with the new prefix “delu_” except the admin section.”

It works just fine when it’s set to wp_ within the config, but when I changed it to delu_ it errors out.

The ONLY change I did was renaming the tables. The install was installed with “wp_” as the prefix, which makes me wonder if it’s set someplace else. There were no other changes.

Yes several values in the usermeta table do use the $table_prefix value (e.g. wp_user_level and wp_capabilities).

I hate to be the cynical one here, but please don’t tell me you’re using $table_prefix as a prefix value for db value names…not only is that poor design, but it will completely screws up any wordpress install if somebody needed to change table prefixes later, which is what I’m trying to do. There is absolutely no coding reason for this — if two WPs are using the same table prefix, they’re going to use the same data anyway. Why would somebody do such a thing?

Anyway, making said change, in plausible horror, within the usermeta table did not work (I didn’t change, just added rows):

|        3 |       1 | wp_capabilities         | a:1:{s:13:"administrator";b:1;}                                                                                                                                              |
|        4 |       1 | wp_user_level           | 10                                                                                                                                                                           |
|        8 |       1 | wp_autosave_draft_ids   | a:9:{i:-1183829714;i:3;i:-1183829763;i:4;i:-1183862174;i:6;i:-1183894955;i:7;i:-1183910552;i:8;i:-1184030565;i:12;i:-1184076999;i:13;i:-1187797134;i:15;i:-1187879004;i:16;} |
|        9 |       1 | goma_user_level         | 10                                                                                                                                                                           |
|       10 |       1 | goma_capabilities       | a:1:{s:13:"administrator";b:1;}                                                                                                                                              |
|       11 |       1 | goma_autosave_draft_ids | a:9:{i:-1183829714;i:3;i:-1183829763;i:4;i:-1183862174;i:6;i:-1183894955;i:7;i:-1183910552;i:8;i:-1184030565;i:12;i:-1184076999;i:13;i:-1187797134;i:15;i:-1187879004;i:16;} |

As you see, exact copies of the rows and no go.

(goma is the other site I was referring to that’s broken. It’s less “live” as the one above I’m trying to fix)

Any body else have any ideas? My WordPress install still isn’t working. WP is suppose to be able to work with different table prefixes.

Help, please?

WP is suppose to be able to work with different table prefixes.

Only when you do it the right way when you install it.

If you restore access to the one your trying to change you can use this plugin.

But wait a second…there is no “right way” when changing table prefixes. All you do is rename all your tables, and then edit the “$table_prefix” variable.

WP should not use that value within its WP database. It’s for locating the tables, only. Well, that’s what it’s suppose to be. The ‘wp_’ within the DB should only be namespacing reasons (so it doesn’t conflict with plugins).

This is a major flaw, in my book, within WP. It completely makes it improvable to move away from the wp_ table prefix for anybody with automated installed (think Fantastico). Huge problem.

However, thank you very much for the plugin file. Using it’s source, I was able to determine the one row I missed within (delu|goma)_options with the option_name of ‘wp_user_roles’. Updating that row fixed it.

Is there anyway to fix WP? This, imho, is a big problem. It makes it improvable for anybody to switching from wp_ prefix.

You can go here and submit the idea. Or you can go here and submit it as a bug.

A few SQL queries to help?

‘new_’ is the new table prefix
‘old_’ is the old table prefix

UPDATE new_usermeta
SET meta_key = REPLACE(meta_key,’old_’,’new_’);

UPDATE new_options
SET option_name = REPLACE(option_name,’old_’,’new_’);