Can one MODX rule them all?

I learned this lesson fairly early in my computer experience. After writing utility tools in assembly language, I thought Visual Basic would be really neat. I think we all know where that went (and is still going in many cases).

The thing is, if an application provides pre-built functions that a non-programmer can string together, like Legos, that's very nice... as long as you don't want rose and mauve Legos. Trying to paint or dye Legos is pretty much an exercise in futility. Don't ask me how I know. It's like the original Fords or the first generation of telephones - they came in any color you liked, as long as you liked black.

My point is, we all know by know that, like a dog on one side of a closed door, no client is ever (well, hardly ever anyway) going to be happy with just the provided functions. There's always something totally different. That's why there are so many "modules" or "plugins" for all the CMS, forum and e-commerce applications. It is simply not possible for any team of developers to make an API to cover all possible variations. Sooner or later, the web designer/developer will have to get off the beaten path and try to make his way through the uncharted jungle.

The greatest strength of MODx (either version) is how easy it is to manipulate the front-end. Templates are breathtakingly simple. Snippets, TVs and plugins make it almost childishly easy to create whatever kind of front-end functionality anyone could ever want. Javascript? Nothing at all to do with MODx, except for the advantage that you can use MODx to provide dynamic vales and AJAX processing. Do whatever you want as far as Javascript goes.

Customizing the back-end is another matter altogether. Revo has made steps in that direction, while making the underlying architecture nearly inscrutably complex. Evo has some work to do, and we're in the process of doing just that. One idea is to make it one page, but put the Tree in an iframe to insulate it from main page refreshes. Re-factor the action .php files to work with templates, as the login form and the Welcome page do. Generally clean up and simplify the code. Make the Javascript truly unobtrusive, and it would be fairly easy to use whatever Javascript library and UI you prefer. Basically all the action .php files would do would be to provide the necessary data from the database and check for permissions. Customizing the action pages would be as simple as creating a clone of the default theme folder and editing the desired action templates, then selecting your new theme in the site configuration. The plugins, of course would still be available for added functionality. Individual users can already be assigned a theme, so there's granularity there. Add assigning themes by group and/or by role, and it would be perfect. [ed. note: sottwell last edited this post 14 years, 5 months ago.]

I've encountered more bugs in 2.2.1pl now (and yes, I've reported them). Combined with the fact that the manager has become really sluggish, I've decided to switch to Evolution for smaller clients. It works better, is more stable and faster. Revo just isn't that far yet, in my opinion.

I have never used Evo (by the time I learned of MODX, Revo had come out), and I haven't done anything large enough to tax Revo to the point of causing major performance issues (other than evil code that I myself created and subsequently refined).

I see the advantage of maintainability using classes, and though I've always been a procedural kinda guy, I'm learning the OOP way for my own good. I have spent many hours pouring over Bob's amazing book to get myself up to speed (I think I was probably one of the first to pre-order the book).

One question I have is this: Given that PHP is an interpreted language, wouldn't some of the heavy lifting be a lot more efficient being compiled into shared objects or dlls?

I know that this would probably mean more things to compile, etc. but in the world of video games, those processes that have to be really really lean are still written in assembly language.

As well, in terms of OS sprawl, are there really 20 or so OS'es that are actively downloaded? If OOP allows encapsulation, could we have a DLL for windows machines (which is what most of my clients use) yet still retain the PHP files for a UNIX install. In addition, using a PHP to C++ converter would mean you're still only doing PHP coding yet reaping the benefits for those OS'es where there's a real demand for compiled code. As well, if I write a call to getResource, by definition it shouldn't know or care whether it is being handled by a PHP script or a DLL. Am I right?

---

Just so you have some context as to where to place me on the spectrum between:
* the guy who thinks PHP is like a remedial course for the PMP designation, and
* basically most of the gurus posting on this thread

I'm closer to the former than the latter, and I'm a consultant by trade (Business Intelligence Architect to be precise) so I've got broad shoulders (and fully admit I'm not a web developer).

