Core Drupal in its own directory, configuration, modules and themes in custom

I would prefer:

public_html (root directory)
public_html/index.php
public_html/.htaccess

public_html/drupal
public_html/drupal/core

public_html/drupal/config
public_html/drupal/user

config containing sites and any other config files
user containing all user additions including modules, themes etc.

using 'local' is not very intuitive IMO, and I think config should be separate.

I am however unsure how this would pan out for multi-site configurations, as a big plus point is having modules unique to certain "sub-sites" etc.

Regards,
-K

Adrian's installer will take care of upgrade issues and avoid the inconvenience that presently exists.

This is scheduled for 4.7.

Whether we still need a reorg of directory for aesthetics is yet to be determined.

Some of Drupal's top level directories, like "scripts", are clashing with directories already on my site. Hope this will be implemented soon!!!

The solution for me to install everything of drupal in another directory and make it 'feels' like it is in the main page is this:

Works like a charm... And you don't have to worry about your other directories...

naudefj: It is generally safe to delete the scripts directory of Drupal. It is needed for some development work, but not for running a site.

I tried this method, but when the index appear, css didn't load and the node links don't work.

Update, the above method work. But you need to enter your base url in your settings.php

But in our nodes url, the /drupal/ directory still appears.

Any way to remove that without causing any problem?

I've been looking everywhere for this functionality. The above code works very nicely for redirecting from the root directory to the frontpage under the /drupal directory, but it still leaves the URLs looking like and accessible only at http://www.example.com/drupal/links, for example. I would really prefer if it could be accessed directly from the root directory (I.E., http://www.example.com/links).

Oops, fixed version field back to cvs.

Another method that work via htaccess.

http://drupal.org/node/135206

But we still need to know how to remove the /drupal/ portion from the urls.

I solved this problem by using a RewriteRule in the .htaccess file.

I also found that the key to removing "/drupal/" from the URL is in setting $base_url appropriately.

See my comments here and here for how I did it.

Marco

I have a somewhat unique situation that seems to be a bit direct but, I would like someones input on this. I currently have Drupal 6.1 (w/no additionally installed modules or themes - only written nodes and some edited CSS files for themes) installed and running in a sub-domain, ie: http://test.mydomian.com, whereas test, being the sub-domain. I am looking to install/upgrade Drupal 6.2, but eventually I will have it located in my main domain, ie: http://www.mydomain.com, whereas mydomain, being the main domain.

I have an option, I believe, that would allow me to just "install" a fresh copy of 6.2 in my main domain and move effected files and such to the new installation from my sub-domain version. I thought this would be less extensive than updating 6.1 first, then moving it into my main domain later. Would this be the most appropriate choice? (I am ready to have it go public in my main domain at this point!)

Also, I have a concern with the existing database information. Will the new installation over-right any db entries? Will the current users still be there? etc. (I have backed up my db and such already) I hope this is not off topic but, the thread that contained all these concerns directed me to this node for any new posts.

Thanks folks....I'm really impressed with this Drupal website maintenance environment!

Roger

Please don't hijack issues.

Never mind....again!

I guess this issue is outdated anyway. Drupal cleanly separate core files from custom ones (that lie in /sites). So marking that as won't fix.

This is not an outdated issue. Drupal 6 still expects everything to be installed in the root. This request is to allow everything to be installed in a /drupal subdirectory instead and potentially move /drupal/sites outside the core installation (e.g. /drupal_sites) -- all WITHOUT including "drupal" in the URL.

While this can be done currently, it is less than straight-forward and requires hacking the .htaccess rewrite rules and settings.php. It would be ideal if Drupal would support this configuration natively instead of hacks that work to obscure its relocation.

No, Drupal does not requires you to have a "drupal" subdirectory or to include "drupal" in the URL. You can put everything in the root directory of your website (do you see any "/drupal", here on drupal.org?). The separation between Drupal Core and custom code is *very* clean (every thing custom is put under /sites), so there is no point in that issue anymore. If you really want to physically separate the two, you could use a link at the operating system level (symbolic link or anything else).

I'm closing that issue again (won't fix, because you can't fix what ain't broken). I see no point in hacking rewrite rules to do something that is done by default.

Please explain your needs more clearly if you want to reopen that issue.

The original post explains the issue very well.

I believe you are misunderstanding that the primary issue is to ALLOW Drupal to be installed transparently in a subdirectory. Currently, Drupal expects everything to be installed in the document root, causing problems described by the original poster.

This issue was discussed at length in the developers forum (link in the original post), with a general consensus that this is a good idea that should be implemented.

Please don't disregard this issue as being pointless without reading that thread.

then we'll mark it by design.

Does it make sense to mark a feature request as "by design"?

