[drupal-devel] Cleaner Directory structure

[K B]

Great points Jaza

On 5/8/05, Jeremy Epstein <jazepstein at 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?)