Five Things I don’t like about MODx Revolution

(Text auf englisch, weil die MODx-Entwickler das vielleicht auch lesen möchten.)

Everyone knows that I love MODx – I really do. I’ve donated some money, report bugs on a regular base and I spread the word where I can: MODx is certainly one of the coolest Open Source Content Management System you can choose.

But still there are areas where the system drives me nuts! I’ve recently set up a couple of clients’ websites with the completely re-written version of MODx called “Revolution”. And besides a lot of positive experience, I think it’s necessary to also talk about the weaknesses of Revolution. My judgments are based on the regular tasks of a web designer who wants both – an easy to use system for editors and a flexible framework for developing.

I know that Revolution is still at its infancy. Actually, that’s why I write this rant! It’s not too late for changing and improving things – at least I hope that some of my real-life experience will be helpful to focus on the important areas!

1. Backend Performance

One of the things I liked most about Textpattern and the traditional MODx (called “Evolution”) is their super-fast backend. Sadly this aspect does not get a lot of attention in today’s CMS conversation. Still, it’s oftentimes critical to get your shit done very quickly, be it content editing or templating.

In MODx Revolution, however, the backend is made with ExtJS, which is a framework for building complex user interfaces with HTML, CSS and JavaScript. It certainly does its job in a super-cool object-oriented and MVC-driven way, I don’t know. Obviously, ExtJS wraps twenty div containers around each form element and embeds several tons of JavaScript to make the UX shiny and consistent across all platforms. Unfortunately, it’s slow as hell! Buttons don’t respond when clicked at the wrong pixel. The always-present page tree ajax-reloads after almost every operation, even if it had nothing to do with the page tree. Changing from one view to another makes you wonder why they didn’t just used frames like in MODx Evolution.

This surely isn’t about connection speed (it happens even locally), nor a specific browser (Chrome’s V8 engine should be fast enough). The current responsiveness of the backend might be okay for casual content editing, but while hacking together dozens of templates, snippets and system settings, it just steals way too much time.

(Almost ironic: The most inconvenient task is configuring and simplifying the backend for editors. You have to fill out a cryptic popup-form for every single change, which can be a nightmare.)

2. Image handling

This is a tough one, because there are only few content management systems around which solve this damn image handling problem in a proper way! One of them is WordPress, which does a great job at uploading images, managing them globally and/or article-based, and building gallerys. In MODx Revolution, you can upload files into the file system, and chose them afterwards for inserting. That’s about it. The official way to generate a database entry for an uploaded file is to manually create a new “static resource”, which behaves and looks exactly like a regular web page, must sit in the page tree and has no automatic functionality for gathering meta data or attachment information. This doesn’t make sense to you? Yepp.

Of course there are Add-ons like Gallery or phpthumbof, which help you a little bit here and there. And with some patience you can finally build an “okayish” picture workflow for your client. But to be honest: A modern CMS must automatically track every single upload with a proper database record, so you have at least an unique ID to be able to rename or exchange your image files later on. “Static resources” are not the right way to do so!

3. Nested URL paths

It’s a simple thing, but it nags the hell out of me! Friendly urls are an integral part of MODx, which is nothing special. There is also an option for so-called “alias paths”. Activate this, and you should get permalinks that are based on the page hierarchy, e.g. “http://example.com/company/history.html”. So far, so good.

The internal link creating system, however, does only do “docrelative” permalinks. These permalinks typically do not start with a slash or the base URL, but look like this: “company/history.html”. If you use this link on a page that is not on the first level in hierarchy, it’s rendering a wrong link which leads nowhere. Yes, MODx literally generates wrong hyperlinks, when using “alias path”. And to be honest: Everybody should use “alias path”, because it’s useful for humans and search engines alike!

It would be so simple! If “alias path” is activated, put the base URL in front of every generated permalink. But instead, the official manual advices you to use the old and almost forgotten HTML <base> element on every page to fix the problem. Which has the side effect that you cannot use internal jumplinks anymore. This is embarrasing, but my forum post did not attract any reactions, which is funny. I can’t be the only one with this problem! (filed as a bug now, let’s see if it will be fixed soon.)

4. Permission management

I’m not very often in a situation where I need a sophisticated permission system. Most clients work in small teams (mostly one person), so this wouldn’t be a big deal. However, last month one of my clients wanted a login area for three of his clients, which contains only one page for each of his clients. Should be a piece of cake for a system like MODx Revolution!

Turns out, it isn’t! Instead of simply restricting access of those pages (=resources) to certain users, you have to setup two additional layers: resource groups and user groups. You cannot drop this steps. You have to build resource groups, even if there is only one resource in it. Plus you have to build user groups, even for only one user. Then you can finally restrict access of a resource group to a certain user group. This final step, however, is designed in a highly confusing way. It took me some serious time to setup the correct permissions. Of course, next time I will be faster. But my client will certainly have forgotten these steps when his fourth client is about to get his personal login …

5. Time-based articles

Why do we have to decide? Some CMS are based on flat streams of posts (e. g. Drupal and every weblog system), some are hierarchy-based and have a central “page tree” which contains all the content (TYPO3, Contao, MODx).

If your website contains a large number of news, blog articles or events, you might not be too happy with MODx Revolution. Every news article has to be placed within the hierarchical page tree. And if it is article number 449, you will have to manage 449 news article in the page tree! Of course you can use folders (by category or year or month), but you have to do it manually. The sort order of the page tree is manual, too. It can be switched to time-based view, but not exclusively for news.

