Multiple WP installs, same login for each?

Furthermore,

I tested some more and found out that test user created using the second blog gets the same error message: “you do not have sufficient….” while logging into the first blog.

What to do?

-LR

Well, visiting the first link you pointed to, have you looked into defining the CUSTOM_USER_META_TABLE constant? User level and capabilities are held there (i.e. in the usermeta table).

If that doesn’t solve it, even though I tend to a lot of the WP user issues, I don’t maintain a multi-user environment and couldn’t say what would be at fault.

Hi Kafkaesqui,

By adding this line:
define(‘CUSTOM_USER_META_TABLE’, ‘wp_usermeta’);

it makes things worse… the admin account then gets the same message as the test user.

Interesting thing to note:
If I go into the admin interface, and then to “Users” and then to “Authors and Users” and create a test user from here, call it “test1” and then login with that name, it works just fine on the blog site it was created on.

on the other blog site, the same user “test1” gets the error message “you do not have sufficient…”

Now, when I log into the other blog site (where the newly created user does not work) and go to Users–>Authors and Users and look to the list of all users, the interesting thing is, “test1” user is listed separately from the other “subscribers” users.

If I edit test1’s status and change it to subscriber, I can then login using “test1” without any problems.

IN CONCLUSION:
the blog which creates a new user, enters correct information in the SQL table for “Membership Type” (Subscriber in our case) but this same information appears differently in the admin area for the other blog.

-LR

Luckily I had a little time this morning to play around on my test setup (which, luckily again, I have several WP installs on). I plucked away at additional constants wp-settings.php checks on to no avail, but after looking through the issue of how ones role is handled throughout WordPress, I found a line in the capabilities.php file (wp-includes/ directory) that seems to be the cause here.

In the WP_User class in capabilities.php, one finds this:

$this->cap_key = $table_prefix . 'capabilities';

Modifying that line so it reflects the table prefix of the *primary* users/usermeta table, for example:

$this->cap_key = 'wp_capabilities';

Solved the problem. Afterwards I could log into my secondary blog with any account from my primary, edit user settings, etc. It’s possible other issues may crop up that I can’t test for here (i.e. your blogs are on separate subdomains or completely different domains), but so far so good from what I see.

Anyway, I’m submitting this as a bug. I’m not sure how to resolve it fully, since plugins could have problems with this too. I have a few test plugins that work off the capabilities record in usermeta, and call it by the current blog’s table prefix as well. Ugh…

Hi Kafkaesqui, yes. That solved it.

But might have conflicts such as you mentioned…. hopefully none will popup.

thanks for your help and effort. you do a great job helping ??

Happy holidays! Merry Christmas, and a Happy New Year! ??

Best,

-LR

I tried this on WP 2.1 and it didn’t work. Did I do something totally wrong (a possibility, for sure), or have some of the tables or some such changed?

Edited to add:

$this->cap_key = $table_prefix . 'capabilities'; doesn’t seem to exist in capabilities.php in 2.1.

So… am I just out of luck?

Found this fix in a year old patch for the user role issue.

Assuming you’ve got your unified user database, head into wp-includes/capabilities.php, to line 172 as of 2.12. (It’s in the function _init_caps.)

Change this:

if ( ! is_array($this->caps) )
         $this->caps = array();

To this:

if ( ! is_array($this->caps) ) {
         $this->caps = array();
         $this->roles = array();
         $this->set_role(get_settings('default_role'));
}

This won’t sync all user roles across the board, it will just guarantee that all users will at least be the default role (“Subscriber” in a normal installation), and thus be able to both log in without nasty error messages.

Any roles or capabilities other than defaults will still be unsynchronized between all blogs involved, but it seems to me that this will be relatively amenable to most people. The major problem with sharing a database is for new users (since you could manually set all existing users roles), and this fix solves that.

Hopes this helps someone else out there.

I’ve played around with this a little and I kinda have it working, but not quite the way I’d like.

I am trying to integrate the following…

1) WordPressMU
2) Instance of WordPress 2.1.2 running with a “wp_” prefix. This happens to be a “sitewide tags” blog (see the mu forums to know more about this).
3) A second instance of WordPress 2.1.2 with a “events_wp_” table prefix, used as a special site news and events blog (different from the main MU blog).
4) bbPress

I’ve got everything using the same cookies, so single login works across them all. And the user tables are working pretty well.

EXCEPT… using Dan’s ‘default_role’ suggestion exactly as above, I couldn’t access the admin backend to my 2nd WordPress instance (with the “events_wp_” table prefix).

I looked at the code and realized it was because even though admin was a user it was only given ‘default_role’ rights.

I got around this problem by extended Dan’s hack a little more. Namely, I added the following code…


if ( ! is_array($this->caps) ) {
$this->caps = array();
$this->roles = array();
$this->set_role(get_settings('default_role'));
}

if ($this->user_login == 'admin')
{
$this->add_role('administrator');
}

This works ok, but not great. For example, I’m not really able to use any other roles for users.

In looking at the code I wonder if the right fix is to adjust the $wpdb->prefix variable to match the prefix of the user table and user meta data. But my first attempt at modifying the “cap_key” and “role_key” didn’t seem to work. Is there a good source of documentation on how roles and capabilities are handled in the code base?

Oops sorry I haven’t read your last post — after modifying the wp-includes/capabilities.php file it works as it should ??

Figured out a workaround in WordPress 2.2:

1) Add new keys to the usermeta table in the database that corresponds to your prefix. For example, if your usermeta table is “wp_usermeta”, then you probably already have keys in there for “wp_capabilities” and “wp_user_level” for each user (except admin, which doesn’t have wp_user_level). Copy those rows to a new key, named “wp2_capabilities” and “wp2_user_level” (assuming your second blog has “w2_” as the prefix. I haven’t extensively tested this, it may be a pain to add/register new users.

2) The workaround in the code: edit line 169 from:
$this->cap_key = $wpdb->prefix . 'capabilities';
to:
$this->cap_key = 'wp_capabilities';

Hope this helps someone!

I read all the post but i cant undestando what to do and the order to do it, so, my situation is this,

1 fresh wordpress instalation connected to SMF via this Plugin (https://www.freakitude.com/2006/11/04/wordpress-smf-bridge/)

5 more blogs to install

what to do it, i understand that i need all the blogs in the same database and modify, the databases and the php’s but please someone explain it step by step

hmm we need to figure this out for 2.3

Yes, I agree – (for 2.3) – I have two WordPress instances sharing the same database, except for the options table. In the “second” instance, users get the insufficient permissions error. I don’t know how it is discriminating between the two set ups.