Keeping MODX Relevant — Part Two

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

I’ve watched the discussions and disagreements ebb and flow for years over interoperability in both the Open Source PHP CMS development communities, and later, the greater PHP development community. In the CMS communities it seemed like a pipe-dream, and there was rightfully some resistance from the developers involved with the various CMS products. What needed to happen before discussions about interoperability between offerings of a specific type of product were discussions about interoperability at a lower level. And I believe that was at least a partial motivation for the formation of the PHP-FIG.

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

Beyond the benefits of an autoloading standard, some of the additional PSRs that are coming out of the FIG are simply defining common interfaces that anyone can implement and share with anyone else that adopts the interface. The first of these was PSR-3, which defines a standard logging interface. Projects that use this interface can select from any number of implementations that implement the common logging interface. In fact, they can allow their users to simply configure and use a specific implementation through the use of a dependency injection container.

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

I don’t think I saw the true significance of what the FIG was achieving until I recently reviewed the PSR-7 specification. Though not yet accepted (it’s still in the proposal stage), I believe this set of proposed interfaces can do more to improve interoperability between PHP frameworks than any other standards recommendation adopted to date. What’s this proposal I’m so excited about and why is it important?

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

A small scale example of what a standardized interface for HTTP messaging can accomplish can be seen in the existing Stack project. Stack provides a PHP implementation of middleware — an approach to extending an application by decorating it with a wrapper object which creates an outer layer around the existing application. This layer can alter the behavior of the application through the common interface, before and/or after the layer it wraps executes. Execution starts and finishes with the outmost Middleware layer.

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

Making MODX more adaptable to the changing needs of web developers, designers, and content managers is what we are all after. I believe above all else, making MODX more testable, starting at the unit-testing level, will allow the MODX community to more quickly evolve and improve MODX features. By adopting these various standards and interfaces, and by utilizing existing libraries with complete test coverage, we don’t have to try to do everything ourselves. We can bring MODX up-to-date and start focusing on producing content management innovations instead of managing the complexity of home-grown solutions.

Microframework

I’ve heard from numerous MODX developers over the past couple of years that think MODX should be rebuilt on top of the extremely popular Laravel framework. With Drupal 8 aligning with the Symfony framework, it might make sense to align the future of MODX with an existing solution and competitor. So I took it upon myself to explore Laravel.

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 is clear to me that neither creating a new microframework from scratch, nor retrofitting test coverage on the existing legacy MODX codebase make any sense for the long-term viability of MODX. We do not want to continue the NIH culture that has already lead to some heavy technical debt. We want to instead immerse ourselves in existing, high-quality, stand-alone solutions that focus on doing what they do and doing it well, so that we can focus on doing Content Management well.

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

And if you think the struggle to find a new foundation on which to reconstruct a more relevant, next generation MODX core has been challenging, wait for Part Three. I’ll discuss how I see the role of database persistence changing in the next generation of MODX releases, and what tools might pave the way for those changes.