Feature Poll for 1.9

Topics: General
Coordinator
Apr 2 at 12:45 AM
Edited Apr 2 at 1:58 AM
Now that 1.8 has been released, we will focus on fixing bugs and also planning for the next version. Here is a list of feature that have been mentioned in some ways for potential priorities. There are many more things that could be done, but here we will talk about the modules that have a bigger customer base. Feel free to start implementing any other one that would not be part of the core effort right now.

REST API

Provide services that can be used to create REST API in Orchard, such has Materializers, Serializers, Authorization, Formatters, ... This will certainly be implemented using Web API.
It will also be a set of APIs specific to each module. For instance the Search module would provide search API endpoints, the Tags module would let a user query content by tags, the Contents module query content by ids and so on for most modules.

Being able to update content using an API has a lower priority, as the main goal would be for consuming the data exposed and managed by the CMS.

Audit Trail

This module would provide an API for other modules to log not removable events, and also provide a UI to list and filter these events. It would also display previous versions of a content item and the users who modified them.

Localization

We need better localization throughout the CMS. Most features are already available on the gallery. We also need to integrate more content filter in the UI to ease editors' work.

Placed Content (aka dynamic layouts)

Onestop has open sourced a module developed by Bertrand which allows any user to create dynamicly layouted content. The hard part is done, and the remaining work would be to replace the current editor by something more user friendly, maybe with drag & drop.

The idea is that the different pieces of content placed on a layout would be owned by this content item, as in "composition".

Deployment Module

This module has already been discussed and design notes are available on the forum.
https://orchard.codeplex.com/discussions/452000

SQLite / PostreSQL

SQLite has the advantage over SQLCe of being much faster. Erik Schultz has already provided a PR for the feature.

PostgreSQL should not be hard to integrate either, and maybe there is already a PR too somewhere.

The discussion is open, what are the ones you would like to see implemented first, with the user base in mind, not just your own personal requirements. Please order them or propose other ones with similar importance. Please don't mention others that you would not place in the top 3 features to add.

I hope to be able to publish design notes for each of the features, so that if we can't implement them someone can work on it following our recommendations.
Coordinator
Apr 2 at 1:06 AM
I think the audit trail may be the opportunity to set-up some reporting infrastructure. If any module can log events that can then be queried against, that would open up some really interesting opportunities.

On dynamic layouts: the idea here is to replace placement.info as the default way to place parts and fields on the page. Placement would still be there, but would become more the implementation of defaults from modules. It should be noted that there is currently no way for placement to send something into dynamic layouts but that may be a good idea. Also, if a part is present both in a dynamic template and placement, it will appear twice. All this to say that sanitizing how templates and placement work together would probably be a good idea. Making template editing more drag&drop-based, and allowing for ad-hoc templates per content items are other desirable improvements.
Apr 2 at 2:42 PM
In Europe Localization is key feature. Think that to sell to the 200 million persons market in Europe you need at least 5 or 6 languages.

Is not the same in USA where you can sell in English to 200 million persons.

So a better way to manage localization and specially to contribute to translate is very important.


In the other hand Dynamic layout sounds great, Oh no, no this exactly. Drag and drop...

There are my votes / opinions to the poll

Thanks
Apr 2 at 2:54 PM
About localization, if I didn't miss it? Localizable widgets! Just finished doing 4 separate widgets to show the same content localized ;p
Apr 2 at 5:32 PM
I'm a fan of SQLite but I'm biased. :) It also has the advantage that it's open source versus SQLCE and could run on Mono (although that's untested and may require a change or two)

Also @sebastienros, you spelled my first name wrong. :P
Developer
Apr 2 at 5:52 PM
Audit Trail missing and Localization services being incomplete are long outstanding issues wanted by many and I personally think that having a standardized REST API (at least in a basic, starting form) is a must. I'd add a fourth point: bugs. There are hundreds of nerving bugs out there, many of them not even triaged yet. We have to do something with them.

Dynamic layouts is a topic where I think there are many different ideas out there (I remember people wanting drag&drop placing for widgets and content part displays, widget pages or page widgets instead of/besides layers...) so IMO we should open a discussion about clarifying what the community wants. Similarly for the Deployment Module.

