MODX: The Best CMS You’ve Never Used?

By Zack Wallace
We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now

MODX is a content management system that was first released in 2005 by Ryan Thrash, Raymond Irving and Jason Coward. They created it to give them freedom of design and yet retain robust security which they felt other CMSs didn’t allow.

MODX logo

In 2009, MODX was released as Evolution and Revolution. Evolution was built and maintained on the original codebase, while Revolution was entirely rewritten. This article is based on Revolution.

Within the MODX manager, you have access to a built-in package library which contains most of what any developer would need for common tasks. Creating your own plugins and scripts is quite trivial, and there are some good for-pay extras out there too.

Visit the MODX Home and about pages for more history and feature information.

Have We Met?

If you’ve never heard of MODX before now, just realize it’s a long-lived and pretty powerful engine that is often compared with the likes of Joomla and Drupal. Some also compare it to WordPress, but that’s not apples to apples. WordPress is meant to be usable out of the box by non-technical people. In fact, MODX has been described by some as the best CMS you’ve never used.

In general I would summarize MODX as a framework for developers to build with, and not an out-of-the-box, point-n-click website builder. MODX would not be the best choice of CMS for a person with no PHP or HTML skills. There are no menu builders or lists of modules to drag and drop in predefined theme positions.

MODX may be better described as a CMF (content management framework) than a CMS. You could use just the API purely to control endpoints and scripts with no pages or posts at all, if you wanted.

Digging Deeper

MODX, like many popular frameworks, is built with PHP. It can run on popular servers such as Apache, IIS, Lighttpd and nginx. Its database of choice is MySQL, and it uses xPDO as an ORB (object-relational bridge). xPDO is built directly on PDO, and uses an active record style pattern for database access. It can be compared to the likes of Doctrine or Propel, for example.

The Manager is built with ExtJS, Smarty templates, and MODX’s own API. Editing the manager itself and its dashboards, menus and other features is an ability built right in to the UI. You have fine control over everything in the Manager as far as what you want your clients to have access to.

Custom menus, and very fine-grained ACLs (access control lists) round out your back-end options. Security is probably one of the top features MODX fans love about it, though understanding it fully involves a significant learning curve.

MODX itself is backed by an LLC, which is MODX, LLC. They offer other products such as cloud hosting and consulting services. MODX is not an SGP (some guy’s project); it has a bit more staying power than some other modern CMSs that just popped up, created by one person, managed in their spare time. You can be pretty confident that if you choose MODX for your projects, it’s not going to disappear any time soon, and good support is available.

Education and Documentation

MODX is well documented, including videos, books, and the standard community forums. The forums, incidentally, are built on MODX itself, using freely available extras, and you can find threads over 10 years old still lingering.

All in all, you will want to check out the Revolution Manager Tour, watch the Video Quick-Start Series, and browse the documentation such as the Overview to get well acquainted.

MODX also has a fairly active Slack channel where friendly people are always available to answer quick questions and gotchas.

The Installation

MODX is only currently installed by downloading the ZIP and extracting to your web folder.

Download MODX

As far as updates go, there’s no self-updater in the core product. However, there is an extra which does the upgrade for you just as easily. All of the extras themselves can be updated through the manager.

The project is managed on GitHub, which will always contain the latest snapshots of the project. You could install this way, but downloading from the main website is the preferred and normal method.

Why It’s Awesome

MODX is something of a power user’s CMS. Out of the box you get a blank template to design with, and hundreds of settings to change how things work. There are no wizards, drag and droppers, menu builders, widget organizers, template settings, strange forced file system hierarchy structures or magic functions to throw everywhere.

I was hunting for a CMS some years ago as a means of converting some older, hand-coded sites into a CMS. Nothing I found made this very easy without a lot of tweaking and learning complex template structures. When I installed MODX, there was this link to BaseTemplate; I pasted my HTML in there, and it just worked, no fuss no muss, as they say, and nothing broke.

In fact, if you’re typically a hand coder, MODX may be the best CMS for you. The learning curve to creating hand-coded websites is extremely small.

When you want to develop multi-language, multi-site websites with separate paywalled content and a customized manager for your clients, then you’ll experience what MODX can do!

Everything about MODX is rather unassuming. For any given task you need to complete, there are typically multiple ways of getting it done.

From simple to complex, MODX can do it all. It’s been used to build API endpoints, forums, blogs, business sites, brochure pages and multimedia sites. It can handle languages, advanced security permissions, and customizing of the manager for client logins.

Assembling a Web Page

MODX uses a stack of pieces to assemble a web page. It uses what are called Templates, Snippets, Chunks, Template Variables, and its own template tag system. These are all called Elements:

Elements tree

You can get any system data from within templates — such as logged in user data, current page data, metadata, system-wide settings, template variables, chunks, snippets and placeholders — by using tags.

