Right, so usually config.php is used for the key data/db/url settings but it also allows for settings which can usually be edited in site admin to be overriden & enforced. That's usually something which might be done for a couple of settings for security purposes - e.g. preventing cron from the web from being triggered by anyone.
I am however considering using this mechanism to it's fullest extent to deal with moodle configuration management across all our test to prod environments, versioning with peer-review, etc. Would also allow us to ensure that when a plugin is deployed the associated configuration we want for it is deployed in one go - for example with a highly configurable theme, one could ensure every single setting gets set correctly from the get go rather than re-doing all of this manually and that this goes through our CI/CD pipeline, changing all of the environments consistently. Now, I had thought we could do that by inserting the configuration into the database table but doing it through the config.php seems much better suited and much easier to script.
Assuming that once put together, that would be in the 1000s of lines of config. Has anyone else done this? Any impact on performance to expect?
I guess it should reduce queries on the DB and increase(?) memory usage on the app servers - though most of this ends up being cached anyway so it probably shouldn't make a difference either way.
I have no idea about the performance impact, but I can confirm that defining settings in config.php is very useful indeed. This way, all our (major) configuration changes are versioned via git. Of course we still make some changes in the UI, but this always lacks traceability (as to who changed what, when, and -most importantly- why!).
So, I can definitely recommend putting settings into config.php and our pages do not load noticeably slow (but I never did a comparison). More specifically, our config.php is not versioned, but near the end it includes the (versioned) configuration from a separate PHP file.
Thanks Jan. Had a bit of a lightbulb moment about this, this morning, and figured someone must have also thought about it. So it's great to hear that you are already doing this and there is no noticeable performance impact.
The GUI way, there is a log of any admin config changes at your.moodle.site/report/configlog/index.php but as you said it doesn't say why. We are meant to track these config changes through ITIL "Standard Changes" but seeing as this is disconnected from making the change, it can easily be avoided and we wouldn't get that justification recorded whereas with this way, we should. I think we will have to omit any setting which has references to a file though as the path will be unique to the environment. But there's not many of those - mainly site logo or other frontpage icons would be affected I think.
It's quite well hidden, but is this what you are looking for - https://github.com/moodle/moodle/blob/MOODLE_36_STABLE/local/readme.txt#L235
A performance issue wouldn't be the first thing I would think of. I don't know why you are concerned about that.
Offhand question here with the $defaults settings for local/defaults.php. How do you tell it to override the settings configured in the gui to force moodle to always use the settings set in defaults.php?
Update: Never mind. I am looking in the wrong place. I need to use the FORCED SETTINGS in config.php.
Performance is definitely not an issue here.
I've put > 1000 lines of configuration into config.php with no visible effect on the performance.
With OPcache enabled, I suspect that this is actually the fastest way of PHP getting your data (I have no data to back that up - you have to test by yourself ).