We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 36632
    • 202 Posts
    I guess this would be a Batcher+Provisioner Utility:

    Remove all unused Templates, TVs, Chunks and Snippets.

    How: I don't know but I thought it would be very useful to parse through various tables and assign all unused elements to a new category called `Unused`.
      • 22303 MODX Staff
      • 10,725 Posts
      While this kind of automatic garbage collection would be nice to have, you would basically have to parse every tag in the entire site as every user with special permissions on the site to determine which TV's, Chunks or Snippets were used or not. That's not really a scalable solution. But a simplified, non-thorough approach might work for very simple sites.
        • 36632
        • 202 Posts
        Could there be an Element Log to log what Elements are used vs what is not?

        Or require any Element on the Revo install to have their ID salted. When it's used the salt is removed. Then a utility could categorize salted Elements "For Removal".

        Working on someone else's Evo 2 Revo site with too many categorized elements....

        Thinking out loud here. You wrote `getResources`. How about a utility called `getElements`?

          • 22303 MODX Staff
          • 10,725 Posts
          Quote from: ultrasef at Mar 14, 2012, 10:09 AM
          Could there be an Element Log to log what Elements are used vs what is not?

          Or require any Element on the Revo install to have their ID salted. When it's used the salt is removed. Then a utility could categorize salted Elements "For Removal".
          Those are certainly possible, and good ideas. Let's collect some other folk's ideas here and create a feature request ticket for this where we can pick from the best ideas to implement.
            • 36173
            • 26 Posts
            I think this would be a huge benefit. My suggestion is to initially focus on one resource type...It's the chunks for me!

            MODx already tells you about Template dependencies-when you try to delete one that is in use it does not allow it. Simple queries for checking all or a particular chunk's existence anywhere in code for example-yes, there can be conditionals that may hide usage of a chunk, but something that could at least report on what chunks are in use/not in use. Next, check all chunks. An SQL genius could write the queries in 5 minutes.

            Implementation wise it could be similar to Template deletion, or just a query - check if this chunk is named anywhere in code.

            Next step might be a way to declare a chunk as interdependent with another. It would aid the logic / decision-making with any mass delete function.

            My $0.02.

            Peace.
              • 28042 ☆ A M B ☆
              • 24,524 Posts
              Sorry, this would not be as easy as it appears. You would have to scan all templates, all resource fields, and all chunks for chunk tags. The you would have to scan all snippets and plugins for getChunk function calls, as well as chunk tags. Snippet properties would have to be checked for chunk tpl assignments, as well as property sets and snippet tags. And I'll bet you that somebody would have some other way of accessing a chunk. So it's really not all that obvious how such a beast would work. Template assignments are easy... just run a query for all resources with a value of <template-id> in its "template" field.
                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
                • 36173
                • 26 Posts
                @susan,
                Those dependencies are understood and your answer explains in more detail the type of queries for a complete solution. If things were simple, well... wink
                Approach to be determined for sure.



                  • 28042 ☆ A M B ☆
                  • 24,524 Posts
                  What I was saying is that I'm not sure it's really feasible to cover all of the possible ways snippets and chunks can be invoked. In my opinion, good documentation during the design process would be much more effective.

                  Another example I just thought of is in the case of snippets that use config files, where the chunk tpl is specified in a file. So now your utility has to scan files for possible references to a chunk, or to PHP code that refers to or invokes a chunk in any of the myriad possible ways.
                    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
                    • 36173
                    • 26 Posts
                    @susan,
                    Understood. ...and Yes! to the documentation. I was giving this some further thought and since MODx is so flexible, the structure comes not from the CMS itself but from our build protocol (how we do things and doing them consistently every time-methods, naming conventions, file structures). It's as flexible as the good old file base webs but we can still create spaghetti for sure...

                    Good point on what you mentioned about tpl files. My stuff is pretty straightforward and the bits and pieces becoming more uniform over time--usually chunks/snippets within chunks within templates (give or take). I keep everything in the db (usually).

                    Pondering further...(and time to log off).

                    Cheers.
                      • 3749
                      • 24,544 Posts
                      Consider something like this (which is not uncommon in snippet code):


                      $tpls = array(
                          'innerTpl',
                          'outerTpl',
                          'rowTpl',
                      }
                      foreach($tpls as $tpl) {
                          $this->config[$tpl] = $modx->getChunk($tpl);
                      }


                      or this, which is even more common:

                       $tpl = $modx->getOption('rowTpl', $scriptProperties, 'componentRowTpl');
                       $this->rowTpl = $modx->getChunk($tpl);


                      The name of the chunk being used here depends on the value (if any) that the user puts in that property, which could be in the snippet tag, the snippet's default properties, an attached property set, or (in rare cases) a System Setting, Context Setting, or User Setting.

                      In fact, almost all of the getChunk() calls in a well-written extra are dynamic so that the user can pass the chunk name as a property. In all those cases, even parsing the getChunk() call would get you nothing useful, and a whole lot of chunks would be mistakenly listed as unused.

                      And, if that's not bad enough for you, the chunk may also be retrieved with getObject() or getCollection() and that call is also likely to be dynamic.

                      It's a feature that's often asked for and seems really easy, but it's a real can of worms when you try to implement it.

                      As Susan says, Templates are easier, but in rare cases, they can be used without being attached to any resource.
                        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