A few other comments:
1) I've worked for over a year with SharePoint, and I want to say thanks to the MODX people for not making it SharePoint (SharePoint is really bloated out of the box IMO)
2) I remember a while back the manager for Revo had a major performance boost, thanks to someone in the community coming up with an improvement. This doesn't happen with closed source systems; in a closed source system, they would sue the person who came out with the better way, do some quick and dirty performance fixes and then sell it as a new version of the same product with a brand new licensing structure solely to increase revenue. MODX, being open source, does it better!
3) I don't understand the Revo security model too well; I'm sure it is superior to my own view of how it should work. Once I figure it out for myself in a way that I can explain, I'd love to post something on it.

[ed. note: stalemate resolution associate last edited this post 14 years, 5 months ago.]

Hey Ryan,

Thanks for asking.

#1 - Speed. Frontend and backend.
Frontend is the HUGE issue though. Frontend speed is hugely important in SEO/Conversion. And just usability.
Backend: The speed can be dealt with but it's slower, which means I make less per hour or have to charge my clients more per task (because it takes longer)

#2 - Speed. This one is just huge

#3 - ACLs need to be easier more straightfoward. (If you want complex things, leave it a Addon)

#4 - Please dont take this the wrong way. I think Revo became too complex.

Creating a module in Evo: drop files into a folder. Create a PHP include in the module and assign permissions
In Revo: it's not that easy

Being encouraged to migrate from using TVs to custom modules or resources. TVs are huge and easy. At a time when Joomla got K2, and we got CCK and Expression Engine all touting their custom fields. I feel like Revo has encouraged to not use them.

ManagerManager compared to Revo custom rules.

Permissions

I REALLY want to use Revo. I check it out every few months. I miss the community, but feel like Evo was abandoned and my complaints on Revo weren't being heard.

However, I love the idea of really listening to us, being friendly, and hopefully we can make both systems better.

El Chucko!

I have been developing sites in Revo for about a year, and I've even made some small extensions. I worked with Evo a little before that, but not extensively.

Here are what I see to be the pain points for a developer:

• 
  ExtJs/ModExt is a maze of twisty little passageways, all alike. The documentation is generally poor. It is said to be MVC, but I'll be damned if I can find any Models, Views or Controllers anywhere.
  


• 
  When I'm developing a Manager user interface and something goes wrong, there's usually no feedback as to what broke. Sometimes I'll get a Javascript error deep within a minified Ext file somewhere. Or I'll just get nothing, with no errors appearing in any log.
  


• 
  It's very hard to debug a manager application (e.g. with Xdebug) when all these tiny, disconnected components are making all these asynchronous calls. I'm not asking for a return to page-based applications, but I think better facilities for debugging are badly needed.
  


• 
  The Clear Cache command doesn't actually remove all files in the cache, and sometimes you have to delete files by hand.
  


• 
  MODx developer documentation is generally skimpy, and in some cases, missing altogether. Sometimes in the place of real examples or information, there's a cheeky informality: "Go ahead and add a snippet now". The only thing more irritating than unhelpful documentation is cheerfully unhelpful documentation.
  


• 
  The names of the database tables don't match up with the names of the MODx classes that model them. For instance, when you want to find out what properties modUserGroup has, you have to look at the modx_membergroup_names table. The table for modTemplateVarResource is modx_site_tmplvar_contentvalues. I think.
  


• 
  Packaging takes forever. I'm using Bob Ray's skeleton for that, and I'm really, really grateful it exists, but it takes me hours to package even a small extension, with lots of trial and error. It doesn't help that installing your own package takes about 10 clicks in the manager. I hope someday that creating a package is as simple as selecting existing objects in the Manager UI and clicking "package". I hope also that updating a package (from those existing manager objects) is as simple as clicking "update". This functionality would help non-programmers as well.
  


