We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 21946
    • 283 Posts
    @lossendae
    Ok i will try this code.
    But it seems to work only if this is your OWN snippet, is it possible to to the same thing when i override a chunk from an existing snippet ? Let’s say i want to override the default tpl from quip, the normal way is to create a chunk via UI to set my own html (and call it in the snippet call). Do you know a way to put those chunks in file too ?
      [url=http://www.savepoint.fr/index.php?id=38] -petits tuyaux pour les d
    • Unfortunately no.

      It would not be hard to implement facilities for files based chunks, but most of the components available use file based chunks only for the default chunks.

      Generally speaking, i like to use similar function as above + an helper theme path.
      When that is done, i can use de default chunks name, separated by directories (theme).

      Like :
      assets/templates/mytemplate/getresourceschunks/ and the get resources chunks in here
      assets/templates/mytemplate/quipchunks/ and the quip chunks in here

      It would be nice to have similar functionalities in all majors snippets by default.
      But i think it’s a too light implementation for now, since it impose some directory structure and that is not the leimotiv of many MODxers.
      I think that some imposed structures can sometimes help, and would allow quicker implementations of snippets with chunks without having to learn each snippets of doing things.
        • 21946
        • 283 Posts
        It would be possible to do this without impose a directory structure, just looking recursively in the template directory (here "my template") or a given path for a file chunk matching the name of the requested chunk. (well, we get closer from drupal way here...)

          [url=http://www.savepoint.fr/index.php?id=38] -petits tuyaux pour les d
        • It will eventually be addressed in the core in a way that offers a smooth migration path and that fits with the long term vision. It’s not on the immediate priority list, thought. There are workarounds even if they’re admittedly inconvenient.

          I suppose an improvement would be to create a plugin that automatically inserts an include statement into the text area whenever you create a new chunk/template/plugin, and stubs out a file on the filesystem in your preferred location. You could even have the same plugin hide the textarea itself and so it would appear as if the you were just loading the metadata.

          You could then take it a step further and create a custom component that looked in your "Elements filesystem location" for files ending in .chunk.inc, .template.inc and so on, built a grid with any it found, and allowed you to "register" those filesystem based Elements into your MODx deployment. Again, not ideal, but definitely a decent workaround.

          At least with MODx you can come up with creative methods that work to emulate other ways, without breaking the system or requiring custom hacks.
            Ryan Thrash, MODX Co-Founder
            Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
            • 21946
            • 283 Posts
            Sounds interesting.

            edit :i deleted what was written about a snippet to do that, just understood that i need a plugin as ryan says.
              [url=http://www.savepoint.fr/index.php?id=38] -petits tuyaux pour les d
              • 28215
              • 4,149 Posts
              "Static Elements", or file-based elements, is currently slated for Revolution 2.2: http://rtfm.modx.com/display/revolution20/Roadmap
                shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com