When you set up the second WordPress installation to point to the same database as the first one, did you choose a different table prefix in your wp-config.php file before doing the install? This is the line in the wp-config.php that controls what the prefix is:
/**
* WordPress Database Table prefix.
*
* You can have multiple installations in one database if you give each
* a unique prefix. Only numbers, letters, and underscores please!
*/
$table_prefix = 'wp_';
While I don’t suggest it, it is possible to run multiple WordPress installs from the same database as long as the prefix is different for the two installations.
If you use a different DB prefix there is no reason to prefix capabilities because they will come from different tables, depending on which installation is used. The only reason I see to prefix capabilities is if one were trying to run two sites from the same codebase, which seems plain crazy to me, just use the multi-site option.
Additionally, any solution that requires altering core files is a really bad solution and should be discarded from consideration.
Are you truly so restricted with databases that you cannot simply create a new database for the new site? Most hosts make available an adequate quota of DBs. Combined with the possibility of multi-site installs, I’m not seeing the point.
No, I’m not so restricted, I just wanted to make users sign up on only one site and they will be automatically registered on my second site. It works now perfectly, I just wanted to know how to fix You do not have sufficient permissions to access this page when trying to access admin dashboard on my second site. Can you help me, or is there any other possibility to share an user database between two sites without having them in one database?
This situation arises in these forums on a regular basis. Unfortunately I don’t know of any comprehensive topic that would set something up for you. There’s a number of approaches, by searching through old topics you might find an approach that resonates with you.
I would go ahead and have two installations, each with their own separate DB. Designate which installation is to be responsible for authenticating logins, I’ll call it the parent. Alter the other installation’s (child’s) authentication process to check password hashes contained in the parent’s DB. This way you don’t need to be concerned about odd behavior arising from unforeseen DB conflicts.
wp_authenticate_username_password() is used by default to authenticate users. It gets the user’s WP_User object based on the supplied login name with get_user_by(). get_user_by() is a pluggable function, meaning you can override it with your own function. The default gets user data from the DB and creates a new WP_User object based on it. Your replacement function would simply get the user data from the parent DB instead.
You can connect to the parent DB by creating a new object of the wpdb class. This would work just like the global $wpdb object, except it has a different name.
There are other functions that get user data, so the above fix only addresses part of the situation. You’ll need to track down other user functions and ensure they all use parent data. Another option would be to mirror the parent user data in the child DB. There aren’t too many functions that update the DB. They should all have hooks where you can update the child DB when the parent is updated.
You wouldnt by any chance have any tutorial for this?
I figured it out by using this tutorial.
You need to copy wp_capabilities and rename it ab_capabilities, where ab is the prefix of your second WordPress installation. Now you just need to copy the admin priviliges from wp_capabilities to ab_capabilities and it all works like a charm. The only problem is just that you cannot be logged in on both sites at the same time with this admin account.
But now I have another problem and that is that when an user who is for example subscriber on first wordpress installation comes to second, his user role doesnt copy to the second installation and he is an “orphan”.
Any help with this?
Yeah, you actually need to copy the wp_capabilities value in user meta for all users. And any time a user is created or their role or capability modified, the updated value needs to be copied again.
If manually copying becomes onerous, the process could be automated by hooking appropriate actions. Initially, the existing capabilities still need to be manually copied, but then the hooks can take over.
The not logged in to both sites rule would apply to all users, which could become a problem. I think it may be possible to create some sort of semaphore system between the sites; where, should a user try to access the other site while the semaphore is “up” for the current site, the other site would only respond with a “please log out of my-other-domain.com first” message.
