Is MODx Evolution Dead ?

I do not understand the need for Revolution, I do not understand what was broken in Evo that is fixed by Revo. But I have confidence in the developers...

As fond as I am of Evo, there is a LOT that is broken. Just as a quick example, nested snippets. The way snippet are processed, it takes a kludgy work-around to allow a single level of nested snippets. A very common usage is using the UltimateParent snippet as the startId value for a Wayfinder snippet call.

Evo just blindly processes snippet tags as it finds them, so the Wayfinder snippet is processed as soon as its tags are encountered. The UltimateParent snippet tags are meaningless, so you’ll get the default startId. The UltimateParent snippet will be processed next, but it’s already too late.

The workaround is to call the outermost snippet (Wayfinder) uncached, so it doesn’t get processed until later. The UltimateParent snippet is called normally, cached, and so it does get processed. Then when the Wayfinder snippet is processed later, the correct parameter value is available so it works.

Revo handles snippet (and all other element tag) processing differently, so that they are processed from the innermost set of tags to the outermost in the case of nested tags. This allows for (as far as I know) unlimited nesting of tags, without any dependence on multiple parser passes (and what happens if the parser reaches max number of passes and there’s still an inner element or two to process? You get the tags themselves displayed in the final page!)

That’s only one of the simpler reasons for Revo. For basic, fairly simple stuff Evo is just great. But get complicated, and Evo definitely starts to suffer.

Quote from: sottwell at Nov 12, 2010, 12:39 AM

That’s only one of the simpler reasons for Revo. For basic, fairly simple stuff Evo is just great. But get complicated, and Evo definitely starts to suffer.

Alas, for basic, fairly simple stuff, Revo makes *us* start to suffer.

So Revo is supposed to be preferred solution when managing bigger sites ? But in the same time the resources manager is the first thing people complain about in Revo... All this JS interface is probably cool and challenging for modx core developers but I still think it gets in the way of users.

And that leads to perhaps the biggest advantage of Revo. That manager interface is just the one that the developers came up with. Actually Revo manager pages are built with Revo, just like front-end pages are. So it will be easy enough for a developer to create his own manager interface. Give it a little time, and there will be interfaces for all kinds of users. I personally don’t like the extJs/Smarty combination either; the Evo frames approach has its advantages in its simplicity. But the Evo manager’s action and processor .php scripts are a nuisance. No way to customize them, which is why we have ManagerManager manipulating the DOM in the browser. There’s also no way (well, I have done it but it’s not pleasant) to move or rename the /manager folder in Evo.

May be from a technically point of view, Revo is a Dream for high-end coders, and its Manager is considered as perfect for the same people, I just would like to remember, that, professionally talking, the only people we should consider, in fine, are our customers.

Most of them just wanna to edit their pages, easily deal with images transfer and resizing, even if the site is a very specific development.
From the CMS point of view (and not the CMF one) the Modx backend is still not ready for lambda users.

May be many people consider developing their own module to specifically stuck to each need of the customer and will rebuild every thing for each new project.
I’m no sure this is profitable.
When the necessary foundation will be part of Revo, then it will rise, but for the moment, it will remains as brilliant development plat-form.

For the core team, I suggest to think about a strategy wich will includes much more extra integration (to be choosen or not during install) in order to release in a minutes an almost running site.

To cover the real CMS needs:
in manager:

