[drupal-devel] Cleaner Directory structure

[K B]

> While on this theme it might be a good idea to consider the different
> deployment scenarios, their merits and how does that change the
> configuration. For example:
> 
> In shared hosting:
>    drupal/core
>    drupal/local
>    drupal/index.php
>    drupal/.htaccess

No, it is like this:

public_html/
public_html/.htaccess
public_html/index.php
public_html/drupal/
public_html/drupal/core
public_html/drupal/local

Then the admin can put:

public_html/files
public_html/somethingelse

As long as they are outside of the drupal directory.

This way, the index.php is in the public_html directory of the
account, and .htaccess affects how it works.

> Custom (non-distribution) unix install:
> (in /usr/local)
> 
> lib/drupal  -  equivalent to core above
> var/drupal  -  equivalent to local above
> 
> var/www/drupal/sites/example.com/files - this is configurable anyway
> 
> lib|var/drupal are not in the web-server's display paths, this
> potentially makes sharing the same web-server location with other
> apps easier

I think this is a bit overkill.

We do not do this now, and it works fine for both shared and dedicated hosting.

The admin of such a system can do all the tricks he wants separating
filesystems and such using symlinks.
 
> windows based installs:
> I'm clueless there
> 
> The changes to the current drupal are minimal, mainly in the multi-site
> file include code.
> 
> Apropos. Recently there was a lengthy discussion on the debian-security
> mailing list about the general security status and practises of php
> applications. There was, let's say, discomfort about exposed
> configurations, 'talking' files, etc... While drupal is relatively good
> in this respect, we should be able to enable better practises and offer
> advice on the site configuration choices. Not everyone is experienced.
> Some people are willing to learn.

This is why I mentioned the possibility of moving Drupal to the
directory ABOVE the public_html, so nothing can be read at the web
server level, and if the web server misbehaves, and does not process
.php files, no peeping Toms can see the configuration.

I have done this in the past on a crude CMS that was home grown. It
needed changes to the php include path to work correctly, which we
still can do in the .htaccess anyway, and guaranteed a certain level
of security.