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?

Current D7 List:

New proposed structure based on #37 and my own thoughts:

Edit: Sorry, I meant to click preview originally, I just changed some formatting and moved a few files.

WHy not also move install.php and update.php into core? If we can move cron, why not those?

Like this structure, but also like config better than sites, but I'm a bit on the fence on that one.

I'd recommend naming "readme" "docs" instead. And don't forgot the .htaccess!

subscribe

Building on #38, #39 & #40 I would propose the following

My thoughts are, while config is clearer than sites, it also encourages new users to think only configuration files go there not modules, themes, etc. I think that custom is clearer. I also believe that a single instance install is much more common than a multi-site install. If that is true I think Drupal should be optimized for that. Merging the sites/default and the sites/all folders to the root of custom I think accomplishes that, and leaving the sites folder there notifies people of that capability but doesn't require that they understand it just to get a single site install running.

That is my two cents worth.

I am in favor of leaving the *.txt files at the top level where they will be easy to find.

IMO we should consider this strongly as an early entry into D8 so that we can get it done and out of the way while there are still few patches against D8 (since it will invalidate, oh, every patch. And then some).

I don't believe the .php files can be safely moved out of the top level directory, because technically we do not rely on .htaccess. We only rely on that for clean urls.

I'm not sure I like 'custom' because it suggests that it's custom to a site. I don't know that it's worth changing it from sites/all, especially since we now actually include sites/all/modules

I was envisioning custom as in my custom files, modules, themes, etc.. However, I'm not set on that particular name.

I'm really opposed to sites/all and sites/default. I've used Drupal for quite a while now and the distinction between them only matters for multi-site. Thus the current stucture requires understanding the multi-site capabilities just to "properly" get a single instance site up. I feel that is a major usability problem. I have also witnessed firsthand the problems it creates for new users.

Actually it's documented on drupal.org somewhere (I'm sure it's moved since the page was written) to use sites/all for contrib modules and sites/default for custom-written modules. That makes a perfectly good distinction even for non-multi-site sites.

Of course, the D7 update system breaks that horribly by putting all modules in sites/default, even though drush puts its downloaded modules in sites/all. I think that's a critical core bug, but I was overruled. :-(

That doesn't even work for multi-site, since sites/default is for just one site. =(

#45: Yes, but would this usability problem exist if 1) 'modules' wasn't at the top level, and 2) 'sites/all/modules' already exist? Particularly if the INSTALL.txt instructions told you precisely where to put modules you downloaded? With a separated 'core' directory, it's easier to say "DO NOT MODIFY THIS STUFF" AKA "DON'T HACK CORE".

to throw more bikeshedding into the custom folder name debate, when we build sites, we use:

'contrib' for contributed modules and 'custom' for modules written specifically for a site.

and subscribe, and +1 to this great idea.

#48

1) Helps a lot.
2) Helps some.

However I really like the idea of the sites/all/ content being at the root of some custom/ (or your favorite name) folder. It seems to me that logicly the contents of those folders would be avaliable to all the deeper folders. It is using the folder structure to reinforce the actuallity of what is happening. For instance.

Currently.

My Proposal

This also makes getting a single-site up clearer. However, I can see your point that it will also discourage proper multi-site setup over time. (My use case of Drupal has multi-site installs causing far more problems than they solve, so I am a bit biased I suppose.)

Having said that any of these proposals are significantly better than what there is currently.

Let us not forget settings.php. That has to be per-site by nature. And there's also now sites.php. Multi-site is rather intrinsic to Drupal's architecture at this point, like it or not.

Throwing my two bits in, having default / multi-site-wide modules and themes under sites/all is a bit of a pain from a backup standpoint. It would be better if 'sites' was just that... sites... and modules and themes (the contrib and custom kind) were held elsewhere. I'd frankly prefer something like

What about a (slightly) different approach. Are we completely wedded to the sites folder, or could we have something like:

My thoughts behind this layout is that it becomes instantly obvious to a new user where to put their modules and themes. A slightly simpler option for single-site installs would be to drop the subfolders of modules and themes, and allow multi-site to add example.com/{modules|themes|files} folders for site-specific files.

Do we really need a default folder for modules and themes? Can someone let me know where you would use default in place of example.com, especially now with the ability of sites.php to provide a different domain and/or path for development.

As an aside, maybe the index.php should as minimal and free from change as possible. Maybe even to the point of simply being a list of include statements, so that when upgrading users do not have to think about copying the index.php file into the root. That way, the Drupal tarball could be extracted into the folder and renamed core and the upgrade performed.

For the normal case of single-site, having a consistently named directory is very helpful. Especially when you're spinning off a lot of non-multisite sites on a regular basis (like many dev shops do).

I'm really not wild about splitting settings files from site-specific modules. That only makes backup more of a challenge since your not-from-d.o files are now spread out to 2 or more locations. (Remember the files directory.)

Let us not over complicate this.

Let us keep it clean and simple:

The Drupal tarball should ship with two top level directories and just 2 files:

/sites
/core
index.php
.htaccess

The /sites directory should have the following empty directories
/sites/all/modules/contrib
/sites/all/modules/custom
/sites/all/themes
/sites/all/addons
/sites/default/default.settings.php (renamed in D7, I know)
/sites/README.txt

Anything you download should go in contrib
Anything you develop should go in custom

The README.txt explains that ...

/core should not be touched. It is the part that can be safely overridden during updates.

Don't hack core now means something tangible ...

I agree with #55 in general, though it's missing robots.txt, UPGRADE.txt, INSTALL.txt, CHANGELOG.txt, and hopefully #607028: Add README.txt to core.

What's sites/all/addons? The same as libraries?

