Can one MODX rule them all?

I think that there is not need to get so excited, this will not help the core team understand what's wrong with Revolution or what we like about Evolution. It will just add pressure on the community.

We shouldn't forget that the people working on Revolution have been working for a long time on MODX Evolution too, so I think they understand what are the issues with Revolution.

@blackflow has never used Evolution and Revolution works well for him, so it is comprehensible that he will not use it, I would do the same if I were him.

The people involved in the project of improving Evolution are only looking for a basic support from MODX Team so that the changes will be added on modx.com website when they're ready.

...50 getResources calls. That's simply a lot, and definitely needs to be optimized better.

Oh I completely agree that the code could be better optimized -- I stipulated that I'm using it hard, by which I mean that I know I'm making unreasonable demands on the system.

However, saying that 50 calls is "simply a lot" just begs the question, doesn't it? I mean, why is 50 a lot? In most contexts I wouldn't consider 50 to be a particularly large number of operations. Yeah, if a function is so slow that calling it 50 times takes several seconds, then you should avoid calling it 50 times -- but the question remains, why is the function that slow, and shouldn't it be faster?

Actually what I meant was more specific: why is it that calling a snippet takes so much longer than performing another iteration within the snippet? The answer is that making a snippet call carries system overhead that looping within the snippet does not, but is that much overhead a good thing?

Maybe what's needed is some sort of MODX code compiler or optimizer, which could take code involving large numbers of snippet calls and re-create it as iterations within a single snippet call.

The same question applies to output modifiers. A good example is in this thread: https://forums.modx.com/thread/75264/extreme-pageload-time-20-secs-and-up#dis-post-418795 where somebody is getting very slow performance, and one of the first questions asked is "are you using output modifiers?" Well, yeah -- because output modifiers are damn cool! I'd love to use more output modifiers. As it is, I hardly ever use them because they slow down getResources.

If I say "this tool is too slow" and the answer is "well then use it less," doesn't that just prove the point that it's too slow? Its frustrating having all of these awesome capabilities, but having to hold back on using them.

Please don't get me wrong, I love Revo. And I don't mind being asked to write better code, it makes me a better coder. I just wish it were faster, that's all...

The problem with output modifiers is that they are based on an interpreted language built with PHP - an interpreted language. So you have a double layer of language parsing and interpretation. That's like having a native Spanish-speaker interpret Chinese into English for you. I use "interpret" here rather than "translate" intentionally; interpretation takes place live, while translation is done on written material and doesn't matter (within reason, of course) how long the process takes.

As far as snippet efficiency goes, I think a system where snippets are loaded from file using the include_once directive would go a long way toward solving the problem in Evo. As it is now, Evo passes snippet and plugin code through the PHP eval() function. Now, TVs have always had an @EVAL binding, which does the same thing, but custom TVs also have @INCLUDE binding for including external .php files. So if your @EVAL code does nothing more than include a file, you've still got the overhead of running that one line of code through the eval() function. I'm not sure if the included code is also processed through eval() by PHP or not, though.

I understand everyone's frustration, and really hope you'll continue with the discussion.

As I stated in my blog post this week, we're thoroughly committed to figuring out the best way for everyone to proceed, and not in some nebulous timeframe in the future either. We're investing heavily in our ability to build the best experiences for everyone that designs, creates and manages websites (which happens to be our corporate vision). Neither Evo nor Revo in their current forms come close to passing muster against this standard.

Case in point on the investing-in-making-it-better front: we've been on a hiring spree of late. We brought Dustin in specifically to focus on UX and Design for the Manager and everything else we do. He comes right out of the Agency world, working with pointedly non-technical end users. His passion is making the best Manager experience for all users. He's also built solutions in a variety of other platforms, too, including Expression Engine, WordPress, Drupal, Dot Net Nuke, Evolution and Revolution. He brings a lot of insight to the table about what works well in a variety platforms, and what doesn't.

Similarly, Mark also joined us recently, a truly talented developer and an incredibly helpful community member. He cranks out Add-ons and shares them, and he is the only person in the Community we're aware of that has built an alternate Manager for Revo—based on jQuery of all things. Crazy coincidence? Nope!

To further the discussion, MODX Cloud is a major part of our future at MODX and how we plan to fund a major portion of ongoing product innovation (there's a ton of really cool ideas we'll share later). MODX Cloud will literally offer the best experience for anyone that builds and maintains websites. Attempting to do what we've already done in the Cloud in Evo would require exponentially more effort, if it's possible at all. While I won't go into full details today, MODX Cloud is absolutely a game changer, and where you'll see the first fruits of Dustin's UX and Design influence. The design and interaction patterns established there will likely be carried over into a future Manager.

To that point, an alternate take on a Revo Manager, whether it's based on ExtJS 4.x or jQuery or even Coffeescript for that matter, is absolutely not out of the question, nor is making Revo faster for smaller sites and on shared servers. Nor are more efficient menu building Snippets something we're averse to working on, or dealing with TVs in a fundamentally different way that scales better… we have to live up to our vision of building the best experience for everyone, and we're focused on living up to that.

In the end, we all have to weigh the effort of making some improvements to how things work in Revo against the effort of what essentially is rewriting Evo to do a lot of what's already done in Revo. There's no final decision made, but it certainly seems that fixing Revo makes a heck of a lot more sense.

I think some understanding of output modifiers might help here. The whole point of using output modifiers is coding convenience for people who are not skilled at using PHP to create snippets. The price of that convenience is execution speed. This is true in both Revo and Evo, BTW.