I don't think the argument that SQLite is faster than SQL CE is very strong, since SQL CE is already used only for development (where it's fast enough not be a bottleneck, so why care) and for small sites (that use it because they don't need something faster anyway). There is also the option for MySQL already for a potentially cheaper or multi-platform alternative of SQL Server. That said I'd love seeing SQLite support but I don't consider it a priority for the next release. My question though would be how much effort it would take to integrate what Erik has already done, or what is missing. If it's just a matter of merging the changes then I don't see why not do it.
Apr 2 at 6:16 PM
I think RestAPI will boost html5 based mobile apps on sites powered by Orchard. And I will agree to BertrandLeRoy, Audit Trail will open up some really interesting opportunities.
Apr 2 at 8:28 PM
Hi, I vote for:
  • Solve most pending issues before going on with new features .
  • REST API will enable more scenarios than the audit trail, I think.
    In fact, if it is complete enough, maybe it can help to solve another issue I found in Orchard : admin interface seems a little outdated and need improvements from a user experience point of view. For example using a REST API we can design an admin theme that made intensive use of angularjs or similar or maybe mobile apps to edit content.
Apr 2 at 9:07 PM
Edited Apr 13 at 5:22 PM
signalR
rest api
localization
placed content
Apr 2 at 9:11 PM
mmolleja wrote:
Hi, I vote for:
  • Solve most pending issues before going on with new features .
Yes, I fully agree with. Orchard contains a lot of features, but almost none of them are well polished.
Apr 2 at 11:50 PM
Congratulations on another great release. I agree with mmolleja
  1. Resolve open issues & get them back down to a comfortable level
  2. REST API for the mobile apps capability
Apr 3 at 9:27 AM
Edited Apr 3 at 9:34 AM
I think localization is really neglected due to the fact that its treated as a CMS module/feature rather than a content feature.
localization should be tightly coupled with orchards content type system because it revolves around content itself.
When new features appear in orchard there are sometimes issues with the localization aspect because they are not tested against localization.
For instance the new media feature in 1.7 brought some issues with localizing media items as described here :
https://orchard.codeplex.com/workitem/20510.

Also in the admin area take a look at how content appears when you translate it. for instance the navigation menu looks like this :

https://dl.dropboxusercontent.com/u/12899887/temp/img1.png.

The same applies to the widgets admin page and media items page. You get a list of all localized content.
This is very confusing for content authors . there should be at least a drop down list to query based on language.
Localization should be a first class citizen in Orchard, in my opinion.
Thanks
giannis
Apr 3 at 11:23 AM
  • SQLite would be great to reduce the cost of hosting for smaller sites
  • REST API for extending apps
Developer
Apr 3 at 11:31 AM
  • Integration of OWIN + new ASP.NET Identity (authentication providers, ...)
  • SignalR + WebAPI (Ex : comments refreshed in real time)
  • New admin theme (CSS framework, Dashboard Widgets, ...)
  • JS MV* Frameworks (Angular, Backbone, Ember, KnockOut)
  • Upgrade JQuery version (and check Shape tracing)
Apr 4 at 12:39 PM
Edited Apr 4 at 12:40 PM
tl;dr; edit: ditto aggrifards Dashboard Widgets request

Customizable Dashboard UI

Although I know this isn't really a feature that needs core integration to be built, but it is one I think the Core should contain. Orchard contains a hell of a lot of sweeeeet as features but it's tough teaching site admins to remember where they all are. To combat this we have a simple page that appears instead of the default dashboard homepage that is just a customizable html page that has a bunch of links to various important places in the site. Clients literally wet themselves when we added this and I don't really know how they functioned without it. However, some clients are asking for a more dynamic nature to this page: displaying data, latest posts, comments, latest published content etc. Crap like that basically.

It would be awesome if something like Orchards widget system could be implemented for the backend.
Developer
Apr 4 at 12:53 PM
@Hazza: this is indeed a long outstanding feature request as well, and might be quite simple to implement: https://orchard.codeplex.com/workitem/18227
Apr 4 at 1:18 PM
Edited Apr 4 at 1:19 PM
@Piedone: Yes would be great to see it. Even better if it could be available before 1.9 is released. Could we maybe open a new discussion for this feature and the best way to go about implementing it? Or is that overkill and it just needs to be made ^_^
Coordinator
Apr 4 at 5:33 PM
Forgot about the dashboard idea, great reminder guys. Would be awesome if you could do something on this. Do you want to open a thread to discuss it ?
Apr 5 at 5:40 AM
Edited Apr 5 at 12:26 PM
Hi,
For me in priority order:
  1. Localization and better custom calendar (for example new PersianCalandar in 1.8 has bug in dashboard and new dateTimePicker & ...)
  2. REST Api is very good feature because it is very useful for mobile application development or link orchard to other systems.
  3. I also suggest my recent problem solution:
    Repeatable feature for content fields and content parts as a new checkbox setting in content definition panel like this in wordpress or other system.
  4. SQLite / PostreSQL (I Love SQLite)
Thanks
Apr 8 at 1:33 AM
Edited Apr 8 at 3:26 AM
For me and (i think) for most developers working in Europe, the main priority now is Localization.
90% of my customers ask for mutlilingual websites, or at least two languages (their country language and english).

Here a some ideas, and dificulties that i usually have to face:
  • Localization features, like culture picker should be implemented in the core, not as module, it needs to evolve at the same pace as orchard does;
  • When managing Content Items (or Widgets) in the Dashboard, there should be a filter by culture;
  • Ability to set default culture for the dashboard and front end separatly;
  • Possiblity of having fields or parts in which it´s values are shared between the translated versions of a content item, like singletons, i give you an example below:
When creating an ECommerce website using Nwazet and localization, I add the localization part to the product content type, the product has fields like Inventory and SKU.

When creating translations of a product, it will just clone itself to new content items, each of them will have it´s own fields holding it´s respectives values, this poses a big problem, especially when dealing with the inventory field, what happens to a product inventory when a customer checks out a product?

answer: The inventory of the product content item checked out is decremented, but only the chosen localized version, what about the other versions (content items)? if your customer is selling physical goods, for him the product is the same, no matter in which language it´s written so is the inventory, he just wants to translate the descriptions, titles or whatever, even the sku he wants it to be common to the translated versions.

The above example is real, i´ve been asked to build a multilingual wine shop for a Wine Producer, and i still am cracking my head on how to solve this, probably i will have to fork Nwazet and then create a service that deals with inventory and skus storing them in a separate table in the database, and on the product just holding a reference to those values.
It would be nice to have the ability of having a setting on the Localization Part, where one could establish this kind of relation between content items that are translated.
Probably a Parent/Child relation, well this is just an idea.

Thank´s
Apr 8 at 7:31 AM
@nduarte We did that a bit differently @ https://www.tacx.com/en/onlineshop

We haveplenty of custom fields that have an option to use the 'master content'.

If enabled, the value will be fetched from the default culture.

Also, the product specific data is stored in separate records and not stored on the content item level: per content item we just 'link' to the right product record.
Apr 8 at 1:55 PM
@AimOrchard Thank´s for your feedback,

I´m going to try your aproach custom "fields that have an option to use the 'master content'", that´s a nice aproach.
I would like to ask you some questions:
  1. Did you build your Commerce module based on Nwazet.Commerce, or did you start from scratch?
  2. In you module, when creating a product, do you provide the user a single place to create/edit the specific product data and the localizable data, or is it separate, meaning, the user first creates product specific data then and only afterwards he´s able to create the localized data (on separate editors)?
Thank´s

Nuno
Apr 11 at 12:13 AM
I'd like to see a slightly different focus for 1.9 :)

After developing some sites/services with Orchard over the last couple of months I've definitely found a lot of pain points....
I really like the overall architecture of Orchard and all the extensibility points are great. I've often heard people say that orchard is a developer focused CMS. While this seems to be true the - it seems the focus is more on the orchard core developers, rather than for devs that want to build orchard based solutions.

Development story: this is the real low point of Orchard for me. It seems there are two options - use webmatrix or clone the entire source repo. There needs to be a simple option for developers using Visual Studio that doesn't require cloning the repo. You should be able to create your own repo for a project that only contains the code for your project specific modules and config.
When I first started Orchard I looked for a "how to get started developing a site on orchard" and couldn't find anything like that. In general there's not much in the way of support/documentation for developers creating orchard based solutions.

Nuget: It should be as simple as creating a new web project in visual studio and running install-package orchard. Doing version upgrades or adding new modules through nuget would be great.

Deployment: I've found the deployment options to be pretty basic.

SQL Server LocalDB: This seems totally obvious and simple to do. It should be the default database option.

In general it would be great if Orchard could be abstracted away from website based usage. I don't think this is an assumption that should be made in a CMS. Orchard can be used in many ways that don't require pages, navigation, templates etc. e.g. a content service for apps.

+1 for the REST api.
Apr 11 at 1:50 AM
Azure Deploy that 'just works' - including as a VirtualApplication (MySite.com/WordPress = easy peasy, MySite.com/Orchard = ouch, cough, choke, confusion)

I would also like to see a SQL cache option rather than the expensive memory cache. ugh. I was pretty stoked to find Orchard not use sessions... until I realized it needs cache. Or maybe use cookies, not sessions. something.

Use Azure Table Storage as an alternative to expensive SQL, or even text based (see Composite C1).

OpenID

alternative to custom login. Not impressed AT ALL by the custom built in identity. It doesn't even use a standardized Simple Membership or similar provider, which also means I cannot implement my own provider! eeeek! But most importantly, identity should not be so tightly coupled with the app. Most organizations have their own identity system. I would like to see Thinktechture and Orchard "just work", and result in JWT tokens the Orchard client would use for authorization - this would be GREAT.
Apr 12 at 10:50 PM
  1. +1 for solving/closing open tickets. We have 1249 active/proposed issues. I know that some of them are actually resolved, but it looks really bad if someone doesn't know that. Other issues just need to be fixed. Maybe it would help if everyone would check if the issues one reported are still valid and leave a close request (comment) if it isn't reproducible anymore.
  2. Accept/decline pull request. This would help reducing the number of open issues and my personal belief is, that it is more encouraging if one’s pull requests are processed in time for the next release. I think before we moved to Git we had some hundreds of open pull requests that are now closed and forgotten. Currently we have 56 open pull requests that would fix several issues and introduce new features (including support for PostgresQL).
  3. Some Web API support would be really nice, even nicer if non-content related services (e.g. notifications, auth etc.) could be used as well.
Apr 15 at 7:05 AM
  1. We definitely need proper localization. It would be rather nice if the localized content could be reached via the same url.
  2. Also +1 for soliving active issues.
  3. SignalR + RestAPI would be really cool
Apr 16 at 1:08 PM
Edited Apr 16 at 1:15 PM
for me, +1 on localization, especially combined with taxonomies. I actually stopped using Orchard since this combination is a no go at this moment.

I also think solving issues is a big deal in making the decision to choose for orchard allot easier. I suppose that this is even more imporant than features.
May 14 at 3:01 PM
http://www.hanselman.com/blog/IntroducingASPNETVNext.aspx
for deploy, does it mean that we just wait for ASP.NET vNext ?
May 28 at 1:08 AM
Orchard needs greater uptake, preferably by companies willing to support/contribute to core development. By 'core development' I mean everything in the official repo. You do not need new features. You need to refine what you have so more people will use it. The emphasis must be to reduce the pain and improve the developer experience.

@ztsmith is right. I also extend orchard without contributing to the core development and I frequently find this painful. There is little or no advice and what exists is out of date and/or simplistic. I would like to see:

A documented methodology for non-core developers to use for maintaining up-to-date core source code. I see no reason this cannot be based on git but it should clearly document how git is to be used to maintain core source locally, and a workable method of keeping a separate repo of locally developed modules.

A web page dedicated to changes in orchard that impact on developers, and what to do about them. This would include changes to config files, changes as a result of dependency updates, breaking changes as a result of changes to core modules, etc.

Also, bugs need to be fixed and the outstanding issues that seem to stop improvements to existing modules need to be resolved.

The only new code I vote for is a dynamic layout. Placement is a huge pain that currently stands in the way of easy adoption.

You are developers and developers want to write new stuff. But unless you fix what is already there Orchard will get sidelined as 'too hard'.
May 28 at 7:28 AM
Also, to continue on bsdr: there need to be backports of fixes for prev major versions!

We do not wish to upgrade to 1.8 at this time, but any fixes that come out that are not 1.8 specific we have to discover and apply ourselves...
May 28 at 12:27 PM
... which opens up the issue of better version control, both for the core and for contributed modules. The gallery is a mess, or at least it was just after the 'release' of version 1.8.
Developer
May 28 at 1:58 PM
AimOrchard brings up a good point.

My pull requests for fixes to the Media Library and a few other things, I knowingly submitted them to 1.8.x.
I am happy there were taken in, but I was concerned they were taken into 1.x instead.
If 1.8.1 were to be released, noone would see these fixes.
May 28 at 8:12 PM
Localization
Audit Trail
Bug Fixes
Developer
May 28 at 10:59 PM
@StanleyGoldman - I did'nt take then in to 1.8.x for a reason, there was a big release I knew was going on - but I wanted to get these fixes in the the code base, so figured putting them on 1.x was the best way to de risk this.
Developer
May 29 at 2:47 AM
Edited May 29 at 2:51 AM
@Jetski5822 Again, much love for taking in my pull requests ;)

