This is mostly for i18n variables, but there are various reasons why you would want to allow specific users (with proper permissions) to add stuff to the settings.php file for more complex configurations (like #494446: allow shared tables between sites).

Comments

adrian’s picture

adrian CreditAttribution: adrian commented

I had this at some point, but i had no idea how the precedence is.

ie: where do you configure it. per platform (ie: drupal release) , per site , per server, globally?
how do they layer and interact.

how do you take care with different drupal releases needing different code.

The same goes for custom templates for the virtual host configs.

anarcat’s picture

anarcat CreditAttribution: anarcat commented

Well, right now we have a per-server global settings file included everywhere. I'm proposing to have a per-site local configuration that can be edited by a third party.

anarcat’s picture

anarcat CreditAttribution: anarcat commented

Rather trivial patch uploaded to #500088: allow user-defined settings.php overrides.

steveparks’s picture

steveparks CreditAttribution: steveparks commented

People do start contributing to drupal and other OSS projects in 'rather trivial' ways, but if encouraged rather than dismissed can then learn and get confidence and become more valuable contributors in time.

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Status: Active » Needs review

Hum. I think we have a slight misunderstanding here: i wasn't meaning to degrade your work at all by qualifying as trivial. It's pretty much the patch I had in mind when I opened this issue back then and I am very happy you are providing it.

The work here *is* rather trivial: it's just one include. And in fact, you accomplished it beautifully (I wouldn't have thought of using conf_path()), so maybe I am wrong and this is not at all trivial (especially considering the ordering issues that Adrian mentioned).

So I apologize if you felt that I dismissed your work, this is not at all what I wanted to express. I'm really sorry about that and I hope this will not hinder further contributions, we need all the help we can get!

I'll be happy to test out your patch this week, if I find the time. Unfortunately, it will not be part of the upcoming 0.3 release, because it's in a feature freeze, but it will make a great addition to 0.4.

Thank you for contributing to the Aegir project and sorry again for mishandling this issue. To my defense, English is not my native language so I may sometimes miss subtleties in my own discourse...

steveparks’s picture

steveparks CreditAttribution: steveparks commented

Ah, okay - thanks for clarifying, it's appreciated. It probably is a language thing.

I do know that this is only a tiny, tiny, really simple patch, and didn't expect a fanfare or applause or anything, but took the comment to mean I was wasting your time by submitting it. I'm glad that's not what you meant :)

I'm keen to learn and start to contribute more - but it's daunting how much you guys know, so it actually takes a bit of bravery to put a first submission up! Anyway, I'm keen to test, document and help in any way I can.

cheers
Steve

anarcat’s picture

anarcat CreditAttribution: anarcat commented

Raaah i really got that wrong, the issue i was meaning to refer to was #538742: Enable customisation of settings.php via include file. Sorry again, pilot.. :/

Macronomicus’s picture

Macronomicus CreditAttribution: Macronomicus commented
Status: Needs review » Reviewed & tested by the community

Ive tested and it worked perfectly.. thanks Pilot! I ran into this because I normally add a tag to set a maintenance theme (tweaked version of the sites theme) for when a site is offline, took me a while before I noticed that they were being dropped.

Including a site.inc was a perfect easy fix, for what I needed!
This should make it into next release IMO unless there are some hidden unknown beasties lurking .. I guess I'll notice if they rear their heads .. I went ahead and added it to my production environment because its just too useful and tested perfectly.

