[development] let's cleanup /misc

vlado vlado at dikini.net
Fri Jan 6 10:06:48 UTC 2006


>   * rework misc/
>   * rework sites/
>   * rework files/
>   * leave everything else the same
>   * move toward a protected admin-only configuration ("do you
>     want drupal/modules protected? click yes and type in a
>     non-public directory and we'll move it for you").

My heart warms with joy when somebody puts their thoughts better than
me. This probably means that my heart is burning all the time, but
nevertheless Morbus makes a really good summary of the situation. I
can't, so this is long, sit back and relax :)

I personally would prefer minimalistic changes to the DEFAULT directory
layout, while allowing variants for other uses and situations. If we
won't find a reasonable common ground why not accomodate the common
cases and let the historical model be the default - less confusion in
current users, less pain to upgrade.

Based on the discussion I would suggest:

* move the default files location under sites/<host>/files

* add a sites/all directory for all non-core modules, which should be
  available for all hosts

* extend the directory scanner to understand different layouts - this  
  can be done by introducing $public_location and $private_location
  in settings.php and using those for module, theme or other file and
  directory lookup in any of the scenarios above

* get rid of misc/ - in favour of 
    - sites/all/themes/all/js
    - sites/all/themes/all/css
    - sites/all/themes/all/css/images
  the disadvantage of this is the directory depth both to type and to
  see in browser, the latter can be remedied in code 

*  */vendor  is a worthy contender to consider - this way we won't mix
  drupal and non-drupal code too much - this will be easier to upgrade
  but otherwise I don't have an idea on all implications

* Although I use something like the suggested public/private separation
  already, I would NOT make it the DEFAULT - it is not for the faint
  hearted, it needs an installer for the majority of people. I have
  sets of shell scripts to do the maintenance here, but for an average
  webhost that is not good. It can be implemented with an installer.

* I wouldn't touch the css bundling with modules now - it is too
  complicated to achieve, but I would put it in the longer term
  TODO - having all css files in one location is logical, it is easier
  for the designer, it will be easier to handle within the theme
  engine the selection of which css files to include - for example
  a custom event.css for your carefully crafted theme- How would you 
  do that with the current layout?




More information about the development mailing list