I could've asked at the time, i figured you had your reasons.
Jun 1 at 2:53 PM
Web API
Dynamic Layout
Audit Trail
Jun 10 at 11:44 PM
My votes in order:

Deployment
Dynamic Layout
ASP.NET Identity?
Localization

I also agree with @ztsmith that a better development story would be great. Make it really easy for developers to get started developing custom modules and themes and put our code under version control without mixing in the orchard base code. Maybe this is just a documentation problem?
Developer
Jul 13 at 11:51 PM
Edited Jul 13 at 11:51 PM
To repeat what JasperD said above...
Accept/decline pull request. This would help reducing the number of open issues and my personal belief is, that it is more encouraging if one’s pull requests are processed in time for the next release. I think before we moved to Git we had some hundreds of open pull requests that are now closed and forgotten. Currently we have 56 open pull requests that would fix several issues and introduce new features (including support for PostgresQL).
Can we please work on the pull request queue?
Jul 14 at 6:46 AM
Ouch, 56 pull requests, I think that's more important then proceeding any other code.
Jul 17 at 9:54 AM
Edited Jul 17 at 9:55 AM
  1. Bug Fixing
  2. Localization by using Attribute routing : http://attributerouting.net/#localizing-urls
  3. REST API, SignalR, Angular.js
  4. Audit Trail (wich could use the #3)
  5. Dynamic Layout (wich also could use #3)
  6. New responsive admin interface (LESS or SaSS) ... also could use #3 !
my vote :)
Aug 25 at 2:46 PM
Edited Aug 25 at 2:48 PM
Enjoying watching harvest videos.

This is my vote:

1.Bug Fixing
2.REST API, SignalR, Angular.js
3.Dynamic Layout
4.New responsive admin interface
5.Deployment Module
6.Localization
7.Rewrite data access replacing NHibernate ORM per Entity Framework 7 to have uniform access to SQL and NonSQL dbs and to have the chance of exploring the possibility of running Orchard within a Mobile device as a standalone app.
8.Audit Trail
Developer
Aug 25 at 6:58 PM
You can try number 7 with Orchard App Host.
Aug 25 at 7:19 PM
Edited Aug 25 at 8:19 PM
By the description of the project it looks that it is for the opposite I meant. Orchard App Host looks like help to run apps within Orchard, doesn't it? I would need to run Orchard framework within a mobile device and current limitation as far as I know is Orchard doesn't support dbs used in mobile devices. Specially because NHibernate is not supported neither on Windows 8 Metro apps nor Windows Phone apps.

Am I wrong?, thank you!
Aug 25 at 7:48 PM
@jersiovic that's the pb, no mobile os supports something able to host a web server as far as I know. Interesting concept, hosting its web site in his mobile phone or a farm of mobile phones :) , even a Cloud of.
Concerning your point 7, I agree let's get rid of NH, I was interested by Sebastien intention to go to DocumentDB.
But no interesting document DB is available Open Source. May be Orchard should build its own Document DB, quite evrything is here.
Nethertheless as VNext is incorporating many Orchard features and for some other taking different directions, leaving actual asp.net for Vnext will be a terrible effort which could shut Orchard down for several years, not only concerning code but also for implied project people. Communication should be very clear.
Aug 25 at 9:27 PM
@CSADNT jajaja hosting a farm of mobile phones was not the idea...

The point is we have a native mobile app running on Winphone and Win 8, and in the future in Android. The app by requisite needs to be able to work offline (it should be able to work offline for days without sync with the server). It is architected following DDD. Currently I'm going to start to develop an Orchard module which harness Application Layer, Domain Layer and Data Layer of this app to offer the same functionality in an Orchard website.

As you can see despite we share a big amount of code between applications we still need to maintain a number of presentation layers: Windows 8 and Windows Phone 8, Android, Web App. The point is that Universal apps adds support for WinJS (and hope soon for Metro UI with Polymer) in mobile devices, so it sounds interesting for me to look for a way of reusing all the work done with Orchard to have only one Presentation Layer with different Orchard themes to render the app on different devices.

I know other solution is to use an SPA application with storage on the client. However the offline requisite arise other challenges to face so that's why I ask this question as an alternate path.

I don't understand why you mentioned VNext. For using EF7 is it mandatory to migrate to VNext? Or you mean it is a priority in the roadmap over anything related with changing to EF7?

Regards
Aug 25 at 9:37 PM
Edited Aug 25 at 9:37 PM
My opinion is more in reingineering than adapting and extending. Faster to dev and maintain. But different opinions exist :)
Concerning the futur of EF, from what I understand in VNext, they are all rewriting keeping few items from actual EF. Good point adapted to my philosophy, but consequence is it would be risky to move actually something to EF....
Aug 25 at 9:53 PM
Well yes there is other constraint I didn't mentioned. The app has a big do.main which need to be maintained with very frequent changes for many years on all platforms. But as you say for same requisites different opinions can fit.

