Nathan Barry
Sophomore
Just Getting Started
Member Likes (0)
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?
Responses (36)
Developer (joined June 2008) Likes (0)
Have you gone through the steps in this post:
http://premium.wpmudev.org/forums/topic/domain-mapping-wpmu-dev-premium-style#post-14715
Member (joined September 2008) Likes (0)
I went through the entire thread, but didn't find anything to fix my problem. Can you be specific?
Developer (joined June 2008) Likes (0)
Have you got any of the following defines in your wp-config.php?
COOKIE_DOMAIN, DOMAIN_CURRENT_SITE or BLOGID_CURRENT_SITE if so can you comment them out.
Member (joined September 2008) Likes (0)
I have both DOMAIN_CURRENT_SITE and BLOGID_CURRENT_SITE.
I commented those out, but the cross domain login still doesn't work. Any more ideas?
Developer (joined June 2008) Likes (0)
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.
Member (joined September 2008) Likes (0)
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:
-------------------------
<?php
/**
* 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', 'shop208beta.com' );
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 https://api.wordpress.org/secret-key/1.1/ WordPress.org 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
* de.mo 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 http://examples.com/ for the following: define( 'NOBLOGREDIRECT', 'http://example.com/' );
// 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');
?>
Member (joined September 2008) Likes (0)
Any ideas for making this work?
This site is supposed to go live tomorrow.
I appreciate the help!
Developer (joined June 2008) Likes (0)
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.
Member (joined September 2008) Likes (0)
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?
Developer (joined June 2008) Likes (0)
Just to go over what we have so far:
You have sub.domain.com and it's mapped domain subdomain.com
if you log into subdomain.com then it creates the cookies for domain.com (and thus sub.domain.com)
if you log into sub.domain.com it doesn't create the cookies for subdomain.com?
You have a single domain mapped to sub.domain.com?
Member (joined September 2008) Likes (0)
Yes that sounds right.
I have subdomain1.com mapped to the blog sub1.primarydomain.com & subdomain2.com mapped to sub2.primarydomain.com (only one domain mapped to each blog). Then I have primarydomain.com.
If I log into subdomain1.com it creates cookies for itself and for primarydomain.com, but not subdomain2.com.
If I log into primarydomain.com 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.
Thanks!
Lead Developer (joined May 2009) Likes (0)
I don't think this is a feature of our plugin.
That is the feature advertised as Cross Domain Logins.
Barry, can you confirm?
Member (joined September 2008) Likes (0)
Seeing this on the marketing site made me think that the plugin was more robust:
It definitely sounds like if you login to one mapped domain, you will be logged into ALL mapped domains on the MU installation.
Founder & CEO (joined May 2007) Likes (0)
Hmmm... I think it is a feature, but I'm not 100%... it certainly *should* be a feature :)
Will look into it more...
Apologies for any confusion.
Member (joined September 2008) Likes (0)
Well, I appreciate you guys looking into it more.
Member (joined September 2008) Likes (0)
Has any progress been made on this?
Developer (joined June 2008) Likes (0)
It should work like this:
sub.domain.com -> mysub.com
These are the orig domains and the mapped domains.
If I log into sub.domain.com it will automatically create the cookies for mysub.com
If I log into mysub.com it will automatically create the cookies for sub.domain.com
if I log into domain.com (the main site) it won't create any cookies because it doesn't have a mapped domain (sub.domain.com does)
Member (joined September 2008) Likes (0)
It seems as though this is quite a bit more basic than advertised. Are there plans to build the robust cross-domain login plugin mentioned on your marketing page?
Founder & CEO (joined May 2007) Likes (0)
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.
Member (joined September 2008) Likes (0)
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?
(joined January 1970) Likes (0)
I agree something needs done because as of now, there's some functionality issues for end-users.
mu Install = MUInstallDomain.com
User Install = user.MuInstallDomain.com
User Install Mapped = UserInstallMapped.com
Our users are, for the most part, no matter how many times we tell them otherwise, logging into their dashboards from our MUInstallDomain.com Which, even if they have a mapped domain, auto-forwards them to their user.MuInstallDomain.com 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 MuInstallDomain.com sends them.
Even if MuInstallDomain.com 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.
Developer (joined June 2008) Likes (0)
Ok, this is the functionality so far:
Log in to sub.domain.com - logs user into sub.domain.com, domain.com, mappeddomain.com
Log in to mappeddomain.com - logs into mappeddomain.com, sub.domain.com, domain.com
That is the functionality as of the current version (2.0).
If a user logs into domain.com, then they are also logged into sub.domain.com, but not mappeddomain.com - 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.
Member (joined September 2008) Likes (0)
How much overhead is it to check, when the user visits mappeddomain1.com if they are already logged in to domain.com and if so automatically log them in to mappeddomain1.com.
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.
(joined January 1970) Likes (0)
@Barry
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.
Developer (joined June 2008) Likes (0)
Setting a main domain is a good idea. I'll look into that.
@Nathan
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 mappeddomain1.com we can't read the cookies for domain.com 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.com 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.
Member (joined September 2008) Likes (0)
Has there been more thought on enhancing this plugin? That would make it very powerful!
Erstwhile founder (joined May 2007) Likes (0)
At the moment we're busy preparing other plugins for launch. We'll revisit this plugin shortly.
Thanks,
Andrew
Member (joined May 2009) Likes (0)
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,
Member (joined February 2010) Likes (0)
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)
Erstwhile founder (joined May 2007) Likes (0)
Hiya,
Barry (plugin developer) will get back to you on this as soon as possible :)
Thanks,
Andrew
Developer (joined June 2008) Likes (0)
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.
Keeper of the Dark Chocolate (joined July 2007) Likes (0)
My understanding of how the wp.com 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 wp.com 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.
Member (joined February 2010) Likes (0)
Hey there,
thanks a lot for the fast response on my q. (the support here really IS superb) I'll try looking into it these days.
greetings from Berlin
Developer (joined June 2008) Likes (0)
@drmike - thanks for the idea - I've had a hunt around WP.com forums but couldn't find anything, however I did find some people using the wp.com 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.
Member (joined March 2010) Likes (0)
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?
Thanks,
Ed
Member (joined January 2013) Likes (0)
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:
Is there something I need to change?
WordPress Questions?
We've got answers!
Find out more »