New Community Forums are coming. Watch this space for news.
Subscribe: RSS
  • I need to create/update the name and descriptions of a some system settings via code.

    I can create the setting with its key, type, value, namespace, and area settings with no problem and it shows up nicely in the Manager grid.

    However, I can't set the name and description that appear in the Manager grid for users to tell them what these are. Looking at the MODX docs, that makes sense because these don't appear to be part of the modSystemSetting object, but I'm not clear how they actually do get set and stored. Is there a special method or a related object one has to work with? Can anyone help?

    Here's the relevant code:

    $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();
    


    Thank you...
    • 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',
      );
      
      $modx->runProcessor('system/settings/create', $fields);
      
      // to update an existing setting call the 'system/settings/update' processor.


        Get my Book: MODX:The Official Guide
        MODX info for everyone: http://bobsguides.com/MODx.html
        My MODX Extras
        Bob's Guides is now hosted at A2 MODX Hosting
      • Quote from: BobRay at Feb 14, 2019, 04:04 AM
        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.


        Bob - Thank you very much - I hadn't twigged the names and descriptions were lexicon strings and hadn't thought of using a processor, but that feels like a better way to do things.

        After a bit of experimentation, I found that one extra step is needed to persuade it to update the lexicon entries - in needs to be told which lexicon namespace and topic to use. So the following is the version that seems to work as desired:

        $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)
        


        Many thanks!

        Alex
        • 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.
            Get my Book: MODX:The Official Guide
            MODX info for everyone: http://bobsguides.com/MODx.html
            My MODX Extras
            Bob's Guides is now hosted at A2 MODX Hosting
          • Quote from: BobRay at Feb 14, 2019, 08:57 PM
            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.

            Thanks Bob. I often wish there was more explicit documentation of things like processors' expectations, but of course that all takes a lot of time to do...

            I appreciate your help sorting this out. It had become a bit of a puzzle prior to your suggestions!