Modx revolution future Vs rest of the world

I would like to ask the community and the core team about what's next for modx.

How do they want their favorite tool to evolve ?
How will it handle the fast paced evolution of web development using PHP as main language ?
How will modx fit as a modern CMF compared to other solution's who embrace the future of PHP who lean toward standardization ?

First let's take a look at the current roadmap:

• Many Package Management improvements
• Transport Package dependencies - IOW, if a Transport Package specifies a dependency of another, then the package will attempt to "retrieve" the needed package from its Provider before installing.
• Extras Provider to PHP/REST with public API
• Auto-loading of xPDO Package classes
• Uninstall Options (similar to setup options)
• Deprecate modAction and move to file-based controller pages
• Make modNamespace a first-class citizen for development, tie it to Extra and version of Extra, etc

The main point of interest for me as a developper is Package Dependencies.
The industry seems to welcome Composer + Packagist, as THE way to manage librairies dependencies and/or whole CMS distribution.

Most of Modx adversaries embrace it as well, we can already see some of them relying on it for distribution and package management :
- Silverstripe (http://doc.silverstripe.org/framework/en/installation/composer)
- Drupal (http://drupal.org/project/composer)
- Joomla (https://packagist.org/packages/joomla/joomla-platform)

Which in turn facilitate greatly integration with other packages as well, like a forum :
- FluxBB (https://github.com/fluxbb/installer)
- PhpBB (http://area51.phpbb.com/phpBB/viewtopic.php?f=81&t=42757)

Does Modx have any plan to be a part of this at some point ?
Or will it develop it's own way of doing thing appart ?

This would be a shame.
Composer + Packagist are widely recognized, setting up a packagist server is easy to do, and it would allow people to have access to thousands of librairies cross platform as well.

Which leads to another important point : namespaces and autoload.

Will modx plan to use native PHP namespaces (instead on relying on heavy prefixing) ?
What about CMS wide autoloading ?
Will modx follow PHP-FIG (PSR-0/1/2) recommendation's too ?
Adversaries also started conversion steadily : Joomla, PyroCMS, Drupal...
This would allow the platform to use a widely accepted standard and probably better code reuse/adaptation when/if needed in the long run

I must be honest, if modx misses those 3 particular points, for me, it will be placed in the same place as Wordpress (or codeigniter) : an old tool who was once a cool kid, and has grown to be a tool who does not embrace innovation and in the end, actually makes me lose more time compared to what other "modern" platform can offer me.
It's not a rant, i understand the need with backward compatibility either with previous Modx version and API, or old php version.
They are definitively legitimate concerns, if you like Modx as it is and it does everything you need, that's cool for me. I'll move on.

That's not all

At the time when modx came out, Jason did review a lot of tools before choosing to do it's own "better" tool.
I believe that he was right at the time, xPDO was a very cool tool, and imo better than the alternative.
But now, in 2013, xPDO feels like yesterday's Doctrine for me.
Today i can use a complete ORM without having to build a schema, generate maps, while being less verbose and more straight forward than with xPDO.

Does MODx still evaluate what it could gain by using 3rd party codes for the core ?
Like using some of the Symphony 2 components (yes this is linked to composer usage).

Since Modx seems to evolve toward the cloud, i have a feeling that the CMS/Framework/ORM will have less "hands" to work on it, and therefore will not be able to evolve as fast as it would like to be.
Why trying to play catch up indefinitely (and reinventing the wheel) when you don't have the time (or the money i guess) to do it on your own ?
Maybe take a 3rd party tool as a strong base, a maintained API, with having lots of support and industry recognition is not such a bad move ?

And voilà, what do you guys think ?

In my mind, the roadmap is that what the community asks for and helps make happen.

Backwards compatibility is always a major concern, but that's where semantic versioning comes in. While I think that the releases would needs to be balanced so you don't break everything too often, it's important to not be afraid to come with a new breaking release.

The famous MODX3 will be the first semver release that is ready to break free from current restrictions in the way Revo broke free from Evo. What you fancy breaking?

A lot of these concepts are well beyond the level at which I think/worry about MODX. But down here at my level, I would love to see some strong enhancements to the Package Management system. I don't necessarily think about this from a technical perspective, but more from a practical one. I'd like to see more progress toward a model where 3rd party providers are developing & selling more and better add-on packages. Generally speaking, I think there is tons of development creativity happening all the time within the MODX community, but only a small fraction of it ever sees the light of day as an official package. I think this is because the incentives often just aren't there to take a concept past what "works for you" and abstract it enough to make it usable and beneficial for others. If there were an easier way to monetize this kind of development, I think we'd be seeing a lot more innovative packages popping up that would generate a lot of good buzz and only lead to better things.

Quote from: markh at Feb 20, 2013, 09:43 PM

In my mind, the roadmap is that what the community asks for and helps make happen.

Totally agree.

The famous MODX3 will be the first semver release that is ready to break free from current restrictions in the way Revo broke free from Evo. What you fancy breaking?

I don't really care about breaking things, as i'm used to switch between different tools (sometimes against my will).
As long as the breaking bring something that is better, i would welcome it anytime.

I will not port websites built with Revo on Modx 3, so backward compatibility is not a concern for me.

I would love a "simpler" xPDO (or broke free from xPDO altogether) allowing me to work with database without having to define a model via xml, then a build schema, which generates map files, and if i change one relationship or add one, i have to edit again the xml, then rebuild the maps.
Having a migrations system however would be a huge plus.

I would love to be able to switch template system at will. I don't really care if the other prefers the modx template tags, i would like to use the template system i fancy most.

The following point have already been discussed many times, but it remains a major concern for me, and grow bigger year after year: I would love to broke free from elements in database.
And honestly, since I dont use property sets, I don't care if it's not backward compatible.

I would love Modx to use third party code when possible, like Monolog instead of MODX::LOG or Symphony Request for Routing.
Obviously the later is far from being easy, but hey, you asked

I would love Modx to be less verbose ($modx->regClientStartupCSS() Vs Asset::css()), more expressive ($modx->sendRedirect() Vs Redirect::to()).
I would love Modx to use php 5.3 _call_static so that i can use Facade and cool DIC feature while keeping the code fully testable.

Ultimately I would be ecstatic if modx to concentrate on being an awesome Content Management System, while letting the framework part being handled by a real framework.
There are plenty awesome frameworks to rely on (Yii, Symphony, Laravel) with lots of people working on them, allowing other people to build applications and CMS's upon them.

Quote from: jrotering at Feb 20, 2013, 09:55 PM

A lot of these concepts are well beyond the level at which I think/worry about MODX. But down here at my level, I would love to see some strong enhancements to the Package Management system. I don't necessarily think about this from a technical perspective, but more from a practical one. I'd like to see more progress toward a model where 3rd party providers are developing & selling more and better add-on packages. Generally speaking, I think there is tons of development creativity happening all the time within the MODX community, but only a small fraction of it ever sees the light of day as an official package. I think this is because the incentives often just aren't there to take a concept past what "works for you" and abstract it enough to make it usable and beneficial for others. If there were an easier way to monetize this kind of development, I think we'd be seeing a lot more innovative packages popping up that would generate a lot of good buzz and only lead to better things.

Well, most of these concepts make my life easier as a developper.

But the whole picture is also to take in consideration.

Packagist would allow Modx website maker to have access to thousands of 3rd party library and tools.

Some of them stay binded to a specific tool (which is precised - no surprises), but most are written in a way that allows people to integrate them as it is in their projects (PhpExcel, User Management, Paypal, Cart Management... )

Since they are librairies, nothing will then prevent modx community to build plugins based on them.
That would also dev to be quicker, without the need to reinvent everything in the modx context.

An example ? Who wants to build a cart system within Modx ? It's always asked but, hey, it's a freaking huge task...

With composer you would could have started by using this cross platform library https://github.com/adrianmacneil/omnipay
It's already there, a solid base would have been already handled. And bonus gift, the API and documentation is already in place.
That's just an example.

I don't really care about breaking things, as i'm used to switch between different tools (sometimes against my will).
As long as the breaking bring something that is better, i would welcome it anytime.

I will not port websites built with Revo on Modx 3, so backward compatibility is not a concern for me.

Obviously, an "upgrade" shouldn't be a "port", but by communication through the version number that backwards compatibility has been broken, it makes handling expectations so much easier. We shouldn't be breaking stuff "cause we can", but it does provide an opportunity to shake up what needs to be shaken up. And only for the better, of course.

Oh, and I do know that Jason has been experimenting with PSR-0 / autoload / namespaces and that's definitely one of the things I personally support as it'll aid consistency and make it easier to write certain code. [ed. note: markh last edited this post 11 years, 2 months ago.]

Quote from: lossendae at Feb 20, 2013, 08:47 PM

And voilà, what do you guys think ?

I was actually wondering about this earlier today... Specifically about Composer and how that might best fit into MODX projects. @lossendae, I really like where you are going with your ideas here, taking it further, making it more integrated into the CMS itself, allowing for even more "Creative Freedom" than most already find possible with this amazing framework.

In hindsight, I think the MODX team probably takes a lot of pride (which they should ) in the "Core Only" approach, as this helps to absolve the CMF from the inevitable bugs or vulnerabilities that are bound to appear in any given third-party components (3PC) that arguably could be considered a "dependency" (e.g. getResouces, Wayfinder, etc.) MODX-specific or not, integrating third-party tools as you're suggesting would come with some huge benefits, but also some risks. That's not to say the Core should ever be considered "bug free", but looking at MODX Evo as a specific example of marrying the two together, I completely respect the direction taken.

What's interesting about the Composer idea is that would allow for dependency declaration within the "core", but also keep things separate as is the case today. Historically, if a critical patch was required to a 3PC, that meant a version bump and hotfix release of MODX, when really it wasn't otherwise necessary.

@Mark, I fully agree with you. MODX ultimately can/will become what the community makes of it -- to a point. In all fairness, there are many great Pull Requests to the MODX core or MODX add-on GitHub repos (some authored by the core team members) quite simply collecting dust... Please don't take this as any kind of complaint, I completely understand the balance that must be sought here, not to mention, who complains for something Free?

I guess my point is, giving the community a little more freedom over what can or can't be made available to "the masses" might not be such a bad thing for the future of MODX... [ed. note: pixelchutes last edited this post 11 years, 2 months ago.]

Wow plenty of points here which I have been raising over the past 4 months or so on Twitter, via Skype with various MODX devs. I am all for change as you prescribed Lossendae. I think they should be welcomed by the MODX core team, if not all at once at least little by little.

I am working on a few Extras to make some of these ideas possible, although not in the core as I would like it to be but it will be a good enough proof of concept once done.

These are some really interesting questions. Thanks for asking them.

I expect MODX 3 to be an excellent package and I think it will address some of these issues. Revolution was always held back by being tied to Evolution and MODX 3, hopefully, won't have that problem. That said, I'd hesitate to change the current tag scheme since a whole lot of people are familiar with it.

I personally like xPDO a lot. I don't think it would be at all difficult to create a wizard to help people design a system of relational tables and create the schema and class and map files for them (though it would be time-consuming). The infrastructure to do that is already built into xPDO, and the createXpdoClasses snippet gets you about half-way there. With a well-made UI and a way to specify the relationships between the tables, it would be dead simple to add your own tables to MODX using xPDO.

BTW, autoloading classes is already fairly simple in Revolution with PHP 5 (unless I'm misunderstanding your point). MyComponent, and I think some other extras, already do it. I think a MODX convenience method to register autoloaders would be really easy to make and could use the existing namespace path field.

As someone with about 30 MODX extras, monetization (I hate that word) for extras is a concept I would support. People have been very generous with donations, but at the present rate, it works out to about five cents per hour. To my knowledge, there has never been a MODX extra that people could buy as you buy extras for the other major CMS platforms (though I suspect that no one is getting rich that way). There simply isn't any infrastructure for that. You could argue that there would be more developers working on extras and the quality of both the extras and their documentation would improve significantly if that infrastructure existed.

The idea of building MODX on top of some other platform, or integrating it with another platform, is a really interesting one. I'm curious to hear the official response to this. Having spent a lot of time wandering around in the core code, though, I suspect that it would delay MODX 3 for at least a year or two, maybe more.

With respect to the roadmap, I found Mark's comment particularly interesting:

In my mind, the roadmap is what the community asks for and helps make happen.

I originally intended to contribute to the MODX core code. Over time, I found that it just wasn't possible for me to contribute anything other than relatively simple bug fixes, suggestions, and feature requests. It may be that I didn't have the necessary skills (especially with regard to ExtJS), but it does seem like many others came to the same conclusion.

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. Unfortunately, I don't have any worthwhile suggestions about how to change that.

I'm really looking forward to seeing more comments in this thread.

I get a mix of nervousness and excitement when I think about the amount of work there is to do!