This is a cross-posting from my (german) weblog, where I usually post all my CMS-related stuff: http://praegnanz.de/weblog/five-things-i-don-t-like-about-modx-revolution (The attitude might sound a bit ranty, but it’s not meant unfriendly at all...)
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.
MODX Staff
☆ A M B ☆
☆ A M B ☆
