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
    Has anyone tried building a package with more than one snippet and/or more than one chunk in it? I’ve been trying all day to make it work.

    I’ve probably making some simple mistake, but when I do it, only the last snippet and the last chunk make it into the package, and the properties I set for the first snippet get attached to the last one. The lexicon entries come through fine as do the readme.txt and license.txt.

    SPForm has two snippets and four chunks. I’m building it with this code. The appropriate values are set in a multidimensional array $objectArray and each vehicle is built and added to the package in a loop. I know the values are ok because the echo statements look fine. The build code runs fine with no errors or warnings. Here’s the loop that does the work:

    foreach($objectArray as $object) {
        if (!file_exists($object['source_file'])) {
            $modx->log(MODX_LOG_LEVEL_FATAL,"<b>Error</b> - Element source file not found: {$object['source_file']}<br />");
        }
        $modx->log(MODX_LOG_LEVEL_INFO,"Creating element from source file: {$object['source_file']}<br />");
    
        // get the source from the actual element in your database OR
        // manually create the object, grabbing the source from a file
        echo "   Creating newObject of type ". $object['object_type'] . "\n";
        $c= $modx->newObject($object['object_type']);
    
        echo "   Setting name to " . $object['name'] . "\n";
        $c->set('name', $object['name']);
    
        echo "   Setting description to " . $object['description'] . "\n";
        $c->set('description', $object['description']);
    
        echo "   Setting category to " . $object['category'] . "\n";
        $c->set('category', $object['category']);
    
        echo "   Setting " . $object['type'] . " from " . $object['source_file'] . "\n";
        //$c->set($object['type'], file_get_contents($object['source_file']));
        $c->setContent(file_get_contents($object['source_file']));
    
        if($object['props_file'] != "") {   // set the properties if there are any
            require_once($object['props_file']);
            $c->setProperties($spformProperties, true);  // merge with current properties
        }
    
        // create a transport vehicle for the data object
        $attributes= array(
            XPDO_TRANSPORT_UNIQUE_KEY => 'name',
            XPDO_TRANSPORT_UPDATE_OBJECT => true,
    
        );
        $vehicle = $builder->createVehicle($c, $attributes);
    
        if ($object['resolver_source'] != "") {    // create a resolver if one is specified
            $modx->log(MODX_LOG_LEVEL_INFO,"Creating Resolver<br />");
    
            if (!is_dir($object['resolver_source'])) {
                $modx->log(MODX_LOG_LEVEL_FATAL,"<b>Error</b> - Resolver source directory not found: {$object['resolver_source']}<br />");
            }
            $modx->log(MODX_LOG_LEVEL_INFO,"Source: {$object['resolver_source']}<br />");
            $modx->log(MODX_LOG_LEVEL_INFO,"Target: {$object['resolver_target']}<br /><br />");
    
            $vehicle->resolve('file',array(
                'source' => $object['resolver_source'],
                'target' => $object['resolver_target'],
            ));
        }
        $builder->putVehicle($vehicle);
    
        unset($c);
    }


    Here’s the console output from the install. Note that there’s only one snippet and one chunk referred to and no errors or warnings. Uninstall goes smoothly as well.

    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...
    Object for class modNamespace not found using criteria Array
    (
        [name] => spform
    )
    
    Object for class modSnippet not found using criteria Array
    (
        [name] => SPFResponse
    )
    
    Object for class modChunk not found using criteria Array
    (
        [name] => spfresponseTpl
    )
    
    Object for class modLexiconTopic not found using criteria Array
    (
        [name] => default
        [namespace] => spform
    )
    
    Object for class modLexiconEntry not found using criteria Array
    (
        [name] => hidden-last-name
        [topic] => 44
        [namespace] => spform
        [language] => en
    )
    
    Object for class modLexiconEntry not found using criteria Array
    (
        [name] => send-to
        [topic] => 44
        [namespace] => spform
        [language] => en
    )
    
    ... more of the same (lexicon entry stuff).
    
    
    Object for class modLexiconLanguage not found using criteria Array
    (
        [name] => en
    )
    
    
    Successfully installed package SPForm-3.0.5-beta



    Any idea what I’m doing wrong?

      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
      Ok, this is really getting strange.

      I went to another MODx installation and upgraded it to r4414, did a build and an upgrade install.

      I installed the same package I’ve been having trouble with and both snippets and all four chunks were installed. Both snippets got the properties from the first snippet, but otherwise, everything was perfect. Then I uninstalled and reinstalled the same package. Back to one snippet and one chunk (confirmed in the DB).

      I thought it might have something to do with an incomplete uninstall but I uninstalled again and found no trace of the package in the DB. Then I cleared the cache and my browser cache, did another upgrade install and tried again. One snippet, one chunk. No matter what I do, I can’t duplicate the success I had on the first install after the upgrade.

      Somebody just shoot me and put me out of my misery. wink

      [Update] I thought the foreach() loop might be causing trouble so I started over and created a traditional build script with no loop that creates each element in sequence and got the same result. I put this up on Jira as [$MODX-491]. If I have just one snippet and one chunk using the same script, everything works perfectly.
        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
        BobRay:

        Vehicles in a package are identified by an md5 hash of the classname + _ + the native key string. If you create a package with four objects, all of the same class, that do not have unique primary key values, each vehicle will attempt to store it’s payload in the same file and directory location.

        For now, you can get around this by simply making sure every vehicle object has a unique and valid primary key, even if that key is arbitrary.

        After discussing with Shaun, I’m going to modify this so that each vehicle is identified by a random guid instead of the primary key string, which will allow you to create objects without unique primary keys (i.e. new objects without arbitrary primary keys assigned) in your scripts. This will mean that all packages will have to be rebuilt once we introduce this change, but I believe the change is worth it.
          • 3749
          • 24,544 Posts
          Thanks. I guess I couldn’t have known that, so I feel better. It took me less than a minute to pop an index into my loop and use it to set the id.



          As for altering the process, I wonder if it wouldn’t be less disruptive to just put code setting the id into the example build script and have Package Builder throw an error if the user tries to use a duplicate id or if there’s a filename collision (assuming that’s possible)?


            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 Nov 13, 2008, 03:56 PM

            As for altering the process, I wonder if it wouldn’t be less disruptive to just put code setting the id into the example build script and have Package Builder throw an error if the user tries to use a duplicate id or if there’s a filename collision (assuming that’s possible)?
            I do agree it will be a bit disruptive, and that validation on the package builder side should be added, but I’d rather go ahead and make this change now, while in alpha, because it actually solves some other issues (like not handling primary key values that contain a ’-’, since I was concatenating compound primary keys using ’-’).
              • 3749
              • 24,544 Posts
              Will the id’s I’m using now need to be removed? Would they be ignored by the new code? Or used instead of the new random guid?
                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 Nov 14, 2008, 11:41 AM

                Will the id’s I’m using now need to be removed? Would they be ignored by the new code? Or used instead of the new random guid?
                Actually, nothing will change with existing transports; nothing will have to be rebuilt for this after all. The primary key string was simply used to help generate the name representing a vehicle on the file-system. Once the transport is built, the file name is determined and stored in the manifest. Working with an existing transport (i.e. install(), uninstall(), etc.) is not affected in any way by how these vehicle identifiers are constructed.

                So, I retract my previous statement; it will not be disruptive at all.