It seems that using the administrator pages causes a rewrite of the config.php file. That is ok but it reformats syntax to array() functions is there a way to prevent this?
I did not find anything in Configuration Parameters — Nextcloud latest Administration Manual latest documentation other than it suggest the short syntax.
‘version’ => ‘31.0.7.1’
I would expect simple “using” of admin pages leave the config untouched but a soon you change something the config must be written in parts or entirely. a complete full config “dump” sounds valid for me as long it doesn’t brake anything I don’t see any problem with valid alternative syntax.
I think it’s actually the other way around.
I’ve never really used the [ ] syntax myself, and I don’t fully understand the logic of when to use one or the other, or how it behaves when programmatic changes are made via the web UI or the occ command.
However, based on what I’ve observed, I’d say it’s probably the programatc changes that cause arrays to get rewritten, because arrays written via occ commands or the command-line installer always use the “classic” syntax, at least on all the instances I’ve ever set up. So, I’d guess that if a setting in the admin UI adds something to an array written with the [ ] syntax, it ends up getting rewritten using the classic syntax.
Long story short: to keep things consistent, I just stick with the classic syntax. 
@theking2 Btw, I’d avoid editing the config.php manually whenever possible, and also avoid using tools like sed or awk for that. It’s better to use the occ config:system:set command instead. That way, at least the syntax will always be valid, and who cares whether it uses “classic” arrays or [ ] then, right?
There might be other reasons besides just cosmetic ones, why you should or might want to use the [ ] syntax. And if that’s the case, I agree: the documentation should definitely explain that in more detail — or, well, explain it at all.
Let me add couple more suggestions:
Actually, I’m not sure how useful it would really be in the end if it’s limited to just the config.php, since only a subset of all configuration options are actually managed through that file. To implement something like this in a meaningful way, you’d probably need to abstract the entire configuration system. That is, you’d need some kind of middleware that manages all available options and settings — ideally including those from installed apps — while also maintaining a change history, supporting rollbacks, and so on.
I’m not a PHP programmer, but that should be possible — though I’ve never actually tried it: PHP: Comments - Manual
However, if I were to use comments, I’d probably place them at the beginning of the file. That’s because when you change the file programmatically via occ, or when certain settings are added by the admin UI, the lines in config.php can get shuffled around. So while this likely wouldn’t break anything functionally, the comments might no longer appear next to the relevant lines.
Btw. depending on your exact usecase, this might also be interesting: https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/config_sample_php_parameters.html#multiple-merged-configuration-files
Well, the main idea is to have backups. I am backupping manually each day the website with config.php in any case. Just if you change something there and the system is down/giving you some error, you may click on the button as an admin and revert back the config file to the previous state.
One more thougt is to develop self-healing, when nextcloud will correct/comment the lines which are affected.
Talking about mega config.php, which will incorporate settings from all apps, well, there are no specific small config files for apps, as far as I know.
All comments are just disappearing when I make changes via webUI.
Yeah, but what’s the actual use case? Being able to reset changes you made to the config.php? I mean, I can see some value in that. But since only a small subset of all configurable settings in Nextcloud are stored in that file, a backup of the config.php alone doesn’t really qualify as a backup of your instance.
In other words, in order to be able to restore your instance if s*** actually hits the fan, you’ll need a complete backup anyways. And that backup should include the Nextcloud folder, which also includes the config.php file, a database dump, and the data directory,
I guess there’s a niche use case, like if you accidentally deleted a ' in the Redis or database config and triggered an internal server error where a separte backup of the config.php would be useful. But even then, you could probably fix that manually without needing a backup of the file.
Interesting. That means the file does actually get fully rewritten, at least in some cases. So yeah, I’d say if you want to keep documentation of manual changes, you’ll need to store that somewhere else then.
And again, having proper backups of everything is necessary anyway, so I’m still not sure how much value a separate backup mechanism just for the config.php really adds in the bigger picture.
Fortunately, most apps don’t store their config in the global config.php but in the database.
I totally get what you’re asking for, but currently there are a number of challenges with handling this that would need to be worked out. Though there have been discussions and proposed paths forward for some aspects of this (e.g. here), but others are more difficult to overcome than they may seem (and IMO not currently worth the resource allocation such as supporting comments).
Depending on your primary motivators, fortunately, one can take advantage of the multiple/merged configuration file support still for things such as keeping their config under version control (mostly and just as an example). This works because secondary config files always take priority over the main config/config.php (even if there are various situations where their values end up merged in to the main config/config.php. And since secondary config files are not modified directly ever by Nextcloud Server itself, they could also contain things like permanent PHP comments AFAIK.
That all said, you may have some good ideas or solutions to some of these problems that haven’t been thought of yet. Don’t hesitate to experiment. 
P.S. Composing this pre-coffee so apologies in advance.
Whether that’s fortunate or not is debatable, especially since some of the app:config parameters you might want to change are not exposed anywhere, neither in a config file nor in the UI.
But yes, if we’re focusing solely on backing up the config.php, I guess that’s fortunate, as there aren’t usually that many things configured in it and they also tend not to change all the time. In most cases, if something were to go missing, it could be fixed relatively easily. Unless, of course, you delete the instance ID or something…
…but then you you could just get it back from the nightly backup or from an hourly ZFS snapshot, right?
However, wouldn’t it be great if there were some middleware that would manage all the settings, so could easily export all the settings and import them to a new instance. I’m imagining something similiar to TrueNAS or pfSense, where you can set up a new box, import an XML file, and almost everything is just as it was on the old instance.
Btw, such a middleware could offer numerous other advantages:
For example, a history of configuration changes could be exposed to the the UI to make it easy to roll back configuration changes. Or when uninstalling an app, the users could be asked whether they want to delete the app’s data and settings or keep them in the database, which would help people with OCD, like me, to sleep better, without having to fiddle around with the database, and thus always being one step ahead of destroying the instance. 
(Kidding I don’t fiidle around with the database, but it’s about 400MB, and has ptobably still tables in it created by apps I used 5 years ago)
And possibly much more…
Thanks. It is fascinating that the documentation uses a mix of long and short syntax.
(Btw I’m not sure which one is classic. I’ve been programming php sites and frameworks for about 20 years now and comming from a C++/# and Pascal background used [] from day one.)
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.