[support] support Digest, Vol 120, Issue 34

[Richard Damon]

On 12/22/12 1:22 AM, Roger wrote:
> Thanks Richard, you are correct, I don't understand exactly what is 
> going on but am learning.
>
> You mention that we must own the domains and this is a problem as she 
> wants to use the shared server to host 3 or 4 other sites for teachers 
> who will have their own domain names, not yet established.
>
> It seems that one way is for each to have their own share on the server 
> which means she will have to manage several drupal installs on different 
> servers, something I wanted to avoid because each is a very simple 
> requirement easily handled by a fairly basic drupal and a few modules.
>
> The other option offered by the ISP is to have the separate drupal 
> installs on her share then have the domains as Add Ons. I'm not familiar 
> with this - seems I must learn.
>
> Have no interest in example.com it is just mentioned in the drupal 
> tutorials. I tried it and it doesn't work, no matter what I have in 
> /hosts or /httpd.conf
>
> As for .ab and .xy these are my invention for practising on my home pc, 
> I found the home pc it doesn't care what the domain is called as long as 
> it has a name a dot and an extension of 2 or 3 letters, Drupal and 
> apache don't care.
>
> Regards
> Roger
>
Every site on the internet should have a domain name for people to get
to. (It is possible to access a site via just its IP address/port
number, but this isn't done often, and doesn't work for shared servers),
so to do any testing on a shared server you need a domain name that you
"own".

When you sign up for server space, the hosting provider will give you a
"default domain name" to access the server, normally a specific
subdomain, something like u12345.example.com, where example.com will one
of the domain names the host provider uses for their hosting. In
addition you can register other domain names and connect them to the
server.

The use of the example.com domain names in these examples is largely to
avoid the problem of people copying them exactly, then testing them out
and hitting some real servers with strange requests. It is expected (and
usually spelled out) that you need to replace the example domains with
your real domain.

Either you local machine has been set up to map unknown domains to
localhost, or (based on some of your comments) the instructions included
steps to modify your host file to tell your machine where to find these
domains (as localhost). The key is that somehow you need to establish a
mapping from domain name to server (either via the global DNS system for
registered domains, or via the hosts file on your machine for
unregistered domains for testing purposes, and then tell the server
where to go to serve request for that domain.

As far as having a multi-site system or a couple of independent
installs, I would suggest that it may be better to have separate
installs.  One issue with a multi-site install is that Drupal's built in
update tools are not setup for it. For a single install, a module update
can be done solely inside Drupal, and it will take the site off-line,
update the module, and you can run the database update. This is NOT
automated for a multi-site install. You will need to manually take
off-line the other sites, and manually run the database update
afterwords, and then manually put them back online. There are more
advanced tools (like Drush) which can help with this, put it does
require someone to understand a lot more about how the system works.

-- 
Richard Damon