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?

See also : #22336: Core Drupal in its own directory, configuration, modules and themes in custom

Hi,

I am really happy to find this thread for D7.

It seems not needed to have drupal outside the webroot. But i think it can be very handy.
Then a SERVER-side install of Drupal will become possible!! This would be a major feature, and is not so difficult to make.

To get this done for our install I had to hack Drupal 6 very much. Sorry :(
I wrote an article to explain what we did. I will be happy to write more info, if that is needed to get D7 to adopt this . ;-)

If Drupal 7 would support variables to all the important paths anyone can decide for himself how he wants to handle its installation. And Drupal 7 can boost that it can be installed SERVER-SIDE.

What is needed:

• configuration to set the paths (also to /modules, /themes, /includes etc.)
• configuration to set symlink-paths
• a class/script/functions to
  • search the global and client paths and decide what to send back
  • it should also test if the path exists, handling files and dirs
  • give back root-paths and url-paths
  • give back a relative path to store in the database
  • keep a list of paths, so each path is searched for only once
• change drupal scripts to request paths by this class (ohoh.....)
• no hardcoded paths ever; even the class gets its info only from the init-settings

Greetz, Joly

Ohoh, I cant get used to this kind of forum ;)
I keep editing settings and tags, thinking it is only for my comment.
I do hope I learned it from now on.

By just symlinking ../sites/[client site name] to another location on the server, you get separation of server/client files. Then provide the client with access to that area only.
e.g.
$ cp -R /var/www/drupal/sites/* /var/www/public_html && rm -rf /var/www/drupal/sites
$ ln -s /var/www/public_html/ /var/www/drupal/sites
$ chown -R client1:client1 /var/www/public_html/client1-site.com/
or something like that. This could be done across NFS mounts, if you have multiple servers.

It's what I do, though I am a small shop with under a dozen clients.

The individual site directories can contain themes, modules, and files - pretty much the only things that you cannot separate out are theme engines and core modules; if you need to separate these out for some reason, then you'll just have to give each client their own copy of core. Which is really not a big problem if you are using revision control (svn/cvs/bzr etc.)to keep every install updated.
For site-specific apache configuration, use per-site directives in htaccess or apache config file. Sure, you'll actually have to do the work of changing the config files, but if you are a service provider your worth is determined by your toolchain, and so you probably would write a script to change the apache config (as well as create and populate the new site directory) for each new site.

I just find it very curious that you hacked core so much (Ive read your article), and wonder exactly what circumstance would require you to do so given that drupal + linux provides much of this functionality by default. Call me curious ;)

EDIT: also be sure to check out Aegir, a hosting platform for Drupal. http://groups.drupal.org/aegir-hosting-system

Note: this would make life easier for #606592: Allow upgrading core with the update manager

This is a long standing issue I've had with Drupal since I started back at D6.1 -- and continue to wrestle with on a daily basis. All of the core files are "up front" and all of the "you should edit these files" are hidden under that strange name "sites."

For the usability experts, tell me which folder you are likely to drop your very first module into...

• modules
• sites/all/ —> mkdir modules —> sites/all/modules/
• scripts

Exactly. This is a huge Drupal-WTF. The best proposal so far from the comments above is this:

What if we did something more along the "Drupal as a framework" lines...

At least then we are not asking a new user to understand the difference between 'modules' and 'sites.' In fact, "Config" is 1000% more understandable without documentation than "sites." I also recommend that we move all non-essential *.txt files to drupal_framework/ as well.

Ideally, this folder structure should be very lean and very controlled. Sadly, I don't think drieschick would consider this kind of change so late in D7. But that's ok because I wouldn't even know how to roll a patch with this ;P

Please, can we have others weigh in on this issue? Tagging for exposure.

drieschick == dries + webchick ?

I'm not sure I like the idea of hardcoding the name "drupal" into the folder structure. It makes things more confusing for those repacking Drupal.

/core and /sites seem really good to me. However, I think all of the *txt files, and special files like authorize and update.php would need to remain in the root, unless we require mod_rewrite?