New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"MODX" Next Roadmap? #12863

Closed
jpdevries opened this Issue Jan 18, 2016 · 38 comments

Comments

Projects
None yet
@jpdevries
Contributor

jpdevries commented Jan 18, 2016

Summary

Moving a discussion about "MODX 4.0" vs "MODX 3.0" from #4675 (comment) to this issue. Will MODX Next be a separate repo or part of the modxcms/revolution repo?

Opening as requested by @adamwintle

@jpdevries I'd like to discuss this, +1 for a new Github issue so everything is permanently logged.

Observed behavior

The community does not know where to go to contribute to "MODX Next" or of said roadmap.

Expected behavior

The community should know where to go to contribute to "MODX Next" and of said roadmap.

@Mark-H

This comment has been minimized.

Collaborator

Mark-H commented Jan 18, 2016

Pinging @gpsietzema

@adamwintle

This comment has been minimized.

adamwintle commented Jan 18, 2016

I was just looking around at how other larger open-source projects handle this. WordPress has a vote-based system where members of the community choose what goes into each release: https://wordpress.org/ideas/

To me this totally makes sense and leaves things in the hands of the community, rather than decisions being made behind closed doors and then just announced and expected to be accepted.

From what I understand about open-source software everything related to the project, not just the core code, should be considered open-source, including the planning, designs, marketing sites and roadmaps; and that would be the only way to make it a truly community project.

Regarding MODX 3.x/MODX Next, these should have had some type of open document (Github issue, Trello board, Google Doc) so at the very least ideas can be logged and timelines can be discussed.

@gpsietzema

This comment has been minimized.

Collaborator

gpsietzema commented Jan 19, 2016

I agree Adam and I also think you need to add something extra: people should also pledge hours to a project, because we need people to plan/design/write stuff. It would be awesome to create a format for that.

We're currently doing an inventory on the community and helping the modx team to create some structure for the Next MODX :) This will take some time now without directly visible results, but in the long run it will save us all a lot of time. Starting on something like this without a plan/strategy and tactic will not bring our community any further.

@OptimusCrime

This comment has been minimized.

Contributor

OptimusCrime commented Jan 19, 2016

I'd love to see some sort of RFC like PHP-FIG and PHP.net uses.

@jaygilmore

This comment has been minimized.

Member

jaygilmore commented Jan 19, 2016

I think there would be value in documenting problems people would like solved in MODX Next somewhere. I have a slight concern on this statement:

We're currently doing an inventory on the community and helping the modx team to create some structure for the Next MODX :)

The reason I am concerned is because there are end user oriented innovations that should be made before the first line of code is written or the architecture of MODX Next is even a glint in a developer's eye. I already find that the problems solved in MODX tend toward mostly fixing their own site builder problems. Of course, that's not 100% the case. Focusing only on the MODX Community, IMO has been the problem. The people who's content problems need to be solved is a group of stakeholders we need to address. We also need to be mindful of where the content management and website industry is going. I'd hate for MODX Next to be another version of Revo/Evo but using modern techniques. There's a much bigger leap to be taken for users of all types.

@gpsietzema

This comment has been minimized.

Collaborator

gpsietzema commented Jan 19, 2016

Jay, that's exactly what we've been talking about so far. There needs to be a lot of stuff, before we can even start thinking about writing code. The inventory is not only aimed at finding developers to do their magic, there is much more know how in our community and a lot of people with clients ;-)

I'm fairly sure we're on the same page regarding this.

@jpdevries

This comment has been minimized.

Contributor

jpdevries commented Jan 19, 2016

I also think some sort of "Field Guide" is needed. Working on something like this would be a great way to keep us from making some of the same mistakes that were made in 2.x in a different way. For example, Angular-izing everything instead of ExtJS-izing everything when really we should be HTML-izing everything.

We also need some sort of regulations. @OptimusCrime why is it totally fine to make breaking changes for composer but frontend breaking changes aren't invited because they would "crash every single extra ever written for Revo". Doesn't this composer stuff break stuff too? Isn't that what breaking changes are for? This is another example of the MODX "Roadmap" demoting frontend. Also, that is assuming some contributors haven't already envisioned a legacy driver that ports the legacy JSON to raw HTML components. If it were voted up enough, we could make it happen.