Ahh now I get you, I misunderstood you when you said vNext I though you talk about Asp.Net vNext :)
Aug 25 at 10:03 PM
Yes I was speaking of asp.next VNext, EF is tight to it now in its V7 version
https://github.com/aspnet/EntityFramework
Aug 25 at 10:24 PM
Ahm ok

So then this:
"Nethertheless as VNext is incorporating many Orchard features and for some other taking different directions, leaving actual asp.net for Vnext will be a terrible effort which could shut Orchard down for several years, not only concerning code but also for implied project people"

Sounds pretty bad, because one of the reason we were moving to orchard was that it was an easy way to maintain the technologies supported by our app updated to latests technologies. :(
Aug 25 at 10:28 PM
Edited Aug 25 at 10:29 PM
I am not even in Steering Committee so you still have a chance :)
Just trying to evaluate the effort from what I have seen in Orchard and what I see in VNext.
The good point is it is all open source, which was not totally the case for asp.net (for exemple see asp.net identity)
Coordinator
Aug 25 at 10:44 PM
Orchard will be ported to vNext, the only question is when, this year, or next year.
Aug 25 at 11:05 PM
@Piedone you were right, Orchard Application Host is just what I would need. I have find another description of Orchard Application Host different from the one in the web of the module that explains clearly its purpose:

