What are the most urgent additions to MODx ?

[Guest]

Welcome, Guest. Please login or register.
Did you miss your activation email?

1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[rthrash]

Fellini, Plugins are tough. I think it'd probably be very good in fact to have a explanation of how the document parser works, including where and how the different events tap into it.

[sottwell]

I've started on that; I've actually written plugins using two of the Template Service events, and have documented OnWebPagePrerender and how it was used in the adding of the lang variable to links in the page.  As I work with them and come to understand them, I'll be adding to the list.

[sottwell]

multi lingual sites

Check this.
http://modxcms.com/forums/index.php/topic,409.0.html

[banzai]

e-commerce and an advanced search system (to search for folder, subsites or fields like alias or description)..

[Mitch]

For me an important addition would be a better/easier way of organizing and moving snippets/plugins/modules/chunks.

For example I am working on a some code that consists of a module,plugin,snippet and some chunks. I have to keep switching between all the tabs in the resourcemanager to find all the things I am working on. Also it is hard to find the correct snippets/plugins/modules/chunks in the rather long lists I have. It would be nice if you could put the snippets/plugins/modules/chunks in a group so you know they belong together and are easier to find.

Next thing is moving those snippets/plugins/modules/chunks to a productionserver or swap it with other users. Currently you have to copy the code and settings and make sure all the events for plugins are set correctly. This is a quite difficult and timeconsuming process. It would be very nice if you could just "package" the snippets/plugins/modules/chunks you need. They get combined into one file and you can just copy that file to your server and "unpackage" it.

And last I think that the usermanagement is now too complex. I have users that have to login to the frontend and manager and I can't really explain to them why they have to login twice, have two passwords etc... Also the administration of a person that is twice in the database is a bit difficult to keep them in sync.

Related to that is that it is hard to get a bit of overview of which user can access what documents or the other way around, what documents belong to what documentgroups and which webusergroups/usergroups can access/edit them. It would be nice if you could highlight documents in the documenttree that belong to a specific documentgroup or that can be accessed by the currently selected user/group..

I had some more minor stuff, but I forgot what it was    but those are not urgent anyway

[rthrash]

Great stuff Mitch. I can assure you that I share much of the same concern. Some could be addressed in the current branch, some is addressed in TP4, and some needs to be addressed. Keep 'em coming!

[Robsta]

eCommerce without a doubt. Almost every small business I have spoken to (when touting for business  ) had shown either an interest, or it's their main requirement, in a shopping cart system or online sales system.

Personally, I've not spoken to any businesses who look for a forum.

Just my opinion from my experiences. 

[sottwell]

Actually, that's not really an "addition" to MODx, that would be a separate module, not part of the core.  Like a forum, an event calendar, photo galleries.  But the core coders need to focus on improvements to the core itself, and let others who are interested and talented make up the extra optional modules.

[Robsta]

Actually, that's not really an "addition" to MODx, that would be a separate module, not part of the core.  Like a forum, an event calendar, photo galleries.  But the core coders need to focus on improvements to the core itself, and let others who are interested and talented make up the extra optional modules.

I was actually talking about shopping cart integration, which was what the first post (and attached poll) was asking about.  Sorry about the missunderstanding in my original post. I perhaps didn't phrase it ideally. 

[Mark]

For me an important addition would be a better/easier way of organizing and moving snippets/plugins/modules/chunks.

For example I am working on a some code that consists of a module,plugin,snippet and some chunks. I have to keep switching between all the tabs in the resourcemanager to find all the things I am working on. Also it is hard to find the correct snippets/plugins/modules/chunks in the rather long lists I have. It would be nice if you could put the snippets/plugins/modules/chunks in a group so you know they belong together and are easier to find.

Next thing is moving those snippets/plugins/modules/chunks to a productionserver or swap it with other users. Currently you have to copy the code and settings and make sure all the events for plugins are set correctly. This is a quite difficult and timeconsuming process. It would be very nice if you could just "package" the snippets/plugins/modules/chunks you need. They get combined into one file and you can just copy that file to your server and "unpackage" it.

And last I think that the usermanagement is now too complex. I have users that have to login to the frontend and manager and I can't really explain to them why they have to login twice, have two passwords etc... Also the administration of a person that is twice in the database is a bit difficult to keep them in sync.

Related to that is that it is hard to get a bit of overview of which user can access what documents or the other way around, what documents belong to what documentgroups and which webusergroups/usergroups can access/edit them. It would be nice if you could highlight documents in the documenttree that belong to a specific documentgroup or that can be accessed by the currently selected user/group..

I had some more minor stuff, but I forgot what it was    but those are not urgent anyway

Great ideas!

Please add these to the bug/feature tracker at modxcms.com/bugs

