I setup a Page for testing which used this code:

global $base_url;
print $base_url;

to test what value was being given. When Domain Access is turned on, this value becomes different than what is in settings.php. Is this pulling the value from a stored / cached location? It is definitely not pulling from the settings.php file (even after clearing the cache multiple times).

This becomes a problem because I had duplicated our database from our live server to a development server; and somewhere in the database this value is stored. I checked the Drupal databases and found nothing; but subsequently turning On and then turning Off the Domain Access module allows you to watch the value change before your eyes.

CommentFileSizeAuthor
#14 Picture 2.png65.56 KBagentrickard

Comments

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

Just a quick clarification, when Domain Access is disabled, the value is taken from settings.php (and is correct).

Also, this becomes a much bigger problem when attempting to post forms (for editing nodes and turning on other modules) since all forms are then given the incorrect $base_url path as their form action, when Domain Access is activated.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Active » Closed (works as designed)

You cannot hard code $base_url when using Domain Access.

See section 4.1 of INSTALL.txt

----
4.1   $base_url

The $base_url setting is normally not set.  With Domain Access, you
cannot set this value manually.

Since multiple domains are involved, Drupal needs to be allowed to
set this value.  (For the technical, this happens in the conf_init() 
function).

See also http://drupal.org/node/217710#comment-718517.

Please read the documentation carefully. You are fighting against the design of the module. Form actions are handled for you automatically. See domain_form_alter().

http://therickards.com/api/function/domain_form_alter/Domain

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

See also http://drupal.org/node/196217

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

Thanks for the reply. I understand this, I should have also mentioned that even with $base_url commented out of settings.php, the value for this is changing when Domain Access is activated.

Let me give you the real use case that's happening in my testing.

exampledev.com/testing - this is the page on my Development Server that is echoing the $base_url value.

When DA is disabled, this value is returned correctly, even after $base_url has been commented out. When the DA module is activated, without any sub-modules activated, the value returned by my test page becomes:

shop.example.com - a completely different URL that was part of the previous installation, which has been migrated to the Dev server.

My question is, where is this value stored? I've searched the Drupal system and variable tables to no avail. Somewhere this value is being incorrectly retrieved, and it's making the configuration of my development environment take a bit longer than it should :)

Thanks again.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Category: bug » support
Status: Closed (works as designed) » Active

It's not being stored. It is generated dynamically by Drupal's conf_init() function and placed into a global variable.

http://api.drupal.org/api/function/conf_init/5

This many be a DNS configuration issue. Or possibly you haven't finished configuring the module.

If you set the primary domain and then try to access a domain that is not registered as a DA domain, then the module will force you to the primary domain. So perhaps this is occurring.

For example:

DNS records correctly map the following domains to your Drupal installation:

example.com
one.example.com
two.example.com

If you set 'example.com' to be the primary domain, all requests for "unknown" domains will resolve there. That is, domains that are unknown to the Domain Access module.

So if you do not configure Domain Access (by creating a domain record) for each subdomain, here's what happens:

-- User tries to access one.example.com
-- Webserver sends the user to Drupal
-- Drupal (the Domain module) does not recognize one.example.com
-- Domain module pops user to example.com

--

it is also possible, if you are upgrading a legacy site and still have multiple folders inside your 'sites' directory, that an old settings.php file is being loaded.

I am on IRC right now.

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

It's not that I'm being "sent" anywhere - the value that is being generated by conf_init() is the value from the old server. Unless that function, which I'm not familiar with, is somehow finding DNS records then that could be a possibility; the only problem with that, is that the domain it keeps generating is not hosted on this particular server.

This is a new installation, with no extra sites/ folders, just sites/all and sites/default. But I will look for any extraneous settings.php files.

I have an IP address only site, and my hosts file set to resolve them, as well as a VirtualHosts setup in Apache to do the domain aliasing. Everything seems to work correctly, including domain aliasing, the only thing that is incorrect is the value of $base_url when Domain Access is enabled.

I'll try to narrow this down further. I appreciate all your help.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

conf_init() wouldn't be finding DNS records. it pulls from $_SERVER['HTTP_HOST']

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

Any other ideas? I even tried manipulating the value of $base_url directly in the conf_init function, to no avail.

And I confirmed again, that when viewing my testing page, the $base_url shows up as shop.example.com (the OLD value) as opposed to the domain it currently resides at, we'll call that exampledev.com. This is even true if I view the file at an IP address, the $base_url shows up as the old value.

When I disable Domain Access, the value becomes generated from the current domain as it should be in the first place. I suspect this issue goes a little deeper, possibly somewhere in Drupal itself, but I find it curious that it only shows up when Domain Access is enabled.

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

Using the LiveHTTPHeaders extension for FireFox, it looks like I'm seeing somewhat the same issue as was seen here: http://drupal.org/node/215657 .. where the form sends a request to the correct domain, but it comes back with a 302 redirect. I'm not quite sure what is causing this, but it does seem to be related to $base_url not being correct - at least, that is my guess. Unfortunately this may hold up our site until I can get it resolved. Thanks again for helping me troubleshoot. Enjoy the free tracks :)

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

And when DA is enabled, you are viewing exampledev.com, not shop.example.com? See the first part of comment #5.

This comment is no longer relevant. It was posted a the same time as #9.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Oh, well http://drupal.org/node/215657 was a misconfiguration on the user's part.

What do you have your Primary Domain set as? That needs to be a host configured and accessible by your webserver.

I suspect you are having a DNS issue.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

I actually have code (in testing) that prevents you from setting the Primary Domain to any host that returns an HTTP request other than 200.

If may be that you're doing some sort of redirect 302 from www.example.com to example.com, in that case, I suspect a misconfiguration of the Primary Domain.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

To fix this, you may need to edit the {variables} table directly in MySQL. Set the domain_root variable to a web server address that returns a 200 value -- not a redirect.

Then clear the {cache} table.

See http://drupal.org/node/215657#comment-711720

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
StatusFileSize
new Picture 2.png65.56 KB

LiveHTTPHeaders is cool. Attached is a shot of my test setup. I have hosts configured to map 127.0.0.1 to 'example.com' which I use as my Primary Domain.

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

That sounds like it could be the issue. I will re-check my DNS information - still strange, though, that it comes up with a specific shop.example.com. At least it seems odd to me.

Thanks again for your help, I'll report back once I've gone over every detail with a fine toothed comb.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

I think that's your DNS speaking, not Drupal. You aren't using anything custom in .htaccess or mod_rewrite, are you?

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

Ken,

I'm still experiencing this issue. The DNS is being set correctly, there is only one settings.php file, Apache is setup correctly (I commented out the VirtualHost entries in httpd.conf) and everything appears to be setup correctly in Drupal. When I go to, for instance, the Site Information screen to setup my front page, the site prefix correctly displays as:

http://www.exampledev.com

But when I turn on Domain Access, it changes to:

http://shop.example.com

Which, again, is the value from the old server that the database was migrated from. I'm not sure why, if Drupal no longer has this value stored anywhere, the value keeps coming back up when Domain Access is enabled.

Very, very strange and I'm ready to do a database dump and try again - but that might set me back as I'd rather work on an existing exact duplicate of our live site which has accumulated quite a bit of data.

Thanks again for any insight you can provide.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Did you remove the row from the variables table as instructed in #13?

The only place this value might be stored is there.

You might also try this. Disable DA and then Uninstall the module. This will wipe all traces of the module from your installation.

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

I've tried all of that, to no avail. FYI, this does look related to the issue seen in the previous "Redirection" thread - For some reason the POST that admin/build/domain is generating, is creating the 302 redirect. Here's the snippet of Live HTTP Headers where the change happens:

#request# POST http://shop.exampledev.com/admin/build/domain
POST /admin/build/domain domain_root=shop.exampledev.com&domain_sitename=Example+Store&domain_scheme=http&domain_behavior=2&domain_options=3&domain_debug=1&domain_sort=name&domain_editors=0&domain_search=0&domain_seo=1&domain_www=0&domain_grant_all=user%2F*%2Ftrack&domain_cron_rule=1&domain_paths=node%2F%25n%0D%0Acomment%2Freply%2F%25n%0D%0Anode%2Fadd%2Fbook%2Fparent%2F%25n%0D%0Abook%2Fexport%2Fhtml%2F%25n&op=Save+configuration&form_token=7101d26995fe59d53c56ac55f22c30e5&form_id=domain_configure_form
#request# GET http://shop.example.com/admin/build/domain

Notice how the last line, the GET request, is not the same domain as in the original POST request.

Still digging...

EDIT: Problem solved. It turns out there was an extraneous, offending $base_url that I found... I think I had put it there during testing.

Man, I am an idiot sometimes. Sorry for taking your time - but in the course of this discussion I've learned a lot about how some of this stuff operates. So, all's well that ends well.

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented
Status: Active » Fixed
agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

I must kill you now. You know that.

Issues like this are important. You may have uncovered a bug hiding away in a corner -- so we have to track this down. But user error always make me laugh.

We killed about an hour (6 people!) on the launch day of SavannahNow because a stray 'a' appeared in someone's code and was appearing on all site pages.

Back to the module -- we did 7 betas and 4 rcs -- and the module is running on some live sites. So it's been testing pretty thoroughly. We are finding some bugs at the edges, but core behaviors like this are solid -- hence my original response #2.

So when the site goes live, you have to send a link.

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

Kill away, Ken :)

Actually it's the PEBKAC errors that are always the easiest to spot, isn't it? Well as I mentioned this was at least a valuable way to learn about some inner workings not only of the module, but even of Drupal itself. The stray $base_url value came from when I was testing a related issue, I think it's the one that had to do with domain_strict being enabled; and for some reason I neglected to undo those changes. Next time I will just untar the module files another time.

I will send you a link and I'd like to write up a use case for you as well, to make up for my operator error :) I'd like to offer subdomains for our users, but I'm not sure if that's something they would need or embrace. We'll see as time goes on.

Thanks again for your help, even if the error was all mine. Keep up the great work.

scedwar’s picture

scedwar commented

Can I suggest that section 4.1 of INSTALL.txt is amended from:

----
4.1 $base_url

The $base_url setting is normally not set. With Domain Access, you
cannot set this value manually.

To:

----
4.1 $base_url

The $base_url setting is normally not set. With Domain Access, you
cannot set this value manually and you should therefore comment out
this line in your settings.php file to avoid any confusion.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

But it is commented out by default, so that doesn't make sense to me.

scedwar’s picture

scedwar commented

It wasn't commented out in my install, rightly or wrongly. I'm not sure why but I seem to have vague memories that some of the multisite installs suggested setting it. IMHO it would be worth amending the wording for clarity to remove any doubt and ensure that it is commented out.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

So, something like:

4.1 $base_url

The $base_url setting is normally not set. With Domain Access, you
cannot set this value manually.

The $base_url line in your settings.php file is commented out by default. If you have changed this
setting previously, be sure to disable the  $base_url value.
Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.