[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