We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 28150
    • 155 Posts
    Instead of posting on the public forum for all the world to see, wouldn't it be a nice idea to start a thread for the developers to post what hopes and dreams they have for our product's future?
      • 28150
      • 155 Posts
      I think it's already planned, but I think Versioning would be a great thing to implement. I can forsee it just starting out as a simple var counter that tells you how many times a particular record has been edited...then possibly growing into a full blown rollback system.

      Heh, you add the same feature to file upload management with a front end for web users to add/delete/create folders/files...you've got yourself a more kickass version of Sharepoint laugh
        • 22303 MODX Staff
        • 10,725 Posts
        I think it's already planned, but I think Versioning would be a great thing to implement. I can forsee it just starting out as a simple var counter that tells you how many times a particular record has been edited...then possibly growing into a full blown rollback system.

        Heh, you add the same feature to file upload management with a front end for web users to add/delete/create folders/files...you've got yourself a more kickass version of Sharepoint laugh

        We also need to consider WebDAV in this regard, an always overlooked, but promising protocol for content authoring on the web, and it includes versioning. If we could develop this correctly, we could allow the use of FrontPage, Dreamweaver and other WebDAV enabled clients to publish directly to the MODx repository.
          • 34162
          • 1 Posts

          We also need to consider WebDAV in this regard, an always overlooked, but promising protocol for content authoring on the web

          I think it is overlooked because it's a pain in the rear to implement compared to the benefits that you receive from it, at least with Apache 1.3.x :lol:

          Plus in shared hosting environments not a lot of people can convince their provider to compile Expat and mod_dav just for them.

          I personally won't run WebDAV on any production server because it opens up too many security/performance issues. Between no enforcable quotas and XML payloads that can consume all the server's memory, there are enough scary things associated with WebDAV that most providers won't go near it.

          The tech behind it is cool and I've used it internally quite a bit but, like I said, would never use it on a production server that has clients.

          Others experience may differ greatly from my own.
            • 28150
            • 155 Posts
            I tend to agree insofar as that webDAV is great for dorks like us but it seems almost useless to the general site manager using Etomite. 99% of the anticipated usage for the product tends to surround creating/managing content, not code.
              • 22303 MODX Staff
              • 10,725 Posts
              I tend to agree insofar as that webDAV is great for dorks like us but it seems almost useless to the general site manager using Etomite. 99% of the anticipated usage for the product tends to surround creating/managing content, not code.

              Perhaps, though if you notice, much of the open source world is moving from CVS to the WebDAV-enabled Subversion for source code repositories. I agree this should be long-term thought, but since we were talking about wishes...

              I'd just love to be able to code my snippet in dreamweaver and upload it directly to the server without cutting and pasting crap into the manager UI. Perhaps there are other ways to accomplish this without WebDAV support?
                • 34162
                • 1 Posts
                I still say we need a proper module/plugin/whatever you want to call it that allows snippets, along with supporting UI templates, to be loaded from a directory on the filesystem, ala Mambo, the Nukes, and pretty much any other thing you want to shake a stick at.

                If you had that in place then, sure, you could do exactly what you are asking-- just publish it via FTP. smiley
                  • 28150
                  • 155 Posts
                  Actually I like where Jason is going with that. Either or, I think we want to go with a fairly openly accepted standard, considering that we are still developing for PHP4 because it is more global than 5 at this time.

                  That being said, I think it would be a supremely great idea if we removed all of the different type of snippets/chunks/plugins and had one universal interface that had a dropdown:

                  This is PHP code that I want to add to my pages by typing [[droplet]]
                  This is just HTML code that I want to add to my pages by typing [*droplet*]
                  This is a small program that will add funtionality to ShoeHorn.

                  Something like this?
                    • 34162
                    • 1 Posts
                    That being said, I think it would be a supremely great idea if we removed all of the different type of snippets/chunks/plugins and had one universal interface that had a dropdown:

                    This is PHP code that I want to add to my pages by typing [[droplet]]
                    This is just HTML code that I want to add to my pages by typing [*droplet*]
                    This is a small program that will add funtionality to ShoeHorn.

                    Something like this?

                    I'm speaking more of the actual code itself. From a performance and optimization view point, storing all this code in the DB and then parsing it out (especially with the overhead of encoding and evals()) is a *horrendously* bad design.

                    While I'm not saying we need to scrap it, because it does serve a purpose, we need to think a bit about these 100+ line scripts being handled this way. There needs to be some way to do this more efficiently, i.e., store them on the filesystem, but still use them just like any other piece of code in the system.

                    Does that help illustrate better?
                      • 28150
                      • 155 Posts
                      One thing that I have noticed is that most hacks for OS software are only regarded as third-party.

                      Does anyone think that it would be a decent idea to not only welcome hacks into the software, but also to offer on a limited basis the ability to incorporate the most popular/useful hacks into the base install after a thorough code optimization?

                      Does this even make sense?