[yama-kei]

I totally agree with Mitch.

For me, MODx is a nice tool to customize and create something out of almost nothing(from only what MODx itself provides). But to be more productive, MODx should be able to export/import some form of package.

And to do this, MODx should have some way to convert document ID or separate namespace of documents. Since all documents are managed by a single ID without any hierarchy or namespace separation, there would be a problem when importing/exporting package which has *FIXED* ID. This applies Snippets/TVs/Chunks/Template also.
Good concept can be drawn from "Prouct" in Zope.

Other specific functionalities like "e-commerce site" or "photo gallery" should be built on this kind of package mechanism, I think.

Also, it would be nicer if one could access to Caption or Description of each Template Variable from template.

thanks,

[jlarson]

And last I think that the usermanagement is now too complex. I have users that have to login to the frontend and manager and I can't really explain to them why they have to login twice, have two passwords etc... Also the administration of a person that is twice in the database is a bit difficult to keep them in sync.

Amen.  Couild someone please explain the security benefit of separating backend/frontend users in the database?  It makes no sense to me.  Why can't one table just store both kinds of users and eliminate the need for a plugin to syncronize the two when needed?

Related to that is that it is hard to get a bit of overview of which user can access what documents or the other way around, what documents belong to what documentgroups and which webusergroups/usergroups can access/edit them. It would be nice if you could highlight documents in the documenttree that belong to a specific documentgroup or that can be accessed by the currently selected user/group.

It seems to me that the best software applications provide more than one way of going at a task or problem, and indeed Modx does that with template and page creation.  In the backend however things are pretty limited, e.g. having to pull up a page at a time to assign it to a document group, same thing with assigning users to user groups, TV's to templates.   

I may be off the wall here, but what I've been wondering about is why we can't have the backend work exactly like the frontend, or at least very similarly.  Design your own interface using templates, snippets etc.  Instead of an inflexible menu, have a user-definable page tree just like the frontend has, creating an easier system for the community to develop and share site management tools.  Why have two completely separate ways of going about things?   Do we even need templates and chunks to be treated separately from documents?  Why not make everything a document??  And what if snippets, although handled differently, could be managed heirachically like documents?  Am I crazy or onto something (if so, I suppose Raymond has probably already thought of  ).

[OpenGeek]

For me, MODx is a nice tool to customize and create something out of almost nothing(from only what MODx itself provides). But to be more productive, MODx should be able to export/import some form of package.

And to do this, MODx should have some way to convert document ID or separate namespace of documents. Since all documents are managed by a single ID without any hierarchy or namespace separation, there would be a problem when importing/exporting package which has *FIXED* ID. This applies Snippets/TVs/Chunks/Template also.

Other specific functionalities like "e-commerce site" or "photo gallery" should be built on this kind of package mechanism, I think.

Actually, documents are part of a hierarchy and most components I've developed for my MODx sites are configurable to work on any document ID.  It's the configuration of the components that drives these sorts of relationships and I strongly encourage you not to develop components that use specific document ID's.

Using the hierarchical relationships between documents, and utilizing MODx modules (see the quick definition at http://modxcms.com/docs-modules.html) is really the way to package related components together.  We'll have some more documentation and better examples of this in the near future, but feel free to add any more input into how this can be made powerful and intuitive, or ask additional questions as to the packaging aspects of modules.

Cheers...

[OpenGeek]

Couild someone please explain the security benefit of separating backend/frontend users in the database?  It makes no sense to me.  Why can't one table just store both kinds of users and eliminate the need for a plugin to syncronize the two when needed?

Already in the works; in fact we're hoping to merge web and manager users before the next release (or two  )

It seems to me that the best software applications provide more than one way of going at a task or problem, and indeed Modx does that with template and page creation.  In the backend however things are pretty limited, e.g. having to pull up a page at a time to assign it to a document group, same thing with assigning users to user groups, TV's to templates.   

I may be off the wall here, but what I've been wondering about is why we can't have the backend work exactly like the frontend, or at least very similarly.  Design your own interface using templates, snippets etc.  Instead of an inflexible menu, have a user-definable page tree just like the frontend has, creating an easier system for the community to develop and share site management tools.  Why have two completely separate ways of going about things?   Do we even need templates and chunks to be treated separately from documents?  Why not make everything a document??  And what if snippets, although handled differently, could be managed heirachically like documents?  Am I crazy or onto something (if so, I suppose Raymond has probably already thought of  ).

Amen, and most of what you describe is already part of a defined project that is already underway.  May be a few releases out, but it'll be worth it.   

[xwisdom]

Hi,

Just like Jason said it's all in the works and I sure hope you will love what's coming. We will also be making the manager much easier to use.