Opened 15 years ago
Closed 15 years ago
#12570 closed defect (bug) (worksforme)
New Network site non directory & non subdomain
Reported by: | Raptor235 | Owned by: | |
---|---|---|---|
Milestone: | Priority: | high | |
Severity: | major | Version: | 3.0 |
Component: | Administration | Keywords: | |
Focuses: | Cc: |
Description
I've been using WPMU for a few years running sites from different domains on one database... so I'm using wp30 to test things out and I've got my network enabled...
I've setup a new site as a subdomain... I then go in and edit the site settings change all sub domain info to actual different domains as I did before with MU... the new site loads fine no problems... data is showing up, default theme is working...
I can't login with my admin user name though... I'm not sure if the cross domain security is messing things up but my admin login is just being redirected back to the login page... with no error page...
I know that only subdomain and sub directory are "supported" however I've been using WPMU to do this without an issue and really there is no reason why other domains shouldn't be supported if one needs to...
any thoughts on this?
Change History (8)
#2
@
15 years ago
- Keywords login network domain removed
It sounds like something to do with cookies, and it would help to get to the bottom of what's going on there, as it could cause other problems as well.
That said, each subdomain/subdirectory blog is a row in wpdb->blogs, but they're all the same initial site ID, and thus one row in wpdb->site. Each domain should be a separate row in wpdb->site, however. So how is your installation set up?
#3
@
15 years ago
Hi nacin the db is setup as it should be all sites are on seperate rows... I narrow this down to the COOKIE_DOMAIN issue... the cookie cannot be set for the login function because the COOKIE_DOMAIN is set as the original parent site...
shouldn't COOKIE_DOMAIN be updated once you update the site_url in the options for that network site?
#4
@
15 years ago
Looks like everything is coming back to wp-config and define('DOMAIN_CURRENT_SITE', 'ampblogs.local' );
then for all the current_site instances and other cookie constants everything is using the DOMAIN_CURRENT_SITE which breaks login into a website that's been setup for other domains....
any suggestions here?
#5
follow-up:
↓ 6
@
15 years ago
Just a confirmation after changing wp-config to define('DOMAIN_CURRENT_SITE', 'hybridmile.local' );
I was able to log into that site without a problem...
could we not set this variable up dynamically to avoid this issue and assume whatever domain the browser is pointing to is what we're trying to log into?
#6
in reply to:
↑ 5
@
15 years ago
Replying to Raptor235:
could we not set this variable up dynamically to avoid this issue and assume whatever domain the browser is pointing to is what we're trying to log into?
By hard-coding it (whether it's done in wp-config.php, or sunrise.php), we improve performance and prevent unnecessary queries.
Your setup may require it to be handled differently. But the standard use-case is one "site" (one row in the site table). It's designed to be scalable without reducing performance at the smallest scale.
I'm seeing that DOMAIN_CURRENT_SITE is defined via network.php just as it was in MU's index-install.php. Thus, either you set up your MU install more than a year or two year ago (see http://trac.mu.wordpress.org/changeset/1422), or you removed the constant definition just as you'll need to do here.
#7
@
15 years ago
Hey there, you don't need to do a query... all I did to resolve this issue was change the hardcoded url to
define('DOMAIN_CURRENT_SITE', $_SERVERSERVER_NAME? );
works like a charm
can we implement this into the core or is there issues that might arise because of this?
#8
@
15 years ago
- Milestone 3.0 deleted
- Resolution set to worksforme
- Status changed from new to closed
We couldn't implement that in core, for a few reasons. It is dependent on the setup of both the server and the network as to whether that will work. Also, we clean up the domain name in ms-settings.php -- it isn't the raw SERVER_NAME value.
Just as an addition a subdomain site on the same setup works without a problem.