• 
  MODx's greatest strength is its modularity. However this leads to sites filled with dozens or hundreds of templates, chunks and snippets. It can be very hard to keep them organized. Even with very disciplined naming conventions, it can be difficult to track down the particular chunk you're looking for. Usually, what you have to do is:
  
  --- Edit the resource to see what template it uses
  --- Edit the template to see what chunks it uses
  --- Edit each chunk to see what snippets and chunks it uses
  --- Lather, rinse, repeat
  
  
  The slowness of the manager makes this process very painful. What would be really useful would be if each resource had a visual graph indicating which elements are used by a resource and allowing direct navigation to those elements, preferably in a new tab.
  


• ACLs are very hard to implement. This is partially due to the fact that everything is visible until you add a rule to it, at which point it becomse invisible by default.
  
  For instance, as soon as you add read/write permissions to a resource group, there's a cascade effect, and you now have to add read-only permissions to this resource group for everyone else in the system.
  
  Conversely, it is confusing that in order to deny access to anonymous web users, you have to grant access to someone else.
  
  I think it would be easier if the "everything readable by default" permission were explicit rather than implicit.
  


• ACLs are very hard to debug. Permission checks fail and there is no feedback as to what happened - whether it was a missing Context ACL or a missing Resource Group ACL, or a missing group membership, or a user having the wrong role.
  

I think Revo has a lot of promise, and it's great to see that it is constantly being improved.

I know some of the things that annoy me are slated for improvements (e.g. the packaging system). Are the plans for future improvements available anywhere, aside from the one line descriptions on the roadmap?

As it stands, Revo makes hard things possible. I hope someday that it also makes easy things easy.


Michael

[ed. note: michael.graham last edited this post 14 years, 5 months ago.]

As it stands, Revo makes hard things possible. I hope someday that it also makes easy things easy.

Wow...that may be the most accurate and succinct explanation of Revo I've ever heard!

Thank you so much for continuing to provide outstanding and honest feedback everyone. I can't tell you how much I appreciate it, and there's so much with which we completely agree.

Some great points. Thanks for contributing that!

One note: The table names are here (though probably backwards from the way you might want them): http://bobsguides.com/modx-object-quick-reference.html, and you can install the ObjectExplorer extra to have them locally.

You gave me ideas for a couple of useful extras.

Let me know if you have any feedback on using MyComponent to create packages. I have some ideas for improving it. I've started work on a utility to export chunks, snippets, and TVs to it directly (along with their properties and an automatic transport.object.php file).



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

I have been using MODX for over a year and a half. I have built with it 30-40 simple sites (navigation, gallery, some forms, some content, some products...standard stuff) and few complex sites (with social elements like frending, following, messaging, custom ACLs, construction spend-book...).
Bottom line is: MODX is excellent for those small, standard sites. MODX is pain-ish for anything more. Sure, you can do it. I did it. I can do sites in C++ also. But I will not. And I will continue to use MODX only for small, standard featured sites.

MODX is in tough position right now:

1. You mostly attracted designers/webmasters with limited programming knowledge.
-You gave them easiest templating possible - but you traded it for performance.
-You gave them output modifiers - again traded for performance.
-You gave them best looking manager ever - you traded it for being very hard to modify to most people (ExtJs learning curve + very limited documentation for CMPs).
- List goes on...
2. Most of community perceives Revo as developers oriented/frameworky and anyone who has done some serious programming knows it is just that - only frameworky at best and far from real framework and quite far from developer dream.
3. My impression is that many community members are at least exploring other options
...
MODX needs to be LOUD and CLEAR about:
1. Targeted audience - you can't satisfy everyone
2. Take it's niche (small sites, big sites, cms for designers, cms for coders...) - big three are out of reach for any foreseeable future - team should admit that to itself (and to us)
3. Feature requests - if you really want to hear community, where is some kind of voting for features

I am sad to say that it seems to me that MODX star is kinda fading and team must act "yesterday".

My proposition:
Take Symfony 2.
Develop new MODX.
UNITE communities on new MODX.
Make only security updates on evo and revo.

Why I propose this:
You gained a lot of experience regarding everything open source CMS related - use it.
You can attract a lot of developers and contributors.
Community size would explode.

Get rid of those silly certifications, stop wasting time on developing your own ORM, use this PHP mini revolution (new frameworks and features) to your own advantage. If you don't others will...

Regards