We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 31471
    • 206 Posts
    Well, I would like to ask about Revo’s modSession and modRequest classes. Are they for 3rd party applications, or only used in the manager?

    Jason said: "Save the POSTed data to SESSION, or if you need it to persist past the session, you could look into the modRegistry service..."

    I have to save some data from $_REQUESTs into $_SESSION variables, and maintain them across login or register events. How to establish this in Revo? Should it be done with modRegistry service, and if so, where to find documentation of it?

    Thanks in advance.
    • A $_SESSION is a $_SESSION. I will be getting into that area soon enough because some of the huge modX Evo sites I have built rely heavily on manipulating the $_SESSION, but my array sets -- now modX’s.

      http://www.shawnwilkerson.com/code/modx_revolution.html has three links showing full dumps of the $_SESSION from the perspectives of the logged-in user and the logged-in manager. Passwords have been changed and these were made into chunks to lesson the load on the system as well as remove the obvious security issues. Additionally, you can find an entire dump of the modx core in a live setting -- again sanitized.



      I have also created some snippets to demonstrate some of the
      simplicity that is in modX Revolution.

      http://www.shawnwilkerson.com/code/modx_revolution/modx_snippets/snippet_accessUserProfile.html
      a snippet which displays the profile of a logged-in user
      http://www.shawnwilkerson.com/code/modx_revolution/modx_snippets/snippet_randomImage.htmla
      snippet which displays random images either as backgrounds,
      banners, or stationary
      http://www.shawnwilkerson.com/code/modx_revolution/modx_snippets/showChunk_snippet.htmldisplays
      the content of a chunk without it being parsed
      http://www.shawnwilkerson.com/code/modx_revolution/modx_snippets/showSnippet_snippet.html
      a snippet which displays other snippets in MODx Revolution

      I seem to have broken the date filter and am investigating if it has anything to do with the beta 5 update.

      Next, I am moving on to dealing with database applications as the vast
      majority of everything I build is tied to a database which is simply
      linked the the internal key of the current user.

      Please use these to get a clearer understanding of using modX
      Revolution, but please do not hijack this thread asking questions.

      The snippets are mostly self explanatory and made very simple and straight forward for the purpose of demonstrating simple applications with modX Revolution.
        Get your copy of MODX Revolution Building the Web Your Way http://www.sanitypress.com/books/modx-revolution-building-the-web-your-way.html

        Check out my MODX || xPDO resources here: http://www.shawnwilkerson.com
        • 28215
        • 4,149 Posts
        FYI: More documentation on Permissions, and how they apply to Access Policies, has been added here:

        http://svn.modxcms.com/docs/display/revolution/Permissions

        As well as a detailed list of each of the permissions in the default policies packaged with Revo.
          shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
        • I would like to see the list of "resource fields" or "Built in Document Object Fields" in the Revolution documentation. I’m talking about the equivalent of

          * [*pagetitle*] = page title
          * [*longtitle*] = often h1 or h2
          * [*description*] = this can be a handy one to use in a meta description, RSS feeds, or with the Ditto Snippet.
          * [*introtext*] = a.k.a. Summary; also may be useful to creating RSS feeds or Ditto Snippets.
          * [*content*] = the content of the document.
          * [*id*] = the unique numerical identifier of the document.
          (I pasted that in from http://wiki.modxcms.com/index.php/Placeholders_used_by_MODx_Pages_and_Templates)

          Looking solely at the Revo documentation, I don’t know how anyone would be able to make any useful templates without access to this information. The Templates page does refer to the [[*content]] tag, but not in a very clear way in my opinion.

          -does the list above carry over exactly from Evo to Revo (other than tag syntax?
          -It seems a bit unclear everywhere (not just in the Revo documenation) just exactly what these things *are*, and what they are officially called? How do they differ from user-created TVs? (Important to know since the tag syntax is the same.) It would be great to see an explanation somewhere.

            • 3749
            • 24,544 Posts
            Quote from: jrotering at Feb 02, 2010, 09:30 PM

            I would like to see the list of "resource fields" or "Built in Document Object Fields" in the Revolution documentation. I’m talking about the equivalent of

            * [*pagetitle*] = page title
            * [*longtitle*] = often h1 or h2
            * [*description*] = this can be a handy one to use in a meta description, RSS feeds, or with the Ditto Snippet.
            * [*introtext*] = a.k.a. Summary; also may be useful to creating RSS feeds or Ditto Snippets.
            * [*content*] = the content of the document.
            * [*id*] = the unique numerical identifier of the document.
            (I pasted that in from http://wiki.modxcms.com/index.php/Placeholders_used_by_MODx_Pages_and_Templates)

            Looking solely at the Revo documentation, I don’t know how anyone would be able to make any useful templates without access to this information. The Templates page does refer to the [[*content]] tag, but not in a very clear way in my opinion.

            -does the list above carry over exactly from Evo to Revo (other than tag syntax?
            -It seems a bit unclear everywhere (not just in the Revo documenation) just exactly what these things *are*, and what they are officially called? How do they differ from user-created TVs? (Important to know since the tag syntax is the same.) It would be great to see an explanation somewhere.

            They’re called "Resource Fields" (formerly "document attributes") and they include any TVs you create. Most are the same as in Evolution.

            There’s a fairly full list near the bottom of this page: http://bobsguides.com/revolution-objects.html. smiley
              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: jrotering at Feb 02, 2010, 09:30 PM

              I would like to see the list of "resource fields" or "Built in Document Object Fields" in the Revolution documentation.
              Definitely.


              -does the list above carry over exactly from Evo to Revo (other than tag syntax?
              Yes.


              -It seems a bit unclear everywhere (not just in the Revo documenation) just exactly what these things *are*, and what they are officially called? How do they differ from user-created TVs? (Important to know since the tag syntax is the same.) It would be great to see an explanation somewhere.
              We call them Resource Fields, but that needs to be shored up in the docs, for sure.
                shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
                • 18654
                • 191 Posts
                Quote from: Crates at Nov 09, 2009, 03:24 PM

                So, does that mean that I need to refactor all of my code into their own classes and a similar directory structure, with resolvers, and vehicles, and assets, and documentation and all that jazz-- in order to submit the snippets, lexicon and chunks that I’ve already written from within MODx?
                Quote from: splittingred at Nov 09, 2009, 03:44 PM

                No, that’s just an example. That tutorial even explicitly states:
                I’m working through trying to learn transport packages now, and even though the tutorial specifically states that you can do things other ways, I’ve always found it easiest to learn when the samples that are given use the bare minimum requirements for a starting point. Jquery tools does a great job of this on their website. Every "tool" has a dedicated page with minimal setup. More complex options are also explained also, but at least there is a clear baseline established as far as what the bare minimum requirements are.

                I think it’s great to have the more advanced examples, I just wish that the package tutorial would start simple and then add complexity. For example, maybe the first sample could show the bare minimum setup to create a package that can transport a single template. Then, from there another tutorial that includes resources, snippets, css / javascript files, etc. - gradually increasing the complexity.

                Also, it’s not clear in the various code samples which documents the code belongs to. Is it all one script in one file? Are all the scripts in different files / folders? I’ve noticed that Zend Framework does this alot in their documentation as well - they show code snippets but it’s not always clear where the snippets fit in the overall scheme of things.

                Another thing I don’t understand is that when I compare the file structure in the tutorial and with the actual transport package (quip-0.1-beta4.transport.zip) they don’t seem to match. What I see in the actual transport package are things like "modCategory" "modLexiconLanguage" etc. I’m confused about where the "assets > components > quip" and "core > components > quip" directories are supposed to go.

                Learning transport packages is really high on my list of important things to learn right now both for backup purposes and also because I’m working with two different ministries that have constantly expanding chapters, each needing a website.

                Any help, suggestions, or direction to other resources would be appreciated.

                -matt
                  God does not save those who are only imaginary sinners. Be a sinner, and let your sins be strong, but let your trust in Christ be stronger, and rejoice in Christ who is the victor over sin, death, and the world.
                  • 3749
                  • 24,544 Posts
                  matt,

                  Transport packages are confusing at first, but eventually they do make sense to you. The docs can always use improvement (and your suggestion is a good one) but improving them is always further down the list than fixing known bugs in MODx and its add-ons. wink

                  This is a sample build script template from the SVN component repository. If you ignore (or remove) all the sections marked "optional" you can see the minimum transport script to package a single snippet (or other element). The timing and log parts are also optional. This might not be completely up-to-date, but I think it is. Ask if you run into trouble.

                  As for the files, their location is arbitrary on the package-creation side as long as you specify their locations correctly. The "sources" array here shows typical locations for them.

                  If you are transferring actual files in a resolver, they go where you send them in the "target" specification. Files that need to be accessible via URL (e.g. image files) should go somewhere in or under assets/components/component_name/. Files that don’t need to be accessed via URL (e.g. class files used by a snippet) should go in or under core/components/component_name/ where they can be more secure.

                  <?php
                  /**
                   * Component Template
                   *
                   * @package component-template
                   * @version 1.0.2
                   * @release beta
                   * @author Test <[email protected]>
                   */
                  $mtime = microtime();
                  $mtime = explode(" ", $mtime);
                  $mtime = $mtime[1] + $mtime[0];
                  $tstart = $mtime;
                  /* Get rid of time limit. */
                  set_time_limit(0);
                  
                  /* Set directories for source files. */
                  $root = dirname(dirname(__FILE__)) . '/';
                  $sources= array (
                      'root' => $root,
                      'build' => $root . '_build/',
                      'lexicon' => $root . '_build/lexicon/',
                      'assets' => $root . 'assets/',
                      'docs' => $root . '_build/docs/'
                  );
                  unset($root);
                  
                  /* Override with your own defines here (see build.config.sample.php). */
                  require_once $sources['build'].'build.config.php';
                  
                  /* The following four lines aren't necessary if you run this as a snippet inside MODx. */
                  require_once MODX_CORE_PATH . 'model/modx/modx.class.php';
                  
                  $modx= new modX();
                  $modx->initialize('mgr');
                  $modx->setLogLevel(modX::LOG_LEVEL_INFO);
                  $modx->setLogTarget('ECHO');
                  
                  /* Set Package Name  */
                  $name = 'component-template';
                  $version = '1.0.2';
                  $release = 'beta';
                  
                  /* Load the Package Builder and create the package */
                  $modx->loadClass('transport.modPackageBuilder','',false, true);
                  $builder = new modPackageBuilder($modx);
                  $builder->createPackage($name, $version, $release);
                  $builder->registerNamespace('component-template',false,true);
                  
                  
                  /* get the source from the actual snippet in your database
                   * with $modx->getObject('modsnippet',array('name'=>'SnippetName'));
                   * OR
                   * manually create the object, grabbing the source from a file
                   * as we do here: */
                  
                  $c= $modx->newObject('modSnippet');
                  $c->set('name', $name);
                  $c->set('description', "<strong>{$version}-{$release}</strong> {$name} for MODx Revolution");
                  $c->set('category', 0);
                  $c->set('snippet', file_get_contents($sources['assets'] . 'snippet.component-source.php'));
                  
                  /* Create a transport vehicle for the data object */
                  $attributes= array(xPDOTransport::UNIQUE_KEY => 'name');
                  $vehicle = $builder->createVehicle($c, $attributes);
                  
                  
                  /* The sections marked optional should be commented out or removed if you don't need them */
                  
                  /* (optional) Add a validator that will transfer files at the beginning of the install.
                   * If the files are not transferred successfully, the install will abort */
                  $vehicle->validate('file',array(
                      'source' => $sources['docs'],
                      'target' => "return MODX_ASSETS_PATH . 'components/component-template/';",
                  ));
                  
                  /* (optional) Add a php script that will execute at the beginning of the install.
                   *  Must return true or the install will abort */
                  $vehicle->validate('php',array(
                              'type' => 'php',
                              'source' => 'preinstall-script.php'
                          ));
                  
                  /* (optional) Add a resolver to transfer files at the end of the install.
                   * This example will transfer the assets/component-template directory
                   *  and all its files to core/components/
                   */
                  $vehicle->resolve('file',array(
                      'source' => $sources['assets'] . 'component-template',
                      'target' => "return MODX_CORE_PATH . 'components/';",
                  ));
                  
                  /* (optional) Add a php script that will execute at the end of the install
                   *  Should return true on success.
                   *
                   *  It can use all HTML input variables defined in the user_input.html file
                   *  added in setPackageAttributes() below.
                   */
                  $vehicle->resolve('php',array(
                              'type' => 'php',
                              'source' => 'install-script.php'
                          ));
                  
                  /* (required) Add Vehicle to Package */
                  
                  $builder->putVehicle($vehicle);
                  
                  /*  (optional) Load lexicon strings */
                  $builder->buildLexicon($sources['lexicon']);
                  
                  /* (optional) Include readme, license, and/or an html file that interacts with the user during the install.
                   * Each array member is optional but you should always include a readme.txt file.
                   */
                  $builder->setPackageAttributes(array(
                      'readme' => file_get_contents($sources['docs'] . 'readme.txt'),
                      'license' => file_get_contents($sources['docs'] . 'license.txt'),
                      'setup-options' => file_get_contents($sources['build'] . 'user-input.html')
                  ));
                  
                  /*  zip up the package */
                  $builder->pack();
                  
                  $mtime= microtime();
                  $mtime= explode(" ", $mtime);
                  $mtime= $mtime[1] + $mtime[0];
                  $tend= $mtime;
                  $totalTime= ($tend - $tstart);
                  $totalTime= sprintf("%2.4f s", $totalTime);
                  
                  $modx->log(modX::LOG_LEVEL_INFO, "Package Built Successfully.");
                  $modx->log(modX::LOG_LEVEL_INFO, "Execution time: {$totalTime}");
                  exit();
                  
                  
                    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
                    • 18654
                    • 191 Posts
                    Got it! (Or at least I’m starting to get it). I think the biggest source of confusion for me was that I thought I was supposed to manually create the file structure first and then fill in all the directories with the necessary code. With that mindset, I was looking at files with names like "62a52da0dff29bde6731051f681cb109.vehicle" and trying to figure out what kind of super-complex naming-conventions had to be followed in order to correctly create a package. Now I see that those long-random-looking file names are auto-generated as the result of the initial script and that likewise the directory structure itself is created as a result of the script.

                    I’ll probably run into some more challenges along the way, but that was a huge help in getting past the initial roadblock of not understanding what the heck was going on with all those long file names and complex directory structures.

                    Thanks!

                    -matt
                      God does not save those who are only imaginary sinners. Be a sinner, and let your sins be strong, but let your trust in Christ be stronger, and rejoice in Christ who is the victor over sin, death, and the world.
                      • 3749
                      • 24,544 Posts
                      Glad I could help. smiley
                        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