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.