Over the past few weeks, lead architect Jason "opengeek" Coward has been sharing his vision about the future of MODX on Medium. Based on that, and other discussions, what do we know about MODX 3? What is its status, and when can we expect to see something? 

To be honest, we don't have the answers. There are bits and pieces we can put together, but as MODX 3 simply isn't here yet, it's a lot of assumptions and "educated" guesses. If anything, MODX 3 is a long-term project that is just getting started. 

Why do we need MODX 3 anyway?

The current version of MODX serves a lot of people really well. It enables designers and front-end developers to build completely bespoke websites with minimal effort and core hacking unlike some of the competition. Even in the current iteration, building websites will be easy and completely feasible for many years to come. The very powerful templating language and elements, template variables and extensions like ContentBlocks are all ready for the future. 

The biggest reason that we need a MODX 3 might just be that number. In order to clean up legacy code and to provide developers with better, industry-standard tools, MODX will need breaking changes. And as MODX follows semantic versioning, that means the major version has to increase when that happens. MODX Revolution is version 2, so we need a version 3. 

So why do we need breaking changes, if the current version of MODX is still very much relevant? I would say it is to get MODX up to speed on what's happening in the PHP world. The broader PHP community has been professionalising and standardising (in part thanks to the Framework Interoperability Group and initiatives like PHP: The Right Way) at an amazing pace over the past few years. By hooking into this movement, the MODX core code can become a lot more awesome (read: stable, testable and potentially smaller) and in turn MODX would become a much more appealing content platform for the PHP developer group.

In the development world, breaking changes happen all the time. With the exception of the bump from Evo to Revo, MODX has been really stable and iterating progressively over the past decade, but at some point a breaking release needs to happen to iterate beyond what the current code allows. 

Not Invented Here Syndrom

In many ways, MODX was (unintentionally) built with the concept of Not Invented Here (NIH), which is not a great design pattern. This basically means that where previously every part of the code was developed internally, in the future more standardised libraries developed by the wider community can be used. This shift has happened across the PHP community over the past few years thanks to Composer and Packagist making it extremely easy to use code from third parties and the rise of libraries that are exceptionally good at one, well-defined task. 

By adopting these third party libraries, it is possible to develop solid applications quicker and better by taking advantage of fully unit tested code. Given how MODX currently doesn't really have any useful unit tests (though there is movement), this is a very big deal when it comes to an architecture and code quality perspective. 

Some examples of places that were developed "in-house" before that we could see adopting outside libraries include the following:

  • Logging. There's currently a handy $modx->log() method, however by changing that to accept a PSR-3 compatible logging interface, people will be able to drop in different logging engines such as Monolog. Monolog offers a ton of amazing features like piping logs to third party services or sending emails to for fatal errors, and once MODX supports PSR-3 loggers, it will be able to support all of that without needing any change in the MODX core. 
  • Routing. There are libraries available that can do pretty cool stuff with translating a request into the right response. See the section about Slim, below.
  • Templating. To be honest, I really like the Revolution templating language, but perhaps making use of something "standard" like Twig could be an interesting improvement. At any rate, it will lower the learning curve for a lot of new people as there are so many projects out there also using Twig. 

These are just some of the first things that come to mind when talking about reusing code available out there. 

What is Slim, and why use that?

In part two of the Keeping MODX Relevant series, Jason mentioned Slim (v3) as the likely candidate to be at the core of MODX. This has not gone unnoticed, with many people looking into Slim, wondering what it does, and how it will work. 

Here's what you need to know about Slim:

  • Slim is a router. It translates Requests (for example GET /manager/resource/update) into a Response (for example a form to update a resource). 
  • Slim follows what is called the Middleware pattern. With this pattern, you essentially get multiple layers that each process the request, and the response, with the ability to change them before they hit the next layer. A technical explanation of the middleware pattern can be found here. The middleware pattern is a very powerful way of extending behaviour. Slim 3 actually follows the PSR-7 (draft) standard from the PHP FIG in its middleware implementation, which means any PSR-7 middleware can be used with Slim 3 as well. 
  • Slim 3 is still in development, so not production-ready, but seems to be stabilising. 

Presumably, Slim will take the place of the current request and response handlers in MODX. Given the ability to add middlewares, that would result in an extremely flexible and powerful system. 

What about the Manager and ExtJS?

If you ask a random group of MODXers about their least favourite part of the system, it is quite likely ExtJS (or more generally "the manager") ranks incredibly high on that list. At this point there is not a defined direction for the manager that I know off, but sticking with ExtJS 3.4 is likely not going to happen. ExtJS 3 is very old, not very fast or mobile friendly, and it no longer receives updates as ExtJS 6 is already in early access

So while we don't know what the new manager will look like, or what it will be built with yet, we can be pretty confident it wont be ExtJS 3. 

But what do we know?

Given Jason's choice for Slim as the core library to build on, his work on something called Tacit ("a high performance RESTful framework", coincidentally based on Slim) and some of the discussions on various IRC and Slack, it seems likely the next manager will see a RESTful API as base. The current manager also has an API, but its structure is not very standard, and somewhat geared towards what ExtJS expects from an API. It is definitely not RESTful. 

By moving to a RESTful API as core service, the back-end and the actual interface will be further separated from a code perspective. That should make it easier to build truly custom managers, and to develop those two parts of the platform independently. Actual (interface) designers could focus on building the v3 manager interface, while the developers focus on building a solid API, which is a good thing. 

What's next?

Right now, Jason is working on the highly anticipated part three of his series on the future of MODX. In that part, he'll share his vision on the subject of persistence - basically, interacting with the database. For the architecture of MODX this is a very important decision to make and Jason is spending time prototyping some possible solutions before publishing the results.

For now, the primary focus of MODX is on 2.3 and the upcoming 2.4. MODX 3 is going to be exciting and challenging to get right, so taking time to make the right decisions is important before laying the foundation of the next revolution in MODX.

And when we get to that, MODX.today will be there to keep you in the loop.