+1 for 'local'. I like the name mainly because it is short and simple, just like all the directory names that we currently have (e.g. 'modules', 'themes', 'sites'). Giving a new directory a name like 'drupal-local' would be inconsistent. However, I don't like the structure of the root directory that was proposed: public_html - .htacccess - index.php - /drupal - /local This structure might confuse people into thinking that everything drupal-related is in the 'drupal' directory, and that the stuff in 'local' is not related to drupal at all. I suggest this structure as an alternative: public_html - .htaccess - index.php - /drupal --- /core --- /local That way, all drupal-related stuff is inside the one directory, 'drupal'. The internal structure of 'local' doesn't need to change (I like what's been proposed so far for that). And when you want to upgrade, you just replace everything in 'core'. Also, I have two concerns about the new proposed system of loading modules and themes: 1. Performance: what would be the performance impact of this system? To load all the modules, for example, Drupal would have to look in /core/modules, then in /local/modules, then in /local/sites/site1.com/modules. Three different locations for one site's modules. Probably wouldn't be a problem, but I'm no expert. 2. Duplicate files: what will Drupal do if it finds three instances of the same module, each in a different location? This is not a problem ATM, because all modules are in the one directory. Will it load the instance that is 'most local' to that site, and ignore the others? E.g. it would load the instance in /local/sites/site1.com/modules, and ignore the instances in /local/modules and /core/modules. This makes the most sense, as it follows the 'scope' principle, much like the scope rules for variables in PHP (and other programming languages). It would also allow modules to be 'overloaded', that is, you could have one version of a module in /local/modules, but you could have a different version of the same module, specifically for site1.com, in /local/sites/site1.com/modules. What would be the performance impact of finding the 'most local' module? The other option would simply be to give an error message if the same module exists more than once, and to not load any of the instances. Overall, I agree with the concept of separating all core files from site-specific files. But we have to think carefully before we implement anything - changing the directory structure is not something that should be done lightly, or often. Jaza.