$newSettingProps=
array(
'key' => 'new_setting', //works
'name' => 'New Setting', //THIS VALUE IS IGNORED
'description' => 'New Test Desc', //THIS VALUE IS IGNORED
'xtype' => 'combo-boolean', //works
'namespace' => 'my_namespace', //works
'area' => 'Test', //works
'value' => '1', //works
);
$newSetting = $modx->newObject('modSystemSetting');
foreach ($newSettingProps as $key => $value) {
$newSetting->set($key,$value);
}
$newSetting->save();
$fields = array(
'key' => 'new_setting',
'name' => 'New Setting Name',
'description' => 'New Setting Desc',
'xtype' => 'combo-boolean',
'namespace' => 'my_namespace',
'area' => 'Test',
'value' => '1',
);
$modx->runProcessor('system/settings/create', $fields);
// to update an existing setting call the 'system/settings/update' processor.
The name and description are lexicon strings, not object fields. They're set automatically by the modResourceCreateProcessor and the modResourceUpdateProcessor, but you bypass the processors when calling newObject() directly. You also bypass a bunch of sanity checks.
I think this will work to create a new setting properly, but I haven't tested it. Some processors can be picky about the fields they get.
$fields = array(
'key' => 'new_setting',
'name' => 'New Setting Name',
'description' => 'New Setting Desc',
'xtype' => 'combo-boolean',
'namespace' => 'my_namespace',
'area' => 'Test',
'value' => '1',
'languageTopics' => array('my_chosen_namespace' => 'default'),
);
$modx->runProcessor('system/settings/create', $fields)
Good catch. That's one of those things that should be handled with defaults in the processor, but isn't.
The user create processor is particularly bad about that. It requires you to set things like the password notification method and password selection method, even though you're not notifying the user and you've already sent it the password.