Running 6.14 and current version of Domain Access.

Drupal installed as a sub-directory off the root as http://my.domain.com/drupal

When I edit page content and resolve web pages off my.domain.com/drupal they work fine

Yet when I try to edit pages at a domain I created in Drupal -- http://another.domain.com -- Drupal wants to append "/drupal" to the end of http://another.domain.com which results in 4040 page not founds when I try to edit. Yet I can resolve the pages at http://another.domain.com just fine in the browser.

How do I get domain access to function when I have installed Drupal as a sub directory off the web root?

Comments

Dr. DOT’s picture

Dr. DOT commented

And here is something interesting:

When I navigate through Home > Administer > Content management and click the edit link under Operations, I get the 404 Page Not Founds.

Yet when I go to the same list through Home > Administer > Affiliated content and click the site under the Site content column and then click the edit link under Operations, I can edit the page because Drupal does not prepend the page with my domain http://another.domain.com -- it leaves the link as http://my.domain.com/drupal

Dr. DOT’s picture

Dr. DOT commented

Installed Modules:
Administration menu - installed version 6.x-1.5 Friday, September 11, 2009
Content Construction Kit (CCK) - upgraded to version 6.x-2.6 Friday, December 4, 2009
Domain access - upgraded to version 6.x-2.1 Thursday, December 10, 2009
IMCE - upgraded to version 6.x-1.3 Wednesday, September 30, 2009
Pathauto - upgraded to version 6.x-1.2 Monday, October 26, 2009
Scheduler - upgraded to version 6.x-1.6 Wednesday, October 21, 2009
SMTP Authentication Support - downloaded version 6.x-1.0-beta3 Friday, September 11, 2009 (not yet installed)
SpamSpan Filter - upgraded to version 6.x-1.4 Wednesday, September 30, 2009
Views - upgraded to version 6.x-2.8 Friday, December 4, 2009
Webform - upgraded to version 6.x-2.9 Friday, December 4, 2009
Wysiwyg - installed version 6.x-2.0 Friday, September 11, 2009
XML sitemap - installed version 6.x-1.1 Friday, September 11, 2009
Advanced help - installed version 6.x-1.2 Friday, September 11, 2009
Token - installed version 6.x-1.12 Tuesday, September 15, 2009 (required by Pathauto module)

agentrickard’s picture

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

This really isn't a DA problem.

If the site is actually installed at /drupal, I don't believe you can remove that for one site and not another without making use of advanced use of .htaccess or mod_rewrite.

I don't think this is a Drupal problem. I suspect it is a DNS/registry problem, as I run Drupal in a subfolder in order to test the module.

Make sure that your DNS / VHosts entry for another.domain.com points to the same root directory, that you only have one settings.php file, and that you are not setting $base_url manually.

Dr. DOT’s picture

Dr. DOT commented

FIRST --
my.domain.com has this in the VirtualHost tag in httpd.conf:
DocumentRoot /htdocs

another.domain.com has this in the VirtualHost tag in httpd.conf:
DocumentRoot /htdocs/drupal/

SECOND --
I do only have 1 settings.php file

THIRD --
I had the issue with $base_url commented out in settings.php so I uncommented and changed to:
$base_url = 'http://my.domain.com/drupal'; // NO trailing slash!
Still have the issue (or the lack of success in getting Drupal to work for me)

agentrickard’s picture

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

AFAIK, you simply cannot do what you are trying to do without using mod_rewrite. Drupal (and Domain Access) expect one location for settings.php. The VHosts setup looks like it should work.

However, you cannot set $base_url manually and have DA work properly, since the $base_url changes for each domain. You might have to put some logic in settings.php to set $base_url properly for how you are trying to run Drupal.

The question is: Why are you even trying to do this?

Dr. DOT’s picture

Dr. DOT commented

"The question is: Why are you even trying to do this?"

I have investigated Drupal and multisite capabilities through numerous sources and experienced users of Drupal. At all turns, I am told Domain Access is the module we need to use to meet our needs.

Our needs are basically this:

(1) we want a single code install of Drupal (don't have the resources to keep multiple copies up-to-date and in sync with each other)
(2) we have shared server running nearly 100 websites and web apps of varying sizes and complexities
(3) some of the ~100 sites will get converted into Drupal for better CMS capabilities
(4) the remainder of the ~100 sites we stay as is -- mature sites requiring very little maintenance and attention
(5) going forward we want single source information so it can be shared and syndicated across many of our sites -- we are a large enterprise that has a great deal of commonality across our sites so we want content owners to manage and maintain their information and data yet allow for realtime sharing of that information and data -- thus a single database

I have installed Drupal as a sub-directory off the web root so as not to disrupt the current production sites running on our server.

So, if Drupal and Domain Access is not the right solution, please let me know.

Thank you.

Prior Posts:
http://drupal.org/node/530260
http://drupal.org/node/596596
http://drupal.org/node/609896
http://drupal.org/node/649354
http://drupal.org/node/651234
http://drupal.org/node/656734
http://drupal.org/node/661250

Garrett Albright’s picture

Garrett Albright commented

Just for fun, could you try setting the webroot of my.domain.com to /htdocs/drupal as well? And comment out $base_url again.

I personally have used Domain Access to build a site which hosts about fifteen separate subsites, so I can attest to its capability.

Dr. DOT’s picture

Dr. DOT commented

Garrett. I really appreciate your suggestion and thank you very much for jumping in.

The real trouble is that our webroot domain -- in this example, my.domain.com -- is used as a base and a host for many production web applications that in one way or another function behind the scenes to certain public facing web site(s). In other words, right or wrong, we have a shared server with nearly 100 web sites and web apps that run as they do with my.domain.com being both the main host and a supportive sub-host.

Hence, I can't alter the DocumentRoot setting or a good number of production sites will break.

This is why my strong push for a Drupal / Multisite solution whereby I can install Drupal in a sub-directory off the webroot.

As each week and now month goes by, I get no further along trying to make it happen and lose confidence that Drupal can fully function in a setting like ours.

Garrett Albright’s picture

Garrett Albright commented

Dr DOT, okay, so my.domain.com is your "production" domain? I didn't see that. Yeah, obviously you don't want to change the web root of that. So perhaps create another testing subdomain and point that one's web root to /htdocs/drupal - basically, what I'm asking you to do is to try doing it so each domain/subdomain is pointing toward the same web root.

Dr. DOT’s picture

Dr. DOT commented

Ok...but actually another.domain.com "is" a testing site. I am not in a position to release anything live in Drupal until I go through this evaluation process and proof of capability process.

Drupal is installed as a sub-dir off the webroot so I resolve to and log into Drupal at http://my.domain.com/drupal -- just an FYI

Since my.domain.com's DocumentRoot is defined to /htdocs
and another.domain.com's DocumentRoot is defined to /htdocs/drupal/
I will follow your suggestion and set another.domain.com's DocumentRoot to /htdocs to see what happens.

Test results to follow in about 15 mins -- stay tuned (and thanks again).

Dr. DOT’s picture

Dr. DOT commented

After changing DocumentRoot to /htdocs the page no longer resolves for another.domain.com.

Garrett Albright’s picture

Garrett Albright commented

What do you mean by "page no longer resolves?" We shouldn't be changing anything DNS-wise here.

Do you see anything at another.domain.com/drupal ?

Do you have some sort of testing environment set up so that you can test these things well away from the production server? I'd strongly recommend looking into this if you want to do any sort of serious web development.

Dr. DOT’s picture

Dr. DOT commented

Sorry, what I mean is http://another.domain.com does not resolve to the home page

Yes, http://another.domain.com/drupal does resolve but we cannot have /drupal tagged to the end of our url's. That would disrupt all of our Google Analytics, SE indexing, bookmarks, etc.

Thanks for the advice on a testing environment. It's a budget and resource issue.

Dr. DOT’s picture

Dr. DOT commented

And as an extension to #13 above, I still get "You are not authorized to access this page" when I try to resolve http://another.domain.com/drupal/?q=content/my-first-page

Garrett Albright’s picture

Garrett Albright commented

Sorry, what I mean is http://another.domain.com does not resolve to the home page

To the Drupal home page? Of course not, because the directory holding Drupal is no longer the web root.

Yes, http://another.domain.com/drupal does resolve but we cannot have /drupal tagged to the end of our url's. That would disrupt all of our Google Analytics, SE indexing, bookmarks, etc.

So then make the Drupal directory the web root. We're kind of going in circles here… I understand that you can't do that for the "live" domain name, so we're just not going to use the live domain name at this point. Using the Domain Alias module, which comes in the standard Domain Access package, you can "alias" another domain/subdomain, like my-test.domain.com for example, to the domain name which will be the "live" one when you're ready to go live.

And as an extension to #13 above, I still get "You are not authorized to access this page" when I try to resolve http://another.domain.com/drupal/?q=content/my-first-page

Let's say "access" instead of "resolve," because "resolve" has a different meaning and it's confusing me. But anyway, check that the page is properly assigned to the another.domain.com domain name.

Dr. DOT’s picture

Dr. DOT commented

I have been working with a colleague of mine from a sister-branch within our organization on this issue for the past few days as well as attempting to get help from the Drupal community over the past few months. My colleague has used Drupal for over 5 years.

We have both reached the same conclusion that Domain Access will not work (easily, if at all) when Drupal is installed as a sub-directory off the web root.

So I am going to create a virtual host designated and reserved as the core Drupal install. I will then attempt to create domains (in D.A.) off the designated virtual host.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented 
We have both reached the same conclusion that Domain Access will not work (easily, if at all) when Drupal is installed as a sub-directory off the web root.

This is simply not true, as I do all my DA development and testing from within a subdirectory installation. For instance, all these domains are active on my test server:

example.com/drupal-5.21
one.example.com/drupal-5.21
example.com/drupal-6.15
one.example.com/drupal-6.15

The problem seems to be that you want to hide that subdirectory for some domains, which is why I suggested .htaccess or mod_rewrite in the first place.

The VHosts solution might be the best route, but I am not a sysadmin and cannot offer additional support.

You may want to investigate custom_url_rewrite_inbound() as well.

agentrickard’s picture

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