Generic "misunderstanding" caused missing feature

Nov 2, 2010 at 10:51 PM


I was very happy about Orchard since from what I read it can be THE cms framework for me. Today I started to play with the latest sources and played on the admin site, and I noticed something what - as I think - is the base for every CMS...It has something to do with the site structure.

If I get an empty CMS into my hands and like to "invent" a new site, for first I'd like to identify my content types, my content type fields. This is something what Orchard has, so far so good.

As a "next step" I'd like to define the site's logical layout, the "constraints" of how those content types related to eachother, what type can be contained by what type and so on.

For example:

1. A site can only have 1 main menu content type.

2. A main menu can contain page, blog, productscontainer, type1, type2, type3 children content types.

3. A productscontainer content type can have only product content types.

And if this structure is ready it's very easy to populate the site with content!

Maybe I am the one who does not see how Orchard approach this aspect of a CMS, or it's not there. Please give some guidance on it!

For first this seems to be a very complex framework, and very hard to locate which parts are responsible for which (MVC) action on the site. Some kind of trace or something should be a great help to locate what module, feature, view, action is responsible for a given part of the generated view. Whay I'm raising this? I tried to hit Edit on the MenuItem content part and I got a 404...and it turned out that somehow, something is missing from the database for that item...but that was generated by a database query, so something is wrong there.

(Repro: Manage Content Types -> Content Parts -> hit Edit for Comment Settings, Content, Menu Item, Message Settings, Site Settings, User Roles,

Also I did not found an intuitive way to create a MenuItem content type and add that to the main menu...




Nov 2, 2010 at 11:20 PM

Containers are not yet surfaced to the admin UI. We are working on this right now. Still, you can already find an example in blogs/blog posts.

As for debugging, there is a profiling feature that you can enable that will give you information on what's getting rendered by what.

Can you please file a bug for that issue you seem to have found?


Nov 3, 2010 at 12:31 AM

Hi Bertrand!

It's not just containers but a content structure tree...looking forward for this feature :-) I'll look into the Blogs/Glog thing.

Thanks for that profiling tip I'll turn that on!

I'm missing an "Exploration guide for Orchard source code" type document :-)))

What about the Menu -> Menu Item relation, how can I populate a structure?

I created a bug for the 404 issue.




Nov 3, 2010 at 1:04 AM

For menu, do you mean create menu items programmatically and adding them to the main navigation menu? If so, you can look at the AdminController in Core/Navigation for examples.

Nov 3, 2010 at 9:51 AM

Thanks, I'll look into this.

Nov 3, 2010 at 8:53 PM

I read thru the code in the Core/Navigation branch where you mentioned, but for me it does not seem to be a way to store MenuItems under any MenuItem to build up a menu hierarchy, am I missing something?

Nov 3, 2010 at 9:58 PM

You only said you wanted to create a menu item and add it to the menu, not that you wanted to put items under items. The current menu is just a simple one. You can implement a hierarchical menu as a module. I think there are folks out there who have already done something like that.

Nov 4, 2010 at 12:19 AM

Sorry about the misunderstanding!

What I saw from the code - and maybe I'm wrong - the default UI renderer for the menu is supporting nested items thru the generic DisplayChildren method since the cshtml files for the menu rendering nested ul/li items for child menu items.

The only question now is how may I add them to the database? am I need to use 1.1, 1.2, 1.3 in the Position field of the MenuItem to express the parent/child (and position within parent) relationship? or something else.




Nov 4, 2010 at 12:25 AM

No problem. Yes, this is one of the ways you could do that. I'm not saying there is that much work, just that we didn't do it yet. I'm not 100% sure but it may actually be just a question of rendering.

Nov 4, 2010 at 12:30 AM

Once I'm clear with how things are going within Orchard, maybe it will be a first thing I'll do as an experiment. Since the dotted annotation to express parent/child relationship could be very fragile :-)

(What are the other ways?)