Keeping MODX Relevant — Part Two

Jason Coward
Feb 23, 2015 · 6 min read

What success MODX has achieved over the past ten years is, in my opinion, entirely due to two core tenets that the community has always stood behind. Those ideals are modularity and extensibility. Together with a natural separation of presentation and logic that the architecture begs you to take advantage of, MODX has carved a significant niche providing Creative Freedom to an Open Source CMS world better known for prefabricated themes you have to hook into or hack around.

These principles and the unique domain model established originally by Etomite and improved upon by the MODX Evolution product, then later embellished further by MODX Revolution, will never be diminished. They gave MODX relevancy for the past 10 years, and together with some careful but bold changes to the implementation, we can propel it to greater future relevancy in a better concerted effort with a much larger and more mature PHP community.

The Promise of and Struggle for Interoperability

Years later, the successes of the early PSR work regarding code style (PSR-1 and PSR-2) and autoloading (PSR-0) is clearly reflected in the widespread adoption and ongoing active maturation of the dependency management project Composer and its companion repository, Packagist. The standards, processes, discipline, and independent, reusable libraries being forged by these recommendations and tools are a commonwealth that all future PHP applications should be benefitting from. I want the next major release of MODX to take full advantage of this thriving ecosystem.

The Benefits of PSR-3

By adopting this standard, both framework and library developers benefit. The frameworks gain flexibility and easy extensibility through configurable service providers. The developers gain wider audiences for their code. In the case of MODX, adopting PSR-3 will mean you can instantly take advantage of all the logging adaptors already available with Monolog. Monolog is the de facto standard Open Source PSR-3 implementation and will provide flexibility and instant access to log handlers that would take years to implement within MODX.

The Importance of the Proposed PSR-7

PSR-7 is a proposed set of standard interfaces for HTTP messaging. Once adopted, this standard promises to launch a whole new era of interoperable libraries and extensions. Being able to interact with HTTP requests and responses in a standard way in PHP is long overdue and it’s something programmers in most web-targeted languages would take for granted. And because of the impact this will potentially have, now is the perfect time to take advantage of it when planning the next major iteration of the MODX architecture.

Extensibility and Interoperability via Middleware

In the case of Stack, the common interface is the Symfony HttpKernelInterface. This is a precursor of and inspiration for PSR-7. Any application that implements this interface can then make use of Middleware designed for the interface and not specifically for the application. This simple approach to interoperability and extensibility is elegant and I’d like to adopt a Middleware architecture for MODX built on top of the common interfaces defined in PSR-7.

Unit Tests and Agility

Microframework

My gut told me from the beginning that neither Symfony nor Laravel were the right foundation for a future MODX product. Symfony is a very modular but extremely tightly coupled framework. Similarly, Laravel components are tightly coupled and dependent on other Laravel components. They both do a lot to help developers be more productive with a minimum of effort, but the tradeoff is flexibility and performance.

I completed a couple of small projects in Laravel 4 recently, and I stand by my original intuition. After struggling horribly to figure out how to work with Laravel basics by using my IDE and exploring the code, then finally realizing the only way to know what classes and methods to call was by reading tutorial-style documentation, I finally completed my projects. In the end I felt Laravel did too much for me. I feel the large code base and kitchen-sink architecture would get in the way of and overshadow the MODX project in many respects, detracting from the flexibility it is known for. Besides, the folks at OctoberCMS seem to be doing an incredible job authoring a CMS platform on top of Laravel.

In my estimation, MODX needs to be reconstructed on a much lighter and more agile foundation which can more effectively provide for its existing and future feature sets. MODX needs a microframework at its core. Both Silex and Slim provide good options. But which one will best serve MODX?

Keeping Slim and Trim

It follows that we should select an existing, well-tested framework that embodies all of the principles we want to adopt, and which supplement those MODX itself already brings to the table. After reviewing the current state of the various frameworks and microframeworks, and how each might provide a foundation for a next generation MODX, I think I am settled on building it on top of Slim 3.x. Though the 3.x branch of Slim is still in development and 2.x itself is a great solution, and despite there being many other great frameworks out there, the early adoption of PSR-7, the middleware architecture built around the PSR-7 interfaces, and the minimalist approach Slim 3.x takes make it a perfect compliment to the existing and future features of the MODX CMS product line.

Crazy Ideas on Persistence

Jason Coward

Written by

MODX Co-Founder and Chief Architect — loves cooking, backpacking, snowshoeing, playing drums, web development, Open Source Software, and photography