What are the most urgent additions to MODx ?

I concur with:

1. Multi-sites
2. Calendar (like extCalendar). Again, the calendar class/library in codeignite is the way to go. I dont have enough experience to develop it. I am willing to put up a little bounty though.

Chuck

Apart from e-commerce (which I really need for some sites) I’d like better documentation. Of course the current documentation is a great start , but for a newbie like me the learning curve is rather steep. It would be great if the documentation would be more geared towards non-programmers. I’d especially like more tutorials and examples. I find myself asking questions in the forum that to some may sound very stupid or obvious, and if there was more documentation to read I wouldn’t have to bother the community
Otherwise MODx looks great and I’m really looking forward to using it more and more. (excuse my english)

the learning curve is rather steep

Depends on the height you start from! I mean: for an experienced PHP-develo(o)per the curve will be not that steep. That’s a matter of the target-group of MODx, basically. Guys who want to set up their sites asap without having to look at just one line of PHP, or guys who are wanting a CMS-development framework to be more productive when creating sites using PHP.

And for the wishlist:
- unified (frontend/manager) permission management - without having to create relations between user- and doc-groups
- multi-language, multi-site support
- integrated forum solution (not just a bridge)

Depends on the height you start from! I mean: for an experienced PHP-develo(o)per the curve will be not that steep. That’s a matter of the target-group of MODx, basically.

I know that (currently) the target group is programmers and not designers (like me). However, I think MODx is great and it’s certainly suitable for people without a background in programming, if only the documentation would be better.

Quote from: Mark at Oct 18, 2005, 06:42 PM

Quote from: rthrash at Oct 18, 2005, 06:41 PM

Gallery 2 ... check

;)

I guess that’s good that it "works" but how about working with friendly urls enabled in Gallery as well as MODX, uncheck, doh, in terms of Gallery integration that’s a major biggie in my books, in fact I dropped integrating with Gallery and went with a majorly less-featured implementation using Slideshowpro as a result of friendly urls not working...

Quote from: Maaike at Aug 03, 2006, 06:28 PM

I know that (currently) the target group is programmers and not designers (like me). However, I think MODx is great and it’s certainly suitable for people without a background in programming, if only the documentation would be better.

About documentation : it’s been discussed time and again, and things will definitely improve.
About MODx target, it’s as much designers as programmers. Right now, it’s not newbies for sure...

Hello All,
Just wanted to reiterate the need for workflow in document creation.

• I forsee the ability to have approvers based on folder or document owner where the content ends up.
• If it is a new subpage then the owner or group owner of the parent should have approval authority.
• if it is a component within a page like a comment then the document owner, or if set the parent folder owner should have the authority to approve
• a backend to support communication between approver and content submitter is also needed

If there is any current work to support this, I would love to hear about it and get involved.

Cheers,
Gregg

There is no current work completed on workflow, and we highly agree it’s time to start cranking on that and a few other things to bring about 1.0. We’d love to have some help in this regard, too.

Howdy-- Just found and read this thread, and would like to add something I didn’t see: document types. In OO-speak, I’d like to be able to subclass documents and add attributes and methods to them. In other words, I’d like to be able to define documents of type "press release", "executive bio", "white paper", "photograph", etc. and for each document type have custom fields that show up (like template variables) in the document editor in the Manager.

Thus for a "photograph" I could have custom fields for thumbnail, fullsize-image, and all the IPTC metadata etc. For an "article" I could have fields for all the Dublin Core metadata (publisher, author, copyright, etc.), for "executive bio" I could have name, title, photo, etc.

These would be true database fields accessible through the API, not psuedo-fields added via templates and template variables.

Quote from: myfriendscallmebill at Aug 10, 2006, 09:33 PM

These would be true database fields accessible through the API, not psuedo-fields added via templates and template variables.

This is what our 1.0 / XPDO based project is about. PM Opengeek for more information and to get involved there.