Hi, On Wednesday 28 December 2005 08:55, Karoly Negyesi wrote:

On Wed, 28 Dec 2005 07:42:47 +0100, Khalid B <kb@2bits.com> wrote:

...

+1 on the general idea. A while back, I suggested that we have all drupal files be under a subdirectory, with only index.php and .htaccess at the root level. And I objected and will object. This brings us no good.

-1 from me. There are only 38 files in /misc and no good reason for doing this. On the other hand, Khalid's idea has much more merit as it will make site integrations and securing much easier. Best regards. Frank

Here are the previous discussions on having a cleaner directory structure for Drupa. It has several advantages: - Isolation of Drupal core from everything else. - Easier upgradability. - Less clutter in the public_html/www directory. As a bonus, this makes symbolic linking for multi-sites easier. http://drupal.org/node/22269 http://drupal.org/node/22336 http://lists.drupal.org/archives/development/2005-05/msg00332.html One objection is CVS history. This can be addressed by moving the files at the backend (requires manual mucking around, but doable). On 12/28/05, Karoly Negyesi <karoly@negyesi.net> wrote:

On Wed, 28 Dec 2005 07:36:06 +0100, Theodore Serbinski <tss24@cornell.edu> wrote:

...

As 4.7 continues to grow and new files are added or about to be added (like the forthcoming textarea patch, w00t indeed!), I think it's time for an early spring cleaning on this folder. I recommend the following:

delete /misc

create: /images /images/logos (for those drupal powered logos) /scripts (merge with shell scripts perhaps?) /styles

Maybe /misc/logos , /misc/scripts and misc/styles?

Well, I never realized this has already been debated so much, maybe I should have kept my mouth shut then :-) But I do agree, I think we need to clean up the file structure, Drupal is growing considerably and a change in file structure is warranted IMO, as it seems many others agree too. I never even considered the security aspect and that is *very* legitimate, more than just tidying things up as I originally intended. I do agree with Ber that his proposed structure similar to RoR is one of the best approaches, as that approach seems to address everyones issues (security, tidyness, etc...). However, it seems we need to tweak things a bit on that before everyone can agree on something. Ber, do you have that online somewhere where we can make changes and come up with a proposed structure? Maybe this should go in for 4.7, maybe next release. Or maybe we should just all try and solidify 4.7 and see if at the same time we can come up with a resolution for directories and if not, so be it, next release it is as Morbus suggests :-) - ted (who seems to be starting lots of debates lately...) On 12/28/05, Bèr Kessels <ber@webschuur.com> wrote:

Tell me if I get annoying, okay? But here is how Ruby on rails does it. Again, I think RoR Just Got It Right.

The idea comes from three things: 1: Revision control. it must at all means map 1-1 to a complete project SVN (or somthing alike it) repository. 2: Security. On your production environment you never (ever) want anyone to be able to access any of your code or scripts. Even if you can disallow this with .htaccess. (for fun: get out there, google for ?q=node urls, and open up theurl.com/modules) 3: Development. have all your development tools and unit testing stuff at hand. ******** drupal *********