• to have a ’content’ manipulator to enable the redactor to create, delete, hide, show as many content block as need, which will appears like the Content windows in the manger (the content will be the sum of those different ’sub content’.
  I’m not talking about TV already set by the site designer (look at Typo3)[/li
  
  [list][li]Include a real native images manipulator (upload and resizing, as most people don’t know how to manipulate their graphics before sending them in the site)
• The good old Directresize was really cool, and something like this (phpthumb based) should be part of the system.
• File manger should be a real one (downloading files from it -from server to local - is still no present, ok not so vital)
• Manager is quit slow on my W7/64 core i7

Including a mobile detection solution natively too could be a must.

Regards


[/list]

@elz64

Im don’t agree with your first point:

show as many content block as need

MODx has no "block" and should never propose any block directly within the core.
If someone come with a front end editing tool (which is coming btw), then people will have to use the proposed tool, but not as part of the core.
I really wish that MODx stays as blockless as possible so that i can play lego with it.

I may sound rude, but the main reason i love MODx is because it doesn’t impose me how i should work.

Now for the other points:

• Image manipulator is coming, it’s on a TODO list, but not in highest priority
• PhpthumbOf component is quite easy and allow caching, it’s quite new but you should take a look at it. It use the native and secured phpthumb facility of MODx Revolution
• There is definitively room for improvements. In the meantime, there is only one developper (back end interface). It’s up to us to make the filebrowser awesome...
  Or just wait until splittingred find the time to do so.
  That last point only works is the feature has been asked officially, not only in a forum topic where it has great chance to be burried.
• 
  ExtJS gives slower perception but is a time saver.
  I don’t think that the team is closed to proposition involving a less JS manager, but again, it’s up to the community to give another solution.
  

There are lots of complaints regarding the manager and ExtJS.
I can understand them, and i would love to see a community driven project for an alternative manager.
I even had contact with a couple of individuals who whishes to make a jquery alternative.

Time ate us all and our good intentions...

In the end, Evolution is going nowhere and if it fits your needs, keep it close to your heart.

And ignore Revolution when it get native ecommerce, forum, galleries, themes...

MODx has no "block" and should never propose any block directly within the core.

I think my formulation is confusing.

I’m NOT talking about block as Oscommerce !

I just try, in English, to describe the capability for any redactor (if rights granted) to create any ’new content TV’ from a previously built types list.
(those kind of ’content TV’ could be made by the designer, but a couple of standard one could be available from the box too.)
example : a ’txt + img’ content with the img embeding element floating right or left.
A 2 columns txt (or 3 or..)
or any kind of valuable content.

It’s not a question of imposing anything.
Because the existing content ’block’ used since Etomite is not considered as ’imposing’ anything neither.
It’s agility for the redactor. and precisely a way NOT to impose him a way to deal with it’s own presentation and not to be dependent anymore from any designer action once all needed types of ’content boxes’ will be setup.

Just place yourself from the user side.

My mistake then.

Is it what your talking about : http://www.ministrycrm.com/widgets.mov ?

Quote from: sottwell at Nov 12, 2010, 02:24 AM

And that leads to perhaps the biggest advantage of Revo. That manager interface is just the one that the developers came up with. Actually Revo manager pages are built with Revo, just like front-end pages are. So it will be easy enough for a developer to create his own manager interface. Give it a little time, and there will be interfaces for all kinds of users. I personally don’t like the extJs/Smarty combination either; the Evo frames approach has its advantages in its simplicity. But the Evo manager’s action and processor .php scripts are a nuisance. No way to customize them, which is why we have ManagerManager manipulating the DOM in the browser. There’s also no way (well, I have done it but it’s not pleasant) to move or rename the /manager folder in Evo.

Susan’s point is (as usual) excellent... I was hoping that there would be ability to do makeovers of the Manager, and I’m hoping that someone will do it. I note that today when I open my Revo Manager the doc tree is expanded, and this would be less forbidding to a newbie. Maybe it just remembers the "previous state".

Despite all the well-intentioned reasons for its organization and nomenclature, I still believe that it’s moving towards being more of an interface for developers, not clients. "Resource", though semantically correct, will mean nothing to a client. And maybe that’s the intention; it’s one valid path to take. And if developers are making an interface, that’s certainly what you’ll tend to get, obviously. The "audience" for MODx may change; time will tell. Maybe just more client training will be needed. It’s also valid not to water down an interface too much - it could become bloated. Many decisions to make, and not easy ones. [Sings "went down to the crossroads, fell down on my knees..."]

If one can customize the Manager (and I’ll try to wade through some docs and learn about that), then this becomes less of a concern. In the meantime, my favorite MODx fans that I work with all the time are still saying "yuck". To me it’s OK - I’m a total geek, and will persevere hard until I find something. It also helps that I know what to look for. I’m thinking that if the rest of the menu is hidden via User Groups or whatever they are, maybe the client will see nothing but a few Resources, so they’ll go there and not get lost.

Since I have made my very snarky points on behalf of hapless newbies, I’ll just mention a few of the great things about Revo that convinced me to use it:

- Ability to search for, and install, add-ons right from the Manager. REALLY GREAT. Though still slightly funky.
- Context-based Help pop-ups in the Manager that connect right to the online documentation. Awesome. Even just having direct links to the forum and API docs is quite nice.
- MUCH easier to set up multisite. Using it as we speak. Bravo!
- News and security notices in the Manager. Nice and Wordpress-like.
- Not having to worry so much about cacheing snippets. VERY NICE.
- Changes in syntax of calls to snippets, chunks, etc. are pretty easy to grasp.
- Ability to have an almost unlimited number of docs before the system barfs. (I probably will never see this, but others will care).

Cheers, Dave

Ability to have an almost unlimited number of docs before the system barfs.

...not so sure about this

I personally feel that the community disdain for ExtJS is unwarranted. The train of though seems to be that Revo is slower than Evo, therefore the ’problem’ lies with ExtJS. Granted it can make the UI feel ’sluggish’ at times; once you start developing with it however, you will find that it is an amazingly versatile and powerful javascript application framework, and understand why the MODx developers adopted ExtJS over JQuery, Scriptaculous or other core JS framework. Creating tabbed, columnar datasets with advanced ajax functionality and a wide variety of functional options and configurations is not only possible, it is absolutely fool-proof and **much** easier than trying to code the same functionality from Mootools or JQuery (speaking from experience). ExtJS is also thoroughly documented and can be deployed from front-end pages as well.

My one and only gripe with Revolution is the decision to adopt Smarty. I’m not a fan of Smarty and have never been inclined to learn Smarty markup, and feel that it’s better to simply use inline PHP tags for better efficiency and a zero learning-curve. IMHO this is what PHP is intended for- jumping in and out of parsing mode side-by-side with HTML. Codeigniter follows the same line of thinking.

That’s one developer’s perspective. But the end-users of my Revolution sites have sung nothing but praise for the back-end interface and out-of-the-box workflow. It is a bit puzzling how some of the community is so critical of Revolution in the usability department. I might be opening myself to flames , but that might actually be more of a reflection of the quality of back-end training clients are receiving from their developers. My instructional techniques have been refined since adopting Evolution a couple of years ago. Fortunately, my clients tend to ’get it’ after less than an hour of training, true to MODx’s marketing pitch

Revolution, in it’s state of infancy, requires extra milk and a burping every once in a while. But it will absolutely shine once development really kicks in and more back-end options become available to allow people to fine-tune it with simple 3rd party interfaces to make it work exactly the way they want.

Cheers!