This project is read-only.

Future Orchard Roadmap

Topics: Announcements
Jul 22, 2011 at 11:36 PM
Edited Jul 31, 2011 at 3:12 AM

Several of you have asked us to provide some info about our roadmap and what we are planning for Orchard 2.0. The dust has not settled on the design board yet, but we are ready to start sharing some of that stuff. My plan for the following days/weeks is to write a series of blog posts exposing some of the planned features and the preliminary design. The first one is Tokens and can be found here:

Future posts on this series (and pretty much our roadmap) will likely be:

  • Tokens, part 2
  • Autoroute: automatic generation of URLs following configurable patterns. If you want your blog post URLs to look like, you will be able to get exactly that, through pure configuration of the site. This feature will rely heavily on Tokens.
  • Projector: build arbitrary queries on your contents from the admin and construct their HTML representation on the site. We like to describe this as Lists done right.
  • Setup: opening setup for integration of alternate database providers, localization, recipes from the gallery, and arbitrary extensions.
  • Gallery extensions: recipes and translations available from the gallery. We'll also see what we can enable to integrate the gallery with the module development process.
  • Commerce: we're still figuring out exactly how we're going to enable this in a way that makes sense for all of you (see
  • Better Azure integration: streamline the deployment process on Azure, enable some scenarios that are currently not available from there (see

These are some of the things we are looking at right now, but Orchard 2.0 will be more than that. We have less details available at this time about other features, but we are building around four pillars:

  • Turnkey: it's effortless to create, manage and deploy sites with Orchard.
    This includes an install free and update free cloud-hosted service, a recipe gallery with more recipes available, more themes, and modules to address common scenarios.
  • Platform: Orchard delivers a production-ready platform that scales and performs to meet real-world demands.
    This will include our work on Azure as well as further improvements to our shared hosting story. We will also optimize the site, module and theme development workflow overall.
  • Commerce: Orchard delivers a competitive solution for small and medium businesses to make money from their sites.
    By the time 2.0 ships, we will have out-of-the-box scenarios enabled, probably through integration of popular third party systems, as well as a flexible foundation for building full custom commerce solutions. 
  • Ecosystem: Orchard has a vibrant ecosystem and community, that encourages participation and contribution. is your one-stop place that aggregates all the activity of the community. We'll add showcases for you to publish your case studies or generally share your creations in a gallery of Orchard sites, you'll see more videos and tutorials from us and from the community. We'll also improve our gallery with reputation, profiles and stats, and with a better publication system that integrates version control. You'll have more ways to extend Orchard with recipes and translations.

And of course, I'm sure most of you are wondering when all that will be available. We are aiming at a first pre-release mid-September, and the actual 2.0 release in early Spring 2012.

Jul 25, 2011 at 2:15 PM

Hello Bertrand,

Thanks for this.  It's great to know the feature-level direction of the product that the core team is going in.  Can you talk a bit about the team's philosophy on open source development as it relates to determining these features as well as the division of tasks and progress towards these features?  There are all sorts of open source projects:  some are run in isolation with code drops every once in a while, others are completely open with a public backlog.  My feeling so far is that this project falls somewhere in between.  The team does a great job interacting with the community on the forums for troubleshooting / architectural assistance, but I feel a bit out of the loop on the project management side until you drop a note like this or official code drops.  There's no right or wrong here, I'm just trying to determine the amount of transparency the team is interested in at this point.

For instance, are you driving development by, or is this just a temperature gauge on the user base?  Are there any plans to increase transparency and resolution on future planning and development, or has the open source philosophy been already firmed up and implemented on the team?  Or maybe the transparency already in place and I just haven't found it yet?


Jul 25, 2011 at 8:23 PM

That's a fair observation. So far, we have been very focused on our vision of CMS and on delivering the base platform. Because of that, design has been so far done by the core team. Our reasoning was that a CMS project is a little different from other types of applications because so much can be done as additional modules. We believe that most innovation will happen in the future through third-party modules, and to a lesser extent from the core. The core should just be an enabler for third-parties, and be the materialization of the platform philosophy. Indeed, we are beginning to see some interesting stuff popping up on the gallery. The hope is that some of those modules one day join the official distributions of the application.

But even for the core, we think we are going to progressively yield more control to the community. I might as well talk about that here although we're not completely ready and are still figuring out the details. Our current idea is to have a steering comittee of sorts, composed of key members of the community, that we would pick for the first batch, then quickly switching to a model where they are elected. This comittee would be included in key meetings way sooner than it has ever been the case so far. In the end, it's what code gets committed that counts, but we do completely recognize the need to be more inclusive in the decisions we make. I've seen this model work well in other Open Source organizations. As for UserVoice, it's been an invaluable tool for us to understand the priorities of our community, and we continue to use it for that.

Does this help?

Jul 25, 2011 at 9:16 PM

Really appreciate the insights and quick response.  Thanks!

I absolutely understand and agree that most of the future functionality gains will come from modules.  From a module developer's perspective, I believe that increasing transparency and resolution on current and future work (especially in core and framework) can help module developers work with you and accelerate the platform.  When you are ready, an excellent first step would be to expose the core team's current task backlog, sprint and sprint tasks.  Even if they are changing (which I'm sure they do frequently), it would allow the community developers to keep pace, get an idea what's coming down the pike and set a better direction for their own modules.  Then down the road, opening up community involvement would be awesome.

Just my two cents.  Thanks for listening!

Jul 25, 2011 at 9:23 PM

Mmmh, yeah, that's what we 're trying to do here:, although it's not as detailed as what you're asking for. It should give you an idea of what we're doing, without having to go through dozens of work items. We do have a view of our Zen board that is available behind a password on our site, but it's actually the first time I'm hearing a request to make it public. But if enough people really want to see how the sausage is made, well, we could I suppose remove the password in front of it.

Jul 26, 2011 at 12:43 PM
Edited Jul 26, 2011 at 2:17 PM

Great! I have been waiting for this :)

I am for a more transparent roadmap because it has a direct impact on developers. For example, one of the projects I am working on needs a feature like Token. We had planned to implement that feature ourselves, but I am glad we may not have to (depending on how usable the September pre-release is).

So, I would like access to this password-protected website for my own planning as well as out of curiosity for this great platform :)

On the other hand, I am a bit concerned about the negative impact this could have. We all know that software design is part science, part art. And I wouldn't want the developers to lose their focus because us developers start over-analyzing and second-guessing every little design decision.

Let's give it a try and change strategy if things get out of control. I like the committee idea, and they could eventually be the only ones who have access to that website.


Regarding the roadmap, I am very interested in the Projector feature as well. Yet another thing I was looking into building myself. Although, I am looking more into being able to build an experience like this:

On top of providing search, paging and sorting, it also generates "facets" to filter per category. And there is also the ability to change the view (Grid/List).


If you accept feature requests here, a core feature I would really appreciate is the ability to have the content item editing experience on the front end of the website (instead of having to go to the Dashboard). This is really important for any scenarios where we want users to be able to contribute items (a little like how they can write comments on blog posts).
In a way, it is a generalization of this feature request:
Edit: I also found this which would be a great improvement on the online content type creation story:
Demo here:

Jul 26, 2011 at 7:57 PM

Faceted search would be a part of the commerce work. It pops up consistently as one of the key features of a commerce platform. Thanks for the links. Checking it out.

Jul 26, 2011 at 8:55 PM
Edited Jul 26, 2011 at 9:09 PM

The roadmap looks good but here are acouple areas I would like to have seen improved upon within the core..

1. A better Moderation pipeline, I think whats there at the moment is a good start, but if you look at what a news team do for example, they create a piece of content and submit to thier editor for moderation.. and then the editor would publish.. Although you could lock down the publish to the editor role, I dont this this is enough.

2. Inline editing without having to jump to the admin page... I think this would make the page editing experiance much better.

3. A more dynamic widget view. Where I work, we have a page canvas that allows our front end developers to move modules around and see what the page looks like there and then... If you need examples I could email them to you if you want? - Im not saying what we have is perfect, but the experiance is quite cool and one of the only features of our CMS that I actually like.

Just my two cents.


Jul 26, 2011 at 9:04 PM

On 3, I have a good idea of what you're talking about, but how would that work with layers?

Jul 26, 2011 at 9:23 PM

Hmm okay...

So a Layer is just a collection of widgets right? So instead of seeing a list of widgets? why not have an option to see those widgets on a page canvas view by layer?

You could expand on this... When an author is creating a 'Page' content type, they could have a view of them creating that content within a 'uneditible widget view' for example of that page canvas (not sure about the layer at this point), this allows them to know how the page will look after it has been published, rather than just a text area and title...

Have you any ideas on how this would work? (I completely forgot about the layer scenario tbf)

Jul 26, 2011 at 9:25 PM

Well, it could be a more visual version of what we have right now, with a way to toggle layer visibility on and off and more drag and drop I suppose.

Jul 26, 2011 at 11:10 PM

@Jetski5822: Here is a discussion about inline editing:

I really think that there should be a more flexible experience when it comes to content item editing. Having to go to the dashboard doesn't work for any scenario where the end-user is a regular member. That's the case for any community-based website including social network/ecommerce/forum/wiki or filling a form like survey/poll/RSVP. Going to the dashboard is too intimidating and disruptive in the user experience.

If it becomes possible to edit content items and view them in the front end, then only the admin will need to go to the dashboard (for admin stuff).

I understand that it will require some big changes in the core, but I really hope you will consider it. That's what a v2.0 is all about :)

Jul 26, 2011 at 11:14 PM

Actually it wouldn't require changes to the core and could be done today as a module. But it will definitely become easier in 2.0.

Jul 27, 2011 at 5:38 AM
Edited Jul 27, 2011 at 5:39 AM

What about a forum module? Does core team have any plan for it at the moment?

BTW, Great work on Orchard. Thank you.

Jul 27, 2011 at 8:23 AM

There are good people working on that already.

Jul 27, 2011 at 8:43 AM

This is a great news. What a community! Many thanks for the update.

Jul 27, 2011 at 3:39 PM

@Jetski5822: good suggestions about the experience, specially the front-editing.

@bertrandleroy: I agree with you about the widgets/zones/layers visual interface, it can be built now with some js, and with supporting drag and drop. Also after a drop, a small menu will appear with a check-list of available layers to select the moved widget will be displayed in the dropped-in zone for what layer.

BTW, I think the docs are very cool, but need more work and examples for advanced development situations. Is there any news about any book in the way covering the Orchard topic?

Keep the good work guys, Orchard rocks ;)

