This project is read-only.

Orchard 1.7 Custom Layouts - Widget Pages feature team

Topics: Announcements
Nov 6, 2012 at 8:50 PM
Edited Nov 6, 2012 at 11:52 PM

This thread is to discuss the custom layout and widget pages features.

Custom layouts will enable site administrators to define responsive layouts using rows and columns in a visual editor. Templates can then be built using those layouts, that define what parts and fields go into what zones of the layout.

Widget pages would enable administrators to build pages from widgets. This replaces what is done today with page-specific layers.

Nov 6, 2012 at 11:47 PM

Can I just confirm that by reactive design you are in fact referring to responsive design?

If that's the case then I'd suggest the following;

This should ideally be intended for use with a grid system. (But should not provide one to be used.) The user should define a global grid size, i.e. 3 columns, 12 columns or 16 columns etc. The you can simply add classes to containers which look like: .grid-1, .grid-2, .grid-3... etc. Code wise you only need to worry about the number on the end of the class. The last item in a row should also have a .last class. Rows are simply wrapped in a <div class="row"></div> which exists to provide a clear fix.

I do feel it's very important to not provide any grid system implementation and keep out of the theme authors way.

I'll leave it there for now in case I'm wrong about what this is! :-)

Nov 6, 2012 at 11:52 PM

Yes, sorry, that's a typo. Correcting.

Agree on grid system. The feature is actually almost done and yes, it's using an undetermined 12-column grid already. It needs to do something in the admin, so it's using a subset of Bootstrap, but it's completely agnostic about what you use on the front end.

Nov 7, 2012 at 8:04 AM
Edited Nov 7, 2012 at 8:05 AM

I'm very interested in the Widget pages feature. Are there ideas or mockups already? I'm also willing to contribute on this if I can.

Nov 7, 2012 at 8:09 AM

For widget pages, no mockups, no, the feature doesn't exist yet.

Nov 7, 2012 at 4:51 PM

Its actually almost done? Where is it almost done?

Nov 7, 2012 at 5:31 PM

Yes, we haven't agreed on the implementation and use case, or did we ;)

Is it still worth discussing it then ?

Nov 8, 2012 at 5:21 AM

@Nick: on my machine

@sebastien: yes, there is much to discuss. Especially after I've demo'ed what I have.

Nov 8, 2012 at 11:19 PM

When are you looking to demo what you have?

Nov 9, 2012 at 1:12 AM

Maybe next Tuesday.

Nov 14, 2012 at 9:19 PM

Will this also include changing the management/administration of Widgets?

One feature currently lacking with the administration of widgets is the ability to allow specific roles access to Zones and Layers. i.e You might have a Moderator that is only allowed to change the Html Widget in the FirstAside on the Home page layer.

Nov 15, 2012 at 5:50 PM

The custom layout editor could be used in three different places:

- Content item editor for Content Types exposing it. This would do the "Placed Content" content type
- Content Type editor, to layout and place shapes for a specific content type, e.g. Product
- Widget editor, to move widgets within the theme's layout. But this one is actually another feature as it's not related to content placement but layout placement (not sure you understand the difference, if so great).

But you question is actually a different concern than custom layout. And it's a valid one, how to handle security and access to specific widgets. That's could be handled easily I think by checking for the rights on the Widgets admin page, like we do for other contents.

Nov 23, 2012 at 3:52 PM


I am new to Orchard and having used it from both a developers point of view and a clients I feel Orchard could be massively improved by the following features:

I would the ability to create a master page template (and, if required, more than 1 template) and then every time I create a new page I would select which template I would like to use for that page.

I would also like to see the ability to create 1 page and then add my widget(s) whilst on that page instead of creating a page, and then create a layer and then assign widgets in a zone on a layer.

Having the widgets defined from the start and then having the ability to drag and drop which ever widget you want to use in a zone would also add to the clients experience. i.e. If I wanted to add some html text I would like drag a 'content' widget into my chosen zone, if I wanted to add a contact form then I would just drag a contact form widget (providing I have that module installed and perhaps a form predefined) into my choosen zone.

I hope all that makes sense, I have spend some time using & developing with Sitefinity and these are all great features that I feel would make Orchard even more of a success that it already is.



Nov 23, 2012 at 9:23 PM
Edited Nov 23, 2012 at 9:23 PM

@Dan do we need one more DNN or Sitefinity, I do prefer the Orchard approach on Content with ability to use css and html.

