We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 34127
    • 135 Posts
    Just a quick question... in one of the recent revisions (I’m not sure which exactly, but it was towards the end of October), the setDirector() method was removed from the modConnectorResponse class, which is how we were pointing our custom manager pages to our processors directory for AJAX stuff. This doesn’t work now, and removing that call to setDirectory() loads the default MODx processor path (which totally breaks my existing pages!). Is there a new way we should be doing this now? Thanks!
      • 28215
      • 4,149 Posts
      That seems to have been an oversight. setDirectory has been added back as of rev 4402.
        shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
        • 34127
        • 135 Posts
        Ah, that makes sense. Thanks for the quick reply! smiley

        And awesome job on alpha 6 so far, it’s shaping up to be a rock-solid CMF! grin
          • 28215
          • 4,149 Posts
          Yeah, seems that your post actually has stirred up some rethinking about how processors are loaded in the core dev team...

          We might be rewriting this to have processors actually loaded at a package level...meaning you wouldn’t have to specify the directory at all, should you place the processors directory as a subdirectory in the model directory. More on this later, as it develops.
            shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
            • 34127
            • 135 Posts
            I’m not sure if it’s worth posting in JIRA now that you guys might be changing this anyways, but it doesn’t seem like rev 4402 fixed it. The setDirectory() error is gone, but it seems like MODX is still looking in the default/core processors directory, regardless of what I pass to setDirectory() in my script. It seems like line 87 in modconnectorrequest.class.php is the culprit (from a glance - I’m not sure):
            $this->setDirectory($procDir);


            Because we already have called setDirectory() from within our connector, then we call handleRequest() which calls prepareResponse() without a ’processors_path’ value in the passed array. So _directory is reset to the default processors path, which kinda undoes out previous call. tongue Maybe remove the aforementioned line, or let us pass a $processors_path directly to handleRequest() and set the directory from there?
              • 28215
              • 4,149 Posts
              Ric,

              You’re right. It isn’t accessible. This has been fixed as of 4438 - you now pass in an array to handleRequest(), like so:

              $modx->request->handleRequest(array(
                  'location' => 'my/location',
                  'processors_path' => '/my/path/here/',
              ));
              
                shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
                • 34127
                • 135 Posts
                Works beautifully now, thanks for the quick fix, Splittingred. laugh