What’s missing is a seperate place for creating, listing and managing all time-based articles. The page tree is the wrong place. Maybe there will be an Add-On for this one day, which puts news article into a different database table and delivers its own managing panel. But that’s not the most elegant solution, because news articles really should be native resources and thus first-class citizens within the system. Once again I need to mention WordPress. It handles both native content types (“Pages” and “Posts”) equally well – using the CMS Tree Page View plugin.

7 Kommentare

Marc

Hi Gerrit,

you made some valid points. I just finished my third Revo site and yes, it is something different in comparison to Evo.

1. Ext is slow, I agree. The decision for Ext is reasonable, but the performance is not as good as I expected. But since the RC versions of Revo I have the feeling that the performance was improved, but I also see that at some point the current version of Ext doesn`t allow any improvements due its blown code. I really hope that Ext in version 4 will be much more performant.

2. Ack, although the possibility of a multiple upload is already an improvement. Also the navigation of the image manager is better, because you don’t have to load every folder you click. I also would like to see any database solution where you can tag, name and describe your uploads.

3. I never had a problem with that. I don`t see why a base href is bad. And for anchors just put a [[~[[*id]]]] in front of your anchor url. I like the relative URLs, otherwise we would have to define a URL in the settings as root, one more thing to change when moving the site. Okay, in Revo we have to change a lot more of settings when moving, because every folder can be located somewhere else. So I think a possible setting for relativ/absolute URL generation would be nice.

4. I don’t think that this is a problem of the core developers. The permission management is very granular, and I don’t think there is a way of defining such fine permission possibilities in an easy way. But I think it is up to us – the community- to provide a permission manager helper which lets you build MODx permissions more easily. Like a component where you can build often used permission scenarios in a few clicks. That component could assemble the resulting permissions in MODx syntax.

5. I think that something like that is already in development. Some kind of custom manager views. If you have a folder like “blog” with your entries in it, the folder doesn’t expand in the tree but displays a time- (or whatever-)base view of elements. Also I don’t think that these entries have to be regular resources, I think a resource should usually be used for defining how data should be displayed and not be used for holding the data itself. So a blog/news component should be a better approach.

6 (important): The customization of manager forms must get much more user friendly. The approach of managermanager in Evo was very easy to understand and let you create custom manager forms in minutes. In Revo this is too complicated. But I think here could also help a component with an easier UI and transforms it in MODx syntax.

Why I like Revolution and use it in favour of Evo:

- Sorting in the resource tree (customers love it) – quick edit / create of elements/resources while editing another element/resource. – drag&drop of elements in other elements/resources (all parameters in one form) – More unified handling of extensions – parameter sets – input/output filter work as expected (no cache/noncache fiddle anymore) – last not least the new API

Ryan Thrash

Great post and thanks for making it. I think all your points are valid, but do take exception to #3. It’s done that way for a variety of reasons, but we’re always open to suggestions and updates. We’ll carry on the discussion about that in your request on the site.

1. Ext is getting better but it definitely is heavy. That being said, it does enable us to rapidly iterate releases, definitely faster than if we were using a more manual approach. Consider the current Manager a reference, power-user’s implementation. The Revo Manager is built using the MODX APIs and you’ll probably see a lighter daily use implementation targeted towards content creators/editors in the future.

2. A proper media manager in general is definitely high in our priority list, but we REALLY want to do it right. Very right. We’d love to have your feedback and input into this.

4. 2.0.5 will make this better. The ACLs in Revo are incredibly powerful, and can be tough to get your head around.

5. This would be a custom Resource type, and thankfully something that Revo supports. Entirely doable as an Add-on and custom Manager page. FWIW, there’s a modification done by the .jp community that accomplishes exactly that for Evo.

Gerrit

Great Feedback, Ryan. I will see if I can provide you with some ideas for a proper media management – stay tuned!

@mrhaw

@Ryan what japanese EVO add-on are you referring to? :)

Official Eagles Jersey

drag&drop of elements in other elements/resources (all parameters in one form) – More unified handling of extensions – parameter sets – input/output filter work as expected (no cache/noncache fiddle anymore) – last not least

chraebs

Nice post! I’m also kinda MODx-Fan but did chuckle with most of your points because i felt the same.

Stumbled on it while i tried finding solutions to get more backend speed in REVO. We’re in 2.2.6 now and i stil feel the backend is heaavvvyy. Really hope EXTjs will speed up some time soon!

Andreas

Hi Gerrit,

I completely agree and I used to have the exact same complaints :)

1. ExtJS: yupp. annoyingly slow, still. Not much we can do about it.
2. Image Management: getResources, MIGX and so on do a fine job (for me). But I understand your issues. ModMore offers a nice gallery, which you might like. It’s not free though, but worth it.
3. what he said.
4. This shouldn’t be much trouble nowadays. I guess a bunch of updates might have solved this for you by now.
5. Try an addon called “Collections”. I stumbled across the same problem, as many others before us most likely.

I know this post is very old and you probably know most of this already, but I thought I’d at least point you to Collections, in case you haven’t heard of it :)

Andreas

Kommentar verfassen

Mit dem Absenden dieses Formulars erklären Sie sich damit einverstanden, dass ich die von Ihnen eingegeben Daten auf meinem Webserver speichere. Ihr Name, der Kommentartext und die angegeben Website werden für die anderen Besucher von praegnanz.de angezeigt. Ich gebe jedoch insbesondere Ihre E-Mail-Adresse nicht an Dritte weiter und nutze diese auch nicht zu Marketing- oder Statistik-Zwecken. Sie können alle Daten zu einem späteren Zeitpunkt wieder entfernen lassen.