Dec 5, 2012 at 1:07 PM

What I feel missing in Orchard in terms of themes is the ability to move the the widgets around to different zones before setting a new theme. Of course Orchard supports "Preview" before setting a new theme but the current "Preview" shows how it will look when we apply a new theme but it doesn't allow us to change zones of the widgets before setting it. If we feel we need to move few widgets around to some other zones before setting the the new theme I don't see any existing way to do this. Currently, we have to first set the theme and then go do this change. This could potentially be a problem when we do this for the live site.

I'm don't think this is directly related to the feature at discussion, but this is something to take into account for anything to do with custom/dynamic layout and widget-zone map.

Dec 5, 2012 at 7:05 PM

Yes it does. You can activate a theme without making it the current theme. Then, its zones will be accessible from the widget editor.

Apr 9, 2013 at 9:57 AM

There are some problems with the section on "Widgets". When a site has about 100 pages, there is no problem, but when the site has more than 1,000 pages that have problems. This is mainly due to the fact that if, for each page to create a widget to 3, the subsection "Widgets" to become so large that it is difficult to work with him.
Apr 9, 2013 at 12:16 PM
Do you mean that there are issues when you create a layer per page? E.g. when you have 1000 pages, and someone creates 1000 layers? If so, then that is problematic. Instead of creating a layer per content item, one could tryout the new Contrib.Widgets module, allowing the user to attach widgets to content items directly without having to create a layer per content item.
Apr 9, 2013 at 1:27 PM
Edited Apr 9, 2013 at 1:31 PM
This is a good Contrib.Widgets, I've been waiting for this. But because the problem is still not resolved. I see in the "Widgets" layer was created "ContentWidgets", that still makes it great. The only difference is that there is no need to create a layer for each page individually. I think I need to group widgets by zones. Module Contrib.Widgets, must move to Orchard.Widgets

Thank you for your support
Apr 9, 2013 at 2:23 PM
Yes, because widgets cannot exist reliably without being part of a layer, all widgets attached to content items will be added to an implicitly created layer called "ContentWidgets". Rest assured though that this layer will never activate (its rule returns "false").
Orchard.Widgets would need some refactoring to allow for widgets to exist without being part of a layer. Until then, we need the "ContentWidgets" layer.
Sep 3, 2013 at 2:33 PM
Edited Sep 3, 2013 at 2:34 PM
Hello sfmskywalker

Possible to hide duplicate widget in subsection Widgets for layer ContentWidgets? And hide a layer ContentWidgets? I need help, correct to change the code.

Sep 4, 2013 at 7:31 AM
Edited Sep 4, 2013 at 7:31 AM
I'm not sure what you're asking, but if you mean you want to hide the "ContentWidgets" layer from the Widgets screen, then yes that is possible if you are willing to modify the Widgets module. One quick & dirty way would be to render the list of layers and do a hardcoded check for "ContentWidgets" and not render that one.

But the better solution would be to refactor the Widgets module a bit so that the concept of widgets per content is intrinsically supported.

However, there's been talk of a way more sophisticated module that truly embraces layouts & UI elements to be associated with content items, so we may not be touching the Widgets module in the short term.
Sep 4, 2013 at 7:33 AM
Edited Sep 4, 2013 at 7:33 AM
I just realized I linked you to this post. :)
Sep 4, 2013 at 8:49 AM
I think I hide the layer ContentWidgets will be a solution for me. I just can not figure out what to change in the code.

thank you
Sep 4, 2013 at 9:13 AM
Just to be clear are you wanting to hide the layer so widgets do not show on the front end? or... do you want to hide the layer from the dropdown in the widgets admin to restrict certain roles from editing them?

I have a custom version of widgets that have extended permissions so specific roles can only edit etc specific layers and widgets, this effect the admin of the layers and widgets only.
Sep 4, 2013 at 8:50 PM
At the front end of the section Widgets. I just do not understand why the display layer ContentWidgets, which differ from the standard.
Sep 5, 2013 at 1:33 AM
Not sure I understand; front ends generally do not show layer names. Or did you mean the Widgets section in the back end?
If you are looking to change the code to remove "ContentWidgets" from the drop down list, you'll find it in Orchard.Widgets, in one of the views.
Sep 5, 2013 at 2:16 AM
In the section Widgets. I understand that I have to change the code of the module Orchard.Widgets. But what do I do? I need a an example, to move on.