Issue status update for http://drupal.org/node/25720 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: adrian Reported by: adrian Updated by: adrian Status: patch 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 ? adrian Previous comments: ------------------------------------------------------------------------ June 25, 2005 - 01:50 : adrian Attachment: http://drupal.org/files/issues/systemdirs.patch (2.16 KB) 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 <?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. ------------------------------------------------------------------------ June 25, 2005 - 04:37 : adrian Set to patch. ------------------------------------------------------------------------ June 25, 2005 - 04:49 : adrian 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. ------------------------------------------------------------------------ June 25, 2005 - 12:56 : adrian Attachment: http://drupal.org/files/issues/systemdirs_0.patch (2.73 KB) Here's a fixed patch. ------------------------------------------------------------------------ June 25, 2005 - 16:10 : basicmagic 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 ------------------------------------------------------------------------ June 29, 2005 - 19:44 : adrian 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. ------------------------------------------------------------------------ June 30, 2005 - 10:19 : Bèr Kessels 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.