On March 26, 2019 we launched new MODX Forums. Please join us at the new MODX Community Forums.
Subscribe: RSS
  • There’s an article in the documentation that includes this sentence:
    MODx, however, stores its data in the database. This has many benefits generally, but DB-stored code cannot be version-controlled via SVN.
    I’m honestly boggled about the supposed benefits of storing files in the database as opposed to the file-system. I might be just too dim, but the only pro for this design I can see is not needing to have write permissions set to be able to edit a file from the manager. Then there are a myriad of cons, of which not being able to use version control is just one. In my experience, when I need to work with a lot of chunks, templates and snippets, it gets inconvenient fast. I try to open each resource in a separate tab and then end up having to click on these tabs blindly because they’re all named the same. Having to work with several MODx sites confounds this. I try to keep the tabs for each site in a separate browser window, but I still end up confusing them and editing the wrong site. I can’t save the files just by pressing Ctrl+S and need to use the mouse. Then there’s the editor that’s just a plain text-box. There’s no syntax highlighting, and when I eventually miss a comma or a semicolon somewhere, it can’t even tell me the precise line and I have to paste the code in my IDE or parse it manually. I know Revo is supposed to have CodeMirror implemented, but I’m forced to use Evo. It’s also common sense that querying the DB means more performance overhead than getting files from the FS. So, what gives? I’m sorry if I sound too ranty, but I keep being bitten by this feature.

    To maybe make this more positive, I like how Revo combines the document and resource navigation into the sidebar, and how it doesn’t use frames. I also hope that the CSRF protection is improved, because it keeps giving false positives in Evo.
    • Searching, sorting, organizing and editing as well as establishing relationships between elements is much quicker using a database (which, when you get right down to it, is nothing more than a managed set of files).

      Your issues can be resolved to a large extent by using a simple include snippet for everything, then you have your actual content in files, with what is largely metadata in the database. http://sottwell.com/working-snippets.html

      If you use Firefox, you can install its "It’s All Text" add-on and use the editor of your choice. There are also plugins to allow the use of hotkeys for saving.

      Getting sites confused? I hate to sound heartless, but I’ve learned to slow down a bit and pay attention to what I’m doing. It saves time and grief in the long run. I read somewhere that doctors, before administering medication, are supposed to read the label three times to make sure it’s the right medication and they’re using the correct dosage. A good practice to incorporate into almost any endeavor.
        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
      • Searching, sorting, organizing and editing as well as establishing relationships between elements is much quicker using a database …
        Thanks for your answer, but what you’re saying only applies to interacting with elements programmatically and just the opposite is true for regular development. That’s why the rest of your post is a list of workarounds that would make my browser a bit more like my IDE.
        • but what you’re saying only applies to interacting with elements programmatically
          Exactly. And that is precisely what the MODx parser has to do with every page request.
            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
          • Personally I would never work on multiple sites from multiple tabs within the same browser window, for the very reason why you find yourself making mistakes.

            Filesystem vs. database storage is pretty much a no-brainer for me. I don’t know how you perceive the myriad of cons, but here’s a few big pros:

            scalability - it’s far simpler to update database records than a directory of flat files
            performance - Mysql is *arguably* faster than flat files in retrieving data
            concurrency - synchronizing record updates across database records is a cinch vs flat files.
            security - Mysql (and Modx) provide fine-grained access control for CRUD operations. Try that with flat files.

            If your primary beef is syntax highlighting and code formatting, just do like Susan suggests and write simple includes within your snippets. That’s the recommended approach when developing snippets anyways, as it is much more efficient to FTP your scripts to your server than continually refresh the browser when making code changes.
              lo9on.com

              MODx Evolution/Revolution | Remote Desktop Training | Development
            • @sottwell: Thanks, maybe I’ve been hasty in criticizing database storage, but somehow what you say about performance still seems counter-intuitive. I’ve always lived with the assumption that when you care about performance enough to want your files cached in memory, you use a ramdisk or something similar and avoid the overhead involved in a database query and the general hassle of being locked to a single tool to edit the files (MODx) because all the other ones like phpMySql or a MySQL shell are not suitable. This is opposed to FTP which has universal support in real development environments.

              You could improve the situation by supporting WebDAV. This would still allow you to act like control freaks and not trust the file-system to do anything, but WebDAV can also be mounted as a file-system allowing developers like me to use a real IDE not a surrogate that doesn’t even allow you to mass search elements.

              You don’t need a database for security. The element files shouldn’t even be writable in the production environment anyway. With a database, an SQL injection vulnerability in your PHP code would mean an attacker could usually write to any part of it, even on production. The file-system permissions, on the other hand, don’t rely on your code being secure.

              The idea of making includes only while developing makes the whole idea of includes better, but I still don’t like it. Making an include for each and every element and then removing it before sending to production would be too cumbersome and error-prone due to increasing complexity (although @sottwell would probably prefer to blame my lack of focus). Complexity would also increase when dividing the editing process between the IDE and browser environments. It would increase if just by making you always perform one additional step when creating, moving or removing an element to synchronize the include and file name.

              P.S.
              Quote from: cyclissmo at Sep 08, 2010, 06:00 PM
              Personally I would never work on multiple sites from multiple tabs within the same browser window, for the very reason why you find yourself making mistakes.
              I specifically mentioned that I keep tabs from different sites in separate windows.
              • This is a complex topic... the present condition of the MODx project is probably not where its devs would ideally want it to be.

                I agree: editing your PHP files inside of a database record is not ideal. Most serious PHP code used in MODx quickly includes the files it needs.

                However, using the database for centralized storage has certain advantages:
                1. It can act as THE authority for the state of any data, including sessions, in a multi-server situation (e.g. multiple load-balanced web-servers)
                2. Permissions and access to that data/scripts etc. is easier to control inside of a database and it helps eliminate the situations where 2 people simultaneously try to edit the same record.

                What we have right now is not ideal... but we have some great potential here. With Revolution, the database has been abstracted via the xPDO layer, and that offers up some very interesting opportunities.
                • And don’t forget that critical snippets like Wayfinder and getResources depend on the searching, sorting, and complex query capabilities of the DB.
                    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
                  • @Everett: MODx currently just prevents two users from editing the same element. It doesn’t prevent the same user editing an element in two instances and accidentally overwriting data. This is a poor resolution to the problem of conflicts and should be left to a VCS that can actually make guarantees and not restrict you. Instead, using a VCS is made more difficult. Maybe I would find that it’s a pattern if I looked at other parts of MODx like xPDO.

                    I’m not knowledgeable enough to comment on your first point, though.

                    @BobRay: Does Wayfinder really do anything with elements, not documents, that it couldn’t with a filesystem? That would be strange.
                    • Quote from: slikts at Sep 10, 2010, 09:18 AM

                      @BobRay: Does Wayfinder really do anything with elements, not documents, that it couldn’t with a filesystem? That would be strange.
                      Subjective ordering.
                      Metadata navigation by indexes.
                        shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com