The future of MODX: ideas, roadmap and release cycle?

UX & Feedback
1

There are now a lot of new pull requests on GitHub, mostly by Bochkarev Ivan – thank you very much :pink_heart:

One of these pull requests has started a discussion that I would like to contribute to.

Over the past few months, I’ve been thinking about the future of MODX and writing the MODX Field Notes. I’ve also been looking at other CMSs, such as Kirby and Statamic. When I look back on the last year, I realise that a lot has happened in the MODX community, but not so much within the core itself — there was ModAI, and that’s it. There is no public roadmap, and there’s no information about what has been done with the Open Collective funding. Looking at other CMS, I found that: MODX is pretty functional, but it lacks features.

For example, the Media Manager lacks Alt-Description fields and so on. On the other hand, ContentBlocks has an older codebase, but it has many features that I’m missing in other CMSs, such as fine-grained user permissions and layout flexibility.

I think we need a clear public roadmap showing what we want to focus on in the coming months and years. Then everyone can make their own decision about whether to stay on board or give another CMS a chance. We will also know which pull requests to prioritise, allowing us to focus on the right ones.

When it comes to testing pull requests, I think we need more detailed documentation for non-MODX pros. Looking at the community, there are a lot of new users who use chunks and snippets but don’t know much about core development. We have to help them with a simple howto, because this is very important.

Also, perhaps we should release the version in smaller parts at a faster rate. The 3.2 update is huge, but it can be split into smaller parts. This would make it easier for people to test.

Here are some key features that need to be implemented to ensure MODX remains a reliable platform in the coming years, in my opinion:

  • Get rid of ExtJS. I think we should work on a Vanilla.js and HTMX alternative, as well as some base components for new plugins. This is a massive milestone, but it must be started for the next few years of development. Maybe we can skip ExtJS in 2030 :grinning_face: There is also a VueJS base that looks very interesting.
  • The Media Manager is great, but it’s a shame there’s no option to add custom fields for alt text, descriptions and copyright information. Hopefully this will be added as a feature soon, perhaps as extended fields in Agenda.
  • The template engine should support Twig. In one of my project, I wrote documentation stating that there are three template engines: Smarty for the CMP, MODX for email templates and Twig for Fred/Commerce. That’s a lot of confusion.
  • Drag to upload the TV field with cropping. Both exist and should be merged together, like the Contentblocks image field.
  • The documentation should be in one place. There are many places where you can read about how to use ModX. Same for the Community.
  • We need a public roadmap showing what is coming, who is working on it, and where to get money for what, as voted by users. This could easily be done in this forum, so we don’t have to start another platform, which I criticised here :zany_face:

I look forward to your feedback — from everyone who is currently using MODX.

8 Likes
2

In 2016 the MODX Advisory Board was announced (“it is the right time to take MODX to the next level”) with the primary goal to “create a public roadmap for future releases”.
What happened to this board? Was a public roadmap ever created?

In 2020 @ibochkarev created a post on the MODX Facebook group (according to this comment here) in which he laments the lack of a “roadmap for development” amongst other things.
(Did he ever get a response? I’m sorry, but I’m not on Facebook.)

Now it’s 2026 and the same questions are still raised.

So let’s not kid ourselves. This ship has been aimlessly adrift for years, and AI won’t be the solution. Using AI doesn’t replace the lack of a vision.

4 Likes
3

While you are doing that you might also be interested in looking at vvveb.

4

I don’t think it’s that simple. Reviewing a pull request doesn’t just mean running the code and see if it works. It also means looking at the code.

Ultimately the person who merges a pull request has to trust the reviewers, or else they still have to check every single PR themselves, in detail. If the reviewers are unqualified (like a random CMS user) or unreliable (like a LLM), nothing much is gained.

1 Like
5

I am ohnestly quite frustrated about the lack of marketing, posts, updates for MODX.
Clients never heard of it, if you Google MODX you get more about a Yamaha synthesizer.

MODX Cloud has been great to use (if expensive) but I am having a lot of problems getting more new clients willing to use MODX. They want WordPress or more modern solutions.

If MODX is to survive I think not only new features but also a lot more active marketing is needed…

4 Likes
6

I completely agree with you. Currently, however, I hardly see any developers commenting on this. Code control must definitely take place, I fully agree with you there. But I think that normal users could also be involved via smaller pre-releases. Similar to the nightly builds with MODX3 back then. Then we would at least get more momentum on GitHub :grinning_cat:

Perhaps we can pay someone a fixed salary through the Open Collective Budget and ensure quick response times?

Now it’s 2026 and the same questions are still raised.

I would like to hear the opinions of @rthrash and @opengeek first.

Feedback from @markh, @jako, @sterc/@nomark, @joshualuckers and @gelstudios would also be great.

1 Like
7
e class="onebox allowlistedgeneric" data-onebox-src="https://docs.modx.com/current/en/contribute/code/testing-pull-requests">
MODX Documentation
1 Like
8

Hi @jenswittmann,

Thanks for taking the time to share your thoughts. I wanted to get you some of my thoughts directly today, while other topics you brought up will take some time to get into shareable shape.

No public roadmap

This has been a longstanding issue. Post-MAB we had a good plan to move forward, then an all encompassing PR that touched almost everything came in. As touched on in my AI-related post in another thread, PRs like that are a virtually insurmountable task to get through.

There was some back and forth that happened and ultimately the person decided not to move forward with the PR change requests, so it died, stalling momentum and probably creating a lot of hurt feelings and frustration. It wasn’t a fun time for anyone, and I wish it had turned out differently. The 3.x release was a compromise on some of the things brought up by the MAB.

I’d love to see a roadmap re-emerge, in a way that can be executed upon with regular frequency. As you suggested, smaller releases are probably better. Streamlining Github to automate a roadmap as much as possible appeals to me a lot.

No transparency about Open Collective funding usage and paid reviewer via Open Collective budget

Open Collective is actually 100% transparent. It’s only been tapped into a few times, mostly for meetup-related food and beverage things: MODX · Expenses - Open Collective

We spend 6-figures a year on salaries across a handful of people (Jason, Mat, John, Jay, Me and others) that go directly to Open Source Software (Revo + Extras) virtually every week. We haven’t directly contributed to the Open Collective ourselves to be clear, but we definitely invest on tasks to get Open Source Software into the world.

While I’d love to have enough regular Open Collective contributions to bring on a full-time person from the Community to triage and evaluate PRs, that isn’t currently feasible. However, we started discussing this area late last year with an active contributor with deep MODX and—crucially for the time being—ExtJS knowledge. Hopefully we’ll see the first of many payments go out soon, and the budget growing as the cadence picks up.

Bounties for large PR reviews might be an interesting idea, too. Some of the recent PRs are straightforward to review, while others require a lot of deep inside knowledge about the inner workings and small-core philosophy we’ve generally lived by. We’re working on some guiding principles that will help make PRs less effort to review for future ones that come in.

Core development stagnant (only ModAI in past year)

I would love to have seen more core Revo releases last year. I’m likewise looking forward to putting a stake down and doing the first official 1.0 release for modAI. There was a lot of work that went into that, and many other Extras. Revo itself is a pretty time-tested and secure piece of software that’s still super-flexible. It also could use some ongoing work and features as you mentioned.

Community willing to help test but needs better documentation for non-developers

The docs Mark linked to above are complete, but they’re admittedly intimidating for non-devs. Love to hear any ideas on how to make this easier. There is also this tutorial using MODX Cloud that can probably be used with virtually any host with some minor updates (especially around builds that may be required): https://modx.com/blog/help-test-prs-to-accelerate-the-revolution-3-release

Suggests: nightly builds for momentum

We actually touched on this today in a call. In theory nightlies would be a great way to test the state of upcoming releases, but we haven’t seen a lot of uptake on that in the past. That doesn’t mean it might not be worthwhile in the future!

2 Likes
9

Nothing has changed for years, sadly. The volunteers who spend a lot of time and effort to help make the product better are not backed by the same time and effort or support by the for profit companies that actually make money from it. One is the company that actually owns the intellectual property and another is the one that silently claims the product and is probably having their own private fork.

I love the product, I enjoyed working on it, I miss working on it. Met some great people (hi Mark). And it gave me some great opportunities career wise.

The company behind the product lacks any kind of leadership in regards to the open source project. Ideas and initiatives from volunteers, other for profit companies are always “supported” but nothing really happens or it’s just left to bleed to a silent death.

10

I’m glad to see this being discussed here. There’s no question that a clear roadmap would be a huge step forward.