We should add robots.txt to the files in the root directory (alongside index.php and .htaccess).

The rest can go into /core.

Yes, addons is the same as libraries (where things that are not drupal should go, like WYSIWYG editors, XML parsers, ...etc.). I am not hung up on the name addons. It can be anything else.

Side note, as previously mentioned on the dev list I am now working with the PHP Standards Working Group (such as it is) on naming conventions as they pertain to classes and namespaces. It's almost certain that such standards will influence file paths. I am trying to keep this thread in mind as I discuss the point. We'll see what happens. :-)

Just trying to keep folks in the loop.

I agree that the Drupal root folder needs cleaning, but going from bloat to the minimalist 2-folders 3-files (a la #55 + #57) seems also overly archaic for noobs as well as seasoned developers. Here's a disclaimer: I guess I'm kinda new-ish to Drupal, but ... anyone can dream, and think outside the box. I hope not to offend anyone with my galactic translucent bikeshed paint :) I'm coming at this from an end-user friendly p.o.v.

As developers and web architects (noob or veteran) using, testing, and building with Drupal, we all live with three components not simply two: core AND contributions AND our site(s). After installing a fresh Drupal instance, the first thing you have to do is add your favorite modules... so burying module code four folders deep inside the sites/all/modules directory (#55 suggests five folders deep!) just doesn't add up to a "sensible default". Neither does five folders deep (!?!) for my own cherished custom code (sites/all/modules/custom/my_module) I want to SEE my code, and know its there, and allow others on the team to readily see and know that i have custom plugins in any given Drupal install. While we are dreaming up ways to improve Drupal folder structures lets go ahead and improve sites/ as well!

In addition, as people move towards automating their update mechanisms (be it through RCS update commands, scripts like drush, or web-based Update modules) EVERYONE needs to deal with and distinguish between "core" updates and "contrib" updates. Lets make a local folder structure agree with the server repository logical division in order to foster usability and instantaneous grokability with what people will be checking out and keeping up to date. "As above, so below."

I hope my structure makes sense, its heavily doted with footnotes.

(*) Despite the idea of introducing an organization that mimics the 'core' and 'contrib' structure, I propose 'plugins' to reenforce the idea that contributions not necessarily limited to the official Drupal "contrib" repository; Take the 3rdparty folder special case as an example (details below). The advantage of having a plugins folder is that it leaves room for future growth, and welcomes healthy additions on down the road, for things that dont classify as modules or themes or profiles or translations. Introducing and really embracing the term "plugins", and noting that modules are really a subset of the plugin cosmos is something Drupal could use to reduce the initial 'nomeclature' barrier.

(**) The 3rdparty folder is THE special case inside the plugins folder that wouldn't necessarily contain elements that sync with drupal contrib repository. Also, the name '3rdparty' makes more sense than 'libraries' to non-programers, because it truly distinguishes this section for what it is: ANYTHING non-drupal that various modules might put to use, that may or may not be added to the Drupal repository (for Licensing reasons or other). Also, very often, the external code packages that go in there aren't technically "code libraries" in the strictest sense, as they are often full-blown applications and may be portrayed online as 'packages', 'components', 'libraries', frameworks, etc. If we stick with the generic term '3rdparty plugin' we can use it everywhere.

(***) Since this folder will potentially house drupal modules and sub-modules, leave it up to the user to determine folder structure inside the directory, and recurse the folder (if it exists). Update: after meditating on the structures here. This point to me is the one that sells the idea of a plugins directory. Essentially, plugins will be a better modules/ directory. One that has sensible defaults, but since its recursed, its internal structure could be customized to anyone's desired structure. For example, if you're going to distribute a drupal+specialsauce solution (eg OpenAtrium), you could isolate your special sauce into plugins/specialsauce/modules plugins/specialsauce/theme.

(****) The sites/default folder should go away if at all possible and be replaced with sites.php or other type of general config file. Disclaimer: I'm not up to speed on D7 changes in the works here.

(*****) A user may choose to customized 'index.php' to point to core outside the webroot. So as not to "overwrite" these changes upon a core update, this file 1) should not be in the repository 2) should never be included in any update scripts and 3) should be added by the packaging script. It's contents should contain a link to more information on how to move "drupal core" out of the webroot.

Subscribe.

subscribe :d

My take on the setup:

I also looked at Wordpress and Joomla to see how they handled their 'core/contrib' separation (from a file system perspective only). Wordpress keeps all plugins and themes in 'wp-content', which doesn't seem all that intuitive. Joomla pretty much throws everything into the root directory (i.e administrator, components, plugins, modules, logs, etc...). Joomla seems the most intuitive yet it fails to distinguish between multi-site setups (if Joomla can even do multi-site setups?).

Doesn't this raise the question that contributed modules/themes should have a different filesystem?
Something like..

For the D7 part; I'm still with #43. Why do we think this is a usability issue? Why don't we document it better? Show explanations of the directories in the installer or admin/help, include a readme, refer to the readme, etc. Someone who uploads his D7 folder using ftp isn't looking for .txt files in the directory, he just uploads everything and clicks 'Install'. .txt files are not (new-)userfriendly.
Look at http://drupal.org/node/43816 for example. It's the first google hit for "Multisite drupal", but as soon as I load that page, I get blasted with irrelevant information. I only see "4.x" and "5.7" in the first comment. Where can I find 6.x? 7.x? Why isn't the first link on the page working?
D.O needs a cleanup. Bigtime. Don't get me wrong, there are tons of useful information available here, but there is even more irrelavant data around it, which makes it hard to find.

The problem isn't in the filesystem, it's in the documentation (of the filesystem, in this matter).