We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
  • Sometimes when working with a lot of snippets, I hate having to go back and forth to the manager from my IDE to cut and paste changes back and forth. A technique I’ve adopted for dealing with this is to include the code for my snippets from an external file. This has the added benefit of reducing the amount of content being kept in memory by the parser for every request to your site, by simply reducing the amount of actual snippet content. And in future releases, all snippets will actually become external files included only as needed by the parser.

    So, here’s an example of including snippets this way:

    [*] Create a directory for your snippets (i.e. identify a location where you will keep your snippet code). I typically define snippet directories for specific projects or groups of snippets, e.g. /assets/snippets/myproject/
    [*] Use a simple naming convention to easily identify your snippet files, e.g. /assets/snippets/myproject/MySnippet.snippet.php, where MySnippet is the actual name of your snippet.
    [*] Copy your snippet code into the file (don’t forget to add the php tags <?php ?>)
    [*] Create your snippet (or edit an existing one you want to convert to use this method) in the manager, e.g. MySnippet, with the following code:
    return include_once($modx->config['base_path'] . 'assets/snippets/myproject/MySnippet.snippet.php');

    Please note that this assumes your snippet is returning content (e.g. return $content;) -- you may want to leave out the return and have your included code echo the content, depending on your requirements; otherwise, the include will return a true/false response in your content. Or you can just add return ’’; at the end of your snippet.

    Also note you may need to do an include vs. include_once, depending on what your code does.

    Once setup, you can now edit the snippet file( s ) and see changes instantly (or edit locally and upload via FTP to see changes on a remote site).
      • 15987
      • 786 Posts
      That is a great tip. That will definatly save some time copying and pasting in and out of the manager smiley
      • Just keep in mind, gentle people, that accessing the file system is the most "expensive" thing you can do, and if you’re on a busy shared host with hundreds of sites all accessing the hard drives at the same time, it will be even worse. I haven’t done any test on this, but I suspect that in some cases it will noticeably increase the time it takes to parse a page; it will certainly more than double the time and server resources that it takes to process a given snippet. If it’s only for convenience, it might be good to consider if the tradeoff is worth it.
          Studying MODX in the desert - http://sottwell.com
          Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
          Join the Slack Community - http://modx.org
        • Quote from: sottwell at Jun 25, 2006, 04:01 AM

          Just keep in mind, gentle people, that accessing the file system is the most "expensive" thing you can do, and if you’re on a busy shared host with hundreds of sites all accessing the hard drives at the same time, it will be even worse. I haven’t done any test on this, but I suspect that in some cases it will noticeably increase the time it takes to parse a page; it will certainly more than double the time and server resources that it takes to process a given snippet. If it’s only for convenience, it might be good to consider if the tradeoff is worth it.

          Sorry, I don’t believe you are correct on this one Susan. Accessing the file system is not the most expensive thing you can do; generally accessing the DB is, as db resources, when in use, degrade much more quickly than accesses to the file system. It’s always a constant balance between db, memory footprint, and code/content size. Eval’ing is the only real bottleneck here. I’ve tested it both ways, and in general, the include method is running faster. This is because of very large snippets with lots of code, resulting in very large includes already, and eating up memory on every MODx request can consume more cycles and slow down the server much more significantly than a typical snippet include ever will.
            • 6726
            • 7,075 Posts
            I’m bookmarking this and will definitely try it out, thanks Jason !
              .: COO - Commerce Guys - Community Driven Innovation :.


              MODx est l&#39;outil id
            • Before Susan hates me for my response, I just want to add that I will be benchmarking and profiling this thoroughly very soon so we can see the actual time and resource usage for both methods.
              • Always glad to learn something new! I’m a bit too fuzzy on exactly how MODx handles snippets to be in any position to put in my $.02, anyway embarrassed
                  Studying MODX in the desert - http://sottwell.com
                  Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
                  Join the Slack Community - http://modx.org
                  • 34162
                  • 1 Posts
                  Can this very helpful method also be applied to plugins and modules?
                  • Can this very helpful method also be applied to plugins and modules?
                    Yes it can smiley
                      Garry Nutting
                      Senior Developer
                      MODX, LLC

                      Email: [email protected]
                      Twitter: @garryn
                      Web: modx.com