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