Jul 27, 2011 at 11:46 PM

FYI, second Tokens post is online:

Jul 28, 2011 at 4:40 PM

For 2.0 I suggest “Community Website” recipe which would include forum, members’ blogs etc.

Jul 29, 2011 at 4:19 PM

Regarding the roadmap, I was disappointed that there was no mention of enhancements to page templating. My company currently does 40-50 CMS sites a year (we use an in-house CMS), and we have been keeping Orchard on our radar since the project was in it's infancy. We would love to move away from our proprietary system to a framework like Orchard. The reason we have not adopted it is that there is no easy way to give our clients the facility to change the layout on a per-page basis.

For example, a typical site for us will have a home page layout, a default sub-page layout, maybe a blog, and a couple of alternate views (page without/sidebar, split view etc.). One of the things that our clients love to do with a default content/sidebar layout is type in content in a main zone, and then drop in page specific content in the sidebar. Another example might be on a contact page - in the main content zone the client might add a WYSIWYG and then drop in a contact form underneath it. And in the sidebar, they might drop in another WYSIWYG widget with some more page specific content. The parts for something like this seem to be in place in Orchard (zones, widgets, layers etc), but as far as I can tell, it is not readily doable for a non-technical end user.

It probably comes down to target audience. Orchard is not targeted at John Doe, the owner of the small business down the street. I understand this and have no problem with it. But I would love to find a way to use Orchard in my day-to-day business.

