What bugs me about MODx, and why

Posted by on 09/04/2012 Leave a comment (33) Go to comments

I tweeted earlier saying I'd had enough of MODx, was never gonna use it again, and that it was a "pile of fricken shite". The second part isn't strictly true as I've still got a client that worships it, but I won't be using MODx for my own projects and I won't be recommending it to anyone still deciding on a platform. The last bit isn't completely true either. Everyone knows there are worse options out there, that's why someone made the below graph. I never got round to coding the best CMS in the world, but in the mean time I'm playing with PyroCMS.

Learning Curve for Popular CMS

But yeah, there's no way I was gonna try and squeeze everything into 140 characters, so I decided to write this post to explain exactly what I dislike about MODx, and why.

My introduction to MODx

I first start using MODx a couple years ago when I started working for a company that, after having used many other CMS, was now using MODx Evo as their CMS of choice. Before I started, I was given the task of learning Revo because they'd be migrating "soon". Using a tutorial I had a simple blog site with comments up and running in a couple hours, so first impressions were good. It took a while to work everything out, but it wouldn't be learning if it didn't.

As it turned out, they only started using Revo around Christmas last year. I tried convincing them for ages that Revo was 'ready', but as far as the boss was concerned, it didn't have enough plugins or the plugins weren't good enough yet. Now, I don't agree with that at all. Sure there weren't as many plugins as evo, but who cares? Half of them will never get used anyway and if something you need is missing, make it yourself! And a lot of people do, but that's part of the problem.

First bad encounter

We had a project come in a couple months after I started that involved selling tickets on a theatre's website. Because the boss was obsessed with plugins, I spent a week trying out what options were available. As the client's requirements were so specific there wasn't a plugin that came close to doing what we needed. I insisted that we needed to start from scratch creating our own plugin, but he settled on Shopkeeper.

Shopkeeper was by far my worst experience with MODx. I had to waste time translating the comments from Russian before I could even think about working with the code, and most of that was in Russian as well! How is anybody supposed to work with that? The code was badly written anyway; when it's badly written AND in another language, shit gets bad. If you're gonna release code to the world, the least you could do is write it in the world's language.

Back to the point

The interface in Revo is generally friendlier than Evo's, but some parts of it just don't make sense. Take user management for example. When I went back to Revo, I spent an hour trying to fix the user list in the manager so I could update a user. Turns out you have to right-click. That isn't obvious at first, and I still forget sometimes. There should be two ways to do nearly everything, especially if the first way requires doing something just to see it.

Documentation

There're many tutorials out there if you're just getting started with MODx, and there's a lot of good stuff if you need help doing things in the manager, but when you're delving into the code you're pretty much on your own. The API documentation is entirely autogenerated, so that's of little use unless I know exactly which file/method I'm looking for. Which I don't. Not to mention it's all in one long list so I have to scroll for ages.

In contrast, CodeIgniter's user_guide works as both a helping hand for new users, and a reference for old. If I want to see how to run a certain query in CodeIgniter, everything's there in one page. Again the navigation could be improved for long pages, but all the information I need is there: clear, concise, and most importantly with examples. CI may not be a CMS, but much of its' documentation also applies to PyroCMS which is based on it, so it's still relevant.

Packages

Developing a plugin for MODx is relatively easy, you just add a namespace in the manager - and an action if you want a CMP. The rest is no different to coding any other snippet. That is, until you need to release it. Transport packages (and more specifically, the build script) are documented in detail, but that detail is either outdated, incorrect or broken. It took me a week and three rewrites just to get a basic CMP up and running in an installable package, and even then I still couldn't get /modExt/ExtJS or even Lexicons to work. Instead there's no language support and all the HTML is pieced together from Firebug's interpretation of other core manager pages.

When I finally got a working package, it turned out that MODx seems to skip the upgrade action of the resolver script for packages uploaded manually. I don't know if that's actually the case, that's what it appears to be doing. The end result was a hack to check if the custom option was set already before showing it as part of the install process. Not ideal, but it works. Would it mess up the upgrade process if the package came from the package browser? Maybe, but I have no idea.

