Multiblog single login in WP 2.6

As described in the last post, is built from a number of WP blogs that share common user tables. After the next overhaul of the site is completed, users will be able to create user accounts that will work for commenting and the forum (which will be run on bbPress). Not only should these accounts be shared among the blogs that make up the site, but the user should not have to log in again to move from one blog to another. Here is how you can make this work.

I assume all of your sites have the same base domain such as,,, etc.

WordPress tracks logged in users using cookies. By default, cookies only match the subdomain in which they are assigned. By setting the cookie domain to the root domain prefixed by a period, i.e. “”, you allow the cookie to be read by all subdomains. Set it by setting by putting

define('COOKIE_DOMAIN', ''); //replace with your domain, of course

in your wp-config.php (or in each wp-config.php, if you don’t have a shared installation).

I couldn’t for the life of me get this to work in my test environment until I read this post and learned that the cookie domain has to have an internal dot (.) in it to be accepted by the browser.

If you have different subpaths for different installations (i.e.,, you must also set the COOKIEPATH to the root:

define('COOKIEPATH', '/');

Now cookies can be read across subdomains, but they also have to share names and keys. WP 2.6 uses a multitude of different hash keys to increase cookie security – all of them have to be identical across installations. For starters, the keys SECRET_KEY, AUTH_KEY, SECURE_AUTH_KEY and LOGGED_IN_KEY must be the same in each wp-config.php. Of course if you have a shared installation, they already are. These keys are used as salt when hashing a cookie value.

But these aren’t considered sufficient and WP also adds additional salt, which is stored as an option in the database, and is usually different for each install, which makes the cookie values incompatible. You can easily override these salts by defining AUTH_SALT and LOGGED_IN_SALT in your wp-config.php files. (You can generate suitable values here.)

Putting this salt in your wp-config.php sort of defeats the purpose of having additional salt; the point is that having the salt in different places makes it harder for would-be attackers to use. This doesn’t seem like an insane security risk, but there are other ways to get around the salt problem:

  1. Write a plugin that adds a ’salt’ filter that returns the same value for each blog.
  2. Synchronize the auth_salt and logged_in_salt options across the different blog tables.
  3. Write your own wp_salt(). It’s in pluggable.php and can be overwritten without hacking source.

Finally, WP sets cookie names using COOKIEHASH, which is generated in wp-settings.php by taking an md5 hash of the siteurl option. WP does not check to see if this is already defined, so if you define it in your wp-config.php, php will give you a notice when WP tries to define it again (if you have php set up to log such notices). This isn’t likely to give you any trouble, but if it disturbs your sensibilities you can either hack wp-settings.php (very easy, but every change to core code means more to remember when you upgrade) or individually define USER_COOKIE, PASS_COOKIE, AUTH_COOKIE, SECURE_AUTH_COOKIE, LOGGED_IN_COOKIE and TEST_COOKIE (all of which WP does check before defining) in your wp-config.php.

Now, clear your cookies (restarting your browser should do it) and try it!

10 Responses to “Multiblog single login in WP 2.6”

  1. [...] Note that there is no way to limit access on a per-blog basis. Also, cookies are not shared, so you will have to log in to each one separately. I’ll describe a fix for this in a later post. (UPDATE: Here’s how to enable single login.) [...]

  2. Space Babe says:

    Blogga lite mer av dina fantastiska recept och lite mindre Wordpress-nörderi.

  3. Unga Morsan says:

    Säger som ovan på order av din fru: Blogga lite mer av dina fantastiska recept och lite mindre Wordpress-nörderi.

  4. Örjan says:

    Min variant.
    Fortsätt med Wordpress-nörderiet. Det har ju gett oss fantastiska Taffel-sidor.
    Men snälla, nyfiken på de påstått fantastiska recepten.
    Hoppas du vill avdela tid till att skriva ned dem.

  5. you can send or show the example of plugin that return the same salt for each blog?

  6. Johan says:

    @Jorge: I haven’t written such a plugin, but there is a filter hook called ’salt’ which makes it possible to write a filter that modifies the return value of wp_salt(). (In pluggable.php). Or write a new wp_salt() and put it in a plug-in.

  7. Monica says:

    Johan, would this work the same way for WP 2.7??

  8. Johan says:

    @Monica: Because of the holidays I haven’t done enough testing to be able to upgrade from 2.6. So my answer is: probably.

    This guy in Spain:
    uses these instructions in his tutorial with WP 2.7. My Spanish is almost nonexistent, but what he does with the code doesn’t seem to have changed.

  9. g.ciprian says:

    Hi. But what if subdirectories style) is WPMU and is WP ? Can I apply this how-to so that users blooging in should not register/reauthenticate in I’v read that the difference between WPMU and WP is that in the WPMU’s database is a blog_id field extra entry. In this case the main db that I have to install primarly is of the WPMU’s and then, on the second install, on I only have to point to this db with different prefix?
    Thank you!

  10. Johan says:

    @g.ciprian: I’m not an expert on WPMU, but my guess is that this will be more complicated. I’m certain you can install WP in the same db as WPMU as long as you use different table prefixes. But can you get WP to use the same user tables as WPMU? Sounds unlikely to work by the method above. WPMU presumably (as I said, I’m not an expert on this) has differences in the user tables since it has to handle multiple blogs. Another thing that’s likely to cause trouble is that the versions aren’t in sync – WPMU tends to lag way behind WP in frequency of updates. And there have been recent changes to what WP does with cookies.

    I won’t say that what you’re trying to do is impossible, but it will likely involve overriding some of the authentication stuff in pluggable.php on the WP side to make it play nice with WPMU.

    What I wrote about the cookie domain is definitely relevant in your case as well.