Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#12 | systemdirs-25720-1.patch | 3.88 KB | redndahead |
#3 | systemdirs_0.patch | 2.73 KB | adrian |
systemdirs.patch | 2.16 KB | adrian | |
Comments
Comment #1
adrian CreditAttribution: adrian commentedSet to patch.
Comment #2
adrian CreditAttribution: adrian commentedeh. damnit. there was an error in that patch (system_dirs needs to be global in the bootstrap function).
I'll roll another one later.
Comment #3
adrian CreditAttribution: adrian commentedHere's a fixed patch.
Comment #4
basicmagic.net CreditAttribution: basicmagic.net commentedhi 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
Comment #5
adrian CreditAttribution: adrian commentedIt'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.
Comment #6
Bèr Kessels CreditAttribution: Bèr Kessels commentedAllthough 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.
Comment #7
adrian CreditAttribution: adrian commentedClutter ? 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 ?
Comment #8
moshe weitzman CreditAttribution: moshe weitzman commentedthis looks sane to me.
i haven't tested it yet.
Comment #9
drummComment #10
coreb CreditAttribution: coreb commented(Moving x.y.z version to a real version number) Feature Request => 6.x-dev
Comment #11
catchbumping and no longer applies.
Comment #12
redndahead CreditAttribution: redndahead commentedHere 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.
Comment #13
redndahead CreditAttribution: redndahead commentedChanging title to be a little clearer.
Comment #14
redndahead CreditAttribution: redndahead commentedTo 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
Now I can give my admin users access to contrib/themes where they can upload their own themes.
Comment #15
cburschkaThe 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.
Comment #16
sun.core CreditAttribution: sun.core commentedComment #17
adrian CreditAttribution: adrian commentedThe 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
Comment #18
sunI'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.:
That translates into:
Whereas every site still has additionally:
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 ;))