Not sure if Domain Access is what I need...

subscribing

I don't have time to dig into this right now, but will leave it open for others.

With regard to Point 1, maybe I'm not entirely sure what you're asking, but Drupal supports assigning an arbitrary URL to any of your content, so paths like that (minus the trailing slash) are totally possible, both with Domain Access and without. As for having part of one essay on one site and part of another essay on the other… I'm not sure why you would want to do that, but that is possible as well with Domain Access. Automatically making each essay part aware of the other part's existence and automatically link to it is where it possibly gets tricky, unless you specify that that content should be shared among all domains and use a content pagifying module (I've never had use for one myself, but I bet one exists).

With regard to Point 2, with Domain Access anyway, there is only one "real" Drupal installation, and it would be at one of the "live" sites. So in your case, Drupal might really live at http://www.green.co.uk , and http://www.blue.co.uk will point to http://www.green.co.uk -- but then, when accessed through the blue domain, Domain Access kicks into action and has Drupal output different content.

I'm still new to Domain Access as well, but that's the way I understand things at this point. I'm sure Rickard will correct me if I'm wrong.

As for choosing between D5 and D6, if you don't need any major modules which are still D5-only (like Übercart), I would highly recommend starting with D6. It will be better supported in the future, of course, but some of the features it has now that D5 doesn't are really slick, like the ability to drag menu items and such to rearrange them instead of fiddling with "Weight" menus. And the new version of the Views module, which is D6-only, is absurdly slick once you wrap your head around it.

In the case of Domain Access, you do all the DNS work at the server level. Simply make a single Drupal installation at your 'primary domain' -- here, example.com. Then point DNS records for any (or all) domains you wish at that directory.

Then you 'register' those domains with Domain Access, and it handles the rest. You only need one settings.php file, one set of code, and one database.

So, for instance, you have the following:

/host/www/example.com/htdocs/ <-- root Drupal installation

This webserver has the IP of 127.0.0.1.

In your host DNS record, simply point all domains at that IP. On my testing machine, I do that through the 'hosts' file on Apache2.

127.0.0.1	localhost
127.0.0.1 example.com
127.0.0.1 one.example.com
127.0.0.1 two.example.com
127.0.0.1 three.example.com
127.0.0.1 ken.example.com
127.0.0.1 www.example.com
127.0.0.1 www.one.example.com

You can also configure wildcard DNS. In any case, requests made to domains not recognized by Domain Access will be redirected to the primary domain.

I am not, however, a sysadmin, so I cannot tell you how to congifure these options. Also not that many shared hosts will not support what you need.

To clarify what agentrickard said, your hosts file is part of your operating system, not Apache (or some other web server). It basically provides a cache of domain name to IP address mappings that the network stack of your OS checks first before it goes to the internet and hits up a DNS server to figure out what IP address it should look for when you ask it to access a domain name. I would not recommend putting real domain names in your hosts file and pointing them back to your local IP address (127.0.0.1 in the example above) because then, whenever you try to access example.com, you won't be able to access the "real" one on the internet; you'll always be hitting up the one on your local computer instead. A good idea is instead to use fake, impossible domain names like example.test instead.

http://en.wikipedia.org/wiki/Hosts_file

Setting up virtual hosts through Apache is another important issue. Info on that can be found here:

http://httpd.apache.org/docs/2.2/vhosts/

In my case, I'm working on a site whose main domain is going to be at foo.org, but who will be using Domain Access to also host bar.com (real domain names substituted, obviously -- older versions of this site, not using Drupal, are currently on the internet). On my local machine, I'm keeping the files for this project in /Users/Albright/Sites/foo, but I have other sites in /Users/Albright/Sites which I want to keep working as well. My Apache configuration file (httpd.conf) has this at the end:

NameVirtualHost *:80

<VirtualHost *:80>
        ServerName 127.0.0.1:80
        DocumentRoot /Users/Albright/Sites
</VirtualHost>

<VirtualHost *:80>
        ServerName foo.test
        ServerAlias bar.test
        DocumentRoot /Users/Albright/Sites/foo
</VirtualHost>

And I've added this to my hosts file:

127.0.0.1   foo.test
127.0.0.1   bar.test

I then configured foo.test and bar.test in DA. Everything works great. Of course, when I move the system to the live server, I'm going to have to reconfigure things to work with foo.org and bar.com instead, but I don't anticipate that being too much of a problem.

If you are confused, don't worry; I'm learning a lot of this as I'm going along myself.

:-) As I said, I am not a sysadmin. These are very useful notes.

