Greetings!
I have a Drupal-based site growing on my local Windows XP development site, which is running Apache Triad. This is my first Drupal site. The theme and contributed modules that are uniquely associated with this site are currently residing in the sites/default directory, under the respective module and theme subdirectory.
I know that eventually, I will want to have three test/development sites on my local PC. When the sites go live, all three production sites will be hosted on different servers at different organizations.
So, now, here's my question: At this juncture, can I wait to tweak Drupal so that I can use one codebase, three databases, three themes and contributed modules unique to each site? By that, I specifically mean: It's OK for me to keep this first site and it's "accessories" in the sites/default directory, yes? Or is it best to move the first site out of default and into its own site under sites/sitename/etc. in order to be best prepared for the later migration to a Drupal core that runs multiple sites on my local PC?
Comments
_
imo you should keep dev sites as close to the live configuration as possible-- i would go with 3 separate sites. You can even use the intended domain names by altering your local hosts file.
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
Sep dev sites locally, hmmmm
Hmmm. So -- just to make sure I'm thinking the same thing you are writing --- you think there's greater benefit in a local dev set-up composed of three separate set-ups of apache, mysql, drupal ?
Why is that better than one local server, one Drupal codebase, separate databases, separate themes?
Thanks for the reply!!
_
Sorry, not 3 separate *amp stacks-- just 3 separate drupal sites. The technology stack piece of the setup should be fairly stable, though occassionally I have run into problems that are OS related.
But that's just me-- I like to keep dev as close to live as possible. The further your dev config gets away from the live configuration, the less it serves as a realistic test environment. And since you're going to be managing the 3 live sites separately, you might as well get used to it now.
But to each his own.
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
SFA between them
I use both multisite and separate sites. To use a specific technical terminology, there is SFA between the two approaches.
When you have 50 separate sites, you update everything 50 times.
It is easier to update from 6.7 to 6.8 if you have only one copy of the code and multisite gives you that. Multisite gives you the choice of 50 databases or one. You still have to run update.php 50 times to update the 50 databases if you choose the separate database option.
When you go from Drupal 5 to 6 using multisite, you have to stop 50 sites, convert 50 sites, then restart 50 sites. If just one of the sites depends on a module that is not ready, you have to restore 50 sites to Drupal 5. I usually keep sites separate when they depend on experimental modules.
You can also use Domain Access to share one database with one set of test accounts. Domain access is good for sites that are similar. If you get a contract to create individual Web sites for every member of a football team, You would use Domain Access.
Creating many sites on Windows is about the same as creating many sites in Cpanel or Webmin. The only slow bit in Cpanel is going into WHM to create a new account if you create separate sites. In Windows you go into the administrator login to add a host entry. When you copy from Windows to your Cpanel site, they will both have the same level of software and same combination of settings because you have the same level of control in both systems.
When you go from the Cpanel controlled quality assurance VPS to the production site, you will find differences because server administrators tend to use the oldest possible release of every piece of software with only security updates applied. If you demand they use the very latest releases, they will randomly switch on and off obscure settings that only cause problems when you demonstrate the new site to your customer. And that is the good news.
I recommend the QA stage, especially when you are about to apply maintenance to an existing site. Make the ISP set up the QA VPS the same as the production server and make them apply all maintenance to the VPS the week before they apply it to the production server. Make sure it is during a week when you are not on your honeymoon, riding in the space shuttle, laying in the delivery suite, or trying to watch all the Alien movies back to back.
When you try to apply a major change to an existing site and have to down several gigabytes of existing database, use a separate Web site. You can still keep all your multisites and Domain Access sites for developing variations on modules and themes. I have 5 or more copies of some sites so I can develop several changes in parallel.
petermoulding.com/web_architect
petermoulding.com/web_architect
Circling back to my original question....:-)
Thanks Peter, for the detailed response! This all sounds, quite honestly, like a huge PIA. Ah well, such is life.
Given the responses, I find myself returning to my original, newbie question. Let me restate it.
I am creating on my local PC, (XP, Apache Triad, Drupal 6.8). I am now working only on one Drupal-run site. For this site, I'm using the sites/default directory (for sites/default/themes, sites/default/modules, etc.)
I know that eventually my local PC will be used for three dev sites, including the current one. When the sites are ready to go live, I also know that all three of these sites will be hosted on three different servers at three different organizations.
So, if I opt, down the road, to use multisite for the dev sites (not for the live sites)....meaning that I would use one Drupal codebase, three separate databases and one Apache server set up on my local PC.......
----- should I be using the sites/default directory for the site that is currently being worked upon (I am doing so at this writing)?
-----Or, alternatively, should I create a sites/domainname/ directory for this first site?
Which is the best practice or, maybe, "it just don't matter." :-)
THANKS
BTW, what does the acronym SFA mean?
S: Sweet, A: All
For al my multisites, I create a base site using a trow away domain that I own. I add all other sites as secondary sites. Think about developing 02d.in as your first site. You make it the first site for multisite or Domain Access. You add some other sites. Then you make major changes to 02d.in and it stops all the other sites from working.
Start with a spare domain, 03d.in, as your base site and set up /sites/02d.in/. When you try out a new module for 02d.in, you put the module in /sites/02d.in/modules/ and it is loaded only for 02d.in, without stopping any other sites.
petermoulding.com/web_architect
petermoulding.com/web_architect
Ahhhhhh.....
grasshopper...now I see! Thank you kindly!
This was the magic sentence that changed my thinking: "Then you make major changes to 02d.in and it stops all the other sites from working."
It never occurred to me that a change to the site housed in sites/default would impact on sites housed in sites/domainname and sites/anotherdomainname
So, the upshot of this, is that best practices dictate that one knows in advance that one is going to go the multi-site direction so one can set up the sites/domainname directories right from the get go. That's not mentioned in the copious documentation I've read.
THANK YOU!!