Domain Mapping: Cross Domain Login Not Working

I am using the Domain Mapping plugin on a site also running BuddyPress. Before I used the plugin form Donncha, but switched to this one when the cross domain login was added.

In short: domain mapping is working, but I am having to login again on each mapped blog.

Any ideas?


    Can you have a look at what is being loaded in the header of one of your admin pages (when logged in on the mapped domain). If possible use firefox and firebugs net tag, which will show the pages that aren't loading in red.

    And if poss, post your config file here (but with the passwords and AUTH_KEY / Has fields removed / blanked out.

    Nathan Barry

    I only had one file show up as not loading in Firebug, and that was the widget-blogs.css file for BuddyPress.

    Here is my wp-config file:


    * The base configurations of the WordPress.
    * Do not try to create this file manually. Read the README.txt and run the
    * web installer.
    * This file has the following configurations: MySQL settings, Table Prefix,
    * Secret Keys, WordPress Language, and ABSPATH.
    * This file is used by the wp-config.php creation script during the
    * installation.
    * @package WordPress

    // ** MySQL settings - You can get this info from your web host ** //
    /** The name of the database for WordPress */
    define('DB_NAME', 'shop208beta');

    /** MySQL database username */
    define('DB_USER', 'shopbeta');

    /** MySQL database password */
    define('DB_PASSWORD', '****');

    /** MySQL hostname */
    define('DB_HOST', 'localhost');

    /** Database Charset to use in creating database tables. */
    define('DB_CHARSET', 'utf8');

    /** The Database Collate type. Don't change this if in doubt. */
    define('DB_COLLATE', '');
    define('VHOST', 'yes');
    $base = '/';
    //define('CURRENT_SITE', '' );
    define('PATH_CURRENT_SITE', '/' );
    define('SITE_ID_CURRENT_SITE', 1);
    //define('BLOGID_CURRENT_SITE', '1' );

    * Authentication Unique Keys.
    * Change these to different unique phrases!
    * You can generate these using the {@link secret-key service}
    * @since 2.6.0
    define('AUTH_KEY', '****');
    define('SECURE_AUTH_KEY', '****');
    define('LOGGED_IN_KEY', '****');
    define('NONCE_KEY', '****');
    define('AUTH_SALT', '****');
    define('LOGGED_IN_SALT', '****');
    define('SECURE_AUTH_SALT', '****');

    * 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_';

    * WordPress Localized Language, defaults to English.
    * Change this to localize WordPress. A corresponding MO file for the chosen
    * language must be installed to wp-content/languages. For example, install
    * to wp-content/languages and set WPLANG to 'de' to enable German
    * language support.
    define ('WPLANG', 'shop208');

    // double check $base
    if( $base == 'BASE' )
    die( 'Problem in wp-config.php - $base is set to BASE when it should be the path like "/" or "/blogs/"! Please fix it!' );

    // uncomment this to enable wp-content/sunrise.php support
    define( 'SUNRISE', 'on' );

    // uncomment to move wp-content/blogs.dir to another relative path
    // remember to change WP_CONTENT too.
    // define( "UPLOADBLOGSDIR", "fileserver" );

    // If VHOST is 'yes' uncomment and set this to a URL to redirect if a blog does not exist or is a 404 on the main blog. (Useful if signup is disabled)
    // For example, the browser will redirect to for the following: define( 'NOBLOGREDIRECT', '' );
    // Set this value to %siteurl% to redirect to the root of the site
    // define( 'NOBLOGREDIRECT', '' );
    // On a directory based install you must use the theme 404 handler.

    // Location of mu-plugins
    // define( 'WPMU_PLUGIN_DIR', '' );
    // define( 'WPMU_PLUGIN_URL', '' );
    // define( 'MUPLUGINDIR', 'wp-content/mu-plugins' );

    // Uncomment to disable the site admin bar
    //define( 'NOADMINBAR', 1 );

    define( "WP_USE_MULTIPLE_DB", false );

    /* That's all, stop editing! Happy blogging. */

    /** WordPress absolute path to the Wordpress directory. */
    if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

    /** Sets up WordPress vars and included files. */
    require_once(ABSPATH . 'wp-settings.php');


    I would try commenting these two lines out as well to be sure:
    define('PATH_CURRENT_SITE', '/' );
    define('SITE_ID_CURRENT_SITE', 1);

    Then, clear all the cookies on your main domain and the mapped one. Log in to the mapped domain and have a look at the cookies that start with wordpress to see what domains it has created cookie for.

    Nathan Barry

    I commented out those two lines.

    Then when logging into the mapped domain it creates cookies for both that and the primary domain. Then I am logged into both domains.

    But if I log into the primary domain first, then click to the mapped domain, it doesn't have the needed cookies and I am not logged in on the mapped domain.

    Does that help?


    Just to go over what we have so far:
    You have and it's mapped domain

    if you log into then it creates the cookies for (and thus

    if you log into it doesn't create the cookies for

    You have a single domain mapped to

    Nathan Barry

    Yes that sounds right.

    I have mapped to the blog & mapped to (only one domain mapped to each blog). Then I have

    If I log into it creates cookies for itself and for, but not

    If I log into it creates cookies for itself, but no subdomain blog.

    It is still just one domain mapped to each blog.

    Now I was using Donncha's version of the plugin before if that makes a difference.



    But if I log into the primary domain first, then click to the mapped domain, it doesn't have the needed cookies and I am not logged in on the mapped domain.

    I don't think this is a feature of our plugin.

    Then when logging into the mapped domain it creates cookies for both that and the primary domain. Then I am logged into both domains.

    That is the feature advertised as Cross Domain Logins.

    Barry, can you confirm?

    Nathan Barry

    Seeing this on the marketing site made me think that the plugin was more robust:

    And, naturally, we've built in cross domain cookie syncing, so your users will stay logged in (or out) regardless of whether they are on your standard domain or their custom one.

    It definitely sounds like if you login to one mapped domain, you will be logged into ALL mapped domains on the MU installation.


    It should work like this: ->

    These are the orig domains and the mapped domains.

    If I log into it will automatically create the cookies for
    If I log into it will automatically create the cookies for

    if I log into (the main site) it won't create any cookies because it doesn't have a mapped domain ( does)

    James Farmer

    Not sure I agree with you there Nathan, although we'll certainly consider any extra features you;d like to see, just put in a quick description and we'll discuss them with other members and check out interest.

    Nathan Barry

    Here is the functionality I would like to see (and what I thought I was buying):

    1. If you login to your primary domain, then you are logged into all mapped domains as well.
    2. If you login on a mapped domain, then you would also get logged into all other mapped domains.

    Now the more I think about it that is a lot of cookies to create. So maybe this would be better:

    When a user visits a mapped domain it checks to see if they are logged in on the primary domain. If they are not logged in, it does nothing (or asks them to login). If they are logged in on the primary domain it then creates the cookies for the mapped domain.

    I am not sure what the best implementation would be, that is just one idea.

    What do you think? Useful?

    I agree something needs done because as of now, there's some functionality issues for end-users.

    mu Install =
    User Install =
    User Install Mapped =

    Our users are, for the most part, no matter how many times we tell them otherwise, logging into their dashboards from our Which, even if they have a mapped domain, auto-forwards them to their dashboard.

    Guess what? Post previews, theme previews, etc. etc. all break for a user with a mapped domain that's logged into their subdomain instead, which is where the sends them.

    Even if could auto-forward them to their mapped domain dashboard if they have one, instead of subdomain dashboard, that would solve all of those problems. Then we wouldn't have to worry about the actual mapping issues within the subdomain dashboard.


    Ok, this is the functionality so far:

    Log in to - logs user into,,

    Log in to - logs into,,

    That is the functionality as of the current version (2.0).

    If a user logs into, then they are also logged into, but not - primarily because they could have multiple blogs, each with a mapped domain. So either we add in the overhead of creating cookies for or checkin login status for EVERY mapped domain they have, or we can have them pick a single mapped domain that they have as their main domain and only log them into that one, OR we do nothing.

    Nathan Barry

    How much overhead is it to check, when the user visits if they are already logged in to and if so automatically log them in to

    This way you could simulate the behavior of being logged into all mapped domains when you login to one, but without having to create all those cookies every time.

    or we can have them pick a single mapped domain that they have as their main domain and only log them into that one, OR we do nothing.

    My personal opinion would be let them set a main domain and only log them into that. I think that'd take care of a lot of issues, at least issues that we are getting complaints about from end-users.

    Although could just be that we're an exception, and if other people aren't having these types of end-user problem, we need to come up with something that's more specific to our installs.

    Thanks as always for all of your work on this.


    Setting a main domain is a good idea. I'll look into that.

    It's tricky, I'm sure there is a way to do it, but it may take some thought.
    The only way, it seems, to see if a user is logged into WPMU is to check for a logged_in cookie on that domain. Now, obviously, if we are on we can't read the cookies for because of the in-built browser security, so we have no way to do a quick check to see if they are logged into the main site.

    If we could include a file on the domain to check that cookie, then it's not easy to pass back the yes or no to the mapped domain without opening a whole raft of potential security issues.


    How about asking from the main site if user is logged there (has the appropriate cookies)? Is it possible to use some kind of redirection for that?

    Namely this is a feature I would very much like to see:

    Login to any hosted domain - Single Sign On to all of them.
    Logout from any - Single Logoff from all of them,


    perhaps this should be optional...
    it sure IS much overhead to create cookies for EVERY mapped Domain on login. But this is only a problem for large numbers of domains...

    However, I'll sure try to implement this in my site, since I really need this feature and it was the reason I signed in to this site in the first place...
    I would appreciate any hint on how to do this, which would save me some time. (create cookies for all sites, logout for all sites)


    To create a cookie for every domain you have to create a cookie AT every domain, from that domain.

    That means adding a file in the header of every page load, from EVERY domain (got 30 domains mapped on your site, you have to include 30 files in the header of each page) to ensure that the logged in cookies for each of those domains exists.

    I'm trying to come up with a different method at the moment, but am not 100% sure how practical it will work.

    If you want to use the existing functionality, but for all domains you will have to look at the build_cookie function (around line 178) and see how that adds the relevant file for a single domain. Change that to loop through all domains and add multiple files.

    For each generated file in the header, the function directly underneath the build_cookie function is called. This function generates and removes the relevant cookies. You should be able to leave that one alone though as it will work as is for each file load generated by the build_cookie function.

    I hope that helps somewhat. Hopefully my new method will work better than this approach, but it needs some thinking through and testing first.


    I'm trying to come up with a different method at the moment, but am not 100% sure how practical it will work.

    My understanding of how the version used to work (it got explained in very basic terms once in the support forums) is their version tries to detect if the mapped domain cookie is present. If yes, all is good. If not, it then tries to detect if the main cookie is present. If it;s not, the process ends as the user is not logged in. If the main site cookie is detected, then a cookie is served for the mapped domain. Going off memory though.

    They used to use some weird 30 minute process way back when that had issues. If you search the forums for 37 strikes or 37 pitches or whatever that blog is called, you should find about a dozen threads where folks were complaining about how after creating an account, folks still couldn;t create comments. They went away after a while so they muct have changed something.


    @drmike - thanks for the idea - I've had a hunt around forums but couldn't find anything, however I did find some people using the domain mapping, so I've had a look at their sites to see what's going on behind the scenes...

    Looks like my new approach was on a similar track, so I shall push ahead with it.


    I will revive this old thread. I am using Domain Mapping 3.0 with WP3.01 and BP.

    When I domain map a sub-folder, the mapping works OK but the cross-domain login gets killed.

    I have played with this enough to confirm it is repeatable, even after clearing browser history.

    The strange thing is this problem did not occur last week, only this week.

    Are there any new solutions to this problem since the last comment in this thread?



    Denis Lam

    I just discovered I have a cookie issue... Domain mapping works no problem with my WPMU subdomain set up however I have to login again when I go to that mapped domain.

    In my wp-config, I have these set up:

    define('WP_ALLOW_MULTISITE', true);
    define('MULTISITE', true);
    define('SUBDOMAIN_INSTALL', true);
    define('DOMAIN_CURRENT_SITE', '');
    //define('PATH_CURRENT_SITE', '/');
    //define('SITE_ID_CURRENT_SITE', 1);
    //define('BLOG_ID_CURRENT_SITE', 1);
    define( 'NOBLOGREDIRECT', '' );

    Is there something I need to change?


    Sorry to revive an old thread, but has any progress been made on this issue? I just purchased this plugin completely because of this sentence on the main plugin page, "Cross domain syncing is built in, so your users will stay logged in (or out) regardless of whether they are on your standard domain or their own custom one." But it's not doing what I expected...

    I still run into the same issue that others are having whereas I can login to my mapped subdomain and get logged into my main domain too, but when logging into my main domain I don't get logged into my mapped subdomain.

    If a solution has not been found for this, I'd like a refund for the purchase I made about 30 minutes ago based on what I believe to be false-advertising. (You guys even noticed how misleading it was in an above post but seem to have chose not to do anything to make it more clear...) Otherwise, this is a very nice plugin. Thanks!


We pride ourselves on our level of customer support and responsiveness to member requests. Your WordPress experience will never be the same

Start free trial