Splitting common D6 code base into 2 totally separate sites

I have re-arranged modules and code bases several times. Just make a copy of everything to split the sites apart. Delete the 'default' folder in the second site and create a symlink named default that points to the directory for the second folder. E.g.

if the sites directory has a structure:

sites
- all
- default
- example.com

you can just delete the folder 'example.com' in the domain that the 'default' directory applies to - your first domain and site is now on that core and module base.

In the copied folder (that I assume is in the correct location for the second domain 'example.com'), the sites structure will be

sites
- all
- 'default' (symlink to example.com directory also in sites)
- example.com

Using a symlink means you won't have to change around files and images stored inside the 'example.com' directory.

Just delete the modules in each respective sites install that you don't need.

Also, you can move modules around between 'all/modules' and 'default/modules' with no fuss. Clear the cache, run cron and you should be good to go again (Drupal will automatically find them in the new location and use them).

Bingo, two sites now using their own versions of core and modules.

If you have to change the database server too you will want to export the tables for the second site, import them into the new database and update the 'settings.php' file to point to the new database (if you don't do this it will probably still work and run off the old database, it depends on the server config). Backup migrate will let you export the tables for each site and download a file representing them. If you are using MySQL, PHPMyAdmin has a simple 'export' and 'import' feature too.

I see two issues, one is the use of symlinks. First, they are exactly like shortcuts, no need to worry about them. There are GUI ways of making them in the exact same manner as a shortcut, the command-line method is a single line though:

ln -s ~/drupal/sites/example.com ~/drupal/sites/default

That will give you a symlink called 'default' that links to 'example.com'. If you are not using the 'files' directory in the 'example.com' directory of your second production site you can probably just rename it to 'default' and be all good to go. If you are though, the other option is to change the address of these files in the database. I have done this before, it's a pain. I can't recall where to look for these though, since moving to using symlinks it hasn't come up. Someone else might help with that.

The second issue I see is the organisation of the 'sites' directory. Let's ignore the test set up, changing that is the same as the first one. I'm a little confused by your description though.

default - links to 'production/public_html/sites/production.tld' - what do you mean by 'links to'? It sounds to me like you mean a symlink, but since you said you dont like them, I am not sure now. That being the case, how is there two sites running of this codebase? The sites directory needs a directory per website, based on your info, I would have expected to see something like this:

There should also be separate 'settings.php' files per site, i.e. one in the directory 'default' and one in 'subsite.production.tld'. There is no simple way to know what site is running by looking at the settings.php file, it's main job (in this context) is to connect to the database where your content is pulled in. The db_url line will tell you what database it is connecting to and on which server.

Does production.tld display different information that subsite.production.tld? I could be missing something, but without multiple settings.php files I don't see how you could have sites displaying different information (not without major changes to the settings.php file anyway).

The only issue I see is the location of files. Where are files stored for the subsite at the moment? The production site files should be fine, since they won't be moving and more importantly the URL for a file won't change. For the subsite this isn't true. Some modules will use the location of the files database you enter as part of the URL, but some (image certainly used to have this problem) modules hardcode the URL for each file at the time of creation, if this is the case with any of the files you have changing the structure will cause a problem.

If i add "//?q=admin" to my url i can get the Administer By Task or By Module but again none of the links will direct me to their intended target

Did you delete everything in the cache? The cache tables can be emptied entirely with no ill effects on the site (bar performance hits as the cache is rebuilt), backup and migrate module by default excludes all data from them in any backup.

Do you use clean urls on the site normally?

I'm assuming the 403 is the browser default, not a Drupal page, if that is the case I would say it is almost certainly the .htaccess file causing that.

I have had problems with transliteration and mimedetect modules when moving sites around too, that can sometimes give the dreaded WSOD - either of these modules in use?

With so many different errors coming up, it's time to minimise potential problems, I would remove all the contrib modules from the sites directory and all sub-directories as a start.

Another debug procedure, put in a fresh settings.php file and see if the default drupal install page comes up, if it does Drupal core is probably working.

NOTE: I always give my sites 128MB of memory - just to be sure.

Ahh, debugging. Code is a fickle thing, web-based even more so, and server-side where you can't access the server is the worst!