Some ideas for MODX3

OK, Tracker, here I come! Is "Proposals" the right place?

I am happy if the tracker is now again the tool of choice for the future MODX versions. In the past it felt to me like and bottomless dwell, where all my ideas drowned in silence – or where they eaten up by the cloud? Anyway, I stopped feeding it and used the free time to play "Angry Birds". Glad this chapter is finished now. I didn't like the pigs anyway.

Jay, I'm probably missing something, but I didn't see any place at the tracker for MODX 3 bugs or features (unless they're supposed to go under MODX 2.3).

There is a Revolution-3.0.0-alpha version setup in the Revolution tracker.

Duh. For other dolts like me, it's under "Target Version."

I agree with my friend Oliver. He has some good ideas there.

What else my clients and I need to see in the next version is definitely a better media browser that allows for multi-upload items and a way to crop and resize images as you either a) assign them to a tv or b) when you add an image to TinyMCE

The other important feature needs to be live previewing. That means that when my clients want to change a live document, but do not want their changes to be officially live, that there is a preview space for them. So that when they click on preview, that an extra throw away version of the resource is created and shown in the browser. If they like the final changes, then they click on save. This preview version would then have to get killed.

Another feature would be to be able to hide certain users in the user profile tool from certain user groups. This would be for the use case that I need an admin to be able to add users to the manager, but I don't want him to be able to delete my account. So, I could hide my user account to that admin.

I have posted these ideas in the Revo tracker a long time ago, but there was never any response.

1. Native migx tv's
2. Live preview for page editing
3. Better file browser / image tvs

Quote from: sonicpunk at Mar 28, 2013, 06:58 AM

Another feature would be to be able to hide certain users in the user profile tool from certain user groups. This would be for the use case that I need an admin to be able to add users to the manager, but I don't want him to be able to delete my account. So, I could hide my user account to that admin.

You could just change the Access Policy that this admin's user group uses so they can only create new users and not delete existing ones. They'd still be able to see your record but would not be able to delete it.

True, but tell your client that they are not allowed to do something... like delete accounts... and you will get a strange reaction. Most people expect to be able to do everything. That is why I would suggest a way to hide specified accounts from the list.

Currently, a user needs to be able to edit and save users in order to to create them. If they can do that, they can change your password (locking you out), log in as you, and make themselves sudo users. I'm confident that this will be fixed in MODX 3 (if not sooner).

I think it's important for people realize that, even if you're not a PHP dev, there's a lot you can do to impact the direction of the project.

In my opinion, MODX LLC / Open Source Project should primarily have a leading role in the direction of the product and supporting the community, but the actual implementation and translation of that direction should be heavily community-focused. This means that user interface designers in the community need to design how a new feature looks, while non-coders should be documenting use cases. Developers in the community can then do the actual development in a way that matches the design and use cases, and then they can work with other core contributors or the project leads to make sure it's ready and will allow the future flexibility MODX needs. While an important step, development is only a part of the story.

As for the ideas proposed by Oliver:

1. Show me how that'd work, cause I can't imagine it yet. From the surface, I'd think ClientConfig-like Extra may be more appropriate as there's probably a number of conflicting use cases a core addition would need to cater for.
2. I think Bob's suggestions here: http://forums.modx.com/thread/82926/modx-3-security-system#dis-post-460231 along with a properly designed interface would be a huge step forward for ACLs. Needs use case documentation and design.
3. I have not managed to completely understand the inner workings of FC and in my opinion it needs to be completely reinvented, starting with use cases and design. I think there's bigger problems beyond syncing "create" and "update".
4. I've not heard anyone opposed to this, so make it happen; this is not a breaking change but I'd personally recommend deferring to 2.3 as it may render product screenshots out of date. https://github.com/modxcms/revolution/edit/develop/core/lexicon/en/default.inc.php
5. Agreed. I'd probably suggest it for 2.3 also, and this might do with some thought / documenting / design of how it should show the results. Different trees per element type or would the different icons be enough differentiation?
6, 7. Not sure. Useful but tricky. Maybe as addon or incorporated into Ace/CodeMirror RTEs would be better?
8, 9, 10: "content elements" in 3.0 - I believe Jason has some thoughts on how that could work but I reckon there's a lot of interface design work that should be involved with that.
11, 13: A completely new, reinvented UI for 3.0 would be great and put MODX ahead of the rest.
12: I made some minor improvements to the media browser in 2.2.7, but I think this could use a use case and design focused overhaul. Possibly in 2.3 but if too drastic in breaking backwards compatibility 3.0.
14: Pretty sure the core allows for that right now, so could be part of 2.3.