. |-- README |-- |-- app | |-- modules | | |-- aggregator.modle | | |-- etc | | `-- watchdog.module | |-- theme-engines | | `-- phptemplate | `-- themes |-- sites | |-- site1.com | `-- site2.com |-- database | `-- create.mysql etc (also update.inc) |-- doc | `-- INSTALL etc |-- includes |-- public | |-- index.php | |-- favicon.ico | |-- images | | `-- druplicon.png | |-- index.html | |-- javascripts | | |-- controls.js | | |-- dragdrop.js | | |-- effects.js | | `-- prototype.js | |-- robots.txt | `-- stylesheets | |-- depot.css | `-- scaffold.css |-- script | |-- install.sh | |-- generate_module.sh | |-- environment_change.sh | `-- generate_theme.sh `-- vendor `-- plugins

You should speak up, and not "keep your mouth shut". A dumb question is the one never asked, as they say. I agree it should NOT be in 4.7. It is too late for major changes for a release that already has 2 betas out. For 4.8, I think this should be considered. Whatever scheme we chose should address a) Clutter in the DocumentRoot b) Security: easier to set file and directory permissions en masse. c) Isolation (this is the big one for me) the separation of : 1. Drupal Core files. 2. Contributed modules 3. Site data files (attachments, images, ...etc.).

On Wednesday 28 December 2005 01:54 pm, Chris Johnson wrote:

...

c) Isolation (this is the big one for me) the separation of :

1. Drupal Core files. 2. Contributed modules 3. Site data files (attachments, images, ...etc.).

Isolation is the big one for me, too. I need to be able to quickly find core, versus add-on/contrib versus data, and be able to make mass copies, backups, perm changes, etc. as an admin. It is error prone to have to find everything by hand, one at a time.

..chrisxj

Random off-the-cuff thought that I ask no one implement before 4.8... :-) Currently, modules and themes can be placed in /modules and /themes, respectively, OR in /sites/mysite.com/modules and /sites/mysite.com/themes, if you're using Drupal's multi-site feature. Why not introduce /sites/all/, and require any non-core-package stuff to go there? So any contrib modules would go in /sites/all/modules, for instance. That way, All non-as-downloaded files are in /sites/ somewhere, and you can just backup that directory and be done with it? There's no change in functionality, just a few paths within Drupal's includes since it already looks for modules and themes in a bunch of different places. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

On Wednesday 28 December 2005 04:47 am, Bèr Kessels wrote:

Tell me if I get annoying, okay? But here is how Ruby on rails does it. Again, I think RoR Just Got It Right.

I've not used RoR personally, but I was recently at a presentation here in Chicago that my LUG was hosting for the creators of both RoR and Django (Python). It convinced me of the following facts: 1) Django is a good CMS, with some RAD features we may want to look into. 2) RoR is NOT A CMS, it's an app framework. 3) The authors of both Django and RoR have *no clue* what the difference is between an app framework and CMS. :-) 4) RoR was too focused on "beautiful code" for me to spend any time on. Step out of what the author thought was "beautiful code", and you are on your own. So while I'm not against the idea of reorganizing Drupal files to make more sense / be more secure, pitching it as "because RoR does" is not necessarily a good way to market it. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

RoR had this particular issue (layout of the files) very well thought out. Indeed very much focussed on development, but we are discussing this on development@drupal,org, so why not focus on that. The whole layout issue, after all will not even be noticed by Joe Average. Its purely a development issue, IMO.

A big part of it is development, but a larger part is a site admininstration/management issue: security, servicability, upgradability, backup. As far as CVS goes, if we decide on a layout, the moving can happen at the server level manually. Yes, this is more reason to use another SCM, but that is another thread.

Op zaterdag 31 december 2005 16:09, schreef Dries Buytaert:

I'm OK with making such changes as soon consensus is reached.

Okay, but how to reach that consensus? I am a bit afraid that if we want to reach this on the development ML, we won't reach this at all. :/ I have a plan, but that is really for a longer term, so in this case it might not be the best route. I want to built drupalCOM on a new structure (after RoR), then spend some time tweaking and trying that. Once some people have tried it, and feel its a good structure for 1) development, 2) security, 3) deployment on Joe Hosting Provider and 4) multisite environments, we could propose that change for core. Now, my main issue was that it is hard to maintain this against drupals CVS, when all the files are moved up and down. So I am still pondering about the practical side of it. But as mentioned, this a long route. We might want a quicker solution? Bèr

On Thu, 2006-01-05 at 11:53 -0500, Theodore Serbinski wrote:

Ber,

So let me start it off, the new directory structure should:

1. Improve the security of a Drupal install by keeping all files private, except for an index.php, no module or include files should be accessible from a web browser

How would moving the files make them anymore protected than the current htaccess method? It would also break module compartmentalization by requiring module specific css to be moved out side of a modules folder. I don't even care if users can view the files as long as they can't modify them. after all they can download them from drupal.org and search for vulnerabilities all they want.

2. Core modules and includes should be completely seperated from extra downloaded modules and themes. This should make backing up things easier, as you only have to back up your "custom" folder instead of all of the main Drupal ones

This is something I brought up in a best practices thread. Drupal is already capable of this, its a part of the multisite features. You can use sites/example.com/themes and sites/example.com/modules.

3. The new structure should be multisite friendly. There should *not* be one files folder, but rather multiple ones, for multiple sites. You don't want that pr0n site on your multsite sharing the same images as your core business website, do you? ;-)

This is also possible... you just have to change the files path to sites/example.com/files.

Please add/revise to this so we can reach a consensus on this soon enough.

I think pleasantly enough drupal already has a lot of these features. So the work is more a matter of changing the default recommendations and documentation.. I personally think every drupal install should be viewed as a multisite install. and configured as a multisite install, so there is only 1 recommended way to setup drupal, instead of this single site, multisite contention. The only change to the sites(modules,themes) handling I can think of would be sites/default(themes and modules) being shared across all sites so you don't have to put anything contrib in the modules folder. And can maintain a clean based drupal install and only have to worry about the sites folder.

Ber, once we arrive at this, the next step would be to take your RoR structure and go through and adjust so the above criteria are met. After that, we setup a patch to implement this, and then commit.

If we get this early in on the next release cycle, we'll have plenty of time to make tweaks and adjust things as development moves forward. Not only that, but it'll give us developers lots of time with the new structure as we work on our other patches.

ted (m3avrck)

On 1/5/06, Bèr Kessels <ber@webschuur.com> wrote:

...

Op zaterdag 31 december 2005 16:09, schreef Dries Buytaert:

...

I'm OK with making such changes as soon consensus is reached. Okay, but how to reach that consensus? I am a bit afraid that if we want to reach this on the development ML, we won't reach this at all. :/

...

1. Improve the security of a Drupal install by keeping all files private, except for an index.php, no module or include files should be accessible from a web browser

How would moving the files make them anymore protected than the current htaccess method? It would also break module compartmentalization by requiring module specific css to be moved out side of a modules folder. I don't even care if users can view the files as long as they can't modify them. after all they can download them from drupal.org and search for vulnerabilities all they want.

Four (uncommon) use cases: 1. If you screw up your Apache configuration, PHP files can stop being interpreted. People will be able to download them as text files and get hold of your MySQL information in settings.php. It is not likely to happen, but it happened to me on my local development machine. If you upgrade Apache on Gentoo Linux, and you choose not to merge the new configuration file with the existing configuration file, mod_php will be disabled. 2. Some editors save copies of the files you edit. Some crappy editors add ~ or .log to the end of your file, so settings.php becomes settings.php~ or settings.php.log. Again, downloadable. 3. There are webservers that don't support .htaccess files. Apache is not the fastest webserver in the world. Sites like wordpress.com (Wordpress hosting) runs on LightSpeed (http://litespeedtech.com/). LightSpeed happens to have .htaccess support, but some of the alternatives have not. 4. PHP has 'highlight files'; an option that allows you to view a PHP file's source code simply by substituting .php by .phps. If someone adds "AddType application/x-httpd-php-source .phps" to the Apache configuration file, you're toast. -- Dries Buytaert :: http://www.buytaert.net/

1. Improve the security of a Drupal install by keeping all files private, except for an index.php, no module or include files should be accessible from a web browser

This will not increase security. If .htaccess can not protect you, why would this? And how would we ship the tarball...? Untar this half below documentroot and index.php to documentroot...? /me shakes head

2. Core modules and includes should be completely seperated from extra downloaded modules and themes. This should make backing up things easier, as you only have to back up your "custom" folder instead of all of the main Drupal ones

Sure thing, use site/default/modules and site/default/themes for your own modules and themes. No need to change core.

3. The new structure should be multisite friendly. There should *not* be one files folder, but rather multiple ones, for multiple sites. You don't want that pr0n site on your multsite sharing the same images as your core business website, do you? ;-)

Opsie, what I suggested is multisite.

Please add/revise to this so we can reach a consensus on this soon enough.

You need to convince me that the current is not good. I tell you, this is not easy. Regards NK

OK, here are my points: 1. In DocumentRoot, there should be only 2 files: index.php and .htaccess, and one directory (drupal/). Nothing else. This allows other applications to coexist cleanly (without clutter) with drupal. 2. Under drupal/, there are two directories: core/ (with includes, modules, misc, ...etc.), and sites/. Anything under core/ should only be core Drupal, untouched by anyone, and hence easily upgradable. everything in core can be read only, and hence security is not an issue. 3. sites/ has configuration files with multi site setup (hostname, default, ...etc.), in addition to an "all/" directory, which is shared by all domains. 4. Each hostname directory, as well as all/ directory can have modules/ and themes/, files/ with site specific themes, modules, ...etc. 5. The current scheme of having .module, .inc and .css under one directory for a given module should continue. It works well. My only gripe is that many modules do not do a drupal_get_path(), and hardcode 'modules' in there. Now, moving to that scheme is a pain, and there are implications on CVS for older releases, but let us ignore that for a minute, and see if the reorganization itself has merits, and leave the "how to move to it" for later.

...

3. sites/ has configuration files with multi site setup (hostname, default, ...etc.), in addition to an "all/" directory, which is shared by all domains.

Now this is a valid idea -- maybe the site/default/modules and site/default/themes should be included for every site? Oneliner patch.

Yeah, this is the one thing that's come up that multisite functionality DOESN'T yet handle, and it would definitely be cool. The core /modules directory etc could be kept completely clean. --Jeff

...

1. In DocumentRoot, there should be only 2 files: index.php and .htaccess, and one directory (drupal/). Nothing else. This allows other applications to coexist cleanly (without clutter) with drupal.

If you want other applications to coexist then use subdirs. That's clean.

It is not. If I want to create a tar archive (or zip) of Drupal, I have to name the directories to include, not just backup the "drupal/" directory. If I want to clone the Drupal install to a subdirectory (say I have a hosting account and they add domains/subdomains in subdirectories) for testing or another site, then it is a pain.

...

2. Under drupal/, there are two directories: core/ (with includes, modules, misc, ...etc.), and sites/. Anything under core/ should only be core Drupal, untouched by anyone, and hence easily upgradable. everything in core can be read only, and hence security is not an issue.

Under drupal/site/sitename you have everything you need to backup.

True. We need to publicize it more, and even enforce it. Perhaps allowing only core themes and modules to run off modules and themes is the way forward.

...

5. The current scheme of having .module, .inc and .css under one directory for a given module should continue. It works well. My only gripe is that many modules do not do a drupal_get_path(), and hardcode 'modules' in there.

So true. What's the URL of the handbook page where you have documented this tip?

Here is an example of a patch I recently submitted. http://drupal.org/node/42899 I found that same problem in many modules when I was reorganizing my site's directory structure to move all contribs under sites. Event, statistics trends, and something else comes to mind.

On Thursday 05 January 2006 11:51 am, Khalid B wrote:

3. sites/ has configuration files with multi site setup (hostname, default, ...etc.), in addition to an "all/" directory, which is shared by all domains.

OK, so Khalid beat me to it by a few hours. :-) That's what I get for replying before I read all mails in the thread. Make that two votes for /sites/all. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

Opsie, what I suggested is multisite. Don't forget that multisite, while good could be a pain for upgrades. The code upgrade is easy, but the database upgrades of a bunch of sites are a pain.

At the moment we don't have an upgrade approach for that, just a set of floating rumors how to do it easily, so that we minimise downtime. The various softlink farms, etc... When suggesting and deciding on a change we need to consider such approaches, so that drupal is easily 'farmable'. Hosting providers will love us for that.

Op vrijdag 06 januari 2006 01:31, schreef Larry Garfield:

/sites /all /modules /themes /theme-engines /default /modules /themes /theme-engines /files /example.com /modules /themes /files ...

That way stuff that people used to put in /modules or /themes would go under /sites/all instead, but otherwise functionality is the same. Nothing outside of /sites is ever edited by a user (unless they're being silly and hacking core). Backup is then cp ./sites /my/backup/directory and you're done, and a .htaccess rule to hide ./sites/* is trivial.

Thoughts?

I like this, but the security part should get some attention too. Here is my shot: /public index.php xmlrpc.php /stylesheets /javascript /images /icons /sites /all /modules /themes /example.com /includes /database /public contains all the web accessible stuff. /sites/all contains the default settings.php and default stuff as well as the the Bèr

On 05 Jan 2006, at 11:37, Bèr Kessels wrote:

...

I'm OK with making such changes as soon consensus is reached.

Okay, but how to reach that consensus? I am a bit afraid that if we want to reach this on the development ML, we won't reach this at all. :/

I think it is a good idea to optimize the directory structure for: 1. Security. Separate public files from non-public files and make it easy to move all non-public files out of the document root. 2. Ease of upgrades. Separate system files from user files to make it easy to upgrade, maintain or backup your Drupal website. How do we reach consensus? If there is no consensus, you'll have to put more effort in it. Continue to propose layouts that satisfy both (1) and (2)? Put all the proposed trees next to each other on a single page along with a summary of their advantages and disadvantages. Next, create a script that converts and existing tree to the "winning tree" so we can test it. Later we can reuse the script to upgrade existing sites. Got it? Do it! -- Dries Buytaert :: http://www.buytaert.net/

On Thu, 2006-01-05 at 13:29 -0500, Khalid B wrote:

...

1. Security. Separate public files from non-public files and make it easy to move all non-public files out of the document root.

That is a good idea, and I think this is what Ted (ma3verik) was saying all along.

This makes part of Drupal live above DocumentRoot, mainly code (includes, modules), as well as configuration (settings.php). CSS stuff has to be under DocumentRoot still.

There will be implications if we take this too far though, for example, if a module has .css files in it, then do we separate the .module from .css in different directories? This would then make installation a pain since files have to be copied elsewhere.

ok... I'll conceed on the file system security for settings.php and the like... just to propose one filstructure that isn't too massive of a move around... 1) move settings outside of doc root, since it is probably the only file that represents a real security risk if it is compromised... ~/drupal-private/default/settings.php ~/drupal-private/example.com/settings.php 2) move everything under drupal folder so sites, modules, etc can exist as they are, leaving index.php in the doc root. ~/public_html/drupal/

Why not combine all those under one directory (e.g. drupal) to reduce clutter.

|-- app |-- sites |-- database |-- doc |-- includes (content similar to now) |-- script `-- vendor

