Jeff Whitfield | Posted | Comments |
Those who know me know that I've been a long time MODX supporter. Hell, I was there from the beginning when the project was forked from Etomite. Since then, I had the pleasure of working for the folks who founded the project for the better part of four years. Eventually, MODX went LLC and was on its way to becoming a full fledged open-source startup. But after four years, I realized it was time to move on, to learn some new things, challenge myself, and expand my career.
Part of that process included learning new tools and new languages. I started looking at Ruby on Rails and, after a brief review, was shocked at how easy it was to create custom data models and do stuff with it. While most Rails developers say that scaffolding isn't the best thing to do, it's still amazing at just how easy it is to get up and running with a fairly complex data model. So it begged the question: Why can't we do this with MODX?
MODX has always been about creative freedom. It still remains one of the best CMS platforms out there for web designers. With a little knowledge of how MODX works, a web designer can build a site with complete creative freedom with little or no PHP knowledge. Not only that, but they have access to a ton of addons that allow for quickly developing custom solutions for clients. That's huge!
I've used MODX for close to five years now. As with any platform, there are limitations to what you can and cannot do. While MODX is a fantastic tool for non-developers, it can be challenging to a PHP developer. For those seeking a solid solution that adheres to a strict MVC philosophy and proper data modeling techniques, you might find yourself scratching your head now and then.
Compared to the first version, MODX Revolution gave way to a whole new way of handling the data model in MODX. The introduction of xPDO allowed for treating data in a more object-oriented fashion using schemas to create custom data models. xPDO is some seriously powerful stuff! You can realistically create some crazy powerful custom applications in MODX!
The problem is that, while xPDO is powerful, the MODX data model doesn't line up with it all that well. The data model built for MODX isn't normalized in a way that makes sense for integration with a custom data model. In fact, the data model MODX is based on is, in my opinion, seriously flawed.
For instance, let's say that you wanted to create a Staff page that listed multiple members of a company in a way that's easy for the client to manage. In this case, the company doesn't want each staff member to have their own pages but would like to relate each staff member with blog posts, project pages, and other related content. The client wants to manage this using an interface that allows them to easily add staff members, filter the list, and export a list every once in a while.
In this case, a third-party component would need to be created. Seems like a pretty simple task. Now, while the data model for the Staff component can be created fairly easily, creating the interface for it and relating it to content in the Resource Tree within MODX can be a bit daunting. Aside from that, you still have to find an easy way to relate each staff member with various other resources on the site.
1. Inconsistent Data Models
While we can build a custom data model that is normalized and makes sense, the way data is stored and related for resources isn't exactly normalized in an obvious way. Resources are broken down by the template they use, the template variable values, and which template variable template each of them use, all stored into different tables. In other words, all content is stored in the same content table, all template variable values are stored in another table, with the template variable type stored in yet another table. This means that a complex lookup of any content and their related template variable values and data types requires parsing a lot of data before generating a result which, from my experience, has always been a problem with how MODX works.
The problem lies in the fact that the MODX data model is not going to reflect the way the information on your site is structured. As such, trying to relate the content and template variable data with your custom data model is going to be tough and somewhat inefficient. While relating a single resource with multiple records in a custom data model is a no-brainer, going the other way around isn't. Even without a custom data model in the mix, parsing multiple resources in the Resource Tree with template variable values and complex content requirements can be difficult without having to write a lot of custom code. Unlike a custom data model using xPDO, it's difficult to create relationships between resources using nothing but the Resource Tree and template variables.
2. Lack of Scaffolding
In my opinion, regardless of how experienced you are, adding a custom component or manager page in MODX is not easy. A simple interface to manage a data model can't be this difficult to create, right? Reviewing the documentation on how to do it is enough to make a modest PHP developer cringe. Unlike Ruby on Rails, getting an interface to manage a custom data model requires a lot of steps. There are MODX manager configuration steps to make, lexicon files, controller files, ExtJS files, and more. Unless you understand how ExtJS works then creating custom manager pages is just painful. This is by far the one area in MODX that I've always hated. Just never could learn how to do it without pulling my hair out.
While xPDO is certainly powerful, it still lacks any cohesion with MODX and feels like a separate component. Multiple steps are required to create a custom data model, including the creation of a schema file written in XML. The requirement for the schema are pretty straight-forward and easy but it does take a bit of time to create it. On the flipside, making use of the schema and generating your PHP classes and maps does require you to create a PHP file to generate your model. On the surface, this seems pretty easy but, when you factor in updates to the model after creation, the generator required quickly becomes a problem. Documentation on generating and updating an xPDO model is skimpy at best. Which brings me to my final point.
3. Lack of Documentation
In the past, whenever I've introduced MODX to a fairly seasoned PHP developer, many get excited but point out the lack of proper documentation. Not that there isn't documentation. While there's plenty of it, there are also holes in the documentation. You can get pretty far with the current documentation but, after a while, you start running into walls. I hit plenty of walls when it came to xPDO and custom manager pages. There just didn't seem to be any way of cohesion between these two topics.
While it appears that the documentation is being updated all the time, many entries appear stale and haven't been updated in some time. With the sheer amount of documentation that's been added, I would imagine that keeping it updated is a task in itself. To make up for this, plenty of MODX fans have stepped up to the plate to offer all sorts of tutorials and other resources.
I would presume that one saving grace in documentation for MODX would be the MODX: The Official Guide book. From the table of contents, it looks well organized and covers a lot of ground. Someone looking to get into developing with MODX would likely want to read it. Unfortunately, it was written in 2011, is 772 pages long, costs $59, and weighs over 3 pounds. Being an older book isn't necessarily bad and is still likely useful. The problem is that, to date, there still isn't a digital version of it available. Many people, including myself, own iPads, Kindle Fires, and Android tablets. We don't want to lug around a brick of a book. As such, many potential MODX users likely won't buy it. MODX desperately needs an updated edition of their guide and one that comes in standard digital formats.
To be clear, I still think MODX is a great CMS. However, I do feel that it could be better. I'm sure the MODX guys have a lot in store for the 3.0 version. In the meantime, improving documentation and getting a better edition of their book would be a good step in the right direction.
I kept mentioning Ruby on Rails in this post. Granted, Rails isn't a CMS and comparing MODX to it isn't fair. However, I recently started using another PHP based CMS for client websites, one that shares many similarities to Ruby on Rails like scaffolding and normalized data models. It's a system that will make Rails users smile and MODX users cry. I'll talk about it in my next post.