Subscribe: RSS
  • I'm planning to work on Evo. The current situation does not satisfy me. There is more than a year since the last update.

    The reasons to stay on Evo for me are:
    The JavaScript library used in Revo, ExtJS. Revo is staying on version 3 because they needed to extend it and these extension didn't make it into ExtJS 4. In addition if I want to extend the back end with non OpenSource components, I have to pay license fee. In addition the current tree component of ExtJS used in Revo does not work with trees with a lot of (more than 1,000) leafs, ak documents.

    In business environments it is totally helpful, to have strictly separated front end and back end users.

    The modules with shared parameters are a must have feature for me.

    It is much harder, to supply new add-ons for Revo. Just a look at the forums about fresh releases doesn't show as much new entries, than in previous times for Evo only.

    Don't get me wrong, I do not want to break with MODX, I just want to have a better Evo, and I offer to work on this in my spare time.

    I've done some plans, what I do need to work further on with Evo.

    First: Change the database class, I prefer the one of Zend Framework. One reason for this is to be able to go with other databases, PostgreSQL for example.
    Second: Make Evo and its core components run on PostgreSQL and MySQL with Innno DB using transactions and constraints. Other databases as SQL Server are possible, too.
    Third: Enable the choice to use separated or non separated front end and back end user as an option.
    Fourth: Changing the JavaScript library to jQuery, because of the license, documentation, and its much more much more common.
    Fifth: Implementing an internationalisation of documents including a proper workflow for this.
    Sixth: Version control with workflows for documents, yes, this should include translated documents. For example you work on a document and decide on your which version is published.

    There are some other things during the development, that should be changed. For example to create unit tests for every procedure or function, that is changed as a must. Code without unit tests end up in more work on code changes.
    All code has to be documented with PHPDoc code, there is no reason to accept code without documentation.
    PHP should be 5.3 and 5.4, by the way there are some very nice extensions in 5.4.

    Everyone who wants to join me on that hard way is welcome. This does also mean people for end user documentations are needed and invited to join.

    Here are some jobs, that have to be done:
    - Projectmanagement
    - Programming
    - Database design
    - Packaging

    I don't think, that this would be easy, but it can be done. And I would like to see more ideas, what do you need or miss in the core of Evo?
      Gone away and found a better place to stay
    • I've had thoughts along these lines as well. My basic reasoning is to keep Evo clean, small and quick.

      I want to re-write all the action .php files to collect the data and use a variable to contain the form as it's being built, in the same way that documents are built.Then plugins can modify any form, no need for Javascript DOM manipulation a-la managermanager.

      Actually, when a DBAPI was first being considered, before everything went Revo, I was pushing for this library I'm also considering using PDO for all database activity, but on the other hand I'm trying to get away from resource-hungry code. It may be all well and good for the developers of applications that will be compiled once to native code, but in the case of PHP web apps it's mostly interpreted at run-time. There's a trade-off between ease of development (at any rate as long as what you want to do is what the original developers had in mind) and performance. Besides speed questions, memory usage is enormously inflated with heavy OOP.

      Template variables need to be completely re-worked as well, so they are more integrated with the core than bolted on as an afterthought as they are now. Excellent afterthought, but still they can work better. I see them as having one default type, a simple input field, with a much more flexible custom type mechanism. Of course, an installation would come with the basic "custom" types by default.

      I'm also considering modifications to the user management system. Nothing like that of Revo, of course (as if I could begin to understand it well enough to even know where to begin!). Actually I'm not so sure that having two distinct types of users is such a bad thing, but I think the user type could better be a field in the main "users" table or perhaps a secondary index table, instead of requiring two complete sets of tables.

      Anyway, I promised myself six month with Revo to get to understand how it works. Three more to go. Then I'll have a better idea of what neat features I'd like to backport into Evo. Like property sets. Those are nice, and would be easy enough to implement. Also static elements; again easy to implement and better than having to have "include" snippets.

      The part I have really been dreading is converting the javascript to JQuery, but I agree that it should be done.

      In any case, something has to be done with Evo; it's been more than a week since the security vulnerability was announced, along with a patch, but no sign of a patched update version release. That's embarrassing.

        Studying MODX in the desert -
        Tips and Tricks from the MODX Forums and Slack Channels -
        Join the Slack Community -
      • I'd also like to see Evo get some TLC and further development.
        My plan is to stick with it as it does pretty much everything needed for the sites/clients I'm involved with.
        Maybe the core team have a view/plan for the future of Evo?
        • Hi Susan,

          Nice to see you interested. I'll take a look into ezSQL. My decision to use the Zend Framework was, that I do know it very well, it is fast, it is easy to integrate, and it has an active development team behind.
          I've already tried, to bring Evo to PostgreSQL, but without good database classes, that is nearly impossible. The current code works fine with MySQL, but not with anything else.

          Hi bunk58,

          As Revo does not fit my needs, I also decided to stay with Evo. As I am not willing to accept the current situation, I offer my work. to come to a better situation.
            Gone away and found a better place to stay
          • I'm not at all familiar with Zend Framework. Actually I used to write assembly language utilities using EDLIN. I've played around with things like Eclipse and NetBeans and just didn't get that bare-metal feeling that I enjoy, and that enjoyment is the only reason I do any programming at all anyway. I also sew my own clothes and bake my own bread, and never learned to ride a bicycle, so you can see where I come by my extreme KISS attitude.
              Studying MODX in the desert -
              Tips and Tricks from the MODX Forums and Slack Channels -
              Join the Slack Community -
            • The advantage of Zend Framework ist, that one can use just components. Meaning using the database classes, does mean nothing else of the framework is needed, thats a little bit like atmoic components,

              Currently, I've used them for example, to talk to other database from within a MODX module. I've also used the SOAP and XML classes within MODX snippets. It is just instantiate them and use them. Even the documentation is very good.

              I prefere Netbeans, because of the integration of PHPDoc, PHPUnit, and code completion. It makes my life easier.
                Gone away and found a better place to stay
              • Well, as long as I can contribute the odd function or bug-fix here and there I'll be happy. If I can figure out what it's doing, that is.

                I also plan to work with WebLoginPE, incorporating it more tightly with Evo's user management core. Maybe even re-work how users are stored in the database; the distributed tables that MODx uses make it very difficult to bridge with other applications. Vanilla is a nice exception because of the way it queries other applications for user data.
                  Studying MODX in the desert -
                  Tips and Tricks from the MODX Forums and Slack Channels -
                  Join the Slack Community -
                • Lets see, how it will work out. I've forked Evo on github, createad a new branch and merged this bug The bug was fixed more than a week ago, but ended not in a bugfix release.
                    Gone away and found a better place to stay
                  • Interesting topic. There are few things which anyone using MODX Evolution would like to see:

                    - Better caching system: fix limit of 5000 resources, fix strange behaviours of uncached or cached snippets

                    - Mobile plugin: this is already there, but as far as I know you need to disable the cache to use it

                    - Flexible Permissions: add the ability to give permissions only to certain users, hide other resources, etc

                    - Front End user management: I don't know exactly how to call this, but it would be nice to have a Front End login for users where they can view or change their profile, etc etc. There is already WebLoginPE, but I find it quite difficult to configure, although maybe it is just me

                    - MIGX!: I think that MIGX is the most-wanted addon for MODX Evolution, in the MIGX thread there are already 37 pages, which means that it is also the most valuable addon of MODX Revolution too

                    - Multi Upload: (of files and images) from a tv, or anyway, directly inside the resource

                    - PHx: fix the bugs of PHx, like the limit of KBs, strange behaviour when used inside other snippets

                    [ed. note: microcipcip last edited this post 3 years, 11 months ago.]
                    • I see it is starting smiley Next steps in public should be a wishlist and a priorisation for all those things.

                      The mobile plugin might be part of the change of JavaScript library to jQuery. This would go on much easier for me in jQuery and jQuery Mobile is very god.

                      What exactly do you mean with flexible permissions? By now, you only see resources, that you have rights for.

                      Front end user management is a good idea and shouldn't be hard to realize.

                      For multi uploads the complete stack for the file management has to be replaced.

                      As far, as I've seen it, MIGX is an add-on for Revo. Someone has to adopt that add-on for Evo, I don't think its core development.

                      The last release of PHx is now nearly two years ago. Have you tried to talk to the original developer of PHx?

                      The problems of bigger sites with the caching is well known and as no one was able to solve it in the past, the code has to be checked and maybe replaced. I had some experiences with the caching of Zend Framework, it might be worth a look to use it as component.
                        Gone away and found a better place to stay

                      This discussion is closed to further replies. Keep calm and carry on.