[drupal-devel] Cleaner Directory structure

K B kbahey at gmail.com
Wed May 11 19:53:57 UTC 2005

On 5/10/05, Jeremy Epstein <jazepstein at gmail.com> wrote:
> On 5/10/05, Karoly Negyesi <karoly at negyesi.net> wrote:
> > If you are doing this, then lose drupal from path, like this:
> >
> > public_html/.htaccess.example
> > public_html/index.php
> > public_html/core
> > public_html/local
> Now that you do it like that, I agree that having 'drupal/' is just
> one more unnecessary path depth. The way you did it above looks good
> to me.
> I'm a bit concerned about renaming 'core' to 'drupal' - might be
> confusing (or even technically problematic) since 'drupal' is also the
> name of the core CVS repository? We would end up with the path
> '/cvs/drupal/drupal/[subdirs]'. The ViewCVS address is already
> http://cvs.drupal.org/viewcvs/drupal/drupal/. Do you want to add a
> third 'drupal' to this path? I sure don't.

All this does not need to go in CVS as it is. The CVS can largely
remain as it is. What the developers see when committing code and what
the end user (site admin) sees are two different things.

The script that creates the tarball can deal with all this and
everything else remains the same.
> Also, if and when this new directory structure gets committed, we need
> to encourage module developers to create new folders only within the
> 'local' directory tree. E.g. the 'files' directory, which is used by
> upload.module (and others?), should NOT be in /core/files, but instead
> in /local/files, or possibly in /local/sites/site1.com/files.

Again, in the respository, things will remain the same.

Part of documenting this new change would be to instruct site admins
configuration goes to local/sites. ANY DEVIATION FROM THIS WILL CAUSE
UPGRADE PROBLEMS which is what we are trying to avoid.

If Vlado's idea gets implemented, we also document that distros can
change where things are, such as putting things in /usr/lib and
/var/lib if they need to.

The files directory can be under local, or one level above. It can be
anywhere the user likes it to be, provided that they do not put it
under drupal, since this can be erased on an upgrade.

More information about the drupal-devel mailing list