Some ideas for MODX3

1. user accessible lexicons: Setting certain global values. OK, we have the system settings but they are not capeable of storing language dependend settings and context settings aren't either. Well, then I could use the lexicon, but it is not possible to give my client access to just one part of "his" lexicon e.g. to change the name of a side box headline which is different for every language or an ID of a certain resource that is language specific etc. A long sentence short: What about a user accessible lexicon for storing such things? Btw: Lexicons are a great way to store nearly every kind of information. But, sadly, their access cannot be restricted.
2. Clustered ACLs: ACLs are just one big list. I would love to see the, structured in clusters of functional groups, like "editing resources" or "managing users" etc.
3. Form customization synced for "create" and "update": A way to change settings for "create" AND "update" at the same time, like a third option for doing both at the same time. Minimizes the nagging work of keeping the user-interface in sync. And: FC should be "server side only", not a JS solution!
4. Replacing "update" with "edit" in the core lexicon: "update" is for software/extras, "edit" is for values. Right? ;-)
5. A search for chunks/snippets in the elements tab: VERY helpful with looong element trees.
6. Where did I use this chunk/snippet? I often wonder, if a chunk is used in a resource or any other place. So it would be great to get a list like "where is this chunk used (if at all)?" Same for snippets. This could be triggered my a menu od by a context menu link of an element.
7. A quickedit inside the code like "quickedit this tpl-chunk that the getResources call I am working on right now is using".
8. A better way to structure the resource editing page, like ordering TVs, repeating blocks of TVs (like "text, image, caption" as a block. Think MIGX here.). I would love to have a customized sequence of fields for every resource template.
9. While we are here: Less "allways there fields", like "description", "longtitle" etc.
10. Content should be a TV or: "Every TV should be content."
11. No right clicks for quicke edit because I often kill my editsthis way. This part is to be taken lightly and humorous although I realy curse on this a lot. Right click is cool and it's not at the same time.


12. A media manager that is capeable of long filenames and remembers my last position in the file tree. When having long trees of files this is a lifesaver. I have trees of more than 100 folders and scolling to "You drive me crazy" (yep, the movie) about 20 times is really driving my crazy.
13. Less frameworks like ExtJS in the manager, more plain HTML/CSS with a little help of a sleek JS framework. Talking jQuery here. Don't kill me!
14. Extend the MODX tag-syntax for direct resource fields access like the extra "fastField" does. I see such an ultraflexible solution inside the core. Creative freedom, you know.

I pretty much agree on everything...

... exept "And: FC should be "server side only", not a JS solution!". I would very much like to keep FC and all manager customization in plain HTML/CSS. That way any average skilled developer could customize the manager with ease and things like hiding default fields would be super-easy.

user accessible lexicons

Clustered ACLs

Form customization synced for "create" and "update" And: FC should be "server side only", not a JS solution!

A search for chunks/snippets in the elements tab

Where did I use this chunk/snippet? I often wonder, if a chunk is used in a resource or any other place. So it would be great to get a list like "where is this chunk used (if at all)?" Same for snippets. This could be triggered my a menu od by a context menu link of an element.

A quickedit inside the code like "quickedit this tpl-chunk that the getResources call I am working on right now is using".

While we are here: Less "allways there fields", like "description", "longtitle" etc.
Content should be a TV or: "Every TV should be content."

No right clicks for quicke edit because I often kill my editsthis way. This part is to be taken lightly and humorous although I realy curse on this a lot. Right click is cool and it's not at the same time.

A media manager that is capeable of long filenames and remembers my last position in the file tree. When having long trees of files this is a lifesaver. I have trees of more than 100 folders and scolling to "You drive me crazy" (yep, the movie) about 20 times is really driving my crazy.

Less frameworks like ExtJS in the manager, more plain HTML/CSS with a little help of a sleek JS framework. Talking jQuery here. Don't kill me!

Extend the MODX tag-syntax for direct resource fields access like the extra "fastField" does. I see such an ultraflexible solution inside the core. Creative freedom, you know.

Let me add a couple:

1. Convenient getObject(), getCollection(), and save() methods for a unified user, profile, and (optionally) extended field object (modFullUser?), so I don't have to keep looking up getCollectionGraph(), and mucking around with the extended fields. I guess remove() and duplicate() should also be in there.

2. Convenience methods for the user object: activate(), deactivate(), block();

$modx->getService('file','modFileHandler');
// create the file object and do something with it, we can already do that, love it!
$fileobj = $modx->file->make($modx->getOption('assets_path') . 'path/to/' . $file . '.ext');

// but how nice would it be to be able to do something like that
$fileobj = $modx->file->get($url);
// or
$fileobj = $modx->file->fetch($url);
// or whatever the method is called, basically it should be a bulletproof method 
//to fetch files from urls via 1. cURL 2. file_get_contents() 3. fsockopen()

// this is actually possible with the following code (while I could never get the fsockopenclass to work...)
if ( function_exists('curl_init') ) {
    $modx->getService('getfile','rest.modRestCurlClient');
    $response = $modx->getfile->request($url);
} else if ( function_exists('file_get_contents') && ini_get('allow_url_fopen') ) {
    $response = @file_get_contents($url);
} else {
    $modx->log(modX::LOG_LEVEL_ERROR, 'Neither cURL nor file_get_contents() is available to fetch data from URL: ' . $url . '...talk to your hoster or get a better one');
}

// but I feel "raping" the modx core every time I do this and at the same time this
// is way more beautyful than having cURL helper functions in every f'ing extra 
// that needs to do some operations with cURL (which actually is mostly fetching some json or API data)

As simple request, but I would really like the drop down menus on the top to be activated by a click rather than rollover. Having the menus flash on and off as the pointer moves over them whilst when making fast edits between multiple browser tabs gets rather annoying.