"Demo by Zoltán - Orchard Application Host: a light-weight framework that allows you to write arbitrary code (console or web applications, anything) empowered with Orchard. You can install shells, use any theme or module, all the services, data access, logging, caching, it's all under your hands"
Aug 25 at 11:08 PM
@sebastienros great it's a relief!!
Aug 26 at 8:46 AM
Moving to vNext is good news.
Nov 11 at 6:33 PM
Edited Nov 11 at 8:02 PM
Might be late to the party... but I'd like to throw in a few ideas.

1) Improve the documentation. There are so many bits and pieces of this system literally strewn all over the place. Some in the main wiki, some in blogs, some in code comments, some in this forum, some in demos long gone. If you're new to Orchard development, it's a very daunting task to understand what is there, how to do it, how to evaluate design points, and what is applicable to a specific version. To give you an example, I've worked with 3 new Orchard developers (self included) over the past few months and we have to routinely have a call to figure out what we've found, where we found it, does it apply, and then make a point to verify that it actually works. This is a huge time burn and a very frustrating facet of this product. I know you guys that have been dealing with Orchard for years probably don't see it but the documentation around this product is pretty slim. I'll be the first to admit that documentation has improved over the last two and half dot builds (I came onto the scene right before 1.6 was released) but there's still a lot of room for improvement. If you want user adoption to increase at all levels - basement coders to corp environments - documentation is the key.

2) Fix the bugs. I've worked on a variety of teams building large apps and the single biggest frustration I had as both a developer and user was shipping new features knowing that the last set was still undone.

For example, why work on a new layout designer for a dot build when there are still issues with the existing system in terms of bugs and improvement requests? If you want a new layout designer, plan to make it the default and replace the existing system for the next full version, not co-exist in a dot build. Please don't add yet another way to do something and not document it, not provide guidance on why this is better/worse than the existing system, etc. Please don't get caught in the loop of always shipping the newest feature to impress rather than shipping to refine. Otherwise, the perceived bloat and increased learning difficulties will make Orchard harder to introduce into more environments.
Developer
Nov 14 at 6:51 AM
Excellent suggestions. Will you help us correct this?