We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 3749
    • 24,544 Posts
    After some fumbling, I’m able to create a new system setting in Revolution:

    $temp_id = 2;
    $newObj = $modx->newObject('modSystemSetting');
    $newObj->set('key','spform_id');
    $newObj->set('value',$temp_id);
    $newObj->set('namespace','spform');
    $newObj->set('area','SPForm');
    $newObj->save();


    The catch is that the system setting isn’t available in $modx->config[’spform_id’] until I manually clear the site cache, even though both the document and the snippet are uncached.

    I tried:

    $cacheManager= $modx->getCacheManager();
    $cacheManager->clearCache();
    and
    $modx->reloadConfig();

    but it’s still not there, even when I visit in another browser.

    Also, what are the ramifications of setting "namespace" to "spform" versus "core"?

    Is there a plan to load (and maybe unload) system settings on demand by namespace as we do with lexicons? That would free us up to use system settings in snippets without taking a significant performance hit.

    I guess I should ask about my general strategy here, in case there are problems with it that I haven’t forseen.

    For complicated reasons, I’m putting a document ID in system settings. In the snippet that uses it, I test for the system setting and, if it’s not there, I figure out what it should be (getting the document by name), then create it. The creation only happens the first time the page is accessed.

    Down the road, I’ll probably do this in the build, but that will be more complicated and it’s working now except for the cache problem.




      Did I help you? Buy me a beer
      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
      • 28215
      • 4,149 Posts
      Quote from: BobRay at Oct 05, 2008, 10:35 PM

      The catch is that the system setting isn’t available in $modx->config[’spform_id’] until I manually clear the site cache, even though both the document and the snippet are uncached.

      I was able to do this no problem in a controller:

      $s= $modx->newObject('modSystemSetting');
      $s->set('key','aaa_test');
      $s->set('value','test');
      $s->set('area','test');
      $s->set('namespace','test');
      $s->save();
      $modx->reloadConfig();
      echo $modx->config['aaa_test']; die();
      


      Showed up ’test’.

      Are you sure that code creating the new system setting is running?


      Also, what are the ramifications of setting "namespace" to "spform" versus "core"?
      It tells the packaging system which settings are part of the core and which are part of 3rd Party Packages. I might add a combo to the system settings grids that filter by namespace.

      Is there a plan to load (and maybe unload) system settings on demand by namespace as we do with lexicons? That would free us up to use system settings in snippets without taking a significant performance hit.

      Hmm, no, there’s not. IMO, 3rd party settings should work similarly to lexicons (ie, $modx->config[’spform:setting_name’]), but that’s another topic. We’ll discuss this idea and get back to you.
        shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
        • 22303 MODX Staff
        • 10,725 Posts
        System settings (as well as context settings and user settings) are for global variables that need to be available to more than the internals of a single Element.  Elements have properties and those should be used by Elements, including default values and in tags.

        So-called 3rd-party settings are not for simple Elements, and you must realize that every setting that is created is available globally to every developer in the site.

        Resource ID’s should probably not be used in Settings for such purposes, though I do not understand the problem this solution attempts to solve clearly and want to reserve full judgment until I do.
          • 3749
          • 24,544 Posts
          Quote from: OpenGeek at Oct 06, 2008, 10:32 AM

          So-called 3rd-party settings are not for simple Elements, and you must realize that every setting that is created is available globally to every developer in the site.

          Can you clarify what you mean by "3rd-party settings." I’m not sure I understand the term.
            Did I help you? Buy me a beer
            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
            • 22303 MODX Staff
            • 10,725 Posts
            Quote from: BobRay at Oct 06, 2008, 11:44 AM

            Can you clarify what you mean by "3rd-party settings." I’m not sure I understand the term.
            Those not in the core namespace, which are installed as part of the core distribution.
              • 3749
              • 24,544 Posts
              This discussion reminded me that I’ve been meaning to ask about the "Default Properties" tab of the snippet create/edit screen in Revolution. I don’t get what it’s for at all.

              I got excited when I first saw it because I thought it would let people set, and change, the default parameters of a snippet without having to edit the snippet itself. I still think that would be useful, as long as the values could be over-ridden by the parameters in the snippet call.
                Did I help you? Buy me a beer
                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
                • 22303 MODX Staff
                • 10,725 Posts
                Quote from: BobRay at Oct 06, 2008, 12:44 PM

                I got excited when I first saw it because I thought it would let people set, and change, the default parameters of a snippet without having to edit the snippet itself. I still think that would be useful, as long as the values could be over-ridden by the parameters in the snippet call.
                That’s always been the purpose of default properties provided with snippets and plugins (and modules), to provide default values to be overridden by tags, or edited by developers when installing an Element.
                  • 3749
                  • 24,544 Posts
                  Right, but what’s the purpose of the "default properties" *tab* of the snippet create/edit page? The text there suggests that it has to be used with a module but it’s not clear to me why you would use it or what it would do.

                    Did I help you? Buy me a beer
                    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
                    • 22303 MODX Staff
                    • 10,725 Posts
                    Quote from: BobRay at Oct 06, 2008, 02:01 PM

                    Right, but what’s the purpose of the "default properties" *tab* of the snippet create/edit page? The text there suggests that it has to be used with a module but it’s not clear to me why you would use it or what it would do.
                    I think the text is misleading, but this is what the default properties tab is for, defining default properties for the Element -- snippets and plugins that are "dependents" of a module can share that module’s default properties (i.e. they are inherited from the module), and this might be where the confusion stems from.
                      • 28215
                      • 4,149 Posts
                      I, for one, have always found that part confusing. tongue
                        shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com