I was under the impression "MODX 3.x" would loose the "Revo" name (and BC) but this change essentially came out of no where. Maybe I am missing something but I don't see any posts about a "3.x being developed" on the MODX Blog yet every other post seems to be an update on MODX Cloud. Again, if a 4.x project is kicking off soon I'm trilled but if it is going to be another 6 years before a breaking change than it's over, we've already lost. We'll have a self driving cars before we can use MODX on an iPad.

It has become increasingly apparent that the LLC is comfortable continuing to invest primarily in 2.x. Look at the a11y campaign. The a11y campaign choses to invest back into the ExtJS stack (2.x) rather than sprint to make it irrelevant (3.x/4.x). Except it doesn't invest directly back into the core, it creates a separate a11y theme instead #12782. I think if you read between the lines, it is safe to assume not a lot of attention is being put towards the future frontend of MODX or the frontend core of the current MODX by the LLC. At least not publicly. Apparently it's too "risk averse" for them to touch? #12782 (comment)

Or maybe they already have the whole thing figured out behind closed doors.

Setting my risk aversion aside, I drafted PR #12776. When welcomed PRs like this one come along that target enhancements to the core, they cannot target the a11y theme also as it has diverged. While the campaign can solve this by merging in enhancements submitted to the core I'm concerned that the time spent doing so eats into the valuable time covered by the donations. It doesn't feel good to know that by enhancing the core of MODX I'm probably either eating into the community's generous donations to the a11y campaign or submitting enhancements that won't make it into the a11y theme at all.

It was never risk aversion that prevented me from submitting a PR like #12776. It was logic. I'd been being told that we were "already onto the next thing" and have been waiting for some sort of baton so we could sprint towards a new MODX Manager for several years now. But it hasn't come. Except it has (3.x) along with the decision to stick with ExtJS. It's becoming the story of a "phantom baton".

I'm concerned with the future-forward contributors we aren't attracting as well as the ones we are at risk of loosing as our frontend tech stack becomes increasingly stale and distasteful. MODX is arguably the best preprocessor of HTML and yet we have repeatedly and collectively failed as a community to embrace HTML within our tech stack. Think about how ironic that is. Our competitors are absolutely destroying us in this area and we have community members willing and able to get us brought up to speed. They just need somewhere to do it.

Regarding a roadmap, we should probably start by deciding which major version we can target HTML 5 in? As of Dec 1, 2015 that was apparently up in the air
#11339 (comment)

@OptimusCrime

This comment has been minimized.

Contributor

OptimusCrime commented Jan 19, 2016

@jpdevries I did not have time to read all you wrote, but I agree with a lot of what you are saying. You should think about MODX 3.x as a Revo version where they don't need to think about breaking stuff. And you are right, breaking frontend (like ExtJS) would fit under this category. However, I feel like the devs want to some extent try to limit the changes that are done, if not they are really just creating a completely new version of MODX, in which case it would make more sense to start all over.

Again, I don't think development on 3.x should hinder MODX Next that much.

Why it was decided to add composer support to Revo is beyond me. I don't really see the benefit of doing this. It might be to use the latest version of xPDO, but again, I am not sure.

I would like to go over these questions you have and discuss them in a blog post some time.

@OptimusCrime

This comment has been minimized.

Contributor

OptimusCrime commented Jan 19, 2016

Btw, one more comment here guys. As you can see, the 3.x branch is already up in this repo: https://github.com/modxcms/revolution/branches

It was just confusion that led to the name MODX 3.x, because it has always been Revo 3.x, a Revo version without BC. Most of the confusion comes from the fact that MODX 1.x has in a way been Evo all this time because Revo is a rewrite of Evo and was started at version 2.x if I am not mistaken. However, you should think about these numbers as Revo ANYTHING is still just Revo.

However, MODX Next will start without a single line from Revo, with a clean canvas (I think, and hope). Which again will make it most logical to number MODX Next from 0.x, 1.x and upwards separate from Revo and Evo version numbers. They don't have anything in common.

