Follow-up to #22336: Move all core Drupal files under a /core folder to improve usability and upgrades, for a customizable core folder location suggested by several people on that issue, for instance chx (comment #126):

"(...) another constant -- it would worth it! Put the constants in constants.php and include it always that saves you the work of defining of it N times. And then aspiring people can put their Drupal where they please. Like, outside of the document root. Put the php files being used in docroot (just index.php in production, most of the time) edit constants.php and have fun. The point, of course, is somewhat heightened security."

A possible way, new constants DRUPAL_CORE and DRUPAL_SITES, with default but potentially customizable locations, mentioned by kbahey (comment #79):

"Perhaps we need DRUPAL_ROOT to stay the same, then DRUPAL_CORE is really DRUPAL_ROOT . '/core' and DRUPAL_SITES is DRUPAL_ROOT . '/sites'. Those can be the first 2 lines in (and friends, such as install.php ...)"

Fixing #22336, which creates an integrated Drupal core folder, would be the first step before this follow-up issue to customize the core folder location inside/outside the web root.


quicksketch’s picture

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/').

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.

juan_g’s picture

A custom location outside the web root seems indeed more difficult than inside. However, a much easier and quick preliminary task would be just a couple of new constants (the already mentioned DRUPAL_CORE, DRUPAL_SITES) that would provide customization inside the web root, and also would pave the way for a future outside.

As one of the use cases, the possibility of renaming the core folder inside the web root, with a custom hard to guess name, can be interesting for some Drupal users as an additional security measure for hacking prevention, for example.

Perhaps at least three steps/issues would be needed here:

  1. Create an unified core folder and move the files; that's #22336: Move all core Drupal files under a /core folder to improve usability and upgrades, the current priority.
  2. Customize folder names/locations with new constants DRUPAL_CORE and DRUPAL_SITES; maybe on a new issue, or this one (#1116144) reduced in scope to inside the web root.
  3. Make possible core partially or completely outside the web root.

That's just a possible way to sort the different suggestions. Steps 1 and 2 are relatively simpler and would be D8 issues. Not sure if the discussion of the more complex step 3 can be D8 or D9.

On which issue should be the possible new constants considered (step 2), after fixing #22336 (step 1)? Other ideas?

juan_g’s picture

Title: Customizable location for Drupal core folder (inside/outside the webroot) » Customizable locations for Drupal core folders (constants DRUPAL_CORE, DRUPAL_SITES)

Following quicksketch's thoughts on the difficulty of moving core outside the webroot, probably we should keep things simple and feasible, step by step. Therefore, I'm reducing the scope of this specific new issue from "inside/outside the webroot" to just the consideration of new constants DRUPAL_CORE, DRUPAL_SITES (suggested on #22336 by deviantintegral, kbahey, wmostrey, etc.).

Naturally, the customization of these constants would initially work for core inside the webroot, like now. A posterior third issue could introduce the possibility of core at least partially outside the webroot.

About the constants, the main point in consideration here (#1116144) has been already suggested for example by kbahey (see the description of this issue) and by scor (comment #115 of issue #22336) with their default values:

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

As said, this can be a follow-up to fixing #22336 (creation of the unified core folder).

quicksketch’s picture

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.

juan_g’s picture

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.

Not necessarily. For example, see the head section of's page source. The CSS stylesheets and JavaScript files are aggregated in the folder, without references to core locations such as the modules folder. It looks like is using the performance options to optimize CSS and JavaScript. And, if there is a problem with images, copies can also be placed in a /files/ folder.

Of course the customization possibility for core location is not a critical feature, but something nice to have, and now it's a good opportunity for it. The note about security was just a possible example of use case among others, such as paving the way for future improvements. If this is postponed to D9 it's not the end of the world, naturally. However, if core contributors think the customization capability could be worth it, then probably the right moment would be just after fixing #22336, so that it's clear what to use -string or constant- to reference core in code during the D8 development.

quicksketch’s picture

The CSS stylesheets and JavaScript files are aggregated in the 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.

Josh The Geek’s picture

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

HonoredMule’s picture

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 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.

donquixote’s picture

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..

Alan D.’s picture

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!
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).

chanderbhushan’s picture

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

Alan D.’s picture

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.

RobLoach’s picture

RobLoach’s picture

lpalgarvio’s picture

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

sun’s picture

Issue summary: View changes
Status: Postponed » Closed (duplicate)

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.