Search This Blog

Sunday, February 1, 2009

Setting up a common login across multiple wordpress installations

A pre-requisite for promoting interaction across sub-domains..


After setting up wisdomspeak.org/mantra, wisdomspeak.org/vedictalks and wisdomspeak.org/gita, i realized that the only way the parent website, wisdomspeak.org, was going to get popular were through inviting user interaction on discussion boards. But for this, users would need to be logged into different sub-domains through a single login (like a global single sign-on feature of Oracle applications).

Assumptions:


First and foremost, the version of wordpress installed on the multiple sub-domains was version 2.7. Also, the wordpress installations were done in the same database, with different table prefixes.

The table_prefix of the first wordpress installation (wisdomspeak.org/mantra) was "wp_", whereas the table prefix of the other wordpress installation with which I wanted to share the userbase of wisdomspeak.org/mantra, was "gita_".

Now I had to make wisdomspeak.org/gita use the same users/roles as wisdomspeak.org/mantra.

What worked finally..


Once you try googling it yourself, this is probably the most straightforward and common response that you would see:

In the wp-config.php of the 2nd wordpress installation, after this line:
/* That's all, stop editing! Happy blogging. */

..add the following:
define('COOKIE_DOMAIN', '.wisdomspeak.org');
define('COOKIEPATH', '/');
define('CUSTOM_USER_TABLE', 'wp_users');
define('CUSTOM_USER_META_TABLE', 'wp_usermeta');

But when I was going to wisdomspeak.org/gita/wp-login.php and trying to login as admin user, I was getting you do not have " You do not have sufficient permissions to access this page." error message while using firefox browser, while IE just gave up with a page not found error.
Interestingly, this error is also encountered a log while people upgrade wordpress installations, so there is a lot of scope of mixing up resolutions while trying to solve this. Better be wary of mixing different recipes.

And so, in desperation, I searched for more options/resolutions and came across a post that suggested changing the prefix values of meta_key column in the <table_prefix>_usermeta table of the 2nd word press installation. Using this hint, I did some more tweaking by opening the phpMyAdmin interface of the gita_metadata, but the permissions error was still coming.

So, i searched a bit more and came across a posting in which a user was not able to make it work, in spite of manually the prefix of <table_prefix>_capabilities table referred in $WORDPRESS_HOME/wp-includes/capabilities.php to the table_prefix of the earlier wordpress installation (which was wp_ in my case). The change is actually quite simple: you are fixing the name of the capabilities table for a user to be wp_capabilities.
function _init_caps() {
global $wpdb;
/* $this->cap_key = $wpdb->prefix . 'capabilities'; -- the earlier entry*/
$this->cap_key = 'wp_capabilities'; /* the new entry */
$this->caps = &$this->{$this->cap_key};

And when I tried with this, not only was I able to login with the admin user's password for wordpress installation 1 in wordpress installation 2, but when I changed the URL from wisdomspeak.org/gita/wp-admin/ to wisdomspeak.org/mantra/wp-admin/, i was not redicted to a login page again, which meant that the same user was shared across different wordpress installation. (It did ask me the login once for wisdomspeak.org/mantra/wp-admin/, so perhaps the cookie was not shared really, but that is something I need to doublecheck).

Extending this concept to roles?


While going across capabilities.php, I came across a similar looking entry for user_roles and thought that logically speaking, a similar fix would be needed in capabilities.php to re-use the user roles :
function _init () {
global $wpdb;
global $wp_user_roles;
/* $this->role_key = $wpdb->prefix . 'user_roles';
$this->role_key = 'wp_user_roles';

But when I tried this, i started getting the "You do not have sufficient permissions to access this page." error again. On reverting it back like this, the login started working again:
function _init () {
global $wpdb;
global $wp_user_roles;
$this->role_key = $wpdb->prefix . 'user_roles';
/* $this->role_key = 'wp_user_roles'; */

So was it really needed..


Looking back, changing the meta_key column's entries in gita_usermeta table did not make any sense, since I was never going to use that table. To prove this point, i changed the prefix values for meta_key column back to gita_ and the admin user was still shared across wisdomspeak.org/mantra nad wisdomspeak.org/gita.

How to share cookies across wp installs in a common domain?


Thanks to Ben (whose comment can be seen below) for sharing the secret for making cookies work across wordpress installs in a common domain:

1) Use the same auth_salt, logged_in_salt, secret key in /wp-admin/options.php page for each sub-domain blog

2) Install Root-cookie plugin ( by LINICKX )

* http://www.linickx.com/archives/831/root-cookie-path-14-an-update-for-wordpress-27

1. Upload root-cookie.php to the /wp-content/plugins/ directory
2. Activate the plugin through the 'Plugins' menu in WordPress
3. Log out
4. Log in
5. Done :o)

3) And in: wp-settings.php

Change this source code like this:

351 - define('COOKIEHASH', md5(get_option('siteurl')));

to:

351 -  define('COOKIEHASH', md5(get_option('http://www.mysite.com')));

Yippee!


All right, so that was a good learning on an early Sunday morning; All in 1 hour of googling and trying out options. Dont they say that early mornings are the most productive of times.