We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 30223
    • 1,010 Posts
    I’m trying to convert some of my snippets to 0.9.7, thought this was a good way to get a bit more insight. After looking through a lot of source I can’t figure out how to access snippet parameters. One of my snippets used to use the $modx->event->parameters array to load extra parameters the core snippet doesn’t necessarily know about.

    I’ve gotten so far as modscript.class.php where there’s a reference to $xpdo->event->params but I can’t figure out how to access this from within my snippet.


      • 22303 MODX Staff
      • 10,725 Posts
      The event parameters were always extracted into the scope of the plugins, but I don’t understand how that is related to snippets at all. The event object only exists for use by plugins. Regardless, all modScript instances have their properties extracted to the local scope of the executing function.

      Maybe if I understood better what you meant by "load extra parameters the core snippet doesn’t necessarily know about," I could better guide you. How would these extra parameters be set?

      But perhaps you can use $scriptProperties to get the properties being sent to the modElement instance, regardless if it’s a modSnippet, modPlugin, or modModule (or even a custom modScript derivative).

      P.S. Look at your script files in the cache directories to see the actual generated functions that get executed when any modScript is called.
        • 30223
        • 1,010 Posts
        Snippet parameters are stored in $modx->event object in pre-0.9.7 versions in the evalSnippet method:
        <?php
        function evalSnippet($snippet, $params) {
                $etomite= $modx= & $this;
        
                $modx->event->params= & $params; // store params inside event object
                if (is_array($params)) {
                    extract($params, EXTR_SKIP);
                }
        //... more code
        ?>


        As an example when using eForm this is a convenient way of accessing eForm’s parameters from within "event" functions (such as eFormOnBeforeFormParse). This also allows you to set extra snippet parameters in the snippet call which are used by the event function but which are not normally used by eForm itself. (This is what i meant by "load extra parameters the core snippet doesn’t necessarily know about").

        I’m still working on a new version of eForm (albeit slowly) which is class based and which supports multiple action classes. The core snippet (class) can only access parameters it knows about by variable name as this is how normally the the parameters are provided to the snippet. This is problematic for action classes which by nature do not share the same variable scope. Since my action classes can have (and need) their own (snippet) parameters the only way I’ve come up with is to capture the $modx->event->params array and make this available to the scope of subsequent action classes.

        I’ve had a look at $scriptProperties and the cached script files and it looks like I can indeed use that somehow. Thanks for the pointers.

        I hope I’m being a bit clearer this time.
          • 22303 MODX Staff
          • 10,725 Posts
          Yes, the $modx->event->params stuff is set. See line 42 of core/model/modx/modscript.class.php; $this->xpdo is the same as $modx. Does that need to be assigning a reference to the properties though?

          Here are lines 41 through 53:
          <?php
                      if ($this->_result) {
                          $this->xpdo->event->params= $this->_properties; // store params inside event object
                          $this->_output= $scriptName($this->_properties);
                          if ($this->_output) {
                              $this->filterOutput();
          
                              // collect element tags in the evaluated content and process them
                              $this->xpdo->parser->processElementTags($this->_tag, $this->_output);
                          }
                          unset ($this->xpdo->event->params);
                          $this->_processed= true;
                          $this->cache();
                      }
          ?>
            • 30223
            • 1,010 Posts
            Just goes to show that staring at a lot of code without a bit of experimenting isn’t always helpful smiley I should have just tried it.

            It is assigned by reference in the old document parser but I’m not sure if it needs to be. It can’t hurt but besides saving a tiny amount of memory and some cycles I don’t see much of an advantage. It’s not like anything happens with those properties later on (or in between) is it?? I know of no event that could change the properties before the snippet is run or that needs them afterwards.