Customizable locations for Drupal core folders (constants DRUPAL_CORE, DRUPAL_SITES)

And then aspiring people can put their Drupal where they please. Like, outside of the document root.

I don't want to kill this issue before it starts, but moving the future "core" folder outside of the document root has at least a couple of very difficult issues:

- Lots of modules include code other than PHP. For example CSS, JS, images, and other files need to be web-accessible.
- Lots of code throughout Drupal core assumes that it is relative to the Drupal root folder. Such as variables and settings like this: variable_get('cache_inc', 'includes/cache.inc').

In #22336: Move all core Drupal files under a /core folder to improve usability and upgrades, I think the suggestion to move Drupal core outside of the Drupal root was mostly an off-the-wall suggestion. I'm not sure it's actually feasible to implement. Even if it is feasible to implement, is such a change necessary or even truly beneficial? The argument is that this would provide heightened security, mostly by hiding information from the public viewing. If an administrator is savvy enough to move the Drupal core directory outside of the web root, couldn't they use .htaccess for the same purposes? Additionally, moving the core directory does nothing for contributed modules which would also need to be outside the web root to get the same level of new security. Then, if both core and contrib modules are outside of the web root, what you're really talking about is nothing but an index.php file being web-accessible. An interesting proposal but once again probably not technically feasible.

To further deflate enthusiasm, I'll again re-iterate it is almost impossible to hide where Drupal stores its files. Even if you were to choose a random directory name instead of "core", this directory name would be littered all over the CSS of core modules. Additionally, how would contrib modules make use of readily available images like "/core/misc/throbber.gif" when it's placed in random directories? CSS is not programmatic and can't use a PHP constant.

All this goes more towards the end of asking what value we get out of new constants? I honestly don't see any benefit at all, beyond preventing typos of the string "core". Even then, any straw-poll you conduct I'm sure you'd find 9 of 10 developers prefer typing literal strings instead of constants.

The CSS stylesheets and JavaScript files are aggregated in the drupal.org/files/ folder, without references to core locations such as the modules folder.

Yes that's true but all of the CSS inside of the aggregated CSS files all references the absolute paths to the images. Would you really want to copy all of the files from your CSS directory to files? How would that work when an image needed to be changed?

Ah well, I may be fighting a non-existent battle here. I just don't see any benefit to adding new constants. We shouldn't make this change unless it has demonstrable benefits, but I'm fairly sure that any realistic patch will make it obvious that this will increase code complexity and then we can argue if it's worth it at that point.

How could you customize the constants without hacking core? -1

I'd like to offer a system administrator's perspective:

A private web host for active development and/or production web apps uses virtual hosting with per-site/project directories containing all site/project-specific content (apache.conf, logs, private files, and docroot directory). Libraries are non-site specific and go in libs/Libname/version/ with "live" and "dev" symlinks to specific versions according to their development status. Specific projects can target specific versions or "latest" versions as appropriate.

Declaring docroot directories inside some subdirector of "libs" is acceptable, because organization and code/files/backup management is the primary concern, not security (which is important, but realistically not really affected by this choice). But having site-specific content or configuration inside "libs" is not ok.

This kind of organization works really well with active development and production use from a single shared filesystem. For most libraries, this separation of concerns comes very naturally. Drupal is the exception, because I have to, at the very least, manually symlink mysite.com into drupal_root/sites from its site-specific location. "Manually" is a minor issue, but the location of the symlink(s) themselves are a major issue--they violate separation of concerns. The symlinks are per recognized project (potentially multiple hostnames/sitenames for that host/vhost), but they have to be maintained outside the site directory, for every new version of Drupal, across host moves/aliases, rebuilt after restoration from backups, etc.

I'm currently using per-site Drupal installations, and I don't like all the extra "crud" in my development space, so I'm investigating multisite setup, with the caveat that it must satisfy my organizational constraints (since that's the whole point). Being unable to extricate Drupal from the static content that must be hosted is unfortunate--though perhaps could be avoided if no static content exists in the core modules and a non-core theme is used--but acceptable. But this symlink-requirement issue is serious enough that I'm considering maintaining a Drupal patch that will auto-generate missing symlinks and clean out invalid/outdated ones (other unsupplied links pointing to the same path) based on data passed from apache.conf as php globals.

Oh, and as an aside, I do consider using a "core" directory to hold most of Drupal's core content (i.e. includes, core modules, etc.) an organizational win even if there's no constant involved. Back when I first started programming for Drupal, I found the usage of module/theme directories buried under sites when they also existed at the top level surprising and counterintuitive...especially where multi-site organization or any designs on maintaining Drupal separate from the site itself are such an afterthought.

I don't see much of a benefit in the suggested change.

I would see a benefit, if we manage to move all php code out of web root.
Currently, php files (.php, .inc, .module, etc) in core and contrib are only protected by .htaccess. Which does not work for some servers e.g. lighttpd.

Full-stack symfony has everything out of web root by default (last time I checked). We should have this optionally also for Drupal.

#1672986: Option to have all php files outside of web root..

Sorta off topic but related, creating symbolic links for core break as authorize, install.php and upgrade.php all fail when trying to determine DRUPAL_ROOT

// This will always follow the real path!
chdir('..');
define('DRUPAL_ROOT', getcwd());

Which makes it impossible to have a single copy of the core files that is referenced from multiple projects (well one copy of core per release).

+define('DRUPAL_CORE', DRUPAL_ROOT . '/core');
+define('DRUPAL_SITES', DRUPAL_ROOT . '/sites');

@chanderbhushan
This assumes that you have already run the install scripts.

You can not install Drupal via a symbolic link for core that is pointing to another folder! Well "core" to "_core" works, but "core" to "../../core" breaks. There are 6 hard coded references to define('DRUPAL_ROOT') within core and 4 more in the scripts directory.

Follow up for this related but different issue: #1801728: Single HTTP point of entry for core (symbolic link for the core folder fails). I'm not sure if the core team will care though.

These are related:

• #1672986: Option to have all php files outside of web root.
• #1540136: Simplify index.php by moving DRUPAL_ROOT to bootstrap.inc

#1540136: Simplify index.php by moving DRUPAL_ROOT to bootstrap.inc will help.

i like the constants =)

define('DRUPAL_CORE', DRUPAL_ROOT . '/core');
define('DRUPAL_SITES', DRUPAL_ROOT . '/sites');

i see many advantages on using these along with DRUPAL_ROOT

All of the consequences outlined by @quicksketch would need to be addressed.

I'm closing this issue as a duplicate of #1672986: Option to have all php files outside of web root., because that issue essentially asks for the same, but properly questions and accounts for the problematic challenges right from the start.