Cheers!
^_^

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Status: Reviewed & tested by the community » Closed (won't fix)

You know what, I feel pretty bad about this, but I feel like actually rejecting this patch. We don't actually *need* a local settings.php in most cases, and the conf_path() does impose an additionnal performance load, by default.

It is fairly simple to add the exact same code to the global settings.php. You just need to add the following lines:

 # Additional site configuration settings. Useful for safely specifying configuration settings.
  if (file_exists(conf_path() . '/site.inc')) {
    include_once(conf_path() . '/site.inc');
  }

to /var/aegir/config//includes/global.inc. We are likely to do exactly just that over here at Koumbit, but I'm trying to avoid it and so far we haven't needed a site-specific settings.php just yet. Note that you can also specify extra stuff to add to the settings.php to third-party provision modules...

Is that enough for you guys? Or do you *really* need a site-specific settings.php? If so, what for?

Macronomicus’s picture

Macronomicus CreditAttribution: Macronomicus commented

Anarcat: That fix didnt work for me :( ..is there something particular I need in the global.inc file that I am missing?

I use my settings.php for setting a maintenance theme when a site is in offline mode.
$conf['maintenance_theme'] = 'site_specific_theme';
Which then calls up maintenance-page.tpl.php

I removed Pilots patch and then I created dir & file /var/aegir/config/includes/global.inc and added the following...

<?php 
# Additional site configuration settings. Useful for safely specifying configuration settings.
  if (file_exists(conf_path() . '/site.inc')) {
    include_once(conf_path() . '/site.inc');
  }

I left the site.inc file the same as it was before with Pilots patch in the site dir for a site.

<?php 
$conf['maintenance_theme'] = 'site_specific_theme';

I ran a verify on the site and then flushed caches & ran cron, then threw it in offline mode to check and all I see is the Garland theme with the offline message. :( no love .. maybe I mucked something up?

anarcat’s picture

anarcat CreditAttribution: anarcat commented

I think the issue you have is this #588042: relnotes: /var/aegir/config should be a+X. I was able to make global.inc work after chmod a+X /var/aegir/config

Macronomicus’s picture

Macronomicus CreditAttribution: Macronomicus commented

hmm .. I do have that directory set to (rwx-rx-x) and also set that on the site.inc file which resides in the sites/somesite.com directory... but still see garland as the maint(offline) theme.

Maybe there's an easier way to do what i want .. as setting the offline theme is the *only* reason I even added a conf variable to the settings.php.
Going to look around and see what else is out there .. I hate seeing that garland theme when sites go offline! lol ;) and re-adding it erratically is not an option.

Still might do me well to figure out why the global.inc method isnt working for me... not sure really, hopefully I'll get some time to come back to it sooner than later :)

Cheers!

anarcat’s picture

anarcat CreditAttribution: anarcat commented

Please provide the output of ls -al /var/aegir and ls -l /var/aegir/config

thanks.

Macronomicus’s picture

Macronomicus CreditAttribution: Macronomicus commented

Its working now .. not sure why but its working, goodbye garland maintenance theme! Im glad I got this working cause may need to use it for more than just the maintenance theme.

Here is the output of that command.

[aegir@devbox][/]
$ ls -al /var/aegir and ls -l /var/aegir/config
ls: cannot access and: No such file or directory
ls: cannot access ls: No such file or directory
/var/aegir:
total 56
drwxr-xr-x 11 aegir aegir 4096 Oct 30 19:08 .
drwxr-xr-x 16 root  root  4096 Oct 14 10:45 ..
-rw-------  1 aegir aegir 6182 Oct 30 09:01 .bash_history
-rw-r--r--  1 aegir aegir  304 Oct 14 15:14 .bash_profile
drwxr-xr-x  3 aegir aegir 4096 Oct 14 10:50 .drush
drwxrwxr-x  9 aegir aegir 4096 Sep 17 14:32 atrium-1-0-beta3-1
drwx------  2 aegir aegir 4096 Oct 15 07:50 backups
drwx--x--x  4 aegir aegir 4096 Oct 30 19:03 config
drwxr-xr-x 10 aegir aegir 4096 Oct 29 01:23 drupal-6.14
drwxrwxr-x  9 aegir aegir 4096 Oct 30 08:27 druplestate
drwxr-xr-x  5 aegir aegir 4096 Oct 27 10:36 drush
drwxr-xr-x  9 aegir aegir 4096 Oct 30 05:25 m-news
drwxr-xr-x  2 aegir aegir 4096 Oct 15 11:58 tmp

/var/aegir/config:
total 16
drwx--x--x  4 aegir aegir 4096 Oct 30 19:03 .
drwxr-xr-x 11 aegir aegir 4096 Oct 30 19:08 ..
drwxr-xr-x  2 aegir aegir 4096 Oct 30 19:03 includes
drwx------  2 aegir aegir 4096 Oct 30 06:38 vhost.d
Macronomicus’s picture

Macronomicus CreditAttribution: Macronomicus commented

Just wanted to say thanks for this again .. I had to come back to this since im now running pressflow platforms inside pantheon mercury which uses cacherouter & requires bits on the settings.php .. I was glad to see this still worked on the 6.x-0.4-alpha3 and I hope anarcats solution in #9 sticks around for the full 0.4 release.

Cheers!

Macronomicus’s picture

Macronomicus CreditAttribution: Macronomicus commented

over on IRC .. omega8cc helped me with an even cleaner method to do this.... just putting it up here in case someone else finds this issue googling....

$thishost = $_SERVER[HTTP_HOST];
if(preg_match("/(dev\.mysite\.net)/", $thishost)) { 
	any custom bits here... etc.. etc..
	$conf['maintenance_theme'] = 'my_theme';
 }

no need for all those site.inc files, unless of course you want different "users" who only have access to their sites dir then the site.inc may be necessary I guess.