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
    I need to get an input string from the user and do something with it during the install. I see there’s a window for that. Can I get an example of how to use it? I might need a yes/no question too.

    Also, is the license screen mandatory or is there a way to skip it during the install?
      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 Nov 18, 2008, 10:37 PM

      I need to get an input string from the user and do something with it during the install.  I see there’s a window for that. Can I get an example of how to use it? I might need a yes/no question too.

      In the $builder->setPackageAttributes function, you can set the attribute:
      'setup-options' => 'HTML code goes here',
      


      It will put whatever HTML you put there into the form - including input/textarea/selectbox tags. You don’t need the <form> tag. The form values are then passed into the resolvers.


      Also, is the license screen mandatory or is there a way to skip it during the install?
      No, it’s not mandatory. I need to make it so that it skips the page if there is no license found. That should be a bug.
        shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
        • 3749
        • 24,544 Posts
        I’ve got the form working to collect the data but can’t seem the make the script resolver work.


        Here’s the script:

        <?php
        echo "Running install-script.php";
        
        $obj = $modx->getObject('modSnippet',array('name'=>'SPForm')); // newly created snippet object
                    if (!$obj) {
                      die("SPForm snippet not found<br>");
                    }
        
                    $newRecipientArray = 'Webmaster :' . $_POST['user_email'];
                    //$newRecipientArray = 'Webmaster :' . $user_email;
                    $props = array(
        
                        array (
                            'name'=>'recipientArray',
                            'desc'=>'Recipients',
                            'type'=>'textfield',
                            'options'=>'',
                            'value'=>$newRecipientArray
                        ),
        
        
                        array(
                            'name'=>'errorsTo',
                            'desc'=>'Where to email error reports',
                            'type'=>'textfield',
                            'options'=>'',
                            'value'=>$newRecipientArray
                        )
        
                    );
        
                     if ($obj->setProperties($props, true) == false) {
                         die("Couldn't set properties");
                     }
                    if ($obj->save() == false ) {
                        die("Couldn't save properties");
                    }
        
        ?>


        The install hangs with this in the console:

        Attempting to install package with signature: SPForm-3.0.5-beta
        Package found...now preparing to install.
        Grabbing package workspace...
        Workspace environment initiated, now installing package...
        PHP notice: Undefined variable: user_email
        PHP notice: Undefined property: xPDOVehicle::$modx
        Attempting to install package with signature: SPForm-3.0.5-beta
        Package found...now preparing to install.
        Grabbing package workspace...
        Workspace environment initiated, now installing package...
        PHP notice: Undefined variable: obj
        Attempting to install package with signature: SPForm-3.0.5-beta
        Package found...now preparing to install.
        Grabbing package workspace...
        Workspace environment initiated, now installing package...
        PHP notice: Undefined property: xPDOVehicle::$modx
        Attempting to install package with signature: SPForm-3.0.5-beta
        Package found...now preparing to install.
        Grabbing package workspace...
        Workspace environment initiated, now installing package...
        PHP notice: Undefined variable: modx
        Attempting to install package with signature: SPForm-3.0.5-beta
        Package found...now preparing to install.
        Grabbing package workspace...
        Workspace environment initiated, now installing package...
        Successfully installed package SPForm-3.0.5-beta
        Attempting to install package with signature: SPForm-3.0.5-beta
        Package found...now preparing to install.
        Grabbing package workspace...
        Workspace environment initiated, now installing package...
        Successfully installed package SPForm-3.0.5-beta
        Attempting to install package with signature: SPForm-3.0.5-beta
        Package found...now preparing to install.
        Grabbing package workspace...
        Workspace environment initiated, now installing package...
        PHP notice: Undefined variable: modx
          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
          BobRay,

          I just committed a fix to SVN dealing with some bugs in the package installer, specifically with setup-options.

          Now, with regards to your script, resolver scripts handle a little differently - here’s how I handle setup-options in a test case that’s on modx-components SVN:

          With the setup-options HTML looking like this:
          <label for="snippetDescription">Snippet 1 Description:</label>
          <input type="text" name="snippetDescription" id="snippetDescription" width="300" value="The first test snippet." />
          


          And my resolver script like this:
          <?php
          $success= false;
          switch ($options[XPDO_TRANSPORT_PACKAGE_ACTION]) {
              case XPDO_TRANSPORT_ACTION_INSTALL:
              case XPDO_TRANSPORT_ACTION_UPGRADE:
                  $snippet = $object->xpdo->getObject('modSnippet',array('name' => 'TestSnippet1'));
                  if ($snippet != null) {
                      $snippet->set('description',$options['snippetDescription']);
                      $snippet->save();
                  } else {
                      $object->xpdo->log(XPDO_LOG_LEVEL_ERROR,'TestSnippet1 could not be found, so the description could not be changed.');
                  }
                  $success= true;
                  break;
              case XPDO_TRANSPORT_ACTION_UNINSTALL:
                  $success= true;
                  break;
          }
          return $success;
          


          This resolver changes the first snippet’s description based upon user input. There is obviously more practical things you could do with this, but that’s an idea.

          Now, note a few things: All your POST variables are automatically sent into the $options array, so you shouldn’t be using $_POST in a resolver.

          Secondly, note the different modes. I don’t need to be changing object properties when the object is resolving after an uninstall, so I added a simple switch statement to handle the different modes. We recommend doing this in all your resolvers.

          Thirdly, note that there is no $modx object; resolvers don’t have direct access to it, since they are acting within an object’s vehicle. Basically, if you need xPDO capabilities, use $object->xpdo. What is $object? Well, it’s the object your resolver is acting for.

          Say you attached this resolver to the modCategory vehicle. Well, then $object would be the object of that installed modCategory. Make sense?

          Warning: Be careful what you change in resolvers. If you were to change, say, the category name, you’ll have problems on uninstall, since the uninstall script will be looking for the category with the old name (the one before you changed it), via its XPDO_TRANSPORT_UNIQUE_KEY option set in the vehicle attributes. So in other words, be careful with changing structure or primary and unique keys.

          Properties, however, are great things to use this functionality with.
            shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
            • 3749
            • 24,544 Posts
            What’s the function of the target setting for script resolvers? I couldn’t figure out what to set it to.

            Here’s what I have but I was just guessing.
               resolver_type => 'php',
               resolver_source => $sources['build'] . "install-script.php", 
               resolver_target => "return '" . $sources['build'] . "';" 
              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 Nov 20, 2008, 05:48 PM

              What’s the function of the target setting for script resolvers? I couldn’t figure out what to set it to.

              You don’t need a target setting in script resolvers. A demo is like this:

              $vehicle->resolve('php',array(
                  'source' => $sources['resolvers'] . 'test.resolver.php',
              ));
              
                shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
                • 3749
                • 24,544 Posts
                Thanks. I got everything working (including setting a property from the user’s input with a script resolver grin ).

                The main reason it wasn’t working was that apparently, both resolvers had to be attached to the first snippet.

                Because I was creating the snippets in a loop and had two snippets and two resolvers (one "file" and one "php" resolver), I tried to attach the file resolver to the first snippet’s vehicle and the php resolver to the second one’s vehicle.

                The build files all looked like they should as did the manifest, but when it came to execute the php resolver during the install, the installer appeared to be trying to execute the readme.txt file and dumped it to the console before going completely haywire -- even when the php script was just: return(true); The uninstall went similarly nuts.

                As soon as I attached the php resolver to the first snippet’s vehicle as a second resolver, everything went fine.

                I’m not sure if this is a bug or a feature. smiley

                While trying to solve this, I did notice a couple of other anomalies maybe worth mentioning:

                - Every install or uninstall puts exactly three of these lines in the MODx error log regardless of what the package contains (Captcha, EZfaq, and SPForm):

                [2008-11-20 23:39:21] (ERROR @ C:\xampp\htdocs\addons\core\xpdo\transport\xpdotransport.class.php : 695) PHP warning: Invalid argument supplied for foreach()

                695 is the end of the file and it has many foreach() statements, so I couldn’t nail it down any further.


                - Firebug shows a seemingly endless stream of activity -- about two executions per second -- from ext-base.js as long as the console is open.

                That might be an event listener, but I don’t see it anywhere else in the Manager. If it’s a circular reference, though, it might be what’s crashing Apache (I’ve seen that
                in both IE7 and FF3 now, although it’s *much* more common in IE7).

                Thanks again for all the help. smiley

                SPForm is about ready for the SVN Repository. The only hitch now is the truncation after René’s name in the readme.txt file. It occurred to me that since that file is coming from outside MODx, maybe it’s being sanitized with a regex [a-z A-Z0-9] somewhere.
                  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 Nov 21, 2008, 12:51 AM

                  I’m not sure if this is a bug or a feature. smiley
                  I’d have to see the build script - sounds like a bug, but I don’t know what your build script looks like. tongue


                  - Firebug shows a seemingly endless stream of activity -- about two executions per second -- from ext-base.js as long as the console is open.
                  That might be an event listener, but I don’t see it anywhere else in the Manager.

                  That would be the MODx.Console, which is that dialog box that opens up and displays package installation info. It’s our solution to grabbing real-time information about package installs, since the install() process happens asynchronously, we needed a way to grab information as it was installing mid-process - so install() sends messages to modRegister, which logs them as file entries, and MODx.Console checks the register and grabs the entries every .5 seconds to keep an up-to-date log of what is happening.
                    shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
                    • 3749
                    • 24,544 Posts
                    Quote from: splittingred at Nov 21, 2008, 08:25 AM

                    Quote from: BobRay at Nov 21, 2008, 12:51 AM

                    I’m not sure if this is a bug or a feature.  smiley
                    I’d have to see the build script - sounds like a bug, but I don’t know what your build script looks like. tongue

                    That build script doesn’t really exist any more, but it should be fairly easy to duplicate if it’s a bug. Just take a build script with two snippets, a license, a readme, and a user input form.  Add a file resolver to the first snippet’s vehicle and a php resolver ( return(true);  will do for the code) to the second one’s resolver. Then see how the install goes.
                    (Like you have nothing better to do.)  wink
                      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
                      • 3749
                      • 24,544 Posts
                      I spoke to soon about everything working. I think this may be an actual bug. I realized that my categories weren’t being set and now, I can’t seem to get categories and the install script resolver working at the same time.

                      The category setting code is below. If I set the first line to false, the php resolver script works perfectly (but no categories). If I set it to true, I get the categories and the script executes but has no effect. I’ve verified that the script is executing and, in the script, getObject() is successful, setProperties() is successful, and save() is successful, but the properties aren’t actually changed. Is there something wrong with the way I’m setting the categories? It definitely sets the categories as it should, but somehow interferes with the script. I tried making sure there weren’t any name collisions, but it didn’t help.

                      I guess I could live without the categories, but it would be a nice convenience for the user and it really shouldn’t interfere with the php resolver.

                      If it means anything, setting the categories reverses the order in which the two snippets appear in the package and in the tree.

                      if (false) {
                      /* create categories */
                      
                      /* This sets the snippets' categories using the $snippet array  */
                      //$i++;
                      $attr = array(
                          XPDO_TRANSPORT_UNIQUE_KEY => 'category',
                          XPDO_TRANSPORT_PRESERVE_KEYS => false,
                          XPDO_TRANSPORT_UPDATE_OBJECT => true,
                          XPDO_TRANSPORT_RELATED_OBJECTS => true,
                          XPDO_TRANSPORT_RELATED_OBJECT_ATTRIBUTES => array (
                              'modSnippet' => array (
                                  XPDO_TRANSPORT_PRESERVE_KEYS => false,
                                  XPDO_TRANSPORT_UPDATE_OBJECT => true,
                                  XPDO_TRANSPORT_UNIQUE_KEY => 'name',
                              )
                          )
                      );
                      
                      $categoryObject= $modx->newObject('modCategory');
                      $categoryObject->set('category','spform-snippets');
                      //$categoryObject->set('id', $i);
                      $categoryObject->addMany($snippets,'modSnippet');
                      
                      $vehicle = $builder->createVehicle($categoryObject,$attr);
                      $builder->putVehicle($vehicle);
                      
                      /* Now we'll set the chunks' category using the $chunks array */
                      //$i++;
                      $attr = array(
                          XPDO_TRANSPORT_UNIQUE_KEY => 'category',
                          XPDO_TRANSPORT_PRESERVE_KEYS => false,
                          XPDO_TRANSPORT_UPDATE_OBJECT => true,
                          XPDO_TRANSPORT_RELATED_OBJECTS => true,
                          XPDO_TRANSPORT_RELATED_OBJECT_ATTRIBUTES => array (
                              'modChunk' => array (
                                  XPDO_TRANSPORT_PRESERVE_KEYS => false,
                                  XPDO_TRANSPORT_UPDATE_OBJECT => true,
                                  XPDO_TRANSPORT_UNIQUE_KEY => 'name',
                              )
                          )
                      );
                      
                      $categoryObject= $modx->newObject('modCategory');
                      $categoryObject->set('category','spform-chunks');
                      //$categoryObject->set('id', $i);
                      $categoryObject->addMany($chunks,'modChunk');
                      
                      $vehicle = $builder->createVehicle($categoryObject,$attr);
                      $builder->putVehicle($vehicle);
                      
                      
                      /* done setting categories */


                      [UPDATE] I’ve determined that if I leave the one snippet that’s affected by the script out of the categorization process, the php resolver script works. So it looks like it’s not creating categories that causes the problem but rather that putting a snippet in a category makes the install script unable to alter that snippet’s properties.
                        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