Again, I don't know why Composer and all this was decided to be added to Revo, because it does not make much sense in my head. I'd rather keep Revo as the product it is today and in stead focus much more intensely on a MODX Next version that we can see as soon as possible.

@sottwell

This comment has been minimized.

Contributor

sottwell commented Jan 19, 2016

This is due to the adoption of SemVer - Semantic Versioning. Minor numbers are for patches and bugfixes, such as from 2.4.2 to 2.4.3. The next number is for non-breaking enhancements, such as 2.5. Major number is for breaking changes, and that applies to MODX 3.

MODX Next will be another complete rewrite of the core, using different technologies, much the same way that Revo was a rewrite of Evo. The introduction of Composer as of MODX 3 takes a bit of getting used to, but it will only apply to development and building, not to releases.

@jpdevries

This comment has been minimized.

Contributor

jpdevries commented Jan 19, 2016

@OptimusCrime I've received some clarification that the "pie in the sky" all-new Manager I'm so anxious of would actually be entirely on it's own versioning system. So it would be like "MODX Next 1.0" or maybe even just "MODX 1.0".

I'm looking forward to what @gpsietzema is working on and agree MODX Next should be an all-new album, not a remastered version.

It would be great to get a working group going that can propose and vote on concepts. For example, the one thing I really really would love to see agreed upon is that the tech stack should be traced back to web standards (ie: the backend requires no external js libs to communicate with API). How does that happen? Where should this be discussed and how should proposals be submitted?

This would allow creative freedom in the manager because developers could use the libraries (or not) of their choice without breaking the core. ES6 gives us everything we could ask for to make an parse an XHR request along with powerful template strings. While I can </rant> all day about not breaking ground, we are at a really interesting point in time to be able to adopt all the web technologies that have recently landed.

@Mark-H

This comment has been minimized.

Collaborator

Mark-H commented Jan 19, 2016

Just to reiterate something @opengeek just said on Slack: nothing is being developed behind closed curtains.

3.x will be Revo with breaking changes for the better, MODX Next is the mythical creation that Jason has been discussing in his Medium posts and for which plans are being made on tackling things like defining a roadmap, structures and development steps to take. This isn't new, but I'll agree it could've been communicated better and I think it might warrant a post on MODX.today soon.

By the way, what's up with the hating on composer? :P It's a tool for (core) developers primarily and the specific changes in 3.x (xPDO 3.x) are 99% backwards compatible (afaik the only actual breaking change is a slight signature change on custom resources), while adding important back-end improvements like namespaces, autoloading of classes, simplified structure of models and a set of CLI tools to replace all sorts of bootstrapping currently required when developing extras.

@sottwell

This comment has been minimized.

Contributor

sottwell commented Jan 19, 2016

I think the concern over Composer is that it's yet another bar to entry, another server-side application that developers may or may not be able to install on their development platform, and need to learn how to use.

@Mark-H

This comment has been minimized.

Collaborator

Mark-H commented Jan 20, 2016

Composer is standard in the PHP world of today.. I'd say that for anyone from outside the MODX bubble, not having composer or those new features in xPDO is a bigger deterrent. I literally got a question from someone about whether the framework behind MODX was "modern" (as defined by being installed by composer and supporting namespaces and autoloading) less than 12 hours ago.

The "bar to entry" you mention applies only to 3.x installs from git, and consists of installing composer globally once on your machine, and simply typing composer install in the root of the project; composer does the rest.

Yes, we need to be careful to not overcomplicate development or to raise the bars for contributing too high. No, composer is neither of those.

@pixelchutes

This comment has been minimized.

Collaborator

pixelchutes commented Jan 20, 2016

I ❤️ Composer! I would highly encourage anyone who's not yet had first hand experience with it to try incorporating it into their workflow. Combine that with PSR coding standards and styles, and it's a whole new PHP world (for the better.)

I am personally very much looking forward to MODX "catching up" so we can autoload, and more easily use alongside other namespaced PHP projects.

@OptimusCrime

This comment has been minimized.

Contributor

OptimusCrime commented Jan 20, 2016

