Keeping MODX Relevant — Part One
It’s been over 10 years since Ryan, Raymond, and myself founded the MODX CMS project and a lot has changed in the world of both content management and web development in that time. Deciding when to let go of the past and try new adventures is always stressful, and leading an Open-Source Software project like MODX affords me ample opportunity to experience this nexus of freewill. Unfortunately, it does not always provide the same abundance of time and resources needed to focus on making the hard choices.
That said, I’ve done my best to use the delays in innovation the project has experienced over the past couple of years as a time of introspection and experimentation. I’ve never been one to make rash decisions, and I like to carefully consider as many options as practical when choosing a path to follow. I hope that this will serve the future of the MODX project well by helping us avoid the pitfalls of being over-zealous or adopting radical changes too quickly. That said, it is now critical that the MODX community refocus energy on keeping MODX relevant in the long-term by taking advantage of and highlighting our undeniable strengths, while minimizing and escaping some clear weaknesses and unwelcome complexity.
Standards and Interoperability
Why are coding standards and common interfaces important to the PHP community? And more importantly, why are they important to the MODX community? Because MODX is a part of the PHP community and for far too long this project has chosen to create instead of adopt existing solutions for one reason or another. Some of those reasons may have been valid at the time, but to ignore the strides the PHP-FIG has achieved in solving the Not-Invented-Here culture prevalent in many PHP projects would almost guarantee irrelevance for the MODX project over the next few years.
In fact, I would like to see MODX get a voting seat on the PHP-FIG in the next two years. I want to adopt the widely accepted code style and autoloading standards PHP-FIG have already help establish. I want to see MODX distributable via Composer and Packagist. I want to see Extras for MODX be distributable via Composer and Packagist. I want to increase the MODular eXtensibility of MODX with a proper dependency injection container that takes into consideration recent thoughts on Container Interoperability. I want MODX development to follow the ideals espoused by PHP The Right Way. I want a framework that is decoupled from the user interface and that is equally competent powering mobile and web applications. I want to make use of namespaces and traits and other modern PHP language enhancements that can help improve both the performance and maintainability of the project. And I want the entire core of MODX to be thoroughly covered by Unit Tests. It sounds like an insane proposition, but this can all be achieved. It will simply require radical change to all but the key tenets that make MODX what it is.
Without a doubt, the Creative Freedom that MODX has successfully delivered to front-end developers since it’s inception is it’s main strength. And I believe through some simple but radical shifts that begin by adopting these continually emerging community standards and best practices, that this same principle can be extended to the other stakeholders involved in MODX deployments: the content producers/editors, the back-end developers, and the systems administrators. Why shouldn’t they also experience this liberty?
Towards a Microservice Architecture
Beyond making MODX more attractive to the modern PHP developer, and hopefully easier to develop with, there are more strategic, architectural goals that will also be served well by adopting these development standards and best practices. Further breaking down the MODX core into smaller pieces can help make each part more manageable, simple, and focused on a more finite set of problems. By following RESTful principles and avoiding tight couplings with specific UI frameworks, we can serve and manage multi-channel content in truly unique and infinitely customizable ways. And ultimately this can allow each component to better serve each of the various stakeholders involved in the process of managing a MODX site.
Following this natural extension of the UNIX philosophy applied to web application design, we can move towards a microservice architecture. We can organize component-specific teams that focus on a finite problem-space. We can provide these teams with the flexibility to quickly introduce new features and fix bugs without the constant fear of introducing regressions. And we can explore new ways of developing, deploying and scaling our sites over the course of their various life-cycles. Making MODX more adaptable, flexible, and more liberating to the creativity of all stakeholders are still the goals of the project. And although these may represent radical shifts in future implementation, they are not so radical in origin or motivation.
What’s Next and When?
There are basically two fundamental decisions that must be made in order to begin effectively replacing the foundation of MODX in this quest for relevancy. The first is a question of which basic libraries and dependencies (e.g. for dependency injection, routing, middleware, etc.) will the new MODX core be built upon. I have a few ideas, experiences, and prototypes that I will be sharing in part two of this series within a week or two, regarding how MODX could be re-architected. I hope this can focus the discussions and effort so we can start moving the next major version of the MODX CMS forward.
The second, more difficult problem, is deciding how persistence will be handled. And this I will save for part three.