drupal |-- | |-- app | |-- sites | |-- database | |-- doc | |-- includes (content similar to now) | |-- script | `-- vendor (for me, I currently delete database and script anyway, for both security and clutter. If they are out of public_html, I don't mind them that much) Another point is adding the "all" directory, and files under it and under sites. |-- sites | |-- all | | |-- files | | |-- modules | | `-- themes | |-- default | | |-- files | | |-- modules | | `-- themes | |-- site1.com | |-- site2.com | `-- ... Also, I am not sure what vendor is. Is this contributed modules?

Some notes:

themes, should be under public, they use images, CSS and more.

I tend to agree with this. However, since modules are now out of the public_html directory, then there will be copying involved when installing modules. Or will the installer take care of that (having a prototype file that says what files get where)?

How supported are symlinks? can we rely on them? if so, each contrib could be symlinked: /sites/default/modules/mymodule/stylesheets -> /public/stylesheets

I don't think we should rely on them, since some people host on Windows (not to many). sepeck? What do you think?

feeble attempt to satisfy the world..... maybe it should all be optional, and what we have now is the default. --------------------------------------------- INSTALL.txt //For advanced and security minded users... At the top of drupals index.php there are two options if you want to be crazy and move things around... $settings_path tells you drupal installation where the root of the settings tree can be found. It uses the same structure as the drupal sites folder, but will only be searched for settings.php files. $drupal_path tells index.php where it can find the rest of drupal if it has been seperated. ---------------------------- index.php <?php ... $settings_path = '.'; $drupal_path = '.'; ---------------------------- Everything else can stay the same only we add the sites/all?

Here is a renewed version:

I can't say I'm too much of a fan of this. There are a few instances, some legitimate, some opinionated, where this layout (and, at the moment, this concept of a "public" directory): * Spaghetti directories offend me. * Some users don't have anything *but* the public_html. * Some vhosts don't have anything *but* the public_html. * Nearly always, more file manipulations are required for install. Spaghetti directories offend me ------------------------------- When I download an application, I want every little bit of it in one parent. I don't want to keep changing parents around just to maintain an application. In many cases, Drupal is *supplementing* existing web site services, such as phpMyAdmin, other blogsofts, wikis, web-based mail scripts, and so on and so forth. The "public" directory harms this by forcing me to copy it's contents into the right place each and every upgrade [1], or live with a "public" word in my URL [2]. And just sticking this stuff into drupal/ and ignoring the non-public protection this layout proposes isn't a solution either - I still have drupal/public to worry about, when there's no need to have public/ in the URL. [2] [1] This also severely inhibits my ability to use CVS or other version control systems, as I will no longer be able to do a master "cvs update" due to this protection. If I'm in /srv/www where all my non-public Drupal files are, and public/ is stored in public_html/, a "cvs update" is not going to update the public_html/ crap. [2] And don't suggest that mod_rewrite can get rid of it for me. One of the primary reasons for this whole "public" stuff was to remove the reliance on .htaccess, no? That means a reliance on mod_rewrite too. Some users don't have anything *but* the public_html Some vhosts don't have anything *but* the public_html ----------------------------------------------------- Some users at horrific hosts are plopped directly into their public_html directory, with no access to anything else. We're now back at a new layout that has no security at all (again, going back to .htaccess, "better security" was the crux of this "public" dir, no, but the same server-unavoidable feature-lack gives us a problem), and "public" in the URL. To remove the public from the URL means copying and pasting all the public/ files into the public_html directory, which is yet another step on both installs and upgrades. In fact, this whole new layout just screams for a much more complicated INSTALL.txt, with multiple if/else chains depending on user desires and so on. Vhosts also apply (potentially - haven't thought it out) to this problem - some hosts configure vhosts.example.com as simply example.com/vhosts/. What does in that directory? example.com/vhosts/public? Or are we now manually copying and pasting the public files for each vhost too? If we're saying that .htaccess is fallible because it makes assumptions on the server, then *so is a default directory layout* which makes assumptions on a) a *need* to protect those files (I'm still not convinced of the need *at all*), b) a server layout that *has* a non-public directory, c) administrators that are smart enough to NOT make a DocRoot mistake vs. a "oops, enabled plain/text on all PHP files" (another suggestion was to rename .module and .inc to .php, thus protecting them from accidental, non-.htaccess-protected reading, but a misconfiguration on *.php files is about as likely, honestly, as a misconfiguration on a directory host, either publically, or from all the other users on a shared vhost). I would much rather propose: * 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"). Note: I profess to not mentally addressing the rest of the structure just yet - public/ just seemed like such a sore thumb to me. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