About the original feature request, just linking the /sites/[your site] to another directory would allow complete separation of Drupal Core and custom files.

Damien

This is not about separating core from contrib. That part has been addressed in D5 and D6 by using sites/all/themes, sites/all/modules, and having a default.settings.php shipped by default.

This is about two things:

1. Moving certain parts to above public_html

It is about taking stuff that does not need to be under document root and move it outside of that directory. This includes stuff like all code that is executed, and configuration stuff (settings.php).

Only index.php, update.php, install.php, and other files of type .js, .css, .ico, and media files need to be under Document Root. The theme tpl.php does not even need to be under document root, or perhaps we make an except for those, and have the themes under document root, since it is the presentation layer.

Everything else will do:

Or we even do a chdir http://ca3.php.net/chdir before anything else, and we are still good.

This way, all that stuff is protected from any flaws in configuring the web server.

This is a common way to setup other applications.

The objection that has been voiced is that on some shared hosts, this would not work. I have not seen this in shared hosts that I used, since you get /home/username/public_html. So Drupal can be in /home/username/drupal, and the rest of it under public_html.

2. Better organization

Moving everything under drupal in one directory, so document root is not cluttered.

The site.php file, or some other mapping file, will tell index.php where to find the rest of the stuff. Crell already has a working patch for something similar for the "sites" directory, so we don't have to have all the files under the domain name.

This way, we don't have clutter, and in each place (home directory, and document root), we have ONE directory with everything under it.

If there are reasons not to do that, then let us hear them.

First off, new features go in 7.x.

I'm against putting parts of drupal outside of the document root, mainly because in a lot of situations where access to the directory below public_html is not straightforward. My reasons are as follows:

1) It adds clutter: Having 2 locations depending on each other, but keeping them at separate locations is counter intuitive and is prone to errors when moving installations around.
2) There are cases such behavior will cause annoyance and perhaps even breaking. All of my websites are on servers which use virtualdocumentroot where folders in /home/username are sub domains of the main domain, and don't have access below that directory.
e.g.
/home/domain.com/www = www.domain.com
/home/domain.com/blog = blog.domain.com

If drupal would need /home/domain.com/drupal/ for includes and stuff and /home/domain.com/www/drupal/ for the rest of the files, that would prohibit me from using drupal.domain.com as a functional subdomain.
3) There are a lot of situations (including the above) where you don't have a directory directly below the document root that is accessible to the users. For example if you have a server on which you have your document root (user-writable) in /var/www, you would need to give users write-access to /var to make up for the missing public_html structure.
4) On some servers Apache (and PHP) is prohibited to look outside their document root for files to run.

Thus, if this feature gets into core it will break a lot of websites on shared and access-limited servers, and will seriously hinder platform independence of Drupal.

I'm urging to mark this won't fix.

maartenvg, I don't think we'd ever require that the Drupal core files live outside of the webroot, just allow it. Ideally, part of this re-org would be adding a variable with the path to the drupal directory, so that it could be moved out of the webroot.

My take on this thread is that it would be great to consolidate all Drupal core files in a "drupal" subdirectory, which I whole-heartedly support. My ideal layout would be something like this:

This would enforce a clear separation between core/system files (drupal) and user files (sites). Everything that currently lives in the webroot would be moved into the "drupal" directory (except those listed above). This would also have the side effect of discouraging users from editing/hacking files in core (or dropping contrib modules into the top-level "modules" dir, etc). And it would make upgrading (conceptually) easier, just replace the "drupal" directory.

Finally, Drupal is currently quite rude in that it assumes it's the only script living in the webroot -- making it difficult to integrate with other systems that might be in use. This re-org would make this task a little bit easier (in that there would be less potential conflicts).

discouraging users from editing/hacking files in core (or dropping contrib modules into the top-level "modules" dir, etc).
Yup, putting new modules into the top-level "modules" dir was the first thing I did as a newbie.

So a big +1 to this because of this and of all the reasons stated in this issue.

I like your (and the original) take on it; it seems the next step in separating core from contribution. I will review & support any nice patch that floats by.

On a side note: Making it possible for D to live outside the document root is okay, but definitely shouldn't be the default behavior. Perhaps leave it almost undocumented because otherwise it will introduce a wagon load of cleanurl- and multisite-like questions which limit the user experience and increase the support load.

I've marked #311783: Directory called "modules" is not for modules as a duplicate. The focus there was just on the modules directory, but I think this would be the better option.

Agree with #25, and also keep install.php, update.php, cron.php and xmlrpc.php in the root directory for backward compatibility. My initial suggestion would have been to move /modules and /themes into /core/modules and /core/themes, but this one is more comprehensive and makes more sense.

Renaming files and folders is difficult in CVS, how do you propose we roll a patch for this issue?