Beyond that, I think the two biggest stumbling blocks for new users are ExtJS (and a very old version of ExtJS), and the very non-intuitive permission system.

There was a time when I would have suggested JQuery as a replacement for ExtJS, but I’m not sure that still makes sense. I think the original attraction of ExtJS was its powerful grid system, but I suspect that JQuery grid systems have come a long way since then.

I suggested revisions to the permission system a long, long time ago, but it hasn’t really changed at all. My proposed changes were, in part, just a reversion to the Evolution permission system, where what users could do was defined by their roles (which held the permissions) , rather than ACL entries. The Evolution permission system was instantly grasped by new users, and I still think it could be used as a top layer over the current permission architecture.

You can make a case that the current permission system is more flexible and perhaps more powerful, but the price of that is that new users really struggle to understand it, and I think a lot of them give up and go to other platforms.

Another challenge is that MODX is now competing with use-case-specific commercial platforms. I’m currently doing some volunteer work on a platform designed specifically for Home Owner Association (HOA) use (mostly condos, gated communities, and RV parks). It has a huge set of features that handle everything an HOA would need, including membership, communication, event calendars, accounting, and compliance with state HOA statutes. It costs $50 per month.

A couple of years ago, I lost a client to a commercial platform designed specifically for auto-repair shops. In both cases, the platforms were sold by a very effective national sales force.

1 Like
11

IMO this is the biggest hurdle moving forward. Even if we somehow managed to get rid of ExtJS in the core manager code, ExtJS is also used in most extras. Extras with a CMP (like e.g. Gallery, ImportX, etc.) use ExtJS, extras for custom TV types (like MIGX or Image+) use ExtJS. And especially critical are extras that change/expand an existing manager page (like e.g. SEO Suite or Collections). It’s hard to imagine a scenario where you could change the core manager code and still have a transition period for tightly intertwined extras to catch up to the new implementation.

What makes you think that HTMX is the way to go? What would you use for UI components?

The current trend is to get rid of jQuery wherever it is still used. So this is definitely not the way to move forward.

For the new version of Minishop (Minishop3), the developers (at least partly) used Vue and PrimeVue (for the UI components) → see the extra VueTools. So maybe it could serve as an implemented example of a possible alternative.

12

This sounds mightily passive. Like a process you have absolutely no control over (like waiting for the sun to re-emerge during a rainstorm.) Aren’t you in a position (with the LLC and the direct contact/relationship to the core developers), where you can initiate/influence such a process?

3 Likes
13

Hi!

We’re also rewriting the remaining parts; we won’t have any Extjs anymore.

Plus, Nikolay and I are using exclusively VueTools with Pinia and Vue3 for all components that require a UI in the admin panel. And it helps us do amazing things! For example, ms3Pulse — дашборд продаж и аналитика для MiniShop3 / Русскоязычное сообщество MODX

3 Likes
14

I will also duplicate my vision of the direction:
From my perspective, the following areas seem critical:

1. API-first core
Built-in REST + GraphQL, auto-generated APIs for resources and models, JWT/OAuth2 authentication, webhooks. MODX has strong headless potential, but this should be native to the core.

2. Modern architecture
Micro-kernel and service-oriented structure, DI container, PSR-12 compliance, Composer as the primary installation method, and removal of legacy dependencies. This would improve testability, extensibility, and make extra development cleaner and more predictable.

3. Modern manager (admin UI)
Rebuilt with Vue 3, customizable dashboards, role-based UX (marketer ≠ developer), dark mode, inline editing — to stay competitive with modern CMS platforms.

4. SaaS-level performance
Built-in full-page caching with Edge support, native Redis support, Swoole/RoadRunner compatibility, automatic image optimization.

5. Stronger Developer Experience
CLI tools, database migrations, package generators, proper unit testing in the core.

6. Ecosystem & security
Next-generation marketplace, native multilingual support, 2FA, audit logs.

3 Likes
15

I’m also very concerned about the response and speed of decision-making regarding the PR review.

I resumed my activity on February 22, and so far only 1 PR out of 79 has been merged: Pull requests · modxcms/revolution · GitHub

Yes, I agree that some PRs are complex and require analysis, but most fix long-standing user issues.

I’ve provided some momentum, but it hasn’t been picked up yet. I really hope the situation changes soon and I won’t lose hope.

3 Likes
16