Replying to myself?

* 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 It just occured to me that http://drupal.org/node/13095 will be made trivial in this case. Which will probably as well reduce the drupal.css hit on webhost traffic.

Earlier I made an experiment with splitting the drupal.css file into logical (for me) parts - color.css, framing.css, typography.css, icons.css and would say that it improved the maintainability and theme development. It was easy to find what do I want to change. Maybe it's me, but it is definitely a nightmare reading/editing/understanding huge stylesheet files. So implementing if xyz.css is not in my theme directory then load the default xyz.css will work fine. As a plus it removes redundant css code, simplifies the css dependencies, removes the need for dirty css hacks to override drupal.css defaults. The negative side is that a designer will always need to start with a copy of the default css file.

* */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?

Is 'all' better than the current 'default', or will we have both 'all' and 'default'? default (currently) means the default website all means for all websites

Definitely the all functionality can be rolled into default, but that might be confusing. I personally would prefer the separate version, it allows treating the default site as any other.

How about the simpler:

sites/all/javascript sites/all/stylesheets sites/all/images sure, it makes sense

...

* */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

I don't see the point of 'vendor'. Well, the only point I see is not to mix drupal and non-drupal code. The equivalent in the linux world will be /opt and /usr/local - you put there things that are not coming with the distribution, so you are responsible for their upgrades and maintenance.