Also, I definitely vote for exposing the Zen board. I have always wondered why there is no link to Uservoice on the Orchard website - if it gives you lots of useful feedback, I think it might be helpful to make its existence more obvious.

Jul 29, 2011 at 7:01 PM

Feedback on tokens so far:

I agree that it is a great core feature to provide.

I couldn't tell for sure, but I assume that you will be providing reflection out-of-the-box!?!
This would basically allow us to use tokens exactly like in Views (eg: @Model.ContentPart.Comments.Count becomes {Model.ContentPart.Comments.Count} without any extra coding).

I wish there was also some kind of auto-completion experience inside the Dashboard, but I guess that's asking for too much :)
In any case, discovering what tokens are available will be a key aspect of this feature (for the end-user). Maybe you could extend the shape tracer to provide them as well...

For security & flexibility reasons, there should be some hooks to listen into tokens being rendered with the ability to change or even veto it based on the context. This would enable permission models per content type or module or logged user. This would be very important (esp. with reflection) avoid hacks like writing a blog post comment containing {WorkContext.CurrentSite SecretSetting} :)

Jul 29, 2011 at 7:34 PM

@jsaccoccio that would be very easy to build as a module. Content parts can dispatch shapes into other zones (see Or you can create layers per page.

@phkuate: a token provider that reflects on content types would be trivial to build, but we're not necessarily going to provide it. Discovery of available tokens is built-in the API already. I think permissions on tokens is overkill and a little misplaced: it's probably the underlying API that a token uses that should accept to give a value or not, not the token provider. Tokens shouldn't be exposed to be written by end-users anyway.

Jul 29, 2011 at 8:04 PM

@bertrand: As long as it is easy to build token reflection as a module, that's enough. After all, that's the power of Orchard.

Regarding the security issue, I took the example of end-user for fun, but it is the same for an user who has access to the dashboard (say an Editor) who could need (supervised) access to tokens.

Jul 29, 2011 at 8:53 PM

True, site settings in particular could be an issue.

Jul 31, 2011 at 3:12 AM

Third post: Autoroute

Aug 2, 2011 at 7:54 AM

what orchard needs is, that you can apply diffrent layouts on different pages. I did it for now with filter but for a normal user this is to much.

Aug 3, 2011 at 12:32 AM

@michaeldickson: try this

Aug 29, 2011 at 10:49 PM

great to see things rolling with the committee, having more of an idea of what the core team is working on could also help the collaborators getting into the groove of the project. I for once, would value all I could learn from your methodologies and work methods.

Also are these available for anyone in the community to work on? I'd love to get my hands into solving some of these which would help me with the learning curve of whole project.

Aug 29, 2011 at 10:53 PM

Any approved bug is fair game to work on. A heads up as a commend on said bug can't hurt though.