[development] let's cleanup /misc
morbus at disobey.com
Thu Jan 5 21:45:35 UTC 2006
> 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 , or live with a "public" word in my URL .
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. 
 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.
 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
More information about the development