guice

Looks like I tracked it down, it’s due to BuddyBoss not initializing with user blogs. I found a way to get the table name into there, but the table bp_user_blogs does not exist. :/

Still trying to figure out why A) it never initialized and B) why we don’t have a bp_user_blogs table.

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.

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?

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)

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.

I wanted to post to say the above PHP bug fix worked for me.