For example: the various Javascript based editors - they don't come with drupal, only their integration modules.

As a slight extension: all should not contain a settings.php file, default should only contain a settings.php file. If /all contains a settings file (defining databases, docroots, etc) will just cause users confusion when they try to change their local site settings.

The /default folder can actually define a specific site, unlike all, which applies to many sites.

Earlier I objected to default having a specific site. It should be the prototype for specific sites. Thus all installs should be treated as multisite with only one site present. This means that when you download a new release the default setting file that comes with it does not overlay one of your sites. So perhaps there should be another name for default, like distributed or original.

Now let's say someone requests a site called "bar".

Oops. I meant "baz". Something not defined in the sites folder. -M

On Friday 06 January 2006 01:00 pm, Khalid B wrote:

Walt

I have an issue with this: migration/backward compatibility.

Agreed. I have another: portability. I never develop on a live site. I always setup on a test server, behind a firewall/NAT/intranet/whatever, then copy the whole shebang over to the live server at once. Currently, all you have to do for that is flush the cache and update settings.php. Now we're talking about adding a rename-a-path step. As Khalid said, that can be problematic. I don't see anything wrong with /default/. Most installs, I suspect, are single-site. Let's not make things too complicated for single-install users unnecessarily. /sites/all doesn't require removing /sites/default, which is still very useful. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

