[drupal-devel] [task] Additional configurability of system paths in settings.php file.

[Bèr Kessels]

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:   Bèr Kessels
 Status:       patch

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.




Bèr Kessels



Previous comments:
------------------------------------------------------------------------

June 25, 2005 - 00: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 - 03:37 : adrian

Set to patch.




------------------------------------------------------------------------

June 25, 2005 - 03: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 - 11:56 : adrian

Attachment: http://drupal.org/files/issues/systemdirs_0.patch (2.73 KB)

Here's a fixed patch.




------------------------------------------------------------------------

June 25, 2005 - 15: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 - 18: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.