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 Thoughts? I think we should make this change before 4.7 ships, it should be relatively simple to do, we just need to agree on the best way to do it. So let's have at it! ted (m3avrck)
+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. Everything else would be under a drupal directory: ./.htaccess ./index.php ./drupal ./drupal/modules/ ./drupal/themes/ ./drupal/includes/ ./drupal/misc/ ./drupal/sites/ ./drupal/sites/default/ ./drupal/sites/default/settings.php ./drupal/sites/default/modules/ ./drupal/sites/default/themes/ This way, when a new release is out, upgrading does not involve a lot of saving of files and copying back or merging. We also have an uncluttered directory under www (or public_html), with only one directory and 2 files in it). On 12/28/05, 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
Thoughts? I think we should make this change before 4.7 ships, it should be relatively simple to do, we just need to agree on the best way to do it. So let's have at it!
ted (m3avrck)
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.
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
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?
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?
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. Here is the tree. below tahat, I present a simplified version that could do for drupal.That is an exerpt from my work on drupalCOM. (I still have to figure out how to map it to cvs tracking, hence I did not work it out completely) . |-- README |-- Rakefile |-- app | |-- controllers | | |-- admin_controller.rb | | |-- application.rb | | `-- store_controller.rb | |-- create.sql | |-- helpers | | |-- admin_helper.rb | | |-- application_helper.rb | | `-- store_helper.rb | |-- models | | |-- cart.rb | | |-- line_item.rb | | `-- product.rb | `-- views | |-- admin | | |-- _form.rhtml | | |-- edit.rhtml | | |-- list.rhtml | | |-- new.rhtml | | `-- show.rhtml | |-- layouts | | |-- admin.rhtml | | `-- store.rhtml | `-- store | |-- display_cart.rhtml | `-- index.rhtml |-- components |-- config | |-- boot.rb | |-- database.yml | |-- environment.rb | |-- environments | | |-- development.rb | | |-- production.rb | | `-- test.rb | `-- routes.rb |-- db | `-- create.sql |-- doc | `-- README_FOR_APP |-- lib | `-- tasks |-- log | |-- development.log | |-- production.log | |-- server.log | `-- test.log |-- public | |-- 404.html | |-- 500.html | |-- dispatch.cgi | |-- dispatch.fcgi | |-- dispatch.rb | |-- favicon.ico | |-- images | | `-- rails.png | |-- index.html | |-- javascripts | | |-- controls.js | | |-- dragdrop.js | | |-- effects.js | | `-- prototype.js | |-- robots.txt | `-- stylesheets | |-- depot.css | `-- scaffold.css |-- script | |-- about | |-- breakpointer | |-- console | |-- destroy | |-- generate | |-- performance | | |-- benchmarker | | `-- profiler | |-- plugin | |-- process | | |-- reaper | | |-- spawner | | `-- spinner | |-- runner | `-- server |-- test | |-- fixtures | | |-- line_items.yml | | `-- products.yml | |-- functional | | |-- admin_controller_test.rb | | `-- store_controller_test.rb | |-- mocks | | |-- development | | `-- test | |-- test_helper.rb | `-- unit | |-- line_item_test.rb | `-- product_test.rb `-- vendor `-- plugins ******** 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 Hope it helps :) Bèr -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
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
On Wednesday 28 December 2005 12:15, Theodore Serbinski wrote:
Maybe this should go in for 4.7, maybe next release.
Next release. IMO, we're too late in the release cycle of 4.7 to make a major change in file layout. +1 on the idea of cleaning up the file layout, -1 on doing it for 4.7. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
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.).
Khalid B wrote:
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.).
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
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
Sounds about right to me. But sites needs a further fixup. If I don't have a multisite setup and just modify the default site then that gets overlayed when I do a download of a new release. I would suggest that all setups be multisite (even if only one) or that the current default settings.php be called sample.php and that the user configures it and names it settings.php so that it doesn't get overridden by a download.
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Larry Garfield Sent: Wednesday, December 28, 2005 3:19 PM To: development@drupal.org; chris@tinpixel.com Subject: Re: [development] let's cleanup /misc
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
Hi: Op woensdag 28 december 2005 20:46, schreef Larry Garfield:
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.
Lets not start debating on how feasible or not RoR is. :) Lets see what RoR can do for Drupal. Lets just look at it and learn from it. 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. Now about the route: DrupalCOM will be restructured to resemble (kindof) that structure i posted. I have to work out some more details (better SVN repos support for separate sites on a multihost for one) but I beleive we should use that drupalCOM as a sandbox. Once we are truly happy about it, and once we found that it actually works much better we can propose this back to Drupal itself. This change is a too big thing to do in an issue on drupal.org. Besides: CVS does not allow us to write patches for moving stuff around. DrupalCOM: It is still vapourware. I am now setting up the whole infrastructure, but am still not too sure about details as whether or not to keep all this on drupal.org (CVS is not particularly friendly for such a project) or to move it to a dedicated location (splintering the community is even worse IMO) Docs are all scattered around on my Drupal wiki on webschuur.com. I will be moving this into the abovementioned infrastructure. Ber
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.
On 29 Dec 2005, at 15:10, Khalid B wrote:
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.
I'm OK with making such changes as soon consensus is reached. Wouldn't changing stuff manually potentially break existing branches? -- Dries Buytaert :: http://www.buytaert.net/
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
Ber, I think your originally proposed structure based on RoR hit the nail on the head. It seems to me, that people are more concerned over the security of an install, keeping extra modules seperate from core ones, and making it easier to have multisite installs. Other than that, I don't think there is too much debate over exactly how this should be actually be implemented, provided it meets this criteria. Perhaps as a starting point, we should define what everyone wants the criteria of this new structure to meet? If we can agree on that, then moving folders around shouldn't be too hard, as that is more semantics then anything. 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 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 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? ;-) Please add/revise to this so we can reach a consensus on this soon enough. 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. :/
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. :/
Darrel O'Pry wrote:
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.
This is very smart, especially when talking about the files folder. The default /files is a next to worthless setting. It should, at the least, be sites/default/files. And when we change this, couldn't we find a way to ship the files folder already created? It's nice that now the server at least tries to create a folder with the right permissions, but sheeesh, this is still a pain in the neck.
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/
On 1/5/06 11:53 AM, Theodore Serbinski wrote:
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
And what then of contrib modules that use images / custom stylesheets / etc?
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 already possible (i think) via multisite - i.e. sites/example.com/modules can house site-specific 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? ;-)
again, you can certainly set sites/example.com/files (we do this for bryght sites)... the only caveat is that you can't force it from being overridden in core now ... but since drupal won't be able to create new folders if you're careful about file system permissions - you can probably get away with it... -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.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
On 1/5/06 12:41 PM, Karoly Negyesi wrote:
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
well, users of non-apache (say, IIS, e.g.) servers or those who aren't permitted .htaccess overrides by their hosting providers are a bit screwed relying on .htaccess ... -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
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.
On Thu, 05 Jan 2006 18:51:55 +0100, Khalid B <kb@2bits.com> wrote:
OK, here are my points:
which I answered already once but let's do it again!
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.
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.
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.
4. Each hostname directory, as well as all/ directory can have modules/ and themes/, files/ with site specific themes, modules, ...etc.
Apart from files/ this is already so. You are, however, free to configure Drupal to use per site files dir.
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?
Now, moving to that scheme is a pain
my head already hurts for answering this again , again and again.
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
On 5-Jan-06, at 10:05 AM, Jeff Eaton 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.
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.
This works with the notion of install profiles. e.g. profiles/ [profile-name]/modules etc. Some more examples... profiles/civicspace/modules profiles/civicspace_civicrm/modules profiles/drupaled/modules etc. etc. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
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.
Khalid B wrote:
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.
yup. xmlrpc.php and cron.php can become url aliases to more standard menu callbacks.
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.
To me, this is an excellent proposal. I read chx' disagreement but I still support this proposal. Just because you *can* do everything today doesn't mean we have achieved optimum state.
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
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 The biggest problem with this approach will be the install of contrib modules that add css files. IMHO drupal can be awkward for custom styling of modules. There is a chicken and egg problem of which css files should come first. Until this is solved there will be holes in the suggested approach. otherwise, in principle +1 for at least enabling such installs
This will not increase security. well not quite right there. It is a common sense security thing. There are plenty of misconfigured|not allowed to use .htaccess|add you favourite sites out there.
htaccess is an apache idiom.
If .htaccess can not protect you, why would this? Simply because you won't have access from the web server to those paths, so your config et al directories are safe. If they are safe, you don't need to rely on extra filtering.
And how would we ship the tarball...? Untar this half below documentroot and index.php to documentroot...? /me shakes head
The majority of installs are either untarred locally or the people have shell access. for both of the is valid untar copy to "system" area with this you will add copy to the "web" area now system and web are one and the same actually both world views can coexist and it is a copule of lines patch, unfortunately I can't find this in the forums (I posted something like that in the summer)
You need to convince me that the current is not good. I tell you, this is not easy. The current is good, it can be made better. What the defaults should be is another matter - probably highly flameable.
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.
On Thu, January 5, 2006 10:53 am, Theodore Serbinski said:
Ber,
I think your originally proposed structure based on RoR hit the nail on the head. It seems to me, that people are more concerned over the security of an install, keeping extra modules seperate from core ones, and making it easier to have multisite installs. Other than that, I don't think there is too much debate over exactly how this should be actually be implemented, provided it meets this criteria.
Perhaps as a starting point, we should define what everyone wants the criteria of this new structure to meet? If we can agree on that, then moving folders around shouldn't be too hard, as that is more semantics then anything.
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
+1
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
+1
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? ;-)
+1
Please add/revise to this so we can reach a consensus on this soon enough.
One thought I had, which may or may not suck, is to eliminate non-site-based additions but add an "all" site. To wit: /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? --Larry Garfield
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
Op vrijdag 06 januari 2006 12:34, schreef Bèr Kessels:
/sites/all contains the default settings.php and default stuff as well as the the
something odd happening here. /sites/all contains the default settings.php and default stuff as well as the default sitewide modules and themes. 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/
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.
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/
Got it? Do it!
Here is a renewed version: . |-- README |-- app | |-- modules | | |-- aggregator.modle | | |-- etc | | `-- watchdog.module | `-- theme-engines | `-- phptemplate |-- sites | |-- default | | |-- modules | | `-- themes | |-- site1.com | `-- site2.com |-- database | `-- create.mysql etc (also update.inc) |-- doc | `-- INSTALL etc |-- includes (content similar to now) |-- public | |-- index.php | |-- favicon.ico | |-- xmlrpc.php | |-- images | | `-- druplicon.png | |-- index.html | |-- javascripts | | |-- controls.js | | |-- dragdrop.js | | |-- effects.js | | `-- prototype.js | |-- robots.txt | |-- stylesheets | | |-- drupal.css | | `-- module1.css | `-- themes |-- script | |-- install.sh | |-- generate_module.sh | |-- environment_change.sh | `-- generate_theme.sh `-- vendor `-- htmlarea Some notes: themes, should be under public, they use images, CSS and more. How supported are symlinks? can we rely on them? if so, each contrib could be symlinked: /sites/default/modules/mymodule/stylesheets -> /public/stylesheets
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?
I don't think we should rely on them, since some people host on Windows (not to many). sepeck? What do you think?
Even so, Apache's FollowSymLinks is not a default enabled option. -- 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
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?
themes, should be under public, they use images, CSS and more.
If themes are public, modules should be public too. They too use images, CSS and more. -- Dries Buytaert :: http://www.buytaert.net/
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
* 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?
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?
* move the default files location under sites/<host>/files
I think everyone agrees with this one. If so, Ber can start working on this.
* 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'?
* 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.
I think everyone agrees with this one. It allows us to get there without destructive changes. In future, we can push this further. In the mean time, we get to play with different layout schemes.
* 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
How about the simpler: sites/all/javascript sites/all/stylesheets sites/all/images
* */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'. -- Dries Buytaert :: http://www.buytaert.net/
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.
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.
+1 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. This might necessitate an additional file, say "globals.php" in /all for variables that should be shared across all sites. A use case for this would be a user using a single database (with prefixing) could set the database in globals.php and delete the corresponding variable in his/her per site settings.php file. -M
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.
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.
Hmm. Let us say I have a multi-site configured. The /sites directory would look like All/ Original/ Foo/ Bar/ Now let's say someone requests a site called "bar". Which folder is used? In the current system, drupal searches through the folders to find the most specific one. If none are found, default is used. The name makes a lot of sense in this context. I think "original" makes less sense in this context. -M
Walt I have an issue with this: migration/backward compatibility. I have a few sites that already run off default, and I created the files directory under sites/default. So, images already have the path: <img src="sites/default/files/blah.jpg"> If we eliminate the default site, then suddenly, lots of URLs will be broken and changing them would be a lengthy chore. Think of default as the "default instance" of a site. On 1/6/06, Walt Daniels <wdlists@optonline.net> wrote:
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.
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
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.
Right on the head. The differentce between them should be default - a site actually, all - a prototype or in OO speak the parent class for all sites.
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
On 10 Jan 2006, at 6:48 AM, Theodore Serbinski wrote:
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.
It is much much simpler keeping all of a module's files in the same directory, as manually installing and uninstalling modules would become a multi- step process. that's wrong. all packages (themes , modules, libraries (includes)) files will live in their own directories in the install system. To try and do anything else adds an incredible amount of complexity. 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. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
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 |
We discussed before, that PHP files should really live in a non-web-acessible
And I still think that's a silly thing to say. -- Morbus Iff ( if i could change the future, i'd change the past instead ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
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 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? -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
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
I started using Drupal back around 4.2 or 4.3, when the installation procedures for many modules required that you splatter files all over the place. I am far happier now that almost modules are self-contained (i.e. they live in a single directory tree) -- even taking into account the security issues. I don't care if the module tree as a whole moves to a new location, but please, let's not return to the dark ages of "put file 'x' here and put file 'y' over there." -Eric On 10 Jan 2006, at 05:49, 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. 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 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
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.
110% agree with this statement The only really security sensitive file(s) in drupal is settings.php That can be out outside of the web server tree, but I think at this point in time this should be optional. Some of the ways to enhance the flexibility of the fs earlier can be employed, without sacrificing complexity. This option should be considered for use by "clued up" users. Which automatically gives rise to the question - if they are clued up, do they need it anyway - it prevents leaks from misconfigured serever confings.
If we create an image directory then I would strongly suggest creating a /images/icons sub directory where Drupal icons can be placed. Further, I would suggest adopting the Linux convention for icon folder names and structure. This would allow people to easily swap icon sets for their site. /images/icons/<style>/24x24 On 12/28/05, 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
Thoughts? I think we should make this change before 4.7 ships, it should be relatively simple to do, we just need to agree on the best way to do it. So let's have at it!
ted (m3avrck)
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
No! Too major of a change. Wait for 4.8. Can we please please please get 4.7 out the door? -- 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
participants (23)
-
Adrian Rossouw -
Boris Mann -
Bèr Kessels -
Chris Johnson -
Darrel O'Pry -
David Reed -
Dries Buytaert -
Dries Buytaert -
Eric Scouten -
James Walker -
Jeff Eaton -
Karoly Negyesi -
Khalid B -
Larry Garfield -
Mark Fredrickson -
Morbus Iff -
Moshe Weitzman -
naudefj -
Robert Douglass -
Syscrusher -
Theodore Serbinski -
vlado -
Walt Daniels