No hate on Composer, I just don't know if introducing MODX to it at such a late stage is a good idea/worth the extra work. What will Revo 3.x with Composer support be able to do that Revo 3.x without Composer support can't do? I know we can separate the codebase with 3rd party apps like PHPMailer og Smarty, but that is about it. And I am pretty sure that in one way or another can be "hacked" without making the rest of Revo compatible with autloader(s).

@Mark-H

This comment has been minimized.

Collaborator

Mark-H commented Jan 20, 2016

"at such a late stage" sounds like you consider Revo to be halfway out the door ;) Composer is only a small part of what's happened in the 3.x branch, the more important changes are namespaces and autoloading in xPDO.

@OptimusCrime

This comment has been minimized.

Contributor

OptimusCrime commented Jan 20, 2016

Well, I more consider MODX Next to be the more logical stage to introduce these features. I agree that namespaces/autoloading for xPDO is smart, because much of that can be reused in MODX Next (as far as I know, that will also use xPDO), but this can be used without namespacing/autoloading the entire Revo code base. It is quiet a change to do this.

@jpdevries

This comment has been minimized.

Contributor

jpdevries commented Jan 20, 2016

Composer is standard in the PHP world of today.. I'd say that for anyone from outside the MODX bubble, not having composer or those new features in xPDO is a bigger deterrent.

HTML 5 is the standard of the HTML world today. We are using HTML 4 in Revo. ExtJS 6.0 is out. We are using ExtJS 3 in Revo.

I'm not sure why or if we are more concerned with the PHP stack becoming more stale than the front end stack, but I think they are equally valuable. Nobody cares what your backend does if they can't navigate the page… frontend and backend go together hand in hand.

I think MODX Next is the next logical step to introducing a re-imagined user experience to MODX so I am really looking forward to seeing how that unfolds.

@silentworks

This comment has been minimized.

Contributor

silentworks commented Jan 21, 2016

@sottwell Composer based projects can be run on any server supporting PHP 5.3.2+. You do not need to run the composer install command on your production server, you should do this in your build stage or on your local machine and you would only need to do this if you are a contributor to MODX. For the end user this is not an issue.

@jpdevries the reason why there is so much emphasis on the PHP side is it will make development easier and it will move us up to a more secure version of PHP (albeit still non-supported version by the PHP core). The front-end is not going to allow someone to hack my site easily, but the backend will, hence the emphasis on it more.

The reasons for changes in MODX 3.x is the codebase is outdated and hard to manage, if you don't believe me take a look at the installer alone and you will get the gist. I have been working on updating the installer since around September last year as an experimental project and the code is so hard to follow that I keep putting it off. If we want more developers contributing to the project, we need to clean it up, because in it current state its not healthy for most developers outside of the MODX eco-system to contribute, actually its not healthy for most developers even inside of the MODX eco-system to contribute.

I will put my code for the installer somewhere online soon, I just need to get the latest updates from the main repo as the project has moved along and left me for sometime now.

@sottwell

This comment has been minimized.

Contributor

sottwell commented Jan 21, 2016

Well, I'm just grumpy because I haven't even caught up with what I need to know to do any serious development, and you guys keep adding more stuff I need to learn. Actually I'm pretty sure that Composer will be extremely useful once I figure it all out.

@silentworks

This comment has been minimized.

Contributor

silentworks commented Jan 21, 2016

@sottwell if you ever need help with anything to do with composer, just ping me. I am more than happy to help if you need me to.

@jaygilmore

This comment has been minimized.

Member

jaygilmore commented Jan 21, 2016

@silentworks and @jpdevries I don't see why we're at an either/or situation? In my mind we can fix the back end developer UX and bring it up to snuff while working on the Front End as well. I'd argue the real reason is that it's PHP developers who seem to dominate the product development decisions and there's a real need for designers and front end developers involved in the direction and decisions on what will be done with MODX—be it Revo or MODX Next.

This is in no way intended to slag anyone. I am noting an observation and a path to a better future.

We can have parallel initiatives on the same project. It will take coordination and there will need to be serious discussion on how the front back will impact one another but the project will be healthier for it.

@jpdevries

This comment has been minimized.

Contributor

