Move config.php settings to database
E
Eugenio
Hi,
I am working hard on the new upgrade procedure. A new script allows to upgrade a DaDaBIK installation just by putting the new zip package into the "upgrades" folder and run the script; everything (files copy, database changes, ... ) is handled by this script.
One of the difficult parts is keeping your config.php settings if the config file (instead of the config_custom file) has been edited.
I am thinking about moving the config settings to the database: this would simplify the upgrade and maybe it's a good thing to do anyway.
In the config.php file we would only store the database connection parameters, while all the other parameters could be changed from the admin section, as it happens for Data -> Settings now.
It would be a big change and quite a lot of additional work, so I am curious to hear your thoughts about this, do you see any disadvantages in having the settings in the admin section instead of in a file?
EDIT: I posted as a comment some updates
E
Eugenio
It is more complex than I supposed for several reasons, including the fact that the connection to the database (needed to read the config parameters from db if they are no longer available in config.php) is executed at a point of the code where those parameters are already needed. Basically this change would require more code modification than expected so, at least for the moment, I might try to migrate some minor parameters to the database but the config file will still be the main place.
However, I came up with a solution for the upgrade script that seems to work very well:
- all the documentation related to custom files (e.g. custom_functions) will be moved to the manual (no more documentation in the file itself)
- the upgrade script makes a backup of your config.php then overwrite it with the new. If you have used config_custom, you don't have to do anything. If you didn't, the script detects which of your old config parameters differ from the current ones (if any, and that means you edited config.php directly) and suggest you to set those parameters in config_custom
- starting from V. 10.4, the config.php file cannot be edited, it will be used for reference only
As usual, any suggestion is welcome!
S
Stefan Taube
Dear Eugenio, I like the idea because this is always a time consuming undertaking during the upgrade. Also for me it is easier to access the database via a browser than opening an ssh connection since our server is pretty restrictive. I do not see disadvantages moving most of the settings to the database since you always leave the variables backwards compatible. I presume that database settings are generally less save than hard coded parameters in a file. Maybe a mix of basic parameters can remain in config.php and a selected set of parameters moves to the database.
Thanks for all the good work and effort.
Stefan
E
Eugenio
Stefan Taube: Hello Stefan! It's hard to say if the settings are safer in the config file or in the db, it depends on many factors but I think that in an average situation you are right.
There are a couple of things to consider, though:
1) DB connections parameters (probably the most important settings) will always be on a file
2) I wouldn't remove config_custom.php for two reasons:
A: you can override settings according to some logic (e.g. chart creation is OFF but if the current table is "customers", enable it)
B: if you are afraid of leaving important parameters such as $enable_auhtentication in the db, you can add them to the config_custom file as well, so if, for some reason (e.g. an SQL injection issue) a malicious user is able to change them, you have the value hardcoded in config_custom, which overrides the value you have in the db
M
Martin
I think it's a great idea in general. Would be a much better and consistent user experience to have the settings directly in admin panel!
Ken Christensen
I'm in favor of the 'new upgrade procedure', although I just went through the current upgrade procedure recently and it didn't seem so horrible. Admittedly, I just moved from 'pro' to 'enterprise' <wink>.
However, if this (the move to databased config parameters) is going to be 'quite a lot of additional work', then I'm skeptical of it's value. I don't know the intricate details of what has to happen, of course, but couldn't the config_custom.php issue be handled by copying it to someplace safe before the upgrade and then just copying it back after successful upgrade?
In deference to Howard Burbank, I only have one instance and three applications, so my thinking is probably under-experienced <grin>.
E
Eugenio
Ken Christensen: the config_custom file is not overwritten so if you use the config_custom file there isn't any big issue, the problem is that older versions of dadabik don't have a config_custom file and/or some users might have totally or partially edited config.php even if config_custom was available.
Furthermore, I think that the config file is becoming very long and especially for new users not easily readable: a Web version allows better formatting and the possibility to hide advanced options.
Ken Christensen
Eugenio: Good points that I hadn't considered. My use of dadabik is pretty trivial. I agree completely with your last paragraph.
H
Howard Burbank
This would be a great help when updating the software on multiple instances.