Comparing the operation of snippets versus output filters (leaving out the the things that MODX does in both cases, like parsing the tag) shows a dramatic difference.

If you write a snippet that prints one string if some value is greater than another value, MODX finds the snippet, and sends it the two values, using a very small number of lines of code (I'd guess less than 10). The snippet itself can be done in one line of code:

<?php
return $prop1 < $prop2? 'Something' : 'Something else';

Done -- and done in a few milliseconds.

I leave the creation of the output modifier version of this as an exercise for the reader, but let's look at what MODX does with it.

First, it runs code (about 30 lines) that loads the modOnputFilter Class (about 100 lines of code) and the modOutputFilter class, which is 647 lines long. Then it has to figure out what, out of all the possible things you can do with output modifiers -- a monstrous list if you consider the permutations -- , you want done. It has to search through the approximately 120 possible filter names (once for each ':' in the tag) to find the named filter, then run its code and pass the result on to the next filter.

With the snippet, that work is done in the brain of the programmer when designing the snippet -- MODX just passes the values and assumes that the snippet knows what to do with them. With the output modifier, MODX has to parse the modifier, identify what has to be done, select the particular methods of the modOutputFilter class to do them and then execute all the necessary code.

Output modifiers are relatively inexpensive when doing simple conversions (e.g., date formatting), and not terrible when you have a boolean (yes/no) test, but when it comes to complex conditionals with nested if, then, and else clauses or mathematical calculations, they can get pretty expensive in terms of execution speed and a custom snippet that already knows what you want done and how to do it will almost always be many times faster.

The output modifier system could probably be optimized somewhat (though the code is pretty efficient), but developer resources are scarce and people who need fast operations really shouldn't be using output modifiers in the first place.

If you are using output modifiers and have slow page loads, you can always ask for help here. The odds are good the someone will write you a custom snippet that will be many times faster.

As an aside, this can make MODX appear slow compared to other CMS platforms that don't give you the option of using output modifiers.

Another aside: getResources and a few other extras are somewhat similar. They are all-purpose tools that take time to figure out what you want before doing it and often perform extra tasks that you don't actually need to have done. Storing data in resources and TV and using getResources to display results is always going to be more convenient but slower than alternatives that are optimized for execution speed.



------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

The whole point of using output modifiers is coding convenience for people who are not skilled at using PHP to create snippets. The price of that convenience is execution speed. This is true in both Revo and Evo, BTW.

Code bloat -
convenience is nice
enabling use by less skilled users is a noble pursuit
slow code is BAD

would not it possibly been better if the modifier system had been less complete, that is limited to fewer possibilities so the code base would have been smaller and would have run more quickly.
If a user truly needs (and can figure out) more complex logic learning php or finding someone who knows php should not be too hard!
just my 2cents
too late now, the horse has left the barn... but for future feature choices

I have to say that this uncertainty of what is happening with the future of MODX has already spooked 2 potential clients and they decided not to use MODX which lost me the work.

It's making me wonder if all the time spent learning how to develop CMPs and using extJS has been a waste of time. Is jquery even capable of replacing extJS to the level that we would need and can it create the same easy to use interfaces?

Nothing is going to happen to MODx. It's merely a matter of choice. Some like extJS, some like JQuery. Some like Evo, some like Revo, some use either one depending on the circumstances.

Storing data in resources and TV and using getResources to display results is always going to be more convenient but slower than alternatives that are optimized for execution speed.

I get what you're saying, Bob, and I personally don't have a problem with it. I'm starting a new project in Revo that will involve lots of custom functionality, and I'm planning to do it with custom tables and resource classes and XPDO schema and my own listing snippets. (By the way, which is faster, using a separate table or using the new Properties field?) I learned my lesson about trying to do complex functionality using TVs and getResources. I'll have fun coding it and it'll be fast, and if it works out well I'll release it as an extra (for event management), and that's all good.

But do me a favor -- read back through what you and Mark said and think about it in the context of Revo trying to compete with Wordpress and Drupal, especially Wordpress. Imagine explaining all of that to a designer who knows some HTML and CSS but doesn't know PHP and doesn't have a talent for real programming. From that perspective, if you're going to have to get someone to code you a custom extra to do the job, why don't you just get someone to make a Wordpress plugin that does the same thing? Yeah, working with the Wordpress API can be a PITA compared to XPDO, but that's not your problem, that's the developer's problem, and Wordpress devs are a dime a dozen.

IMO the most compelling reason for non-coders to switch from Wordpress to MODX is that in MODX you can do things with a simple markup syntax that in Wordpress would involve lots of custom PHP code. But what good is that if in the end it performs slowly and you have to go back and re-implement it in PHP anyway?

I'm sorry, I don't mean to be harsh and I don't mean to complain, like I said, I love Revo. However, I really think that if you continue in this mode of thinking, Revo will be a CMS for hardcore PHP developers only. Maybe that's OK. It's fine with me, I'll keep using it anyway. But it doesn't sound like that's what Ryan is trying to accomplish.

MODX is here to stay, that's for sure. It's been 7 years of work to get here... nobody is planning on throwing that away.

I'm sorry to hear the confusion on certain topics has lost you work and I wish there's something I could do to remedy that. There will be announcements and blog posts which will go into more detail on the direction MODX is taking, which will hopefully get rid of any confusion there may be.

Just trust me for now that there are some great things to happen with MODX