CiviCRM Community Forums (archive)

On #3, there is a hook_civicrm_alterSettingsFolders which allows modules/extensions to register settings. This could be turned into a "civix generate:setting".

But that's really only the data-layer -- it doesn't provide the UX for editing settings. There are a few options, and maybe we should figure out the best recommendation among them:

1) In the description/documentation for each extension, advise users to put settings in civicrm.settings.php using the global $civicrm_setting.

2) Advise extension authors to include a settings form. There is a base-class which I haven't used personally but looks pretty convenient -- one extends CRM_Admin_Form_Setting and declares $_settings, e.g.

https://fisheye2.atlassian.com/browse/CiviCRM/trunk/CRM/Admin/Form/Setting/Miscellaneous.php?hb=true

3) Recommend CiviConfigure to anyone using extensions (or possibly merge it into core):

http://civicrm.org/extensions/civiconfigure

Quote from: totten on February 04, 2013, 05:26:17 am

On #3, there is a hook_civicrm_alterSettingsFolders which allows modules/extensions to register settings. This could be turned into a "civix generate:setting".

Is this 4.3? could you add it to the wiki?
http://wiki.civicrm.org/confluence/display/CRMDOC42/Hook+Reference

I'll take a pass at it.

Quote

But that's really only the data-layer -- it doesn't provide the UX for editing settings. There are a few options, and maybe we should figure out the best recommendation among them:

1) In the description/documentation for each extension, advise users to put settings in civicrm.settings.php using the global $civicrm_setting.

What is the benefit over slapping any global variable? namespace and keep it clean?

The approach of "put it in a config file" seems like a short-term solution to me -- it can ship quickly with minimal development. But it's not ideal to require users to edit config files. One wants a web-based form for small deployments; and one wants a dev/stage/prod workflow for big deployments. If each extension has its own data-structure, then it'll be harder to get these benefits for all extensions. The ambition of the "settings" framework is to provide the features needed for settings on both small and large deployments. (Note, for example, there's another thread discussing an integration between Civi settings and Drupal "Features".)

Quote

2) Advise extension authors to include a settings form. There is a base-class which I haven't used personally but looks pretty convenient -- one extends CRM_Admin_Form_Setting and declares $_settings, e.g.
https://fisheye2.atlassian.com/browse/CiviCRM/trunk/CRM/Admin/Form/Setting/Miscellaneous.php?hb=true

Nicolas if you try, could you let us know?

Ditto

Quote

3) Recommend CiviConfigure to anyone using extensions (or possibly merge it into core):

http://civicrm.org/extensions/civiconfigure

Sounds an interesting option and probably the easiest for simple values. I my case wanted an associative array, so not that simple.

@eileen, is the setting api already dealing with array type?

I Might add a simple json formatting on civiconfigure?

Thinking aloud... Would a SQL table or an OptionGroup be appropriate?

D8 has spent a fair bit of time on configuration management to make things easier

we should definitely take a look at it and see the scope it covers and what we can reuse / build on

deepak will be doing this over the next week or so as part of his course work. I'm encouraging him to write a detailed blog post on this

lobo

I've been pondering the default settings issue for a while and until something better arrives, I'm going down the db road. It's simple and it works for my needs. I suppose an XML settings file would be handy as well but for me the db is there and all I need to do is use it. Mind you, I'm only dealing with a few settings which are mostly bools.

Andrew