6.0.0-git
2019-03-24

[#9140] backends.php.dist does not load configuration stanzas in .d directory
Summary backends.php.dist does not load configuration stanzas in .d directory
Queue Ingo
Queue Version 1.2.3
Type Bug
State Resolved
Priority 1. Low
Owners jan (at) horde (dot) org
Requester requate (at) univention (dot) de
Created 2010-07-14 (3175 days ago)
Due
Updated 2011-03-10 (2936 days ago)
Assigned 2010-08-07 (3151 days ago)
Resolved 2011-03-10 (2936 days ago)
Milestone
Patch Yes

History
2011-03-10 11:18:39 Jan Schneider Comment #9
Assigned to Jan Schneider
State ⇒ Resolved
Reply to this comment
This has been implemented generally in Horde 4, for all configuration 
files, in all applications.
2010-09-24 08:52:40 requate (at) univention (dot) de Comment #8 Reply to this comment
So, let's reboot the discussion:
- First of all, these changes should go into the development aka git 
version of Horde and apps.
Ok, it was just a proposal.
- It looks like we only support .d style loading for registry files 
from horde/config/registry.d/
- The rationale for loading registry stanzas from a directory makes 
sense, but what's the exact reason why you need this for backend 
configuration files in Turba/Ingo?
Seemed like the straight forward thing to do to apply the same 
strategy that is used for all other configuration files (at least in 
Kolab) also to this one, given also that Kolab ships its own 
10-kolab_backends_base.php to override the dist backends.php:
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolab-webclient/ingo/configuration/ingo-1.2.3/
We applied the patch to be able to layer configurations (Horde, Kolab, 
UCS) and ship 20-backends_ucs.php to have a standard clean path to 
override (Horde, Kolab) settings if requirements change at some point.
- If this going to be done correctly, it should be done in 
Horde::loadConfiguration().
Ok.
2010-09-24 08:22:28 Jan Schneider Comment #7 Reply to this comment
Ah, sorry, we were talking about completely different things. The code 
in Turba you were talking about is a Kolab modification that doesn't 
exist upstream either.
I thought we already had some generic *.d/ loading code in Turba that 
you were referring to.

So, let's reboot the discussion:
- First of all, these changes should go into the development aka git 
version of Horde and apps.
- It looks like we only support .d style loading for registry files 
from horde/config/registry.d/
- The rationale for loading registry stanzas from a directory makes 
sense, but what's the exact reason why you need this for backend 
configuration files in Turba/Ingo?
- If this going to be done correctly, it should be done in 
Horde::loadConfiguration().
2010-09-23 18:52:20 requate (at) univention (dot) de Comment #6 Reply to this comment
Of course not. You want to load backends.php, so why would you look 
for sources.php? And if there was some support for config/*.d/ 
loading, you wouldn't have to write the patch. I asked you to look 
into Turba as an *example* how to correctly load config files from a 
*.d/ directory.
I see, fine we agree on the approach, since this is exactly what I did 
to provide the patch attached to this report: I took the following 
kolab patch for turba as the example, and did *not* find a 
corresponting code block in ingo-h3-1.2.3, so I thought it might be 
helpful to file the patch for ingo/config/backends.php.

http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolab-webclient/turba/patches/turba-2.3.3/t_turba_HK_GW_ConfigurationOverride.diff?rev=1.1&content-type=text/vnd.viewcvs-markup

If you consider the patch as futile we would be glad for a hint as how 
to choose an alternative approach to a conf.d-style solution in this 
case. If you consider this patch as obsolete, feel free to close this 
bug as invalid.
2010-09-23 16:18:09 Jan Schneider Comment #5 Reply to this comment
Ok, I see how it is done in turba, but in ingo-h3-1.2.3.tar.gz I 
could not locate a config/sources.php or any place where any pattern 
like config/*.d/*.php gets loaded. Thus we fixed this with the patch 
attached.
Of course not. You want to load backends.php, so why would you look 
for sources.php? And if there was some support for config/*.d/ 
loading, you wouldn't have to write the patch. I asked you to look 
into Turba as an *example* how to correctly load config files from a 
*.d/ directory.
2010-09-23 14:09:36 requate (at) univention (dot) de Comment #4 Reply to this comment
Ok, I see how it is done in turba, but in ingo-h3-1.2.3.tar.gz I could 
not locate a config/sources.php or any place where any pattern like 
config/*.d/*.php gets loaded. Thus we fixed this with the patch 
attached.
2010-09-10 15:36:40 Jan Schneider Comment #3 Reply to this comment
Ping?
2010-08-07 13:38:08 Jan Schneider Comment #2
State ⇒ Feedback
Reply to this comment
Like with Turba, this code must not be added to the base configuration 
itself, but to the place(s) where config/source.php is loaded.
2010-07-14 09:23:36 requate (at) univention (dot) de Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ backends.php.dist does not load configuration stanzas in .d directory
Queue ⇒ Ingo
Milestone ⇒
Patch ⇒ Yes
New Attachment: t_ingo_HK_UV_ConfdStyleConfigurationOverride.diff Download
Reply to this comment
The attached patch adds the include loop to backends.php for loading 
configuration stanzas from a backends.d directory. The code was copied 
from the sources.php.dist in Turba.

This include loop seems to be missing in ingo 1.2.4 as well.

Saved Queries