CiviCRM Community Forums (archive)

I realise that much of what used to be in the settings file has already been moved into the database and appreciate that. However I think that removing as much as possible from that file, and simplifying the rest, would make initial setup and upgrades much easier to handle.

So what should be in there?
In my opinion just what's needed for the system to know where it lives, what it is running on and where to find the rest of the data. All other settings should go into the database, and code into the distribution itself.

What do I refer to with "simplifying"?
Firstly, take the burden to concatenate strings in different ways depending on fixed rules off the user and let some code - external to the file - do it.
Secondly, take all code out of the file (separation of data and logic) and format the data in a friendly, human-readible form rather than necessarily in PHP syntax.
Thirdly, determine as many of the required parameters, or at least defaults for them, from the run-time environment. I'm not a PHP programmer and don't know much about the inner workings of civicrm, but would it be possible to tell from within civicrm which CMS it was called from? What base-URL and file system directory that CMS is installed under? Which database system, version and host it is using? What table-prefix the CMS uses (as in what the "users" table is called)? And so on.

Just to give an impression of what I have in mind, consider this (default values commented out):

//CiviCRM config file (proposed)
//
//stuff where sensible defaults could be assumed if setting absent
//even better if correct values could be determined from environment at setup time
//either would be overridden by user entries here
//
//cms = Drupal
//version = 5.2
//dbtype = mysql
//dbversion = 4.1
//cms_userstablename = users
//civicrm_root = ./sites/all/modules/civicrm  // or whatever default makes sense
//
//settings where no defaults can be assumed
//if retrieval from environment impossible then user entry is required
//
//dbuser = cmsdbuser // otherwise "dbuser = mydbuser", etc.
//dbdbase = cmsdbase
//dbpassw = cmspassword
//dbhost = cmsdbhost // rather than localhost...
//base_url = cms_base_url
//base_dir = cms_base_path
// add whatever parameters are absolutely required to get the site going (if anything) but not more
//
// The End

As you can see I'm assuming that every value can either be retrieved from the host CMS or set to a sensible default, however even if every single one of the above values would need to be manually set that would still
- not be particularly hard to do
- enable the file to be left as is for the next update/upgrade rather than edited side by side with the new one as it is now
- even with comprehensive comments make for a rather short and clear configuration file

What do you think? Is this possible? Is it desirable? If not, why not? Would it be hard to do? What did I miss?

Cheers & TIA,

Ronald

Hi Lobo,

Thanks for your reply.
I would consider working on that itch if it would itch me enough to actually start learning PHP first and then the Drupal and civicrm APIs, meaning it would have to itch really, really badly. I'm generally happy to do things that are down my lane, i.e. something I am actually able to do, which this is not without climbing a very long learning curve first. As it is I primarily see it as a suggestion to make it easier for non-programmer folks to get started and keep up-to-date with civicrm. In fact it does not even itch me all that much anymore but I made the general experience that it's sometimes valuable to point out some of the trees to people who have been in the forest for a long time so I thought I do so before I forget about them as well.

I haven't seen the current installer (no PHP5 yet) and of course having one with an upgrade path in every version would pretty much address the issue, even though I could imagine that implementing it might be easier to do with a simpler prefs file, too.

I remember that there was an installer some while back (version 1.3?) which did quite a nice job but was gone in the next version. I wondered why and just (maybe wrongly) imagined that it was too tedious to keep current and/or/so-that other things were considered more important/urgent/resource-efficient to do at the time.

As for retrieving data from different CMS's and the issues going with that, I can imagine that it would not be trivial to do in a generic way.
I was more shooting at the stars in the hope to find out how much of my suggestion might be feasible.

However even if it were just for simple things like having the user enter values for everything in the list and civicrm assemble the strings accordingly, that would be a big improvement. If loads of comments can instruct a user how to concatenate the needed elements after a pattern for different database systems and versions, different CMS types and versions, etc, it would surely not be too hard to have the user provide the elements and some piece of code assemble them.
As in "tell me what dbms, db, password, user, db-host you are using, one by one - I can build the connection URL myself, thank you very much!". Same for the base URL and basedir: once those two are matched any other directories can probably be referenced using just a relative path and I see that most of the subdirectory and matching URL entries (which seemed redundant to me) are already gone, as is much of the code which used to be in the file in earlier versions, so it seems I'm not too far off of what you've been doing anyway.

In fact I may try and have a go at that string concatenation challenge (sans cute parsing for starters) as it might not even need all that much PHP knowledge to do.
Hm. I'll have a look. I guess it would take a PHP-whiz no more than five minutes to do but gee, I can learn something.

Cheers,

Ronald

Hi Lobo,

That sounds great, thanks.
I was really going to look at the code but now that doesn't seem like a good idea anymore (?) because the issues are being addressed already.   
(Phew!  )
[Edit: Whoops, in this particular case I mean of course - I fully agree with your point regarding contributing to the cause and will be on the look-out for other opportunities to do so.  ]

Thanks also for the cue regarding PHP4/5.

Cheers,

Ronald