We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 24900
    • 44 Posts
    The time is now to create a plugin/extension/module whatever, for MODX to be able to read and compile the popular precompiler languages out there. HAML/SASS/LESS/ETC

    I use http://fireapp.handlino.com/ on my machine to watch my coda folder and compile the SASS but when you move to start templating in MODX I lose the SASS.

    Key Features of the Extension:

    • Choose Language
    • Choose Folder to Watch
    • Choose when/where to compile

    What do you think?
      • 38290
      • 712 Posts
      I don't understand what you mean by when you start templating in MODX you loose the Sass. Are you saying there is no way to compile the Sass on the server, and work directly on the server rather than work locally and upload pre-processed CSS?
        jpdevries
        • 24900
        • 44 Posts
        oh ya I should've specified. I usually setup the frameworks, and my team fills in the content gaps. When something majorly structural is needed I may have to go back in, and that could be from home, work, road, so if everything was compiled in MODX we'd all be on the same docs.
          • 38290
          • 712 Posts
          I can see that there are advantages to compiling and processing assets on the server. The MODX Manager itself has never been a very happy place to edit code. 2.3 may bring some improvements there 3.0 definitely should.

          I'm seeing a lot of teams switch to a combination of grunt and a few other free tools like bower to manage things like Sass, combining and minifying JavaScript, and versioning and fetching all the mixins and third party plugins being used in a project, and even uploading files over SFTP when updated. All this done on the client side.

          While I think CSS and JS should generally be handled client side, I would like to see a Sass Content Type added to MODX. In conjunction with Static Resources, it could make a good workflow for some.
            jpdevries
            • 24900
            • 44 Posts
            Those type of people are not in the marketing world when all we need to change is the look of a slogan or the size of CTA for a new campaign. Recompiling using grunt is a major waste of resources for my team and my company.

            When you've got a copywriter, a junior designer, a seo guy, and someone like me all contributing to the same MODX site happiness isn't an option, efficiency is. Coding in MODX with the ACE extension is great, but I'm not talking about building a site inside MODX manager.

              • 38290
              • 712 Posts
              Sounds like a Sass Content Type could potentially solve this. As far as choosing a language, I'm torn between if one package should do multiple languages, or if separate packages should handle each.

              Since it's something that would be server side, rather than actually watching files it would probably need to consist of evoking things based off plugin events like when Sass documents are saved.

              This is not to say I'm working on such a thing, so anyone reading this please build it and share.
                jpdevries