NOTE: 5.x.1.5 now supports non-standard ports as separate domains.

Incidentally, Rickard, I think it would be great if you made it clear in DA's docs that it works equally well (or has for me so far, at least) on entirely separate domain names as opposed to just subdomains. The example you link to (wheretraveler) only uses subdomains, and almost all of the examples in the documentation (which is otherwise really great, by the way; kudos) use subdomains. Because of this, I wasn't expecting DA to work for my needs when I first tried it. It was a pleasant surprise to see that it does.

See section 1.5.1 of the README and the top of the module description page.

But you want something like:

The Domain Access module group is designed to run an affiliated network of sites
from a single Drupal installation.  The module thus allows you to share users,
content, and configurations across a group of sites such as:

  - example.com
  - one.example.com
  - two.example.com
  - my.example.com
  - thisexample.com
  - anothersite.com
  - example.com:3000 <-- non-standard ports are treated as unique domains.

[Rickard, btw, is my family name.]

Oops! Sorry, Mr Rickard… Ken. No disrespect meant.

Yes, some examples where non-*example.com domains were listed would have helped clue me in. There is 1.5.1, but that's offset by the introduction and 2.2, where only *example.com examples are used.

(New release today, I see… I'll go snag it.)

It's ok, a lot of non-native English speakers assume Rickard is my first name, since it is common in Scandanavia.

So if, using Drupal, I wanted to do that thing described above using the books/T-shirts example (if that was clear), is it possible without Domain Access?

There's lots of ways it could be done without DA, but I think DA might be the easiest. You could do something with Views where, on the shirt site, shirts would show up in the main content area, but maybe there's a block to the side which is showing books on the same topic. And vice versa for the book site. I'm speaking theoretically here, but I think something like that would be possible without custom module development.

By the way, you say you're encountering a learning curve with mod_rewrite -- do you have some special case going on where the rules that come in Drupal's default .htaccess file are insufficient? I've never run into a case like that before. (Or are you getting mixed up with the hosts file thing?)

Well, what comes to mind in terms of doing it without DA is to set up a multi-site Drupal install using Drupal's standard multi-site capability, so that it functions more like you have two separate Drupal installs. Then you hack together a custom module which, when the shirt database is viewed, it sneaks over across tables (and possibly databases, depending on how you set it up) and looks up results in the book table too. Or maybe you really do have two separate Drupal installs (maybe even on two separate servers), and you use XMLRPC or some other sort of cross-site scripting to fetch results from the other server as the user searches -- this could be done client- or server-side. But I think both of these solutions are kludgey when you can use DA instead and (probably) do something like this without even doing any custom module development.

As for mod_rewrite, I worry about it about as much as Drupal makes me worry about it -- which is not at all. (And that's just fine with me, because I'm of the personal opinion that Apache's configuration file syntax was devised by a sadist.) As you're learning Drupal, I would suggest you worry about it exactly that same amount. There are plenty of other things more deserving of worry.

Sounds like solid reasoning to me. Good luck!

Hi @Jennifer_M,

excuse my short or late step in in this. Anyway if you would like to know more about Domain Access and one of the way we did implement you can have a look at
http://adaccs.at. The site is still under heavy development and not all permissions issue are cleared out and set in the manner we want to, and we also need a lot of feedback
as to have an idea where we did customize wrong and where it look ok.

Cheers