The MODX workflow involves coding your HTML templates and parsing out reusable HTML into Chunks and reusable dynamic PHP stuff into Snippets. You can set up any custom fields needed for that template as well. Next you’d create a Resource, assign it to the template, fill in the fields, and Bob’s your uncle!

A Resource is the basic definition of an endpoint; it’s something found at a URL. You could call resources pages, but they can be used for much more than that. You can set the actual content type of a resource to be something other than HTML, such as PDF or binary data. Then you can set the content to either download from the browser, or display directly. A resource could even just point to a file, or link to an outside page, or be used as a symlink to other content on the site.

A Template is the frame around which your resource will be displayed. All resources are assigned a template.

A Chunk is reusable HTML or JS or whatever you need that isn’t PHP.

Snippets can contain PHP. They have access to the MODX core and all its objects.

A snippet can call a chunk, a chunk can call a snippet, templates can call either, and so can resources. Really they are the 4 horseman and can pretty much assemble any conceivable content required while maintaining darn good separation of concerns.

A Plugin can extend the core by hooking into one or more of many events.

A Template Variable is any custom data a template might need, and for which a resource is able to set. For example, it’s common to have a TV for a custom image like a page banner, but then each resource can assign a different image for the template to show. They would be like custom fields in WordPress, but more powerful.

You can organize any of these elements by using Categories. Be sure to make use of categories so that your chunks and snippets don’t get out of hand and cluttered!

All nicely tucked in a simple tree that you just saw.

A Quick Look at the Manager

The manager is built with ExtJS. With that comes interesting abilities with drag and drop, form customizations, dynamic tables, right-click context menus, and more.

You can right-click resources for various options — including Quick Edit — which will let you edit the resource in a popup while keeping another resource open under it.

A handy feature of media management is that you can set up media sources which are then controlled by security. The end result is you can have it be that when clients log in, they will only be able to see the folders you assign for them, and even assign read-only access.

The system settings are based on namespaces. You can even create a namespace for yourself and invent arbitrary settings you may use elsewhere in your app. I’ve done silly things like create a company namespace and settings such as primary company phone so that I can use the same number through the site. Then if the number changes, it’s only changed in one location. I give users access to changing these settings.

All in all the manager is not complicated to get around in, despite the advanced features available.

The default dashboard


Resource tree

Notice the text Website in the image above. This is a Context, which basically means the context that viewers are in when they look at your website. When logged in to the manager, you are actually part of the Mgr context. Different contexts can have completely different resource trees, user permissions, access controls, language — the whole nine yards. The Mgr context is hidden from the tree by default.

Think of a context as being an entirely different website; even advanced sites may rarely take advantage of creating additional contexts. One common use of a context would be to create a type of member only website within the main website for authenticated users. All you would have to do is not allow public (guest) access to the context, among other things.

I’ve also seen contexts used simply to organize similar resources like a set of static files, or when serving non-HTML content types. Use them however you like! One caveat is that if a user is logged in to one context, it doesn’t mean they have access to all of them. If you wanted a type of single sign-on for all contexts, it would need extra development.

A context could be used (without security) to simply separate site areas, like a message board, blog, or a store. Some use it for alternate content for different languages. It’s one of the relatively hidden power features of MODX that many never even notice or make use of!

Templates and Tags

I mentioned that MODX has a built-in template tag system. Here’s how it works, briefly.

Each tag begins and ends with double brackets [[ ... ]].

A character is used to denote if you are calling a chunk or a resource field or system settings etc. They are:

  • [[*...]]: An asterisk retrieves resource fields. That is, specific data entered for the current resource, such as the page title or even the main content. It also looks up template variables.
  • [[++...]]: This is looking up a system setting, such as site_url or a custom setting like company_phone1 if you’ve created one.
  • [[+...]]: This is a placeholder.
  • [[~##]]: This generates a URL to a resource by its ID, such as [[~32]].
  • [[$...]]: This pulls in the HTML from a chunk.
  • [[...]]: No symbol at all will call a snippet.
  • [[%...]]: Pulls a language string.
  • [[-...]]: MODX comment.
  • [[!...]]: The exclamation point tells MODX not to cache the output of the tag; use it in conjunction with previous symbols. If you called [[!$SomeChunk]] then the output would be parsed each time, rather than pulled from the cache. Sometimes caching can bite you! Learn about it here. Did I mention MODX has a powerful cache built right in?

Tag Parameters

Tags can use parameters and filters to customize their output. For example, you can add some parameters to an auto-generated URL like this:

<a href="[[~17? &section=`food` &sort=`asc`]]">Here</a>

As you can see, the syntax of using parameters is not unlike parameters in a normal URL query string. A question mark denotes the start of a list of parameters, and each parameter starts with & and places the value in backticks.

The output of the above would be:

<a href="yourpage?section=food&sort=asc">Here</a>

A snippet can receive extra data when called in a similar manner:

[[!MyCustomSnippet? &input=`something tasty`]]

Here, a snippet named MyCustomSnippet is called, and given the extra data named input, with a value of something tasty. In PHP, you would get a variable automatically created called $input, which you can access in the snippet.

Tags can be embedded within each other. A very common tag is this one:

<a href="[[~[[*id]]]]">Link to this page</a>

There’s a resource field [[*id]] embedded in the link tag [[~#]]. Inner tags are parsed before outer tags.

In another case, where you might be calling an HTML chunk and passing it some dynamic data pulled from a snippet, it might look like this:

[[$AChunk? &data=`[[!GetTheData]]`]]

The chunk tag is sending data to the chunk, but uses a snippet to figure out what that data actually is.

Because the above tag is calling a chunk, which is only HTML, how does it read the data values? They are automatically available with a placeholder tag like so:

<h2>A title</h2>

Placeholders are used most frequently in chunks like this.

Output Filters

Tags accept more than just parameters; they can also utilize output filters. Filters run post-processing code against the output. Multiple filters can be chained together. The easiest example would be changing the case of a string.


A filter begins with a colon; it must come before your parameters. Here are a few chained filters:

[[SomeSnippet:ucase:replace=`this==that`? &param1=`Go big`]]

Here, the Snippet result is first converted to uppercase, then it runs a special replace filter to change all occurrences of this to that. After the filters, the parameters are listed, starting with the question mark as usual.

There are quite a few default filters, so check them out here.

Even cooler than the built-in filters is that you can use any snippet as a filter. All you have to do is use your snippet name like a filter:


Whatever HTML is sent by the CallingChunk code, your mySnippet can access and change it however you like with your own PHP. The value of $CallingChunk would be available in your PHP with an $input variable, and you would simply return the edited value. (See here for more details.)

Filters can be used for logic, with full if then else flow.

If That Weren’t Enough

There are so many things not touched on: structuring the tree, handling repeatable content, accessing the database or creating custom tables.

You can categorize content, have parent/child relationships, create containers, publish/unpublish dates, group content for security purposes, create plugins to validate data your clients may enter.

The list goes on and on. You can edit your content types and MIME data, page extensions (use ‘.html’ or not), or create an Amazon S3 bucket as a media source.

You can edit in the default raw text/HTML or install extras that enable TinyMCE, CodeMirror, or ACE. There’s an editor for Markdown. And there are even extras for tracking revisions or exporting your custom code for use in other MODX websites or to share with other developers.

Elements have properties which are like system settings, but only for that element, so if you create an awesome snippet of amazing PHP, you can use properties as a way to create default settings for it, which users can then change with their own property sets.

Template variables can be assigned categories so that they can be grouped together when editing resources. Very handy stuff when creating custom content that clients can change.


The codebase of Revolution is showing its age, and doesn’t utilize some modern PSR standards such as autoloading and namespaces, nor does it use Composer for packaging.

The third rewrite of the platform, dubbed MODX 3, will move the core into modernity. Don’t let this prevent you from trying MODX though: with age comes wisdom, and the entire MODX platform is quite capable, mature, secure, and extensible. However, you’ll see developers criticize the older code patterns.

A second issue is the use of ExtJS. This framework is quite nice, but the issue is MODX is pretty much stuck using an older version of it. The current manager cannot be updated or it will break many 3rd party add-ons.

Future versions of the manager will likely not use ExtJS at all, or be locked in to any library for that matter.

Beside those issues, the only problems I’ve ever had with MODX stem from server configuration. This has caused conversation about who are the best MODX friendly hosts, such as this MODX forum thread.


Edit home resource

I’ve covered a lot here and hope I’ve sparked your interest to give MODX a try.

Like any tool, it has specific use cases where it fits best. MODX is not my recommendation for a non-technical person to build a website, but it’s a great choice for a developer who needs to give clients protected access to editing content.

MODX is excellent, with a pretty strait learning curve, if you’re a developer and want freedom to design how you wish.

Since SitePoint has never really covered MODX, I’m curious who has tried it. Did you love it or hate it? Do you have any more questions about it? And would you like to see some more coverage of it? Let me know in the comments.

We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now
  • Cracheur DeRat

    With this cms can we personalize it to do all kind of website ?

    • donshakespeare

      Absolutely. There is no inbuilt restriction to what you are able to do.

    • It can do more kinds of websites than you might think.

      Some have used it just for the API with no backend management at all, perhaps as a RESTful server.
      You can build a hand-coded website, anything from a single-page brochure to a blog or custom ecommerce store.
      You can use it to host physical files and mask them behind URLs so that the server paths are hidden.
      You can serve up non-HTML content if you like, and serve PDFs or binary data or JSON or CSV, XML, or text files.

      Unlike many CMSes, MODX starts relatively empty of any assumptions about your design. You start from scratch, that’s why I called it more of a developers CMS.

    • MODX is a “blank canvas”. What you put in, you get out. No extra HTML code bloating from plugins like WP

    • Cracheur DeRat

      Thanks for answering, i’m looking for a simpler cms than Drupal do you think that MODX can do the work ?

      • donshakespeare

        You can always get instant help from the awesome individuals on the MODX forums and MODX Slack channels. Let’s just say the answer to your question is YES!

  • Marek Králík

    After all these years it still completely fails at the UX aspect of working with backend administration. Thats why WordPress is in lead, not because it has nicer codebase but because it’s super easy to use and consistent across the board.

    • I’ve never run in to anybody who has any problems working in the backend.

      I’ve heard lots of people complain about the WordPress backend. Heck, I don’t even like it! Especially when trying to do a custom theme and not using certain features, which then breaks those sections in the backend. In other words, the backend of WP couples too tightly with templates.

      • Marek Králík

        How can you say that you never run at somebody having problems in backend when you just did.

        People have ability to become very effective even when using very bad design and mostly they would never complain about it. If the user doesn’t like the experience, he just wont use it.

        I am guessing here but:
        MODX users are mostly PowerUsers, that are ok with some kind of discomfort.

        • I still don’t understand. What is the problem with MODX backend? What “UX aspect” are you talking about?

          • Marek Králík

            I am not going to do the full UX audit on whats wrong with MODX, but I will highlight the first thing that striked me in the eyes when I looked at the demo page today.

            Its the bad clarity for non-technical users.

            Take following user story:
            – User has just installed the cms on his website and wants to create new page with contact information.

            – User logs in. Sees section specifically named PAGES. Clicks and see button “Add new page”. Fills the information he want to publish and so on.

            – User logs in. Sees panel with kinda familiar icons that is titled “Resources” (WTF is resources he might think). He has to hover them to see the description what the icon really does. But there are actually two icons that looks similar (paper list). One is outlined and the other is filled with color. One is called “new Document” the other is called “New Static Resource”. If he guess the right one.. he moves to the next step to fill the information he wants to publish and so on.

            If you fail to accept that this naming is actually critical to good UX, than I am wasting my time here :)

          • There are definitely interesting parts to the UX in WordPress that I’d love to see MODX learn a thing or two from. WordPress is no doubt easier for a non-technical user to get in to, but that’s also because that is the primary goal of WordPress: to democratise publishing by allowing anyone to publish.

            The goal of MODX is to provide what has been coined “Creative Freedom”, or the ability to build anything, any way you like it, on top of the platform it provides. That means there very little assumptions about the type or form of what is being built, which means it’s mostly going to be useful to a designer or developer that knows what they’re doing – there’s not a lot of handholding.

            To take the term “Resource” in MODX, that is still the best term I can come up as a resource can be a “page”, “post”, “collection of pages”, “rss feed”, “javascript file”, “css file” and so on. By calling it a “Page”, you’re excluding a whole host of possibilities and use cases.

            But you are right, things like that are pretty developer oriented. I’d like MODX to become more welcoming to the non-technical users, and the new “hello world” page in 2.5 is a showing it’s moving in the right direction. Rather than the completely blank white page in 2.4 and before, the welcome page explains how MODX works and gives the user something to experiment with. As far as user experience go, that and more mobile friendlyness are two pretty recent steps in the UX that have a very real impact on users.

            You’re also comparing bananas and apples though, as the UX for a “everyone should publish blogs” system and a “build whatever you want” system are always going to lean in favour of one group of people or the other as you can’t please them all. It’s all about balance ;)

          • Marek Králík

            I am mostly alright with your comment. I just disagree with the last bit. People just wants to publish content on their websites ONCE its build -> and that the important part. You spend like a month building your website using your “Resources” blocks and stuff. But than will come the other guy and spends a year or two working with your backend dealing with this developer friendly abstraction that doesn’t make sense for common user. :) Like you said. It’s all about the balance.

          • Yeah, true that.

            MODX has a number of tools (for the developers) to make the manager more non-techy friendly for when it reaches that stage. Varying from a lexicon (language file) change that replaces “Resources” with “Pages” to an extensive permissions system to remove features that aren’t (or shouldn’t be) used, completely custom manager themes and a bunch of plugins that help automate or improve the experience further.

            MODX has leaned towards the developer in the past, but that’s slowly changing with more focus on the end-user, which is a good thing. As with everything it would be even better if that was done last week instead of tomorrow :P

            If you do end up doing a full UX review of MODX some day, let me know so I can help get improvements added to the project ;)

          • Marek Králík

            At this point I’m just curious here. Can you provide some demo/video of back-end administration that was edited for daily use? Some example of “how good it can get”.

          • You’re complaining about pages being called resources? The reason is because they can represent so much more than just pages (MODX is very flexible).
            But of course, if you prefer, you can just change the name from ‘Resources’ to ‘Pages’ and it can be reflected throughout the whole manager if you so choose. Easy!

          • Marek Králík

            Yep, You understood the true nature of my comment. And use the word “CAN” more often, because you can do everything.. you know like rewriting the whole codebase.

            (sorry for that, I couldn’t resist)

          • Michał Prochownik

            I’m using both WP and MODX and while I could criticize both CMSs for some things You have to understand the differences to complain. The way I see it, WordPress is geared towards a non-developer user, that wants to put a simple site quickly. I think WP is currently unbeatable in this cathegory. So the starting point is the common user and typical site, thats why it seems so intuitive. When you want an advanced site, you may start to run into problems but of course You don’t have to, but it requires skill. So in a way WordPress is a “finished” product from the begining, like a condo You bought with everything, even the furniture and music playing in the radio. MODX is like building your own house. So no smiling developer rep handing you shiny keys, You just have a piece of land, tools, materials and “resources” (ha! a pun!). You will not move-in tomorrow, but You can build whatever You want, but you have to build it yourself. In theory you could even make yourself a flat that looks almost the same as the one above. So there is no point in whining like “oh look John. Where is the bathroom? No bathroom? How come?” Of course some nice features for the less DI-all-Y user would do no harm – for example, as much as I admire how fine-grained the permission system is in MODX I’d really would welcome some predefined user profiles like “full admin”, “power-user”, “editor” that You could customize but only if You want. I sometimes scratch my head making users permission in MODX what policy I forgot to put where so the user can’t edit anything…

          • I would simply reiterate my article, MODX is for developers and designers of custom websites. It simply cannot be compared apples-to-apples with WP, of all things.

            When you say “User logs in. Sees panel with kinda familiar icons….”

            That isn’t even a case at all, MODX is not marketed toward end users who aren’t web devs. Like I said, there are no page builders and drag-n-droppers and menu builders and front-end live-preview color pickers etc etc etc. All those simple tools are obviously built for non-dev end users who don’t want to see any HTML or code.

            To say that something is named “Resource” is automatically a UX failure is just being silly. It’s named that way because it’s the best fit. Since MODX wasn’t built as a blogging platform, it isn’t named “Posts” which, strange enough, is not even a term that’s useful in MODX.
            And I can say too that I’ve built a WP site recently for an elderly person who simply could not grasp why there are Pages and Posts. I tried to explain the differences, and when to use which one when creating a page. I’ve had to write a dozen how-to documents and even visited his house for training TWICE, all because the terms “Page” and “Post” are not intuitive at all. This person is an engineer, super smart, architect, but because they never ran websites before, even the terms Page and Post were NEW and he still has to get used to them
            and learn the intricacies of what they really mean and how they are different.

            You think “Page” and “Post” are such great UX, but in reality, it’s just because we’re used to the terms.

            Case in point: If a dev were going to build a blog into MODX at all in the first place, it would have a special container resource, probably called “Blog” I would imagine, and within that interface would have buttons like “New Post” or what have you. But the point is, this is all set up by the dev. The end user only sees what the dev set up for them to see. Access to certain folders only, to certain contexts. They wouldn’t have access to core templates and PHP.

            In any case, your complaints don’t work for me. It’s kind of like a person saying a truck is bad UX because it’s a manual, simply because they aren’t trained to use a manual. But just because the truck isn’t an automatic, doesn’t mean it’s a bad vehicle. In fact, the manual gives it a few special powers, if you learn to use it.

          • Marek Králík

            You are talking to European here. We all drive manual :)

            I run out of energy to respond to your claims. If you want more on WordPress vs. MODX there are articles dedicated to this with massive discussions. I simply wanted to add my bit, that discouraged me to use MODX.

    • donshakespeare

      WordPress has amazing plugins and page builders etc. But WordPress backend is really really a-mazing. It is a despicable maze!

    • Consistent until you start using different Themes for different site. Every theme changes the theme options, etc and you have sit a learn that person’s theme. Still WP *is* “easier”, but MODX, in my opinion outshines WP in customizable features without having to hack it.

      • Marek Králík

        I am not here to promote wordpress, but I will react on your claims.

        You are comparing bananas and apples. Nobody forces you to use the themes of other developers and I believe that most of them are just bad. But if you write your own using the wordpress interfaces, you will get consistent look and feel everywhere without the need of “hacking”.

        I saw other devs just take wordpress as container for their own framework – no wonder you would have to learn it. But I wouldn’t say that it is wordpress fault. It just isn’t so restrictive.

        • Fair enough, but you can’t suggest that creating a theme from scratch in WordPress requires less of a learning curve than MODX. I would greatly disagree.

          In MODX if you can find/edit the base theme and then the default home page resource, you can create any basic site. And that is just with poking around a little and trying it.
          In WordPress if you want to start from scratch, you are screwed without help. It’s not intuitive at all how to setup the theme.css file and where to put templates and how to set up the metadata and what code goes in the functions.php file and so forth and so on.

          MODX is way easier for hand coding than WordPress. IMO

    • backend admin can be VERY simple, we can customize the backend for the user easily.

  • Todd Zmijewski

    It is absolutely absurd that people are putting out major releases with such low level of programming integrity as modx. Do it right or not all. Keeping all that spaghetti code is definitely not the right way. I for one won’t be rewarding maintainers for their laziness. If Drupal can clean its act so can all the other projects like Modx.

    • donshakespeare

      Do you care to explain? I am reading a lot of English words in your comment … but can’t pinpoint what you are talking about.

      • Todd Zmijewski

        I’m just saying we are doing an injustice to the php ecosystem even acknowledging such poorly architected projects such as modx. We shouldn’t be giving praise to major releases that echo the code quality of the limitations a decade ago.

        • donshakespeare

          Thanks for your clarification. Imagine if you are correct (I used ‘are’ instead of ‘were’, because I am not sure that you are not correct) … but imagine that MODX does “echo the code quality of the limitations a decade ago” … how is it that it still is on top in execution? Imagine if it got rid of these “limitations”, then MODX would be off the chart! I think, sir, you should stay tuned to the Next leap in the MODX major release.

          Until then though, MODX should and must be praised.

        • A bunch of people working really hard for next to nothing to patch a system over the course of 8 years to make sure everything stays compatible despite the changing landscape – and a documentation record of how things have changed to contribute to the education and history of the PHP ecosystem.

          What an injustice!

    • Drupal completely drops all backwards compatibility every couple of years. MODX takes a more respectful approach to the time of its contributors, extension developers and users by not rewriting from scratch every other year.

      There are definitely parts of MODX that can be rightfully classified as “spaghetti” or “old fashioned”. Any system that is still compatible with the PHP landscape of 8+ years ago will have that.

      Luckily, there’s a MODX 3 on the horizon that not only introduces namespaces, autoloading, PSR standards and other modern PHP goodness to the core (you could already use those within extensions, of course), that will also allow breaking changes to remove such spaghetti and legacy code.

      • Todd Zmijewski

        You’re exaggerating the truth there a bit. The previous release of Drupal, version 7 was several years ago. Close to half a decade. At the rate technology moves we should be promoting major rewrites following modern practices every half a decade or so.

        • Any decent sized organization would shiver at such a sentiment.

          Imagine this sales pitch by the developers:

          Devs: “Hey boss, we totally want you to spend half a million bucks building your websites on CMS XYZ! The best part? It will be totally rewritten in a couple years because PHP gurus get some new practices and methods that will break everything to use!”

          Boss: “So I’d have to pay to rebuild the sites over again?”

          Devs: “Of course! Job security…”

          Boss: “Which CMS has LTS? You guys are out of your mind!”

          It’s typically smug programmers who love the idea of updating things every couple years to keep up with new ideas, but any organization that has to shell out millions of dollars on dev resources would not think it’s such a good thing.

          Eventually underlying tech has to be updated, but let’s not pretend these are smooth transitions, with years and years of built up customizations, workflows, business logic that has to carefully be rebuilt. It’s not cheap, and it sucks to do.

    • I call troll, ha!

      • Todd Zmijewski

        Have you even looked under the hood? It’s not as bad as WordPress but it’s bad.

  • A mí no me pagan por opinar

    I’m still sticking to Typo3, thanks.

    • donshakespeare

      Typo3 is great, but I happily moved on.

  • nico jacobs

    I tried the revolution version couple of years ago, I remeber it to be very flexible, but also to be very slow in the backend. I recently discovered processwire, the best cms, for me, so far.

    • donshakespeare

      Old stuff can be clunky at times … good to stick with the latest versions of anything – especially Chrome.

    • It does love having a little more power.

      I used processwire for a project once, it’s not bad, but as I mentioned in the article, it’s just a project written by one person, not backed by an organization, with limited support options.
      Typically for an organization, they will want something a little heartier.

    • When MODX 2 (Revolution) first came out, the manager was slower than it should have been.
      I recommend trying out version 2.5 – very snappy :)

  • Thanks for a great MODX intro article, Zack! A few years ago I moved from WordPress and Drupal to MODX for all my client work and I couldn’t be happier. I get projects completed faster, and the biggest thing is I don’t need to ‘fight the system’ to get all my custom work done. I can’t praise it enough. I highly recommend any designers or developers to give it a go – you are not restricted at all; you can do ANYTHING! :)

  • It sounds silly but as a front end dev who obsesses over things like output markup, http requests ordering/quantities, and adopting the latest front end best practices I really like MODX.

    The output HTML/CSS/JS ends up looking EXACTLY how it would look if I was creating the same page as a static website with absolutely no concessions being made for “that’s just the way the CMS does things” to the pint that I’ve had people comment that they assumed that a site was static when they look at the front end code because they couldn’t find any hints that there was a CMS running the show.

    The back end interface is also VERY configurable, I like being able to give a client a backend interface that shows them just the buttons/menus/options/fields they need to manage/update their website and nothing that they don’t need.

    The back end manager interface has become much faster in recent releases but for php buffs the old code ‘con’ isn’t something that can realistically be updated until the compatibility breaking 3.x major release.

    Another ‘con’ would be the lack of a built in automated way to apply minor or patch level updates. There are third party solutions here but I feel like this should really be figured out and part of the core by now.

    • Agreed. Because the front end output is exactly what you code it to be!

      I can’t tell you how many hours were spent on WP projects when I find some magic HTML in my output which broke the theme, adding some extra empty div or a newline or whatever. I have to search all through the code and templates trying to find what created this output and why.

      A built-in updater is sorely missing, yes.

  • Michael Regan

    Security is a BIG feature for me. Having all the critical files outside the document root is a major selling feature.

    I also agree with @jonathanhaslett:disqus – having final code that looks like a static HTML page is another big feature. While ‘security through obscurity’ is never reliable, why would you make it easier for the ‘bad guys’ by advertising what system you are using.

    While I have never used, it being able to choose any extension is another small security feature. A friend set up his site with a .asp extension to watch ‘script kiddies’ attack his Linux server with Window attacks. ( Of course that would never fool any one that knew what they were doing. )

    Finally, even though MODX has a built in data sanitizer, the xPDO prepare() statement will help protect the database from SQL injection.

    • Script kiddies aside, being able to customise disposition and file/MIME types for any “resource” is actually super useful. For example you could have a “resource” that’s a PDF document featuring some site content being generated by PHP dynamically and downloaded as a file rather than opened in the browser tab.

      • Not only that, but even simply masking the true file system location of a static file is very helpful if you wanted to prevent direct downloads, such as a video file or something.

        I use the PDF MIME type for reports, linked to one URL so they always get the latest report.

        And you could even have a Resource (via a small plugin) act as a handler for random URLs, such as for URL hacking or APIs.

        It’s like what’s been mentioned elsewhere in the comments, a Resource is really just a URL endpoint, but what it serves up can really be anything at all, including nothing! I’ve got URLs (resources) that have no output at all, they may simply run internal scripts or utilities that only I know about. They may be form processors, or front-end utilities.

      • Michael Regan

        Thanks – that is a good idea. I hadn’t consider that – but it sounds like it could be useful.

  • Processwire is a great product, probably my second choice. Well depends on the project I guess. There are things I know I can get done fast in MODX, while I still have a learning curve in PW. Or things that are complicated I don’t know how to solve in PW that I know I can do in MODX. On a particular project I had an issue with PW trying to make a particular menu function the way I wanted, and I couldn’t get it working right in PW, but got it working pretty quickly in MODX.

    Everything boils down to picking the best solution for a given situation.

    I’ve also been playing with October. A nifty newer(ish) CMS built on Laravel and Twig.

    I have to say, though, that I’m excited to see what becomes of MODX 3 and where they take the product, it will probably make or break their future, especially when competing with upstart new CMSes and their fancy pants UX features. Clearly Revolution cannot be brought into today’s standards without breaking everything, and supporting older projects is always a concern.

    Revolution is a great product for what it is. Stable, secure, powerful, easy to get started, but requiring a steep learning curve for the most advanced stuff. And not to mention a good balance between what a developer wants/needs, and what a consumer wants/needs.

  • I do find it interesting that the conversion basically tangled up only Processwire and WordPress. CMS wars are always bound to crop up, but I was curious when this published, what the community would begin praising.
    PW is a good CMS, but for all MODX faults, I’m surprised to see WP being lifted up, since it is pretty much the poster boy of bad everything.

    (P.S I say this knowing full well Sitepoint runs on WP, lol, but they put a ton of work into it. Not just a quick install+theme+10 plugins+go. They take great care to plug security issues and make it perform. These sorts of things are not at all intuitive or built in the UI.)

  • I tried out MODX before the revolution release and was impressed, then
    discovered Silverstripe and have since stuck to that one. Both are CMFs
    and work in similar ways, you should give it a try as well :)

  • This just doesn’t sound right.
    Unless you are doing something very complicated or highly custom, the learning curve just to edit pages and make tweaks is not that high! Perhaps all you need are a few helpful addons to make editing things easier?

    On the other hand, I would agree that there are far fewer MODX devs than WordPress devs. This is simply due to popularity, not because MODX is bad. I would assume that there are even fewer Processwire devs, or Silverstripe devs, etc. The larger the user base, the greater the number of people learning it.

    If your number 1 concern is finding people to help out for free, your best bet is using a tool that the greatest number of people know.

    Might I suggest you create a post in the MODX forums about your predicament. I bet dollars to donuts we can help figure out a way to make editing your e-zine much smoother.

  • I’ve been using MODX for about 9-10 years–before Revolution had been released. Evolution was amazing, but Revolution has never really impressed me much. The backend UI feels outdated and a little clunky, and I have to use Firefox because things don’t work correctly in Chrome.

    The biggest problem for me, as a webdev, are the 15,001 clicks it takes to configure a new site. With other CMS options out there, you can program and configure things easily in files that get uploaded to the server, instead of clicking through the web-based admin to do it.

    And updates have always been a hassle. At least half of the updates–applied to stock MODX sites–have resulted in problems that took hours to resolve, and the process of backing up everything and copying new files over is a pain. One-click updates would really be nice!

    Another major concern is the infrequent updates to MODX. MODX 3 was announced in 2013 and was supposed to launch by the end of the year. Um…it’s now the middle of 2016?

    Overall, I like how simple it is to create new sites in MODX and have full control over all aspects of the site design. I’ve always found my MODX sites out-of-the-box to render faster than WordPress and others.

    • That’s probably not an uncommon testimony. Revolution had a long life, and we’ve seen a virtual explosion of new CMSes in the last 5 years using every new technique coming down the pike.

      The spotty development of MODX 3 is likely due to the burst of PHP versions, PSR standards, Composer popularity and modular frameworks coming out. Things like Slim and Silex and Symphony components and so forth that are increasingly being used as the foundation for many new CMF/CMSes.

      Along with MODX 3, there is also development of some other mystery project named “MODX Next” which I’m not even sure entirely why the two products are needed, but Next I think is radically different.

    • Would love to hear about your quirks with chrome, Chrome is my day to day browser (which sees a lot of MODX) and I don’t immediately recognise your experience with things not working properly. If issues like that are more widespread however, we should work on addressing those.

      • The treeview often goes blank. If I remember correctly, the tabs appear at the top but the content isn’t there. It’s been doing that on and off for a year or two.

        • Michał Prochownik

          I have also problems in Chrome. Chrome asks me if I am sure about leaving this page way too often. Firefox does it better. Sometimes Chrome can also leave some parts of the site blank without any apparent reason

  • you don’t need a modx dev! any dev should be able to go in and work with your site. its php and html.

    • Then you really need a PHP dev. :-)

  • “The product is good, but it’s very, very pricey.”

    Actually, the product is free! :-) It’s the people you’re paying to work on it who are pricey. Zack is spot on when he recommends going with a tool that has a larger developer community if you’re looking for free labor.

    I work with many non-profits, and I often find that people who volunteer to help with their websites are hobbyists at best, without a deep understanding of how to properly set up a website–regardless of the platform being used. They usually over-engineer things and create unnecessary complexity.

  • doomy

    As someone who has in fact used MODX, I would caution to stay away. Documentation is rather sparse, it has a steep learning curve, and (most importantly) it is incredibly slow if you’re running on a shared server (and honestly, why would you run a PHP CMS on anything but a shared server?)

    MODX is one of the few choices that offers flexibility with existing sites, which is why I chose it at the time. However, looking back, a much better solution would be creating my own CMS with something like Rails. I would argue a novice developer could accidentally make a more secure website using Rails (or Django for that matter) than an expert developer could with any PHP framework, given the language’s history of severe security issues.

    In my opinion, prebuilt CMS systems will never offer the flexibility of programming your own site. MODX comes close, but it sacrifices simplicity for verbosity and in some cases outright frustration. I dislike WordPress and think it’s retroactively abused to be a “framework” rather than a blogging system, but it has much more support than MODX.

    • You’re entitled to your opinion, but you can’t really say to avoid it because the learning curve is steep, then say it’s better to build a custom CMS in Rails! That’s hardly an easier thing!

      Also MODX has one of the best track records as far as security breaches. Security has never been a big problem for it.

      It sacrifices some simplicity because it’s made for developers. The solution to a lack of simplicity, however, is not to abandon packaged CMSes and build your own from scratch! How is that simpler? It’s like saying my truck’s manual clutch isn’t simple, so I’ll go build my own truck from scratch.

      Anyway, I would say in a general sense, the more the walls of learning curve crumble, the better it gets. But in the interim, things can be frustrating sometimes.