Well I never knew my little post a while back would be such a catalyst for such a heated discussion :-) But it looks like progress is being made, so that it is awesome! Just like to point out I do agree with the direction this thread is taking and have a few comments from. On 1/6/06, Dries Buytaert <dries@buytaert.net> wrote:

...

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

I think everyone agrees with this one. If so, Ber can start working on this.

Bravo, this should indeed be the default.

...

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

Is 'all' better than the current 'default', or will we have both 'all' and 'default'?

I think we might need both. I see this scenario: most users download and install Drupal and only use it for one site. It should be easy for them to setup *just* one Drupal site, so we need a 'default'. However, there are still plenty of users that will want to add more sites along with Drupal. In this case, they are going to want many of their sites to share the same modules, so we do need a shared directory, or 'all' in that case.

How about the simpler:

sites/all/javascript sites/all/stylesheets sites/all/images

I like this much better and it fits in with above. That way the 'default' site can make use of these as needed and as a user extends their Drupal install with more sites, they don't have to worry about moving things around or sharing files. It's already done for them. Now however, this should not above be confused with modules. I still believe as others have pointed out, that all module specific CSS, JS, etc should be in that specific directory. It would be *much* too hard at this stage to extract, move, copy etc files into their respective positions. However, if a web based installer becomes a reality, we can still use the above scheme and have all module specific CSS and JS files go into sites/<host>/javascript etc for easy loading, if need be. It would make it easier in that case, but, on second thought, is that more beneficial then keeping them in their respective module folder? Probably not, but food for thought. ted

Op dinsdag 10 januari 2006 14:20, schreef Adrian Rossouw:

The OSX way is far far simpler, and much much cleaner.

But much unsafer (not speaking of OSX vs Unix safety). We discussed before, that PHP files should really live in a non-web-acessible place. The biggest downside of that, indeed, is that the web-accessible files can no longer live in the module directories. Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |

On Tue, 2006-01-10 at 14:49 +0100, Bèr Kessels wrote:

Op dinsdag 10 januari 2006 14:20, schreef Adrian Rossouw:

...

The OSX way is far far simpler, and much much cleaner.

But much unsafer (not speaking of OSX vs Unix safety). We discussed before, that PHP files should really live in a non-web-acessible place. -- I kind of have to disagree with this... php files containing sensitive data should not be in a web accessible directory(settings.php)... If you're worried about people uploading randscript.php or rewriting your .php files I think you have other things you need to address like permissions.

The biggest downside of that, indeed, is that the web-accessible files can no longer live in the module directories.

Bèr

On Tue, 2006-01-10 at 19:06 +0200, Adrian Rossouw wrote:

On 10 Jan 2006, at 6:41 PM, Darrel O'Pry wrote:

...

...

-- I kind of have to disagree with this... php files containing sensitive data should not be in a web accessible directory(settings.php)... modules/mymodule/modulename.module is NOT settings.php

Splitting each of the files that are distributed to you in a tarball into individual places is a _lot_ of work.

What about the people that use drupal's cvs to manage their sites?

I was disagreeing with Ber's Idea that all php file smust not be web accessible, and that only files that contain sensitive information should not be web accessible... and moving one file, settings.php, which I hope you aren't managing with drupal's cvs, should be a relatively simple thing todo/

-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

On Tuesday 10 January 2006 07:20 am, Adrian Rossouw wrote:

This is the difference between the OSX (.app directory) and Unix way of doing things.

The OSX way is far far simpler, and much much cleaner.

I hadn't thought of it that way, but it is analogous. Group By Resource Type vs Group By Resource Application. Both directions have a laundry list of advantages and disadvantages. The killer, though, is that managing a Group By Resource Type setup (Unix style) is a usability nightmare, UNLESS (a) You are an uber-expert who likes doing things the hard way or (b) You have a complete front-end to manage everything for you (package manager, vis. RPM, apt-get, and so forth). Drupal doesn't have that at the moment. Until/unless Drupal has a fully-managed module package manager (installer), Group By Resource Type is only going to make managing a Drupal install insanely harder. The security issues should be solved some other, less painful way. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson