Hi All,

I have been using Domain Access for about a year and it's been functioning properly; however, I have recently made some changes to the setup of my domains (previously add-ons vs. now parked) and also changed my hosting company and thereafter Domain Access (or perhaps something else) started behaving weirdly, whereby I try to go x.com but get served y.com instead. Having done some troubleshooting to isolate the problem, it turns out that it is related to caching (the standard built-in one). When I disable caching, the problem simply disappears.

My new scheme for deploying the domains is as such: I have one subdomain.somedomain.com as the main site (site 0) and all other domains (as in x.com, y.com, z.com) assigned as parked domains on top of subdomain.somedomain.com. Of course, each domain has its own directory in sites. They all share the same exact settings.php (of subdomain.somedomain.com) using symlinks. It is a single DB model.

Has this caching-related problem been seen before? Any thoughts on the cause and solution?

Thanks,
-DrupalFan

Comments

agentrickard’s picture

Of course, each domain has its own directory in sites.

This is probably the issue. DA doesn't use this. Point all your domains to a single sites folder (typically 'default').

eldrupal’s picture

@agentrickard

Thank you for the prompt support. I removed all the domain names directories in sites and kept only one settings.php in default. Yet, when I re-enabled caching the anomaly reappeared!

Is it a problem that the domain names are parked on top of a subdomain (instead of a domain name)?

What are the factors that can influence this problem?

Thanks,
-DrupalFan

agentrickard’s picture

On shared hosting? The potential problems are legion. Here's what you should try:

1) Point all your DNS records to the same IP/Drupal install.
2) Use Domain Alias to 'register' the parked subdomains to their active versions. You can usually do this with something like '*.example.com' redirects to example.com.

eldrupal’s picture

Category: bug » support
Status: Active » Closed (fixed)

The problem may have been caused by changing the master domain (domain #0) manually, directly in the database. @agentrickard has explained that this is the one and only domain that should NEVER be changed manually.

Anyway, I have re-entered domain 0's info using the Domain Access interface and rebuilt permissions. The problem was not experienced thereafter. Of course, I am not absolutely sure what may have caused or contributed to the problem, but I would like to put this issue to rest for now.