This patch allows for additional 'system' directories to be searched for modules/themes/engines etc.

You do this by adding the following into settings.php

  $system_dirs = array( 'contributions');

This would allow you to have all of contrib checked out alongside drupal core.

We use this extensively in Bryght's hosting platform, to allow us to add sets of modules to
sites, without having to manage thousands of symlinks for each of the individual module->site links.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

adrian’s picture

Set to patch.

adrian’s picture

eh. damnit. there was an error in that patch (system_dirs needs to be global in the bootstrap function).

I'll roll another one later.

adrian’s picture

FileSize
2.73 KB

Here's a fixed patch.

basicmagic.net’s picture

hi adrian and thanks-

i am having a little trouble understanding this part of what you wrote:

> to allow us to add sets of modules to
> sites, without having to manage thousands of symlinks for each of the
> individual module->site links.

i am running drupal 4.6.1 with multisites. how / why would this new aspect be important for me?

i especially don't understand what you're talking about as far as managing symlinks for the individual module->site links.

i am using symlinks at the root of my individual domains httpdocs directories- meaning that in the case of domain xyz.com-

the httpdocs dir for xyz.com is a symlink to drupal4.6.1install/sites/www.xyz.com.

everythign works great- and of course individual modules, themes, etc. in the sites dir for each domain overrides anything in the drupal4.6.1install core dirs.

could you please advise as to how and why your mod could be used in a multisite environment?

it seems exciting- i would just like to understand its potential application and benefits and use a little better...

vincent

adrian’s picture

It's most useful for mass hosting installs. Where you have hundreds of sites installed on a server.

Simple enough example. Say you have 2 types of sites. 'Simple' and 'Everything' installs.

With this code you could have a 'simple' and an 'everything' directory, containing all the modules
and themes for that specific install profile.

And instead of having to manually link the modules/ theme directories for each of the individual
modules you want to associate with each of the sites, you can just set it up in their config file.

It allows you to more easily manage the visibility of modules that sites have. Modules and
or themes that are specifically installed / linked in the sites/mysite.com directory, will still
override modules found in the additional directories.

At Bryght we set up layers for all sites of the same type (install profile), all sites
sold by a person (ie: a reseller, who might want to install themes that all his clients
can use) and then an additional set of modules for interacting with the hosting system
if you are a bryght reseller.

After all that, if there is a module installed specially for the site (ie in sites/mydomain.com/module/modulename)
it will still take precedence.

Bèr Kessels’s picture

Allthough I really need something like this too, I have my doubts with the overall use of this for Drupal.

Here is what I do:
I have a settings.php, patched in /home/username/settings.php (/home/username is symlinked as drupalroot/sites/sitename) that one includes the settings.php in drupalroot/sites/default/

This is not very safe. for anyone could remove the include line from his private settings,php.

So what about this: drupalroot/sites/default/settings.php is *always* called, drupalroot/sites/

That way we do not add clutter for all the normal drupal users, only to server the very few providers. After all we are not a bryght/webschuur codebase maintaining community, but a community of CMS developers.

adrian’s picture

Clutter ? This is a few lines in system_listing.

It has nothing to do with settings.php other than adding another global variable that can be set there.

If someone has deep enough access to the system to modify global variables in drupal (oh, like say $user->uid) , you have far more to worry about than them seeing extra modules.

Did you mean to perhaps comment on http://drupal.org/node/25745 ?

moshe weitzman’s picture

this looks sane to me.

i haven't tested it yet.

drumm’s picture

Category: task » feature
coreb’s picture

Version: x.y.z » 6.x-dev

(Moving x.y.z version to a real version number) Feature Request => 6.x-dev

catch’s picture

Version: 6.x-dev » 7.x-dev
Status: Needs review » Needs work

bumping and no longer applies.

redndahead’s picture

Assigned: vertice@www.drop.org » Unassigned
Status: Needs work » Needs review
FileSize
3.88 KB

Here is a version for 7.x pretty much the same code just in different places. Also added an entry in default.settings.php. I tested it out on my local box and it seems to work just fine.

redndahead’s picture

Title: Additional configurability of system paths in settings.php file. » Add additional system directories to search within settings.php

Changing title to be a little clearer.

redndahead’s picture

To give another use case. I have a multisite configuration. I don't give users ftp access to their installation. I would like them to be able to add themes to their installation though. There is currently not an easy way for me to give them access to sites/[sitename]/themes. But through imce I can give them access to a directory within files. So in my settings.php I can add

// Get the settings.php directory location starting at root.
$location = str_replace(getcwd(),'', dirname(__file__));

// Switch slashes for windows.
$location = str_replace('\\', '/', $location);

// Remove the leading slash.
$location = ltrim($location, '/');

// Add the file location inside the files directory where I would like to give people access.
$system_dirs = array($location . '/files/contrib');

Now I can give my admin users access to contrib/themes where they can upload their own themes.

cburschka’s picture

Status: Needs review » Needs work

The inline comment is broken. It tells people to use $system_dirs('contrib', 'sites/default/files/contrib);, which is a function call rather than an assignment.

It would also be a good idea to remove the first "contrib" from that example, which would be right in Drupal's root directory. We're trying to discourage users from putting any stuff outside the sites/ folder, keeping the code base clean for upgrades.

sun.core’s picture

Version: 7.x-dev » 8.x-dev
adrian’s picture

The majority of what is needed for this is contained in #911354: Tests in profiles/[name]/modules cannot be run and cannot use a different profile for running tests , which adds a drupal_add_system_directory function. If that gets in, all that would need to get done for this is to add the dirs on include of the settings.php

sun’s picture

Issue summary: View changes
Status: Needs work » Closed (cannot reproduce)

I'm not sure in which version we introduced support for installation profiles to ship with an own set of modules, but the use-cases that were explained here all appear to be solvable through that mechanism; e.g.:

Say you have 2 types of sites. 'Simple' and 'Everything' installs.

With this code you could have a 'simple' and an 'everything' directory, containing all the modules
and themes for that specific install profile.

And instead of having to manually link the modules/ theme directories for each of the individual
modules you want to associate with each of the sites, you can just set it up in their config file.

That translates into:

/profiles/simple/modules/...
/profiles/everything/modules/...

Whereas every site still has additionally:

/sites/all/modules [legacy]
/modules
/sites/example.com/modules

Therefore, even though they are simple, the proposed changes do not really make sense to me, since the use-case can be solved already?

Please re-open this issue in case I'm missing something. (In that case, it would be very helpful to update/rewrite the issue summary though ;))