CiviCRM Community Forums (archive)

Argh - it's hopeless cropped - you can't see the 'revert' link where the default differs from your site

My main concerns are:

1. This project scope is getting to be a lot larger than what was started with

2. I do agree that improving / fixing the current system is a good thing

3. If we agree on a naming convention and protocol, we then need to go back and fix all the places that use various config settings today, unless we do it in a backward compatible manner. Depending on how we do this, it could potentially impact all templates

4. We need to ensure that we dont increase the number of dbQueries significantly due to this change. There are a few settings that are used on ALL pages (specifically the url and path settings)

5.  I'll strongly vote for config is hierarchy

6. If we are doing all the above, should we consider and benchmark the "lets cache the settings in a PHP file" idea of Xavier
 
7. Fix the upgrade and the new install scripts to implement the above

8. Migrate all / most of the settings currently stored in $config (in the serialized array) into their own settings array

if folks think they have the time and energy to push this thru for 4.3, then you can start work on this in a branch. Once that branch is stable, we can merge it into trunk

lobo

we've been removing more and more settings from the config object and moving them into the settings table. We still have quite a few more variables to migrate

i think the next set should be all the ones that are used in only specific workflows (recaptcha, mapping, mailer, search etc)

If keen, you can make a big push and strip most / all the variables from the config object

another related area that needs cleanup is the whole state / country stuff. These days with ajax and retrieving states automatically, i suspect we can do the right stuff rather than loading the entire set in memory / tables etc

lobo

OK - so the specific task I have been working on is moving some config variables to settings - with two done (max_attachments & contact_undelete) - both of which are accessed in only a small handful of places. My focus is on moving the localisation settings as these are the settings that a given integrator is most likely to want to standardise across several installs (e.g set them all to Canadian $$).

The other specific changes I would like to make are

1) make group an optional part of the setting namespace & require the name+domain_id+contact_id to be unique (this second is currently true)
2) allow getValue requests to provide either group or name or both


Other steps I will need to take

1) create an action that converts config settings to settings settings that will run on upgrate / setup.sh / probably from system api.

This wouldn't stop existing settings from working

Some other notes

1) the project scope is to be able to set common config attributes via the api - the problem is that they are stored in different places :-( A lot of the meta-data about what settings are available is currently hard-coded into the form layer.

2) there are a small number of settings that are used all the time (paths & urls). These are currently cached in the $config object as well as stored as settings. I have any short-term plans to change this. Tim has some suggestions about the idea of a $setting namespace instead. The accepted process here is than in 6 months time I will finally understand the full wisdom of Tim's idea, present it as my own & bask in the kudos of Tim endorsing 'my' idea. However, if Tim wants to establish a new crmSetting or an alternative to $config then I will happily implement the code per his method when moving items from config to settings (& existing settings within reason)

3) I don't personally want to get into changing the caching at this time. url paths & directories will still be cached in config. If you access settings with the 'group' in the name it will still be cached as a group. If you access the setting as a single name it probably shouldn't be cached at all. None of this precludes implementing Xavier's idea later (or Tim's ideas once they have been refactored as my own).

4) Country Limit- I still don't really have a clear idea of how this should be implemented - although I think we should be switching to autocomplete. I did create a separate thread on this

5) X - $config->userSystem is a REAL object - with proper class-based function calls - not a setting. I copied this structure for userPermission object in 4.3 as well.

6) agree with Xavier that not exposing dsn via &smartyDebug=1 is a GOOD Idea.

7) Tim - I had been working off the idea that in non-performance sensitive situations (configuration , upgrade, module changes rather than sending a CiviMail) we could use the metadata for considerations around lifecycle.

Some settings are so closely tied together (e.g. SMTP host, SMTP port, SMTP user, SMTP password) that they are currently stored as a single setting in a serialised array. This is also part of the drupal approach - some modules choose to store an array rather than individual settings

9) I guess the fact that means I'm talking about your approach 3? That'll have been my idea all along in 6 months :-)

NB Tim's action list (from pastebin)

1. Add uniqueness constraint on civicrm_setting for (name,domain_id,contact_id)
2. Implement $config->settings (for lookups) and new read/write/cache behavior
3. Implement CRM_Core_BAO_Setting::getGroup($groupName) which fetches all items in a group
4. Rewrite/simplify CRM_Core_BAO_Setting::getItem() -- it should simply call getGroup() or $config->settings (depending on which parameters are passed in)
5. Rewrite/simplify CRM_Core_BAO_Setting::setItem() -- it should simply call $config->settings

I wrote an extension to manage the settings that are exposed through the API

https://github.com/TechToThePeople/eu.tttp.setting

Right now, most useful feature is being able to revert.

Work in progress with Eileen on it. Next steps are to clarify which settings should be on that list (eg they are plenty of settings that don't have a default value, so we can't reverse I suppose)

see how to improve the default value presentation (seems to have escaping problems, eg \n not being displayed as <br>)

and edit in place (at least for the strings, no idea what to do wit most of the arrays)

I have documented where this is at. I probably need to distribute the link more widely but at least one person (although a rather clever person) has already managed to make sense of adding a new setting

http://wiki.civicrm.org/confluence/display/CRM/Settings+Metadata+and+Usage

Coleman - I think that is the preference of Xavier, Joe, Tim & I. Lobo wasn't convinced though. At the moment the setting name ARE all unique so it would still be relatively easy to switch across - there are a couple of proposals earlier in this thread about it.

a few thoughts:

1. The settings stuff is now pushed to 4.4 since we are at a code freeze and no major changes

2. Given the above, we should take a look at D8's configuration system and see if we can adopt some / most / all of the ideas they've incorporated into D8. I suspect they've put a lot of thought and design work into this and performance etc

3. I'm still a strong -1 on a flat namespace. We have quite a few settings and config variables and this will increase significantly as we unify everything under settings.

4. This seems like a great project for a sprint, where a group of folks tackle and wrap this up during a sprint. I think its a fairly big task for one person (eileen) to plod away and get consensus on various things

lobo