CiviCRM Community Forums (archive)

not sure i understand this? Why dont you insert a default value in the setting table when adding that variable (in the upgrade script?)

lobo

NB - on upgrade to 4.3 we need to run

2) run civicrm_api('setting','fill', array('version' => 3, 'domain_id' => 'all') ;

because non current domains have been neglected on upgrade for a while & are missing lots of settings that they should have

I would get directly the json out the api (btw dgg, that was the syntax I was mentioning at civicon

<script>
//CRM is a new global object introduced by Colemans for 4.3, I use it as a namespace to store civi variables

CRM.config = {crmAPI entity="setting"}; // implicit action get
console.log (CRM.config.monetaryDecimalPoint);

//or if you want only one value, this should work too
var seperator      = {crmAPI entity="setting" action="getvalue" return="monetaryDecimalPoint"};

</script>Should work like that. if it doesn't, crmAPI is wrong and I'll fix it

On the crmAPI syntax .. this works!

   function calculatedPaymentAmount( ) {
       var thousandMarker = {/literal}{crmAPI entity="setting" action="getvalue" group="CiviCRM Localization" return="monetary_thousand_separator"}{literal};


Note that for getvalue the function requires group (because the underlying BAO function does).  The underlying BAO function for getvalue is different (faster) than the get function.

for things like the directory / url path values, we store them in the settings table, BUT cache them in the config object

that way we avoided changing a lot of templates

Not sure if we should make function calls to "retrieve" the various setting values. So i suspect caching in the config object is still a good way

we have to make it easy for folks to change via UI. We should not assume people will hack a PHP file to modify settings

lobo

Ok so there seem to be a few things talked about here & not quite separated.

1) Settings Metadata - I am using this term to describe the Metadata ABOUT the possible settings. This includes the 'default' value & various other bits & pieces. It is hook editable & modules can set their own defaults. This should only be accessed during configuration actions (not getvalue actions as Tim pointed out these might occur during a batch job & needed to be 'snappy'). Revert & Fill actions are based on these (hook modified) results. Probably installing a 'localisation modules' would change the defaults & possibly 'revert' to them when it is enabled.

Currently Settings Metadata is stored in xml & is converted to an array when it is loaded - but X has made the case for changing that to a more drupal style set up where each Config file has a sensibly named function that returns an array. The custom separator breaks the xml. Apart from the effort involved in converting from xml to a php function I can't see a downside to doing that. Can anyone else?

2) The DB civicrm_settings table stores the actual settings in use for the site. Front end forms are unchanged but save to settings rather than to $config when I convert settings over (I did 2)

3) Changing the calls to retrieve the settings is a little yuck

      $thousands_sep = CRM_Core_BAO_Setting::getItem(
        CRM_Core_BAO_Setting::LOCALIZATION_PREFERENCES_NAME,
        'monetary_thousand_separator'
      );

A lot of the reason it is 'yuck' is not the model but the choice of groupnames - ie. we have the choice between

 

[ul]CRM_Core_BAO_Setting::LOCALIZATION_PREFERENCES_NAME[/ul]
[ul]CiviCRM Preferences[/ul]
[/list]

If the group name were simply 'core' then the key for the setting could become 'core_monetary_thousand_separator' (other examples would be mail_verp_separator & 'multisite_is_enabled' (rule would have to be one-word, lcase).

4) Alternatively we could ditch the whole group field in exchange for removing the notion of 'setting cache groups' - probably this would be my first choice - but it would involve more change/ work.

5) Makes sense to have REALLY high usage settings cached in the $config object - URLs & directories are the only ones that I would keep there (which is pretty much what has been done with other settings conversions).

6) For the rest the following makes sense to me in tpl files
{crmAPI entity="setting" action="getvalue"  return="core_monetary_thousand_separator"}
or in php

civicrm_api('settings', 'getvalue' array('return' => 'core_monetary_thousand_separator', 'version' => 3));

drush civicrm-api setting.getvalue return=core_monetary_thousand_separator

(And/Or Tim's $config object wrapper)

7) most of the settings are pretty 'lean' but I wouldn't want to be loading up the big ones - e.g. country list , state_list as part of a generic cached settings array.

Namely, wouldn't it be better to simply generate a config.cache.php that contains the $config (or in as a static in a "namespace" function) instead of a serialized in a db row in civicrm_cache (or memcache)?

I agree that the "config.cache.php" is probably a more performant caching mechanism than a serialized DB row.

As for the groups, are the name of the settings unique across all the groups? We could keep the groups in the db and "flatten" them in the config/api.setting (probably going to cost a few more requests if the config isn't saved in the cache file, but shouldn't happen too often)

Empirically, the names for domain settings are unique within the domain. We would want to set a stricter policy for naming them to prevent accidental collisions in the future (eg "tag_unconfirmed" should be called "campaign_tag_unconfirmed", but it's not worth the effort to rename it right now).

7) most of the settings are pretty 'lean' but I wouldn't want to be loading up the big ones - e.g. country list , state_list as part of a generic cached settings array.

P.S if needed for big config items (eg countries list) might be a worthwhile improvement to add a magic __get() so the $config->country is only loaded when needed.

How about eliminating the property 'group_name (string)' and adding a simpler property 'prefetch (boolean)'. If prefetch is true, then the setting will be stored in the cached blob (config.cache.php or memcache or serialized DB row or whatever).

This is how the UI version of the settings revert is currently looking