Great points Jaza On 5/8/05, Jeremy Epstein <jazepstein@gmail.com> wrote:
+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'.
I think I can live with that. Provided that ./drupal/core does not contain any configuration or contrib stuff in it, I am fine. This will also solve the name clash objection, since all will be under drupal. We ship an empty local with only subdirectories in it (no files), and instruct users to copy the sample provided settings.php to drupal/local/sites/default or drupal/local/sites/sitehostname
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.
We already search two places, ./sites/modules and ./modules. I am not sure, but I think that Drupal only searches for modules when they are being enabled from the admin menu the first time. After that, the location is in the database, and no search for modules occur.
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.
They can be in either of two directories, as I outlined above. So the potential for clash is already there in 4.6 today.
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.
Interesting points. I think we can either: 1. Define an order of precedence, and take the first one that is found. This is problematic for support, and will be the cause of a lot of grief for site admins and for Drupal developers down the road. That is, unless we can list in the admin pages what the path for the module is (something that we need to do anyway, and is long overdue). 2. Report that modules with the same names exist and give an error message and do not activate this module at all until that conflict is resolved. We hence disallow the practice of having modules with the same name in different directories. I think that this is best in the near term at least. 3. Module overloading and such is too problematic for my taste from the support point of view. I would not recommend it, at least for now, before thinking it over thoroughly and discussing it in the developer community.
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.
Agree. I like to hear from more old timers (Dries? Killes? Moshe?)