What do we know about MODX 3 at the moment?

Original author: Mark Hamstra
  • Transfer
A few weeks ago, lead architect Jason Coward (“opengeek”) shared his vision for the future of MODX at the Medium site. Based on this information, as well as other online discussions, what do we know about MODX 3? What is his status, and when can we see something live?

Honestly, we don’t have exact answers yet. There are only some pieces of information that we can put together. Since MODX 3 has not yet been created, there are many assumptions and “advanced” assumptions. MODX 3 is a long-term project that is just starting.

Why do we still need MODX 3?


A lot of people make great use of the current version of MODX. The system allows designers and front-end developers to create completely unique sites with minimal effort and kernel changes, unlike some competitors. Even in the current version, website development will be a simple and fully feasible business for many years to come. A very powerful language of templates and elements, additional fields (TV) and extensions - all this is ready for use in the future.

Perhaps the biggest reason we need MODX 3 is just a number. In order to clear the legacy code and provide developers with improved tools that meet industry standards, the MODX system will need critical changes. And since MODX follows the principles of semantic versioning, this means that the major version should increase at the time of implementation of critical changes. Version 2 is installed for MODX Revolution, which means we will need version 3.

So why do we need critical changes if the current version of MODX is still very relevant? I would say this is necessary for MODX to follow in the stream of changes in the PHP world. The PHP community is becoming more professional and standardized (in particular, thanks to The Framework Interoperability Group - a compatibility concept group and initiatives like PHP: The Right Way- PHP: the right way) with impressive speed in the last few years. By joining this movement, the MODX kernel code can become much more cool (read: stable, testable, and possibly smaller in volume). Conversely, MODX would become a much more attractive platform for other PHP developers.

In the development world, critical changes are ongoing. With an exceptional leap from Evo to Revo, MODX actually became more stable and continued to develop over the past years, but from certain points of view, a critical release must occur in order to surpass all that the existing code allows.

Syndrome "it was not us who invented it"


In many cases, MODX was developed using the concept of "rejection of others' development" (the tendency to consciously or instinctively ignore all innovations that occur outside the organization - approx. Translator) , which is not the best design pattern. This basically means that if earlier each part of the code was developed within the MODX community, then in the future more standardized libraries that are developed by external communities can be used. Thanks Composer and Packagist, such a change has occurred within the PHP community in recent years, which made it possible to use the code of external developers as easily as possible, and also accelerated the growth of individual libraries that performed exceptionally well one, well-defined task.

By connecting such external libraries of third-party developers, it becomes possible to develop reliable applications faster and better, taking advantage of the fully tested code of individual modules (unit tests). Since there are no useful unit tests in MODX now (although there is still some movement ), this is of great importance in terms of architecture and code quality.

Here are some examples of modules that were developed inside the MODX team earlier before using external libraries:

  • Journaling. At the moment there is a convenient method $ modx-> log (), however, when changing this method in accordance with the support of the PSR-3 interface, developers will be able to dump log entries to various logging systems, for example, such as Monolog . The Monolog system provides a huge number of impressive log management capabilities, and when MODX starts supporting PSR-3, it will be possible to support any of them without modifying the MODX kernel.
  • Routing There are libraries that can do pretty cool things with transforming the request into the correct answer. See the Slim framework section below.
  • Template system. Honestly, I really like the template language in Revolution, but maybe using something more “standard” like Twig could be an interesting improvement. In any case, this will reduce the learning curve for many people, as Twig is used in many other projects.


These are just the very first things that come to mind when we talk about reusing ready-made external code.

What is Slim and why use it?


In the second part of his article series “ Keeping MODX up-to-date, ” Jason noted the Slim framework (version 3) as the most likely candidate for use in the MODX kernel. This did not go unnoticed - many people began to consider Slim, figuring out what it is and how it works.

Here is what we need to know about Slim:

  • Slim is a router. It transforms Requests (for example, GET / manager / resource / update) into a Response (for example, in a form for updating a resource).
  • Slim supports the Middleware (middleware) pattern. When using this pattern, you essentially get many layers that process each individual request, as well as responses with the ability to change them before they reach the next layer. A technical explanation of the Middleware pattern can be found here . The Middleware pattern is a very effective way to expand behavior. Slim 3 actually supports the PSR-7 standard (draft) from PHP FIG in its implementation of Middleware, which means that any middleware that supports the PSR-7 pattern can be safely used with Slim 3.
  • Slim 3 is still under development; in other words, it is not yet ready for work in real production, but it seems Slim 3 code is becoming stable.


Presumably, Slim will take the place of the current request and response handlers in MODX. Given the possibility of adding middleware code, this would lead to an extremely flexible and powerful system.

What about Manager and ExtJS?


If you ask a random group of MODX developers about their most unloved part of the system, most likely it will be ExtJS (or, more generally, the “Manager”). At the moment, there is no definite direction for the Manager that I would know about, but binding to ExtJS 3.4 is clearly not what should happen. ExtJS 3 is very outdated, it is not fast enough and does not provide proper support for mobile devices. Moreover, ExtJS 3.4 is no longer updated as ExtJS 6 is already available in early access .

So, although we don’t yet know what the Manager will look like or what it will be built on, we can be quite sure that this will not be ExtJS 3.

But what do we know?

Given Jason's choice of Slim as the core library, his work on a projectTacit (the Slim-based “high-performance RESTful framework”), as well as some discussions on various IRC channels and Slack , most likely the next Manager will get a RESTful API as its foundation. The current Manager also has an API, but its structure is not completely standardized, and in some places is aimed precisely at what ExtJS expects from it. Definitely not RESTful.

When migrating to the RESTful API as the main service, the backend and interface will be further separated in terms of code. This should make it easier to develop truly unique Managers, and make these two parts of the platform independently of each other. Designers could focus on developing the third-version Manager interface, while developers would meanwhile work on a robust API.

What's next?


Jason is working on the long awaited third part of his series of articles about the future MODX right now. In this part, he will share his vision on the topic of sustainability - basically, interacting with the database. For MODX architecture, this is a very important decision, so Jason is preparing several possible options before publishing the results.

At the moment, the main focus of MODX is version 2.3 and the upcoming version 2.4. The release of MODX 3 promises to be exciting and attractive, so it’s important to spend some time deciding before deciding on the basics of the new MODX revolution.

Also popular now: