[development] let's cleanup /misc

[Morbus Iff]

> 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