MODX β€” legacy that is here to stay

The word legacy here does not mean "old means bad." Old code can normally do its job for decades.

The problem with MODX lies elsewhere: the platform's architecture hardly evolves, and the project lacks a clear trajectory that would bring it to a modern development level.

And this is no longer a matter of taste. It is evident from the releases.

What has actually been happening in recent years

MODX Revolution 2 was released back in 2010. Its basic model is still very familiar to us today:

modResource β†’ Templates / TVs / Chunks / Snippets / Plugins β†’ parser β†’ HTML

Plus xPDO, processors, Manager, and Transport Packages.

The subsequent years saw the release of 2.5, 2.6, 2.7, 2.8. But if you open the release notes themselves, they mostly consist of:

  • bug fixes;
  • security fixes;
  • compatibility with newer PHP versions;
  • updates to Smarty, PHPMailer, xPDO, and other libraries;
  • Manager improvements;
  • minor UX changes.

For example, MODX 2.8 was officially described through security fixes, file handling, and library updates. 2.8.2 brought PHP 8 compatibility, security, and bug fixes. 2.8.6 brought security again, PHP 8 compatibility, and dependency updates.

This is normal product maintenance work. But it is not architectural development of the platform.

And then MODX 3 was finally released

It was prepared for a long time. So long that the team itself called the release long-awaited and explicitly stated that MODX 3 is the result of several years of work.

What appeared:

  • namespaces;
  • Composer;
  • dependency injection container;
  • new HTTP services;
  • xPDO 3;
  • support for more modern PHP versions.

On paper, it sounds solid.

Yet alongside that in the same release, the team wrote a key phrase: one of the goals of MODX 3 was to maintain as much compatibility with the 2.x branch as possible so that old Extras would continue to work.

And right here lies the essence.

MODX 3 did not replace the Revolution 2 architecture. It wrapped the old architecture in more modern PHP mechanisms.

Resource remained Resource. TVs remained TVs. Chunks, Snippets, Plugins, parser, and the old application model didn't go anywhere.

In other words, this is not a new system. It is the exact same MODX, just from a different angle.

Why this matters to a website owner

Because a website lives longer than a CMS version.

If a business depends on a website for ten or fifteen years, it needs new interfaces, APIs, mobile applications, automation, AI, proper deployment pipelines, observability, and integrations with external services.

And the question here is no longer whether all of this can be bolted on to MODX. Almost anything can be bolted on. The question is the cost of changes and the share of modern performance that the system is capable of passing through itself.

A modern specialist equipped with AI, automation, and good tools can be significantly faster on a new stack. But inside an old MODX project, part of that productivity is lost to manual processes, legacy code quirks, fragile dependencies, and caution with every single change. Therefore, modernization becomes not a matter of taste and not a technological luxury, but an economic necessity. The general law of this connection is formulated on futurist.expert: growth in specialist productivity requires a corresponding development of the business's technological environment.

For a MODX website owner, this means a simple thing: if a business wants to get the maximum out of modern specialists, AI, and automation, it needs to gradually transition the project to an architecture where these capabilities actually work. It is not necessary to rewrite everything at once. But staying inside the old technological environment forever means continuing to pay the old price for changes even when the market already knows how to work faster and cheaper.

Conclusion

MODX will continue to run on thousands of websites for a long time. It will be updated, patched, ported to new PHP versions, and cleared of discovered vulnerabilities.

But this is precisely the normal life of a legacy platform.

You can maintain MODX. Depending economically on its limitations indefinitely is becoming less and less rational.