Last updated July 10, 2013. Created by LeeHunter on July 28, 2005.
Edited by mrogers, bewise, permaculturegeek, lise.perceives. Log in to edit this page.


Production site: The live website where all your web visitors go.
Test site: A copy of your live site, at a different URL, where you can make experimental changes without affecting your live site

Drupal and its modules are in pretty constant development. So things are changing pretty fast and sometimes not completely documented. In practice, that means making a change or adding/removing a module on your prod site can have rather surprising results - surprises you'd rather your visitors didn't have to live with. That's why I recommend making all changes to a test site, and if they work out, promote the changes to your prod site.

Here's how I built a completely parallel site on my hosted, shared server account.

First I need to mention some things about my site, so the rest of this article makes sense:

  • My site is called bewise.com
  • it's hosted on a shared server
  • I have shell access to my hosted files. Without shell I wouldn't really want to attempt all this.
  • I am allowed to have two mysql databases on my account
  • all site files are at /home/user/public_html
     (there's also an alias, /home/user/www, which points to public_html)
  • in the above, user stands for my username, which I'm not telling you
  • I keep my production drupal database in mysql; that db is named mydb_prod
  • Apache is set up so that http://www.example.com and http://example.com will point to /home/user/public_html

All of this is pretty standard stuff, but you may have to make a few changes to this process if your site is set up differently. My test/prod workflow looks generally like this:

  1. Make a new (empty) database, and name it mydb_test
  2. Copy your prod db into mydb_test
  3. Copy all of your prod files (from public_html) into your test directory
  4. Make three settings changes to connect the test site to the test db
  5. Make changes to your test site.
  6. (optional) replicate test site's files and db back into the prod site to make your changes live

So how to actually do all this? Don't worry, it's not that hard once you have the right commands handy. Really, I do steps 1-4 in about 2 minutes. This document is long only because I wanted to be verbose enough for all skill levels!

Step 0 - work with your host provider

The first thing I did was ask my hosting provider to create a new directory, /home/user/test and then set up apache and their DNS servers so that http://test.example.com and http://www.test.example.com would point to this new test directory. It was important to ask them to make a new VirtualHost entry in the apache configurations, NOT just set up a rewrite rule. They should know what you mean by this - and they might charge you extra for it. Mine didn't, but even if this costs you a couple of extra bucks, it's worth it. Trust me when I say that using a rewrite rule or subdirectory of your existing site will make the rest of this much harder to do.

When this is complete your directory structure will look something like:

|-home
|-username
|
|-public_html
| |
| |-database
| |-files
| |-includes
| |-misc
| |-modules
| |-scripts
| |-sites
| |-themes
| |-(drupalfiles)
|
|-test
|
|(empty because we haven't put anything here yet)

/home/username could in your case be /var/www/username, or something else entirely. The point is to have a test directory which is not part of your normal html directory, and which acts as a separate site in all ways.

You'll also need a second mySQL database to house your test site's data.

Step 1 - Create an Empty Database

I use the commands

mysql -uuser -ppassword -e "create database mydb_test;"
mysql -uuser -ppassword -e "grant all privileges on mydb_test.* to user@localhost identified by 'password';"

to create my database and set the permissions. The I broke a single mysql command into the last two lines because drupal.org wasn't printing it all as a single line. If you are restricted from doing so, you may need to create the empty database via cPanel, Plesk, or whatever control panel your provider gives.

Step 2 - Replicate the database

mkdir ~/temp
mysqldump -uuser -ppassword --add-drop-table mydb_prod > ~/temp/prod-db
mysql -uuser -ppassword mydb_test < ~/temp/prod-db
rm ~/temp/prod-db

Above you see the commands I enter. You'll need to change things user and password to your username and password; also mydb_prod should be replaced with the mySQL database name for your prod site. Knowing that, I bet you've already figured out that you need to replace mydb_test with the name of your newly-created test database.

The first line just creates a directory to hold our temporary dump file.

The second line, starting with mysqldump, is where we dump the entire prod database to a textfile. We use the --add-drop-table option because this essentially creates a script we'll run later; this option makes sure that script will erase old data before importing new data. Note that you need to supply the proper username and password for your production database. I specify the database name mydb_prod - you will need to change this to the name of your prod site's database. The textfile created by this command is actually a full script which will create tables and populate them with data.

The third line, starting with mysql, is where we do that. Again, be sure and replace the italicized parts with the username, password, and database name you set up in step 1.

Finally I delete the dump file (~/temp/prod-db); it's not needed anymore now that we have loaded it into mySQL.

Step 3 - Copy the web files

rm -rf ~/test
cp -R ~/public_html/. ~/test

Here I remove the test directory, then recreate it, and copy everything from ~/public_html into it. I remove the test directory and all contents because I may copy of the test site in there, and I don't want it to pollute my fresh new exact replica of my prod site.

Step 4 - Edit Settings

nano ~/test/sites/default/settings.php

This starts the nano editor (or use whatever you like) and loads drupal's settings file. Here you will need to change two lines:

$db_url = 'mysql://user:password@localhost/mydb_test';

$base_url = 'http://test.example.com';

These lines are not together in the file. Set the database connection line, pointing to the test database you created in step one and populated in step 2. (in other words, you need to replace the words user, password, and mydb_test with information that's correct for your test database.) The base_url line sets the URL you will point your browser at to use the site. Save the changes.

Note: If you have previously upgraded your site from Drupal 6 to Drupal 7, the manner in which the database connection is specified in Drupal 7 has changed. What is more, the drupal 7 installer appends the new method at the end of settings.php rather than where it originally was following the instructions. The best remedy is to copy the content of default.settings.php (which has all the drupal 7 documentation) as settings.php and modify that accordingly. It's a good idea to do this on your production site, too.

Now, in your web browser, navigate to the site - it should be working fine. But I also change the Name field at administer --> settings to TEST.example.com (all caps) so its easy for me to remember I am looking at the test site.

Step 5 - Make your changes

This is where you make you changes. Change settings, add/remove modules, muck with the code - it's up to you. Remember you are working in a copy of your site - one that users don't know about - so you don't have to worry that you are creating problems for the users.

Killes has written a very nice and very quick way of testing your site at node/11521

And if you don't like the changes, or if you mess up your test site
completely - no worries! Just re-do steps 2-4 to bring a new copy of your
production site and database into your test environment.

Step 6 - Promoting changes to production

Now that you have your test site the way you want it, you really have two choices.

Method 1: You can re-make all the same changes manually on your production site.
Method 2: You can basically migrate the test site into production, with a very brief outage for the users.

I usually use method 2, but have been known to do it both ways. To use method 2, I'm essentially doing everything mentioned above, but this time copying the test site into the production location. So I'll skip over it more quickly this time around:

  1. mysqldump -uuser -ppassword --add-drop-table mydb_test > ~/temp/test-db
    mysql -uuser -ppassword mydb_prod < ~/temp/test-db
    rm -rf ~/temp/test-db
    rm -rf ~/public_html/*
    cp -R ~/test/. ~/public_html
  2. nano ~/public_html/sites/default/settings.php (here you'll edit the db_url and base_url to the prod-site settings)
  3. Also be sure to open the prod site, navigate to administer // settings and change the name back to the way it should be for the prod site.

You should probably test your site again using the Killes method linked in step 5.

There are a couple of additional cleanup steps I do, once I know my site is in good shape:

  • rm -rf ~/test/* (just cleaning out test dir for next time)
  • rm ~/bash_history(because it has my database password in it)
  • Remove the test database (if space is a concern)
  • R>

    Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

    Comments

    Many thanks for sharing this. I feel much more relaxed about the idea of experimenting now that I can do so in a sandbox! Here's a minor enhancement for the benefit of lazy people like me, followed by a note about the workflow.

    1. Rather than changing the credentials manually in the settings.php file, it's possible to use sed. This example edits files after copying LIVE to TEST data:

    typeset -r LIVE_SETTINGS="/path/to/live/sites/default/settings.php"
    typeset -r TEST_SETTINGS="/path/to/test/sites/default/settings.php"
    sed -e '/^\$db_url/s/live/test/g' -e '/^\$base_url/s/live/test/g' < ${LIVE_SETTINGS} > ${TEST_SETTINGS}

    Obviously, this idea can be extended to include other items (e.g. passwords) which vary between the 2 areas.

    2. Whilst it may be valid, even desirable, to replicate the live database in a test area in order to work in a sandbox, e.g. to mess with templates, styles, etc., it's probably unwise to promote this copy back to the live database when work is complete. Real world changes may have occurred to the live data in the meantime, and these would be overwritten. Thus I have created 2 scripts as follows:

    • l2t - replicate DB and HTML (LIVE to TEST)
    • t2l - promote HTML only (TEST to LIVE)

    I have 1 further script, just in case I ever need it:

    • t2l_db - promote DB only (TEST to LIVE)

    Of course the above works for mods to HTML, but if working on content, user maintenance, moderation, and so forth, this must ultimately be performed directly against the live DB (whether or not a dry-run has taken place against the test DB).

    3. There may be a good reason that I am missing, but I am denied access to Killes' site testing method when I try to follow the link.

    You could also edit 'settings.php' to auto-detect the environment based on the path or url. For instance:

    if current path = './test' then $db_url = 'test'
    else if current path = './prod' then $db_url = 'prod'

    OR based on url

    if url = 'test.domain.com' then $db_url = 'test'
    else if url = 'www.domain.com' then $db_url = 'prod'

    Now when you backup and restore your test site it will detect which configuration is needed. It's worth the overhead for me... but it would be nice if drupal supported different environment configs.

    ... Also, to differentiate the two sites, I setup a new "Block" within the drupal installation, called "Stage Site Indicator", with the following sample php-html:

    if( getcwd() == "/path/to/stage/site" ) {
    echo '<img src="stage.gif" style="position:absolute;z-index: 1;left: 0px;top: 0px;">';
    }

    ... Now anytime I view the stage site, a banner appears diagonally across the top left showing me that I'm definitely on stage...

    Some other things to consider with a test site that may be based on production data:
    - accounts are still active
    - outgoing emails still sending

    My stage site is a localhost install which means external users cannot access the site. In the future I plan to create a module or script that blocks all accounts except admin, or alternatively, resets passwords to a master key.

    The outgoing email was more of an immediate concern so I hacked together a very simple module to detect the stage install, and redirect the email to a hard-coded email address.

    'module/mail_redirect/mail_redirect.module'
    -----------------------------------------

    <?php
    function mail_redirect_mail_alter(&$mailkey, &$to, &$subject, &$body, &$from, &$headers) {
        if(
    getcwd() == "/path/to/drupal_stage" ) {
           
    $body .= "\n\nMessage redirected from $to";
           
    $to = "email@domain.com";
           
    $subject = "[STAGE] - ".$subject;
        }
    }
    ?>

    'modules/mail_redirect/mail_redirect.info'
    -----------------------------------------
    name = Mail Redirect
    description = "Redirect all mail to specified address"
    version = "5.x"
    project = "mail_redirect"
    datestamp = "1180970107"

    Lovely guide that's concise and easy to follow, thanks for that.

    One little polish would be to avoid needing a temporary directory/file for the database dump in step 2 by piping the output of mysqldump directly into mysql like this:

    NOTE: these code examples are one-liners - the formatting here may break the lines

    mysqldump -uuser -ppassword --add-drop-table mydb_prod | mysql -uuser -ppassword mydb_test

    ...and similarly for step 6, part 1:

    mysqldump -uuser -ppassword --add-drop-table mydb_test | mysql -uuser -ppassword mydb_prod

    I just found this article and thought I'd weigh in. The parallel environment you described can stay intact allowing you to make "what if" changes at any time. Being an old mainframe guy I borrowed a concept from the 70's called "copy down, move up" meaning you copy files "down" from production into test but then move them back up (they don't stay in test).

    To use this concept you must be using an OS that allows symbolic links (any Unix or Linux derivative). For background, a symbolic link is merely a special file that actually points to a real file and in our case we want all of the files in the test area to point to the files in the production area using symbolic links unless they are being modified. You'll need to add an Apache directive called FollowSymLinks on the test side only so if a file is not "down" in the test area being modified, apache will pick up all the production files.

    The links in the test environment will look like this:

    index.html --> ../production/index.html (a simplified example, for the example above it would be a bit more complex)

    Once this is in place for all files, you then can create a couple of shell scripts that "check out" production files and copy them down to test.

    CheckOut script function
    - Remove symbolic link in test
    - Copy production file to test
    - create "index.html.o" in production so you know it is currently checked out

    CheckIn script function
    - Verify that "index.html.o" exists
    - (optional) Push a copy of the existing production file down into an archive so you can quickly back out changes
    - Move the test version to the production area, overlaying the former production file
    - Create the symbolic link pointing to the new file

    That's it. You can now easily check out any file and make a small change. When you go to your test URL, Apache will pick up the new file from test and all of the other files from production.

    As for the test db versus production you will have a couple of static "where am I" files that direct your db connections to the correct db. I definitely put these down into a private directory for security reasons.

    I've built several large scale applications this way and it works wonderfully.

    D

    okay, so I am not a programmer and I have a healthy fear of terminals.

    Is there some way I can do the above by just copying over the files in my Cpanel file manager and then changing some (?) *.php file?
    My organization can not afford anything but novice me, and I have been known to have finger dislexia, so if there's some way I can work through a GUI, that would really help me and other novices out a LOT!

    1) made sure I had good backup

    2) used my web host's cp to copy the drupal stuff into test directory

    3) edited settings.php as instructed

    Now to mess things up!

    ...that, using phpMyAdmin, I exported my production site's mySQL database to my local HD then created a test database and imported the production database there.

    Everything worked with no problems.

    I use the combination of git, drush, phpmyadmin and backup_migrate module.

    1. Create a git repository inside the production environment.
    2. Use backup_migrate to create a new database dump.
    3. Clone the git repository to a testing folder.
    4. Create new database using phpmyadmin or mysqladmin
    5. Setup drupal in test (installation),
    6. Enable backup_migrate
    7. Restore the database dump from production.

    At step 7 I have an exact clone of production website. The advantage of this from using mysqldump is that, unnecessary data like sessions information, watchdog information are not migrated to testing.

    8. Any changes made to style or theme or new modules are migrated to production using git push.
    9. Any changes made to the database (new page, new view, new panel, edited content) are migrated depending upon the website.
    9a. if the changes are to an almost static website, we create a dump of test and put it to live server
    9b. If the server is dynamic with almost minute wise changes, I make atomic changes step by step to the production server.

    Thank you for all of the details you provided in this page. I am new to Drupal and just learning how to get under the hood.

    Please explain where the code should be placed (what file and where in the file) for steps 1, 2, 3 and 6. I'm not sure if it's a Drupal file or a file that runs the server ect...

    I really want to get started developing but want to be sure I know how to migrate a site and how to use a test site before I get too many more weeks into development.

    Thanks!!!

    In the beginin, When you mention stuff about your site, you say

    • all site files are at /home/user/public_html
      (there's also an alias, /home/user/www, which points to public_html)

    How do I accomplish that ? Which directory do you move in home ? Is the hole /sites directory in /user/home ? or just /files of each site (I run a multi site install)

    Thanks for the help and this great article

    The shared information is very useful.

    My production website have lot of new pages and comments on daily basis. Now I wanted to develop a forum which will atleast take 15 days to complete in full. I do not want to take risk of doing development on the production website. I these 15 days I know that there will be many changes on production website which is very difficult to replicate manually on test website.

    Please suggest solution for this.

    Thanks

    Hey Chanakya,

    I guess you found your own way now. But i have the simular problem. My approach would be the following, ( i think i will do it like this when my site is live, not tested it yet)

    1.)Create a export from live database with phpmyadmin when you start creating the development site
    2.)Keep this old database file saved on your machine somewhere.
    *3.)Before step 4. Perhaps it would be best to set site to offline, so no new content is added! (or keep it in mind..)
    4.)When you want to migrate the developement site with the live site, create a new export from the live website database.

    *It maybe could take 20-30 minutes if there where many many changes so if you really want no long down time.. you don't need to set site offline directly, you can look when you finished this. Then put site offline. Compare that version with the version you used before, same like you do in step5 below. If there where no changes (except the offline setting in the database and maybe some watchdog information)

    5.)Use a code or text comparison program to find out what is new in the data:
    Check the old database file from the LIVE site with the new database file from the LIVE site. With new i mean it's newer, perhaps a few days or weeks with new articles, comments, users.. etc.
    *i did not find out yet what program is good and free, but i will...

    6.)Go to the Development phpmyadmin and insert all NEW values that you found with comparison.
    (i hope there is a eassier way to do step5 and 6. Perhaps a patch of some kind.. but for now i only know to do this by hand)

    7.)Now database is simular to the database of the live site.

    8.)Export database, upload new/adjusted file to the live database.
    (if you don't know anymore what files you changed, i guess you could delete whole live site and upload the development one, of course ALWAYS make a backup!)
    empty Live database, and import the new development database!

    Now you uploaded development site, with all new database input from the live site!
    Both site are on this point equal!

    Just to remind y'all that a staging site can be found by the likes of Google et al. didn't want that, so I made sure that the Apache config only allows access to certain IP addresses. More info here:
    http://www.cyberciti.biz/faq/apache-restrict-access-based-on-ip-address-...

    but I am accessing my webserver also through the internet and I get a different IP all the time. How can I work around that? Is it sufficient if I put something like "no follow" or "disallow all" in the robots.txt?
    thanks for help, simon

    A quick workaround would be to put the staging site down for maintenance so that only authenticated users can access.

    I'm afraid I don't have the Apache chops to understand why it's important to have my provider make a VirtualHost entry instead of doing a redirect. I completely believe the author, that I'll have many problems if I don't do that, but my provider (Hosting Metro, who bought out DrupalValueHosting) is asking me to explain why. Can someone give me a response that I can pass on to them?

    (I haven't tried just saying "because I'm the customer and that's what I told you to do, but I suspect that won't satisfy them :-)

    Thanks for any help you can give me.

    SERRV International
    a 501(c)3 Fair Trade organization for more than 50 years.

    I am very new to Drupal and using the above instruction and those found here http://drupal.org/node/119752 using my Cpanel rather than command lines I managed to create a test site - problem was when I logged in as Admin (uid=1) to my test site it kept logging me out and when I managed to make a change it occurred in the live site and not the test site. To resolve this issue what I had to do was because I have an SSL set up on my live site I needed to disable via Site Building > Secure Pages BEFORE I copied the database from live to test.

    I followed the instructions on this tutorial and I succeeded in making a test copy on another server and the site worked normally. When I uploaded the module (Backup Migrate) the website stopped working and began to show the following error message. I should be very grateful for any helping hand

    the error message is :
    Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 287498 bytes) in /home1/allwisco/public_html/PMIC/includes/database.mysql-common.inc on line 41

    You might need to increase the memory limit for Backup and Migrate to work. Either the module itself or the files it will write are going to be larger than your current memory limit allows.

    Gents,

    I tried the instructions given above, and got *all* the files copied over (including .htaccess), the database was exported and the imported and I now have the home page "live" in the test site, which is on a local Ubuntu 10.4 LAMP server.

    So the home page shows up with all graphics, contents, formatting etc, but *none* of the other pages of the site are accesible. I get the following errors:

    Chrome: Oops! This link appears to be broken.

    Firefox: The requested URL /testsite/node/2 was not found on this server.

    I can't even login as admin!

    I already checked and the apache rewrite module is enabled.

    Any ideas, suggestions?

    Rgds,

    Philip

    ==================
    Philip Schalkx
    www.schalkx.com
    IT advisor & Project Management

    Gents,

    Thanks for the help, you pointed me in the right direction.

    The issue was that although the rewrite module was loaded, a few more changes had to be made in the apache configuration.

    Here's the link to the documentation:
    Apache 2 on Ubuntu
    http://drupal.org/node/134439

    Rgds,

    Philip

    ==================
    Philip Schalkx
    www.schalkx.com
    IT advisor & Project Management

    I am a new Drupal user with no php experience and managed to set up a test site on my shared hosting provider so I can edit and test locally without running into problems on my live site (when im live). The provider did assisted me in setting up the folders and database and went further and added my custom template in the correct folder. What I have is a test site that has a sub-domain and when I enter the test domain I can see my template that still needs editing. When I go to my test site via the sub domain(www.test@xxxx.com) I can not edit it. It looks ok my template is there. But I can not edit it. What am I doing wrong or have I missed something? I downloaded Bitnami Drupal Stack and set that up correctly so I can work on my PC however My bitnami Drupal only shows a Default Drupal page and not my test site sitting on my host server. How do I config either bitnami/Drupal or my test site on my host server so I can edit....its like two ships sailing in different directions.... HELP!

    Just an fyi, while setting this up using Drupal 7.9, my settings.php does not have a:
    '$db_url' variable

    Instead, db connections are listed like this:
    $databases = array (
    'default' =>
    array (
    'default' =>
    array (
    'database' => 'db',
    'username' => 'user_db',
    'password' => 'password',
    'host' => 'localhost',
    'port' => '',
    'driver' => 'mysql',
    'prefix' => '',
    ),
    ),
    );

    So you'd actually have to modify the 'database' variable within that array to point at your test database.
    The '$base_url' is still present and should be modified as listed in the article.

    Also, the permissions on settings.php are set to 555 (maybe host specific to me); you'll need to change that to 755 to modify the file and then back to 555 again once modifications are saved and on the server.

    This relevant to hostgator shared hosting.

    My changes made to test site shows on live site and vice versa. The DB are not the same and I have even moved the test site to it's own root and used virtualhost to point to it. Has anyone else ever encounter this?

    I am having same issue. I followed instructions verbatim to create a beta site. I can enable/disable modules independent of one site affecting other. However when I put my beta site under maintenance, my prod site also goes under maintenance and vice-versa. I have been monitoring logs and when I use prod site I see no access to beta and when I go to beta, I don't see any access to prod, so it's not like one site is referring to other. But somehow the site maintenance status is linked. I am guessing this may have to do admin user login but can't figure out what's going on. I am running on Drupal core 6.22 and was creating beta site to test migration to 7.

    Thanks for any help here.

    It seems when i go to my site www.mysite.com the action tag in the user_login_form is absolute url 'https://www.mysite.com/....'. However if on a separate window I login to my beta site http://beta.mysite.com and then reload the page www.mysite.com the action tag in user_login_block changes to https://beta.mysite.com... and that is the problem. Looks like php session/cache variables may be getting mixed up for virtual hosts.

    Any help is appreciated.

    Thanks

    I had the same thing going on and then I realized that I never changed the rewrite base to include my test directory

    was: RewriteBase /user
    needs to be: RewriteBase /user/testdirectoryname

    where user is your username

    just a thought...

    Don't panic! Whatever you do, don't panic! Unless, of course, you didn't make a backup - then by all means freak out...

    Same issue with changes happening on both sites (test and live), but this didn't solve it for me. Still working on the issue. The rewritebase entries in .htaccess were both commented out. I couldn't find any change that helped resolve this. I'm in Drupal 7.12. Thoughts?

    if you have memcahe module or one similar enabled on both sites, disable it on the testing site.

    Did you find a solution? I'm having this problem as I'm trying to create a Drupal 6 test site on the same account as my prod site. I created a test folder on same level as my public_html folder (where live site is), and set a test.domain.org to point to the test folder. I've copied everything over and created a new DB, new user, changed the settings.php file, but after all that, the admin/settings/site-information page still shows the old domain as the "default front page," and every time I try to make a change, I get sent to the prod site. Very frustrating.

    You sure you are not using the same database for both sites? You could check sites/all/default/settings.php on both sites and see if the settings.php file is accessing the same database; then what you do in one place will change the other.

    That was happening to me; then I made separate databases via phpmyadmin export SQL, then import SQL to the new database and sychronized them as required after making changes to one site or the other.

    I completed steps 1-3 a few weeks ago and finally got around to editing settings.php today. However, when I navigate to the test site, I see posts made today - it is clear that I am seeing the production site.

    My server runs Parallels Plesk, and I used the Plesk UI to set up the new Virtual Host (reconfiguring Plesk via Shell is definitely risky and not easy).

    What is weird is that I can make the test site give a 500 error via a typo in ~/test/sites/default/settings.php, so drupal is definitely reading that file.

    I can't see anything in the .htaccess which is redirecting:

    # Follow symbolic links in this directory.
    Options +FollowSymLinks
    # Various rewrite rules.
    <IfModule mod_rewrite.c>
      RewriteEngine on
      RewriteRule "(^|/)\." - [F]
    # Pass all requests not referring directly to files in the filesystem to
      # index.php. Clean URLs are handled in drupal_environment_initialize().
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteCond %{REQUEST_URI} !=/favicon.ico
      RewriteRule ^ index.php [L]
      # Rules to correctly serve gzip compressed CSS and JS files.
      # Requires both mod_rewrite and mod_headers to be enabled.
      <IfModule mod_headers.c>
        # Serve gzip compressed CSS files if they exist and the client accepts gzip.
        RewriteCond %{HTTP:Accept-encoding} gzip
        RewriteCond %{REQUEST_FILENAME}\.gz -s
        RewriteRule ^(.*)\.css $1\.css\.gz [QSA]
        # Serve gzip compressed JS files if they exist and the client accepts gzip.
        RewriteCond %{HTTP:Accept-encoding} gzip
        RewriteCond %{REQUEST_FILENAME}\.gz -s
        RewriteRule ^(.*)\.js $1\.js\.gz [QSA]
        # Serve correct content types, and prevent mod_deflate double gzip.
        RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
        RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]
        <FilesMatch "(\.js\.gz|\.css\.gz)$">
          # Serve correct encoding type.
          Header set Content-Encoding gzip
          # Force proxies to cache gzipped & non-gzipped css/js files separately.
          Header append Vary Accept-Encoding
        </FilesMatch>
      </IfModule>
    </IfModule>

    And if I put an index.html file in /test/, that page is displayed.
    Any ideas?

    It was because the Drupal 7 format database call had been added at the bottom of the Drupal 6 settings.php. I have now amended the documentation above to warn about this.

    Folks, thanks for the help. Here is what worked for me, to set up a development site, using namecheap.com shared hosting, where I used a subdomain of my main site, so that I could test things "live", but still not mess up the production site.

    I did not ask the host provider for anything at all, or pay any extra money for stuff, or have to set up a local server on my home laptop, which dies frequently. Setting up a local site on your home computer, which you put a WAMP server on, is all very well, especially if you happen to actually host your own site; that is, your computer is the server, but then you are probably more sophisticated than I am. For the rest of us, using shared hosts, half of us are just modifying the live site online anyway, without any staging or development or testing site at all. Well, that gets complicated, because if your local server, installed on your laptop, is not actually online, it is does not connect with things like paypal or shipping services, so you can not really test those things offline. I found it easier to just have two live sites: one an addon domain and the other a subdomain, both live, up and running. Then sychronize the databases to swap changes.

    Have a live production site called www.freefuelforever.com This is an add-on domain, which I added using the cpanel, which you can find at www.yoursitename.com/cpanel Uploaded unzipped commerce kickstart package to the subdomain using Filezilla, free to download. Go to www.yoursitename.com and go through the installation, maybe make a basic site, get it running. Now you want to make some changes that are known to cause fatal errors as you muck around, things like content translation, for example. Fine-instead of experimenting on your live site, make another site in a subdomain and migrate your existing site over. Here is how:

    login into www.yoursite.com as admin
    Disable clean URLs on the the live site in site setting, site configuration
    Clear cache in site settings, stop junk from being transfered
    Put site into maintenance mode. Otherwise get fatal errors on starting up the dev site.

    Go to www.yoursite.com/cpanel and find phpmyadmin, start it
    find the database for your drupal live site and click on it
    export the database, SQL format worked fine for me, probably goes to your downloads directory when saved.

    Go back to cpanel, to add a subdomain

    Made a subdomain called dev.freefuelforever.com Subdomains are free to make on most shared servers, "dev" means development site, so yours would be dev.yoursite.com You could call the root directory "dev.yoursite" to easily identify it

    Went back to control panel (yoursitename.com/cpanel), find database management, made a new database, named it "fre_dev" to distinguish it from "fre", the live site database.
    add a user to the database, probably "admin", use the same user as for the live site to keep things simple

    Used filezilla to upload the unzipped commerce kickstart drupal files. I tried copying the files from the live site, but somehow that messed up. I found it easier to just put another install of kickstart on the subdomain, "dev.yoursite.com"

    Go to the subdomain, follow the drupal install, just like for the live site, except, of course, you specify that the database is your new database, probably named _dev to make it easy to remember. Now you have "dev.yoursite.com" up and running, with some filler content. I never installed the demo store. You know the dev site works. Disable clean URLs, clear cache and put the site in maintenance mode, as with the live site above.

    Go to control panel (cpanel), my databases, and delete the _dev database, to get rid of all the data from the dev site. Then create that database again, same name, and add the same user, probably called "admin". Now you have an empty database for the "dev" site.

    Go back to phpmyadmin, find the _dev database, click on "import" and find the SQL file that you previously exported from the live site, probably in your downloads folder. Import the live database into the dev database, which may take a while.

    Go to cpanel, file manager, and find your live site folder. Go to the sites/all/default directory and find the settings.php file. Click to download. Edit the file in some program like wordpad so the file name stays the same and no format changes occur, as might happen in big programs like openoffice write. Search for and replace the live site database name and username and replace them with the dev site database name and user. Maybe you have the same "admin" user for both, and only need to add the "_dev" to the database name, if you have named things logically.

    Go to cpanel, find the dev site directory, go to sites/all/default and change the permissions on the settings.php file so that you can overwrite it, something like "775" will do it. Right click on the file or find the "change permissions" button to do this. Now you can overwrite the file, either upload directly using the "upload" button in cpanel file manager, or use something like Filezilla. Upload your modified "settings.php" file.

    If you have done work on the live site, copy the sites directory from the live site to the dev site using file manager. This is to get all the uploaded photos and modules you may have installed. Make sure the permissions allow you to copy; if you get errors, then go ahead in file manager, select all the file to copy and change permissions, which you can do in bulk.

    Go to your dev.yoursite.com and you should see the site in maintenance mode. dev.yoursite.com?q=user will let you login as admin if you are not already logged in.

    Run dev.yoursite.com/update.php to run a database update. Go into the modules under site settings and see if there are updates. See if there are errors, or things missing with the status report. All looks OK? Go to site settings, configuration and take the site out of maintenance mode. Now you should have two identical sites, dev.yoursite.com and www.yoursite.com Make changes in dev.yoursite.com without fear of messing up www.yoursite.com

    When happy with changes to dev.yoursite.com and your want the live site to be the same, go to cpanel, phpmyadmin and click on synchronize. Changes in one site can be put to the other with a single "synchronize" in phpmyadmin.

    In the meantime, if you do not like people seeing your "dev.yoursite.com", you can use cpanel to put in a redirect to www.yoursite.com while you are not working on the dev site.

    I am finding my test sites changes showing up directly on my live site as well. I have triple checked there are two different databases and the test directory settings.php file directs to my test database.
    My host has a file size limit for uploading to databases, so I had to have them populate my database. Is there a setting in phpmyadmin which might be making the databases synchronize or something? I've read through all the previous comments on this topic and nothing already stated here has helped me fix my problem.