jpdevries commented Jan 21, 2016

This is also true for the front end:

The reasons for changes in MODX 3.x is the codebase is outdated and hard to manage

From a Frontend perspective I think MODX is insecure in a less technical way. When trying to sell certain clients on the manager interface itself it is difficult to be confident and secure in what our product brings to the table in that area.

Composer ushers in a whole new PHP world for the better. Does responsive design not do the same for user experience and accessibility?

I think part of the back and forth is we have front end contributors wanting some sort of a data model or functional spec to aim for meanwhile back end developers feel we'll get a new manager interface when somebody goes ahead and creates one. We played phone tag and we missed a chance to break MODX for everybody. It's kind of like we are trying to make music like the Postal Service except we aren't sending each other track back and forth. Then again hey, I hear Tool writes all their music first and then brings in the singer at the end, and they make pretty good albums.

@Mark-H

This comment has been minimized.

Collaborator

Mark-H commented Jan 21, 2016

Composer ushers in a whole new PHP world for the better. Does responsive design not do the same for user experience and accessibility?

Didn't you just make Revo, like, 5000% more responsive? Nobody is battling against front-end improvements. Perhaps it's not quite being pulled as much as back-end stuff is presently, but there are no evil forces plotting to stick with ExtJS or the xhtml doctype for the next decade.

@jpdevries

This comment has been minimized.

Contributor

jpdevries commented Jan 21, 2016

Didn't you just make Revo, like, 5000% more responsive?

There are still important actions you can't do that are hidden behind right clicks.

there are no evil forces plotting to stick with ExtJS or the xhtml doctype for the next decade

Prove it. With a roadmap.

@Mark-H

This comment has been minimized.

Collaborator

Mark-H commented Jan 21, 2016

Roadmap

  1. Update doctype to HTML5
  2. Get rid of ExtJS to be replaced with HTML-first, accessible alternative
@Mark-H

This comment has been minimized.

Collaborator

Mark-H commented Jan 21, 2016

In all seriousness...

Updating the doctype might be fairly simple, though I can suspect for certain older browsers it might require some subtle CSS changes. Not sure how well ExtJS works with it, but with sufficient testing, I don't immediately see a problem doing something like that in a 2.x release.

For getting rid of extjs and building a better alternative there needs to be a plan. Do I have that? No, because what do I know about front-end development. I just make everything #ff9900. That's a process that needs to be guided by a focus group that cares about the topic, has experience/skills in the relevant fields (html, css, js, accessibility, back-end development, design and probably more), and can also start the work on it in a way that others can join.

Getting namespace and autoloading support was probably a lot easier to pull off than a new manager will, because it only involves one area of the code. One person can carry that initiative and make it happen. That does not mean initiatives for more complicated improvements will be shut down from above/below/aside, but it does mean it's a bigger challenge that needs more people to collaborate and dedicate effort to it.

@jpdevries

This comment has been minimized.

Contributor

jpdevries commented Jan 21, 2016

There seems to be confusion around whether a new Manager for Revo is being discussed, or an all-new Manager for an all-new product, or both. For example, if we are talking about an all-new product/roadmap I would think there is no need to "get rid of ExtJS" rather just not add it to begin with.

@jaygilmore

This comment has been minimized.

Member

jaygilmore commented Jan 22, 2016

MODX Next is not Revo Next. We should be thinking about this as a new product. So it's not a matter of getting rid of anything but mapping out a new Web Content Management System (and Framework) interface and interactions (not necessarily in that order). So, any discussions about MODX Next should not be saddled with legacy except for the paradigms that we value around separation of content and code, flexibility, and the system doesn't inject anything not requested on output. (there are other principles/values to discuss).

@OptimusCrime

This comment has been minimized.

Contributor

OptimusCrime commented Jan 23, 2016

I'm thinking that if you rewrite Revo to follow Composer and add namespaces/autoloading, as well as completely change the backend (e.g. by removing ExtJS), what is left of Revo then? One of the greatest things about Revo is the amount of Extras, and how much you can do with them. It will take the community several years to reimplement their extras for a Revo 3.x that is so radically different from 2.x.