Can somebody please explain to an outsider like me (and to the general public) what the current situation is? Who’s actually in the core development team? Who can merge? Who ultimately decides what PRs get merged, when they get merged, when a new MODX version gets released, etc.?

I guess there are 3 major factions. The “Americans” (MODX LLC), the “Russians” (modstore.pro) and the “Dutch” (modmore, Sterc). As the public communication is quite sparse, do you guys at least privately talk to each other (about strategy and stuff)?

And what does this mean? Am I supposed to solve a riddle here?

3 Likes
17

modstore.pro and modx.pro, docs.modx.pro

If we were given the freedom, even just the two of us could complete a significant amount of work.

Others would also join in, at least with testing, but for now there’s no activity in the repository, and the PRs are hanging around and don’t even want to waste their time… - these are the words of some participants in a lively chat room of a 1,500-person Russian-speaking community.

1 Like
18

In terms of proactive collaboration, the core development team over the past year consists mostly of myself and @smg6511v2 with a few contributions from co-workers and community members. I generally do the integration work needed once a PR has been reviewed and accepted. Though, as code owners, @markh and I have the final say on what gets accepted and merged, we try to let active collaboration from the community drive the consensus for acceptance on individual contributions. Over the past couple of years, this activity had dwindled to a slow trickle. In practical terms, that left me to make a decision on every single contribution, with little or no input. This recent influx of contributions with no prior collaborative effort has done nothing but further burden the two most engaged developers with reviewing and deciding the fate of every single contribution. This is a sudden, unexpected problem that will require some careful consideration to solve in a way that best serves the project as a whole.

From my perspective, this isn’t about factions. As I said, it’s essentially been myself and @smg6511v2 communicating and collaborating on core development. But there are definitely other lines of communication that I’m not directly involved with between these groups.

19

To give some context first: there are multiple commercial entities active in the MODX ecosystem.

One entity is tied to the legal and organizational ownership and leadership of MODX itself. Other companies build businesses around MODX and may contribute to the project (or choose not to), but they do not automatically have governance authority unless that authority is explicitly shared with them by the project leadership.

Anyone can contribute to MODX by opening pull requests to the project. Before a contribution can be accepted, contributors must sign a Contributor License Agreement (CLA).

In that CLA, the term “Company” is defined as “MODX Technologies, LLC (and its successors or assignees), on behalf of MODX.” Contributions are licensed so that the company behind MODX can legally accept, use, modify, and redistribute them as part of the project.

In practice, the day-to-day maintenance of the MODX core is handled by a small group of volunteer maintainers (often referred to as Core Developers or Core Integrators). These maintainers review pull requests, test contributions, evaluate whether they fit with the direction of the project, and are the people who typically merge changes into the repository.

At the same time, MODX has historically operated with a structure where the company behind the project still plays an important role in the overall direction. While maintainers handle most of the technical review and integration work, strategic direction — such as priorities, roadmap decisions, and release timing — is generally influenced by the project leadership associated with the commercial side of MODX.

Public company information about MODX also states that the original founders and leadership continue to guide the direction of the project.

Some companies in the ecosystem have historically invested a lot of time and resources into MODX.

With that context in mind, a recurring concern within the community has been the imbalance between the volunteer effort that keeps the project moving and the level of support coming from the commercial side of the ecosystem. Many of the improvements, maintenance work, and day-to-day progress rely heavily on volunteers who invest significant time to keep the project healthy. At the same time, the level of backing, coordination, and leadership from the commercial entities that benefit from those contributions has often been perceived as limited. Over time this has led to frustration within the community, particularly when leadership direction is unclear or when disagreements arise between the different commercial stakeholders involved in the ecosystem.

20

For historical reference, I managed to find this comment I wrote 13 years ago on the old Forum:

There are some real advantages to having the whole core developed by a very small team, but there are some drawbacks as well. Having a small team is the reason MODX is as robust, secure, and well-designed as it is, but the down side is that the community feels less involved in development and development proceeds more slowly.

If I had to create a metaphor for this (and were allowed to exaggerate a little), I would say that it’s like there’s this small team locked inside a building working on the core. Every once in a while, one of them comes out and complains that no one is helping them, but there’s really no social infrastructure in place to get others inside the building.

I don’t mean to say things haven’t improved since then, but IMO, the problem I described has not gone away.

3 Likes