If I go down, you're coming with me!

The package browser seems to load the entire list of packages on every search and filters the results locally in the browser. If you're on a slow connection, you're gonna be waiting a hell of a long time - assuming it's working at all. That's right - if you want to use the package manager but the central package repository is down, you're screwed. You can't even uninstall an existing package or upload one manually, everything just breaks. On the offchance that you happen to be testing your newly built transport package and the main package server goes down, then all of a sudden you can't do your job - even though you're working on a local install with local packages.

Final words

There're a lot more things that bug me about MODx, but this post is already a lot longer than I thought it'd be. It's good for basic sites, and to some it'll be easier to use, but I wouldn't dream of using it for anything complex. Much like my opinion on WordPress - it's a blogging engine, so don't try and turn it into a bloody shopping cart!

MODx is slow, and to me it feels clunky. Whether that's the oversized tabs, the way many plugins integrate (presumably due to limitations of MODx or the laziness of people that develop for it), or something else entirely remains unknown. Oh, and there's the Code Standards too. Anyone actively encouraging the use of spaces over tabs needs to be shot.

Uncategorized, ,
  • lossendae

    A lot of valid points in your article. However: “Anyone actively encouraging the use of spaces over tabs needs to be shot.” is wrong imo.
    Tab differ depending on the base OS you’re working with and if you work with people on github for example, identation become a real mess when using tabs over spaces.
    I’ll try tomorrow to link you to a more technical point of view, but in the end, using 4 spaces is more developper friendly than one tab (Plus, all IDEs – and even some excellent text editors – treat 4 spaces indentation like tabs so there should be no problem using them in the end)

    • http://gravatar.com/xeneco xeneco

      Tabs over spaces. always always always; after 9 years of coding (C, HTML, PHP, CSS, JS & MySQL). I’ve never seen the point of multiple spaces for indentation when a tab works perfectly and is uniform across editors (really it is, when used properly). Not to mention the extra file size multiple spaces take up. My only issue with tabs is not with tabs but that MySQL command line doesn’t like them

      • codeM0nK3Y

        I agree for the most part, but to be honest I couldn’t care less about file size. People say spaces are best to work in different editors but unless I’m missing something stupidly obvious, you can only change the “visible” width of a hard tab. Convert 4-space tabs to 3-space tabs and you’ll be left with a bunch of space-pairs left all over the place.

        With that said… As much as I hate spaces, standards rule. At the end of the day it doesn’t matter what people use, as long as we’re all using the same thing. PSR-2 states 4 spaces, so I’m gradually converting to spaces too. Why? Because if I want to work on open-source projects, they’re probably using PSR-2. People can bitch all they like about spaces vs. tabs all they like, but as long as we’re all using different things, our lives are gonna be hell. The only way things will get better is if we just suck it up, pick one way, and stick to it.

        As for MySQL CLI, I can’t say I’ve ever noticed. I usually use Sequel Pro so I very rarely need to use the CLI for any massively complex queries.

  • Tim

    You’re right about many issues here.
    MODx does lack adequate documentation for many things.
    Shopkeeper is simply one of the worst examples, many addons are better than this.
    ACLs / user management IS one of Revo’s many biggest weaknesses. MODx must run up a 90-degree angle hill to catch up to other CMSes in this area. Bob’s Guide is good for setting up for 1-2 simple user groups but more than that and you need to be a rocket scientist.
    MODx doesn’t have code standards, really. Addon developers can do pretty much anything they want so long as it’s a package. They’re not strict enough about package format and where things should go etc.
    MODx is trying to catch up to other CMSes but they will always be a niche developer CMS until they fix ACLs, documentation, the manager…too many things all at once…I would start with fixing ACLs to be easier ASAP, plus documentation, then try to improve the manager and various other things…

    • codeM0nK3Y

      I agree Bob’s Guide can be incredibly helpful – I used it recently when I was working on something that needed to set/get extended fields. For some reason or other it didn’t work at first (possibly due to variable scope, can’t remember) but a couple tweaks later and the rest was easy.

      I’m tempted to code a script that’ll generate a build script along with a skeleton core/components/package, if only to encourage people to code offline and use version control. I vaguely recall finding one and using it to generate the basis of my first build script, but there was an awful lot of stuff added in “just in case”. For example, it’d add the code in for snippets even if you don’t have snippets.
      Even the best solution could only do so much as nobody can know if, one day, snippets might be added; but I strongly believe that if it was easier to ‘do it right’, more people would follow suit and the world would be a much better place.

      • http://bobsguides.com Bob Ray

        Many good points, but it sounds like you guys don’t know about the MyComponent/GetMyComponent package (or didn’t like it). I use it all the time.

        • codeM0nK3Y

          Hi Bob, it seems WordPress has stripped out half your link code, but I remember downloading that package when I was figuring out my build script. It could well have been the skeleton I was thinking of in my last comment. I can’t be certain though as I rewrote the package so many times that I lost track, and that’s *with* git :P

          • http://gravatar.com/bobray99 Bob RayRay

            MyComponent has gotten a major facelift and it now has a UI and installs like any other package. You edit one config file, it creates the complete skeleton of your package, and you fill in the code. Then, you run the build in the UI and you have a package.

            You can create objects in MODX (e.g. menus, property sets, elements, etc.) and MyComponent will export them to the build files.

            It will also write your lexicon files for you.

  • Tim

    One area where WordPress sucks is there’s TOO many plugins and they are TOO rigid in what you can do with them…

    • http://j-carlson.com Justin

      Thank you. This is what I have been saying for years. Geared way to much toward non-developers. There is no good way to trouble shoot general development hurdles without being inundated with all the half baked crap in the ecosystem.

      And even if you can find all the plugins you need, they are always implemented in vastly different ways – making it impossible to easily train a client how to use the admin side.

  • http://www.susprod.com Eric Wargo

    Saw this from the #modx stream. I’m a modx fan for sure but just wanted to say that I thought your graphic at the top of the post was hilarious.

    • codeM0nK3Y

      Thanks :D
      I can’t take credit though – someone posted it in an IRC channel a few years ago and it’s just one of those things you never forget ;)

  • http://www.redtoadmedia.com Anne

    You’ve made valid points about a lot of things.. which is one reason I haven’t leapt over to Revo. We still use Evo mostly. That said, I do know the guys have hired a UI/UX person to help with some of the issues you mention and I also know they are working towards resolving the documentation issues. But you know, it is open source. We can work to help address the issues we know are there. Documentation is via wiki. I kinda feel like if I have something to complain about I can put in some effort to fix it. jmho.

    thanks for the post.

    • codeM0nK3Y

      I used to use the Trendy manager theme which was nice and relatively minimal, but all of a sudden (perhaps after an update) it prevented resources from saving properly so I sadly had to ditch it.

      Don’t get me wrong I completely agree with you when it comes to giving back to the community, but I would avoid writing any documentation until I fully understood what I was doing with it. The only thing worse than no documentation, is bad documentation. I can however start building a generator for build scripts based on what I know already. It may not do a lot at first, but it can be added to later either by me or anyone else that chooses to help out.

      No worries! Thanks for the comment ;)

  • http://www.kenters.com Jeroen

    I agree almost 100%. I really want to like MODX, but had too much trouble lately. Lots of bugs, missing functionality/packages and performance (front & back end) wasn’t that great either. Even had to go with Drupal on a project that was 75% done in MODX already. Also check http://kenters.com/weblog/2012/04/02/i-have-been-drupalized/ for my blog on MODX vs Drupal.

  • http://www.markhamstra.com/ Mark Hamstra

    Thanks for your honest feedback and criticism.

    If anyone ever wants to make a change to the documentation, but is afraid they don’t know enough and are afraid it will not be entirely correct – remember that the ones that do know it all are probably busy working on other things, and that it’s easier to review and correct than to write documentation from scratch.

    In other words, just go ahead: update, add and make it better as much as you can, and then ask someone to review it if you’re not sure. I’ll gladly promise that if you shoot me a link to what you did via mark at modx.com or @mark-hamstra I will gladly take the time to read through it and correct it if there are any mistakes in there. I really appreciate people taking the time to help out and improve the docs.. just remember that it doesn’t have to be perfect first time ’round – we can (and should) iterate improvements to get to where we need to be.

    Re the package browser: (1) it’s paginated and doesn’t filter locally, there’s just some time between requesting and receiving the data; (2) searching locally for packages does not even attempt to make a connection and as of 2.2.1 you can also search locally for packages if cURL is not available and (3) uninstall / remove / reinstall also does not need the package browser and is all done on the server itself. I’m not sure what happened to make you think it all goes down in case the MODX server goes down, but beyond not being able of downloading new addons or versions from the package browser everything should remain functional. The package browser (and the server-side REST interface) are due for an overhaul in 2.3 as well, which will smoothen the experience there as well.

    I think it was not very professional of your client to force a Russian addon onto you and am sorry for the bad experience that resulted in.

    There’s definitely room for improvement in areas such as the manager and documentation, and I want to ensure you a more pro-active stance is being taken on things like that. Dustin (who actually came up with the new Revo 2.2 Login screen design before joining the team!) will be working on lots of UI/UX stuff and we’ll see his first public work in MODX Cloud soon.

    Exciting times ahead, I can promise you that. :)

  • Brian Larson

    I feel compelled to jump in from a designers’ standpoint. MODX is tremendously friendly to both developers AND designers. Personally I think that’s hard to find in a CMS. And lets remember that MODX is a CMF platform and NOT just a CMS—hence the complexity. I find it rather awesome that someone with NO PHP knowledge can wire up a full custom design by learning a MODX’s super flexible tagging system and not write a single line of PHP. Somebody set me straight if that exists elsewhere. I’ve seen MODX often compared to Expression Engine. ??

    • http://id-web.ca Gabriel

      Glad you mentioned the CMF distinction, because I think it’s an important distinction. I think that there are some good points made in the post, and criticism like this is important and helpful, but at the same time MODx is not really the same kind of beast as the others. I’ve never seen anything so easy to use for making websites with content management capability. But I’ve seen easier ‘Content Management Systems’. Does that make sense?
      And at the same time, I have recently had a couple totally green computer-novice (yes, they still exist in 2012) clients who were baffled by WordPress, but totally “get” the MODx manager. I was actually a little surprised to hear it; it seems easier to me, true, but I’m a geek…

  • soma

    I think you’ll like processwire cms/cmf. I moved away from modx for similar reasons.

  • Maurice

    Hi,

    Just starting with MODx and I must say I was impressed by it’s possibilities and the ease of using them. I still think it is much quicker than any other CMS I’ve used, although I must admit I haven’t created a large (much content) site in it.

    It is known that ExtJS 3 is a bit on the slow side (and ExtJS 4 is, although the thought behind it is great!, even worse).

    I do admit that some parts are hard. The ‘Articles’ addon, released by one of his own developers, is a laugh. Unfinished, the install runs into an error and the documentation is not completely accurate. It seems like no one is doing the quality check.

    But on the other hand: I tried your PyroCMS demo and after a screen with a username and password (where must I enter them?) I didn’t know what to do. Click on my first link opened another window (and again this page didn’t make sense to me), the second link I clicked resulted in an error. So for me, I will not bother spend more time on that CMS. And I know CodeIgniter…

    I’m really curious what MODx is gonna bring in the future. I know (from another partner) that his clients really LOVE the CMS (so easy to use!). They have tried several before sticking with MODx.

    I agree more work has to be done in the area of documentation. So I’m follow Mark’s advice and see if I can add my comments to the ‘Articles’ add-on page.

  • http://www.dangibbs.co.uk Dan Gibbs

    When I found Evolution my work was more design orientated and I loved it. Now that I am more involved in development I really admire the flexibility of Revolution.

    I have created a lot of packages (unfortunately all privately and unreleased for the time being). Initially I had the same issue with you in regards to the transport packaging system and going back and forward with inconsistant documentation. With that said after jumping a few hurdles I now find it extremely easy and quick to develop and appreciate some of the more complex aspects that can be needed.

  • http://peterb.co Peter B.

    Can’t say I’ve tried Shopkeeper. I don’t know why anyone would use anything but FoxyCart for eCommerce sites. I can get it to work with any CMS.

    I do think one needs to be a programmer to get the most out of MODX. won’t ever do a WordPress site because it’s too rigid and once one has more than 10 pages, it’s no longer a blog, but a CMS website for which WP is sorely equipped for.

    • codeM0nK3Y

      I can’t say anything about how it is now as I haven’t used it since, but Foxycart was one of about 4 or 5 different ‘potential solutions’ we tried out. At the time it didn’t offer the flexibility the client needed for their ticketing system. If I had it my way the website would’ve been based around a custom ticketing solution, rather than hacking apart other plugins designed for a different purpose. Standard shopping carts treat everything as ‘a product’, and rightly so. That means that integrating with a calendar, for example, could be impossible depending on what’s used. A ticketing system, while still ecommerce, is not a normal shopping cart and shouldn’t be treated as such. But no, apparently building a custom solution would take too long – despite there being several frameworks out there, some like CI Bonfire also providing ACL as standard.

      Some people just need to open their minds and try something new every once in a while :D

  • http://www.my619.com Kris

    I’ve been using MODx for 6 years now and the move from Evo to Revo was not easy. Evo is so fast in the manager area. Revo is a bit heavy and clunky in the manager compared to Evo. I almost left MODx when Revo rolled out, but after refusing to give up and being patient with it, it’s grown on me. I still can’t find another CMS/CMF with its power but yet ease for someone simply needing to back a template in to the system. I played with WP some, but I find its templating system not nearly as easy as MODx. Also I’ve been watching my friends with WP sites have so many security problems (maybe b/c of all the kiddy script plugins).

    I still firmly believe in MODx, but the Manager UI really needs some work. As one person pointed above in the comments, it’s open source, so you only get what you put in to it. I will continue using Revo for the foreseeable future, but I hope some of the issues brought up here are resolved.

  • anonymous-ass-clown

    I love parts of MODX — the underlying framework (xPDO) is elegantly architected (hard for noobs, but solid). Drupal, WordPress, Joomla, etc. can all suck on MODX’s templating and its underlying framework.

    But how can something that is so awesome for scripts and templates have a manager that sucks so bad? It seems that the manager was designed to be easy for its developer to maintain, but everyone else has to suffer (including your web server). It is painfully laborious to do certain common customizations. WordPress does exactly the opposite: it’s manager is fantastically easy for millions of common users, but any WP dev has to bleed to accomplish certain tasks because its code is just awful.

  • Tom

    The last comment regarding the manager etc. is quite good. WP is awesomely easy to manage but awfully hard to template, modify, etc., unlike MODx, which even after several years is still having growing pains etc. High expectations and all that.
    Also it’s hard to know if #modx staff have read and considered anything said here…they can’t respond to every single blog complaint etc. but they could do something simple like say, ACLs will be much improved in version 2.2.2, manager will be faster come version 2.2.3, etc. etc. I think their heads are in the cloud and they haven’t walked down to earth yet. :) :)

    • http://www.modx.com Mark Hamstra – MODX Complete Team

      We’re definitely listening :) Here, the forums, twitter, facebook. Did I miss anything? As you say, we can’t respond to everything. But yes, we are definitely listening (and discussing what is being said, too!).

      I love the MODX Cloud pun there ;) You could say there’s some very smart heads in the clouds there now, and for a good reason, too. MODX Cloud will be the key to shaping the MODX future to our vision. That’s not to say everyone will be forced to use it, but it will create revenue (which can and will be used to hire more smart minds), it will give an insight into what users are doing with MODX and what more they need, and it will make it a lot easier for non-techies to get started with and build upon MODX on optimized infrastructure. There’s some great features with Cloud that will definitely add value to its users, but most importantly it will be able to give back to the core product: MODX Revolution. There’s some great improvements in 2.2.1 that came directly from MODX Cloud already and that’s just getting started.

      The entire team is dedicated to making MODX the best solution for site builders, and it’s not a question *if* but *when* we will have things like ACLs and front/back-end speed majorly improved. As Ryan has posted in his recent blog and in the forums, those are two of our main priorities (he listed six, I think).

      That said – there have been great community contributions in those areas in the past, so there is an opportunity for people to help out directly to help us speed it up. We’re still a small team (though up to 14 from 5 not too long ago) and will definitely want to work with the community on making things happen.

  • http://designfromwithin.com DESIGNfromWITHIN

    I have to say I really love MODX (especially Revo).
    Sure the Manager is not the fastest out there and it has its flaws, but when I show a client the logical resource tree and the template variables tab they love it. For templating and adding manager options MODX really is amazing (MIGX, Chunks and Template variables anyone?)

    I also use WordPress and Magento sometimes and everytime I do I miss MODX, to me it is a flexible and powerful system for designers/developers.

    I created the Flexibility template (still beta at: http://designfromwithin.com/flexibility/) and it saves me hours and hours of work with starting most MODX projects.

    My biggest TO-DO’s for MODX are:
    - More speed in the manager.
    - Better docs (I will help with this for sure).
    - Great E-commerce add-on.

  • Paul Maxtead

    To me this post says more about your relationship with your clients, rather than the shortcomings of any CMS. Add-ons can be great and there is nothing wrong with using them, if they do the job intended. You really don’t need to write yet another script to give you a feature that is covered by an existing add-on; this is pointless and a sure fire productivity killer.

    You mention Pyro CMS frequently and whilst this new platform (yeah i know it’s CI) looks promising it is leagues behind MODX in terms of capability. I would say the opposite and Pyro was suitable for small sites and Revo has the power to sit at the enterprise level.

    The backend of Revo is slower than Evo, but is really isn’t that bad and you will see this if you have ever built a site with 1000′s of resources. Front end performance can be blazing fast, that is if you are doing things correctly; see Mark’s post here about caching: http://www.markhamstra.com/modx-blog/2011/10/caching-guidelines-for-modx-revolution/

    I second the comments about ACLs – whilst most scenarios are achievable the setup is ultra complicated and takes an age to master. Ecommerce also; Vision Cart was looking great but seems to have stalled somewhat. Migrating a site to a different location was a breeze in Evo. With Revo you need a spare few days and a defibrillator to get anywhere.

    No CMS is perfect – yes MODX has some bad points but also has its USPs – total creative freedom, not being bound by rules etc. and the mature way the community / core team accept and react to criticism is so refreshing.

  • http://gravatar.com/benduffin Ben Duffin

    ModX is a total A$$ to develop Backend stuff for ( which is my primary role in life, creating Business Management Solutions ) – IO have been trying for weeks and all I have managed is a dumb CRUD thing lifted from a Doodles tut that doesn’t actually help you learn shit! Its a “copy n paste” exercise from start to finish.

    Now, if there was a way to create CMP pages WITHOUT all that extJS crap ….

    • https://www.markhamstra.com/ Mark Hamstra

      Newsflash: MODX doesn’t care one bit about what you use :) While people tend to use ExtJS to have it fully blend in and to take advantage of connectors and processors, that’s not a requirement.

      Just create your namespace, add a controller (and an action/menu to get to the page) and just add whatever you want to use as return value of the controller file.

      Eg:
      http://rtfm.modx.com/display/revolution20/Custom+Manager+Pages+Tutorial
      and for the next minor planned version:
      http://rtfm.modx.com/display/revolution20/Custom+Manager+Pages+in+2.3

      • http://gravatar.com/benduffin Ben Duffin

        So I found out yesterday from a chap called Lucas on the ModX forums – I take back the statement about the backend development – without the constriction of extJS we will be able to work at a much more productive pace – I’m almost ashamed to admit I’m excited about it – we are about to start a cool project and boss wants me to build it on modx! We shall soon see how fast I can build up the consoles required for management …

        But the ModX Doodles / other tutorials should have made this info more obvious! At least I know now – hope others found the info useful!

        BTW Mark – Browsed your site LOADS while learning modx, a good source of information!

  • ?????? ?????????

    I from Great Russia and I said: (khm…) just learn new world language.