Based on that, my question is instead, why can we not let Revo continue to exist like it is to day? More or less keeping things like they are in 2.x, and focus on fixing bugs.

To me, Revo is "up against te wall". This is due to the nature of the core, how difficult it is to make it play nicely with something else (like Composer), without a heavy rewrite, and because ExtJS restricts the frontend in a lot of different ways.

As I've said before, Revo is a product that is awesome, but it is old. The time and effort it will take to bring it back to modern times may not be worth it. I am more in favor of fixing things, and start all new with the experience (good or bad) from Revo in mind when designing a new product.

@jpdevries

This comment has been minimized.

Contributor

jpdevries commented Jan 23, 2016

To me, Revo is "up against the wall".

ExtJS arose from the "IE era" which is over now. With continuously updating browsers becoming the norm, the rate at which we are outpaced will continue to accelerate.

@wuuti

This comment has been minimized.

Contributor

wuuti commented Jan 23, 2016

Just started to follow the discussion. I very appreciate that there is one. What I have seen so far: it all went very quickly the same way as it always did since I first got in touch with MODx:
The discussion is getting nerdy and somewhat trolled in a very technical way: why do we always come so early to questions like composer or not, is it html5 or extjs or whatever. does not matter at this point.
Instead let's focus back on the topic! It was/is "MODx roadmap", and as far as I understand, that is a much more abstract and more of an organisational subject.

My suggestion to this: let us first create one ballast free repository for any discussion about future development, roadmap for whatever modx version (evo, revo2, revo3, modx4...), ideas and whishes of the community as well as pros/cons of developers/LLC. Let's place and name it modxcms/Roadmap. Let's make sure, that the state of the ongoing discussion there is regularly summarized by articles on modx.com, modx.today or whatever to spread it out to the wild and attract others to contribute. Let's then use the issue mechanisum to split the whole discussion into several independend parts. Let's use the labels, PRs and other mechanism to manage the roadmaps and ideas to get the details out of textbloated non-permanent discussions on [forum|slack|email|conferences|github|blackbox].

@OptimusCrime

This comment has been minimized.

Contributor

OptimusCrime commented Jan 23, 2016

+1 for modxcms/Roadmap, sounds like a good idea.

@jpdevries

This comment has been minimized.

Contributor

jpdevries commented Jan 25, 2016

A Roadmap would really help clear things up and give us a better way to measure progress, but I think Coding Standards and Guidelines are important as well. So important in fact, that I think creating them should be on the "roadmap" ;)

Wordpress published their Accessibility Coding Standards on their .org yesterday:
https://make.wordpress.org/core/2016/01/24/accessibility-coding-standards-now-in-draft-and-seeking-comments/

Just before MODXpo 2015 I started drafting some generic "Web Guidelines" at:
https://github.com/jpdevries/webguidelines

During Vitaly's talk he mentioned that some guidelines write about what not to do rather than what to do instead, but these focus on what to do.

I've begun drafting some Manager Interface Guidelines (MIG) on another branch of the safe repo:
https://github.com/jpdevries/webguidelines/tree/manager

I'm excited to explore the possibilities of creating Framework Agnostic APIs along with other concepts there.

@wuuti

This comment has been minimized.

Contributor

wuuti commented Feb 2, 2016

Anyone else having thoughts about a modxcms/Roadmap repository? I would like to say, let's just try it and see how far we can get with that...

@jpdevries

This comment has been minimized.

Contributor

jpdevries commented Feb 6, 2016

I think this is pretty interesting:

“Creating an API? Document everything first. And document when you add a new feature.” #ssphp16
— Phil Sturgeon https://twitter.com/dimensionmedia/status/696012986746605569

Maybe non-coders can document before coders code.

@OptimusCrime

This comment has been minimized.

Contributor

OptimusCrime commented May 2, 2016

While this is an interesting subject I don't think an issue at github in the revo repo is the correct place to discuss this. It also looks like the activity/discussion died a bit.

I am going to close this (and I hope that is alright). Feel free to comment or reopen this if you feel otherwise.

I am certain this discussion will resurface in the forums or at Slack.

@modxbot close

@modxbot modxbot closed this May 2, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment