Transforming the MODX dream into a sweet dream: Introduction
Using MODX is a pleasure! Meeting the community, like at the 15th of November at the international Maastricht Meetup, is always a time to look forward to. But while it was a very short night (MODX meetups most of the time end up with a drink or two) I could not stop thinking about what a sweet dream of MODX would look like. Sweet dreams keep you from having nightmare and the same goes for the software that we use and write everyday! In this introduction I will address some experiences that keep me from having thé ultimate sweet MODX dream.
MODX: the promise
Let’s start with the description of MODX, it is best known as a Content Management System (CMS). But it is also described as Content Management Framework (CMF). And although it differs just one word, the meaning is much broader.
“Some technical users refer to MODX Revolution as a Content Management Framework (“CMF”): equal parts custom web application builder and Content Management System (“CMS”). With a flexible API and a robust event override system, MODX Revolution makes building engaging web projects straightforward — or changing core functionality without hacking the core code possible. Custom tweaks won’t leave you pulling out your hair when it’s time to upgrade.” ~ https://modx.com/get-modx/content-management-framework-cmf
At Census we use MODX every day and we do have lots of clients who are very happy with the CMS part of MODX. But reading the description above, the framework part is meant for the developers. So us…
Let’s go through it one by one:
1: Framework
A framework should be an ‘abstract’ start of the software you are going to create. That sounds very close to a library, but I believe the main difference is that a library should be created in a way it does not force the user/developer into using a specific architecture. With this in mind a framework could actually force a specific architecture, and most frameworks will.
In my early days of programming I started with developing in PHP. I do not remember exactly what my first application/website was, but I certainly remember not using any framework. Just ‘good’ old includes and lots of functional programming. It is given that this did not work out that great. I can also remember that the passwords were saved and compared in plain text. This is off course a no go!
This is a good example for the usage of frameworks, they keep us, from making mistakes that we are not aware of at the time we are writing the code. But we are giving up quite a bit of freedom, we are forced to develop things in the way the framework is designed. This will take at least some time to get used to. That might be the reason we do expect more from a framework: features. These features should help us further while we develop the great things!
Bringing it back to MODX: so am I alway using MODX because it is called a framework? No! The first reason is my inner me, who is a great believer in the process of stepping into every project with a clear peace of paper. Keeping the framework out of perspective until I know what the needs are.
But this also explains why I am not a great fan of using MODX as a framework in projects that are a bit more than a ‘website’. It is forcing toO much and not giving me, the developer, enough back, I can simply not justify the use of it in those cases. And this means: the client won’t be getting that great content manager either!
The sweet dream? A framework that ships with lots of useful stuff, giving more and more opportunities to work with while still providing a great system to manage the content.
2: Flexible API
This takes us to the flexible API of MODX. Generally, yes. It is flexible, there is a lot possible with the system and most of the MODX core is extendable. Flexible API could also refer to the customizability of MODX in general. Which I would describe as: very customizable, you will particularly find this out when you start chasing bugs, adding features to the MODX core or start building packages. There is just so much you will need to take in account for!
In general MODX has got this one sorted. I would say there is ‘nothing’ you can’t build with MODX. But does this mean there’s no need for worries?
Not really, there are a few things that spring to my mind:
1. The flexibility slows down development in general.
While I have developed tens of MODX packages, currently only one is available in the official MODX extras repository (I am sorry for that). The other packages are only installed on the environments we (at Census) manage ourselves. This is because we know it works for that specific setup of MODX. In order to share those packages we must put in quite an afford to deliver a decent quality for all the possible environments out there.
The same goes for some of my attempts to fix some bugs in the MODX core or MODX packages. I most of the time fail to finish them within a decent time.
Talking about the sweet dream: It would be better if the MODX core was simplified. By extracting some ‘flexibility’ from the core to some (composer) packages we could end up with even more flexibility and it also simplifies the MODX core itself.
2. The structural part lacks an ability: Version Control.
This one is discussed many times before. Since MODX is fully based on working with the database rather than filebased it does not give you much to track by a version control system like GIT.
At the MODXpo of Minsk in 2017 a talk was held by Gauke Pieter Sietzema in order to start a much broader discussion. This resulted in the creation of a channel for this subject in Slack. Although there were some ideas, I am still searching for the perfect solution. Simply having the ability to track the changes and automating the different stages of development, staging and production would be awesome!
3. ExtJS, well let’s face it, it won’t be chosen again.
It is possible, with some modifications, to use a different javascript framework for custom manager pages within MODX. For example I have created some VueJS based onces. But once it comes to doing some work on the existing parts of the MODX manager you are out of luck. Either stop creating what you want to create or learn ExtJS.
Alright, it might sound worse than it actually is. I have to admit it gives a consistent look and experience for the user. And it is sometimes helpful in thinking less about the layout. But it can not stop me from thinking about how a life of MODX would be without ExtJS. I would probably make some more specific customizations for a single project which would give the user a better experience in managing the thing that matters on that specific application. Right now, most of the time, I can’t be bothered to do so.
Replacing it all together? Well MODX is just not there yet, are we lacking some flexibility here? Using ExtJS has resulted in endpoints which return the exact output ExtJS needs. Replacing the frontend framework would result in rewriting pretty much the whole of MODX, including its packages. Although I do not doubt the abilities of this amazing community, it is just too much too ask. So let’s try and bring it forward, replacing it bit by bit? API first springs to mind!
3: Robust event override system
Event-driven architecture (EDA) is very powerful. It opens up a world of possibilities for a system. Within MODX system events are fired for pretty much anything. You can create plugins in php and attach the events to the plugin.
For each event you will get a specific payload which provide your script with the information you need in order to run whatever you’ll need to run. This all makes it possible to really extend MODX and its packages without having to fear it will all break when update the system.
It sounds like a pretty good dream, but this system is again based on the database. The system events, plugins and the subscribed events are all saved into the database. And is this what we developers want? Personally I am using my IDE for programming, mainly PHPstorm, but with MODX you always have to switch between the manager and your IDE. Off course there are ways of just injecting the plugin and its events inside the database from within the IDE, but that is far from ideal.
The upcoming implementation of composer inside MODX 3.0 will provide some more possibilities. I’m certainly thinking about a system of injecting elements based on composer scripts. This will by then allow the injection of some listeners for the different plugins. Which will make it possible or developers to keep on working from the IDE which will be very nice!
4: Straightforward
This section is mostly based on personal preference. But in my mind the straightforwardness of a framework should corresponds with the following:
The developer should be guided into the usage of the architecture and API in the way it was meant by the designers of that framework by design. Anything that might need a bit more explanation or anything that the developer might not know about from the beginning, should be written in enthusiastic, clear and well formated documentation. Everything beyond that should be available within the API docs, because it is probably such a specific use case or function that it will be fine to put a bit or research into it.
Another framework I use on a daily basis is Laravel. There is one thing that I do differently while developing an application in Laravel than in MODX. When I develop something in Laravel there is somewhere a tab open in my browser pointing to the documentation. Not because Laravel is not so ‘straightforward’ to use, but it is just a nice guide for some of the things you want to create. When it comes to MODX, I just rather Google something when I get stuck, because then I will get the results of the forum as well as the documentation.
Just compare it yourself, the starter page of the MODX and the Laravel docs:
This difference is also visible for most of the packages. Take for example the package MIGX, it has been downloaded more than 163.000 times from the official MODX repository. There are multiple docs available:
- https://docs.modx.com/extras/revo/migxdb/
- https://docs.modx.com/extras/revo/migx
- http://bruno17.github.io/MIGX/
Basically it offers a way of creating a CRUD implementation of custom defined objects, either connected to a resource or stand alone. It is a very complete package and it offers all kinds of possibilities. Lately I have started at a project with some more complicated views for managing the different objects. I therefore delved into the more advanced options of MIGX. But I just could not figure it out with the documentation. In the end I have backward engineered some of the features I had found. Only to find out that it meant something totally different than I first thought.
In general MODX is straightforward, there is no problem in having to invest a bit of time for new developers. And once you know the basics you can start building pretty much anything. But when it comes to development speed: there are some better alternatives.
5: Not pulling out any of my hairs (when it is time to upgrade)
Yes, I’m aware that the quote at the beginning of the post comes from the official website of MODX and that there is a bit of sales talk in it. And indeed, the time that is required by fixing things that do brake after an update of MODX is close to not existing. But I cannot say that this all keeps me from worrying (and losing some of my hair in the result).
Every update I am full of hope: that one feature that blows my mind inside the change-log. Because let’s face it, we are looking for the sweet dream: amazing new features with non-breaking updates. But maybe, from time to time, I might prefer the amazing new features over non-breaking updates.
You can by now imagine how much I’m looking forward towards MODX 3.0 (and for the this month coming 2.7 update).
Identified issues
Please do not get me wrong, I am a real fan of MODX. But in a world that is moving fast MODX should adapt with it. The progress on MODX 3.0 shows lots of improvements, mainly focused on improving the experience of managing the content. Packages like ContentBlocks and Fred do offer flexibility for the designer. Well now, I am not saying the developers have not gained from anything, but just maybe, we can make things a little bit easier for ourselves?
A summery of the things that keeps me personally from having that sweet MODX dream:
- Lacking some features that other frameworks do have.
- You can customize almost everything, which results in slower development of the MODX core and custom packages.
- Your options are limited when it comes to using version control and automated build processes.
- ExtJS does not have any future, but it will still be there for a long time.
- The event architecture can be simplified by using more modern techniques.
- MODX can improve massively on the development experience, when it comes to documentation.
- Breaking changes are sometime necessary to improve the overall state of any framework.
Dutch: “Wie A zegt moet ook B zeggen.” (translated: “He who says A must also say B.”)
The dutch proverb ‘Wie A zegt moet ook B zeggen’ (translated: He who says A must also say B) means that you can not walk away once you have started something. That is why I will keep working on the things I mentioned above in the next weeks (or probably months, highly depends on my schedule). I will write a few stories about my findings and will actually try to create some proof of concepts while fixing some of the things mentioned above. Because In the end we are the community, and creating those amazing features can only be created by ourselves!
Any suggestions or ideas? You can leave a comment below or send it on Slack.
