What do you like to see in OrchardCore 3.0?

[MikeAlhayek]

I would like to gather insights from our community members regarding their experiences and requirements. Let's initiate a conversation focused on strategizing for the upcoming Orchard release. Your input is invaluable in shaping our plans moving forward.

I'll edit this post with a list of all ideas we agree one to have all selected idea in the original post

Selected Agenda

• ...

@sebastienros @Piedone @agriffard @hishamco @Skrypt @BenedekFarkas @deanmarcussen @ns8482e @kevinchalet @hyzx86 @domonkosgabor @rjpowers10 @sarahelsaig @Jetski5822 @lampersky @giannik @MikeKry @MichaelPetrinolis @SzymonSel, thoughts?

[MikeAlhayek]

Here are some actions I like to propose:

Code Cleanup

• I propose reverting the name OrchardCore back to Orchard. Following the example of the .NET Foundation dropping "Core" from .NET, the next major release could be termed Orchard 3.0. This transition would entail changes to namespaces, project names, and more. However, it's crucial to ensure a seamless migration path for existing OrchardCore sites to transition to Orchard 3.0.

• I suggest moving all existing migrations file(s) into a newly created Migrations folder, along with developing a plan to facilitate smooth data transition from OrchardCore 2.latest to Orchard 3.0.

• We should eliminate any elements marked as obsolete and remove components dedicated to backward compatibility. This would necessitate all users to upgrade to OrchardCore 2.latest before migrating to Orchard 3.0.

• Relocate all service classes to the core project, except for services like NavigationProvider and PermissionProvider.

• Model classes such as ContentField, ContentPart, Permission, etc., should be moved into a Core or Abstraction project.

• We should align the namespace of all types with the folder they are currently located in, while removing the term "Abstractions" from any namespace and utilizing file-scope namespaces for all existing types.

Email Module

• Add a new Orchard.Email.Smtp.Abstractions project, housing all types related to SMTP from OrchardCore.Email.Abstractions.

Elasticsearch

• Addressing naming consistency, there are inconsistencies within the module, where some types use ElasticSearch, Elasticsearch, or Elastic. To maintain uniformity, all types should be standardized as Elasticsearch.

[BenedekFarkas]

There are two faces to the problem of dropping "Core" from the name, one is a simple (technical), but the other one is much more complex:

1. Technical, as in just the code: It's kind of an inconvenience to adapt custom code to it, but it's mostly search and replace. Would be nice to make things simpler, but:
2. Visibility/marketing: Yes, MS did sort of the same, but it looked silly and doing the same would hurt us a lot, because:
   1. "Orchard Core" is an established brand we have to keep recognizable. We're a small community with limited visibility.
   2. "Orchard" in itself is a widely used term, but "Core" helps differentiating it from stuff related to agriculture (in search results for example).
   3. This might be less of an issue, but it also helps differentiating from Orchard 1 too.

Even though Elasticsearch hurts me through my OCD so much, I prefer consistency. :D

[rjpowers10]

second, this will lead to changes in the package names and conflict with the Orchard CMS

This is IMO the most important thing to consider. The namespaces could be changed without changing the package names but then "core" will appear in some places and not others.

[Skrypt]

As for Elasticsearch naming consistency I believe that at some point the other dev truncated the name to Elastic because these assembly names were like OrchardCore.Elasticsearch.Abstraction ... Elasticsearch.ElasticsearchQueryResults

That makes a lot of naming redundancy.

[MikeAlhayek]

@Skrypt I am okay with dropping Elasticsearch from type names if that is what you are suggesting. I just prefer consistency in the naming. But if we remove the Elasticsearch from the type naming, we should also drop the name AzureAI and Lucene.

[Skrypt]

Some of them makes sense though. ElasticsearchQueryResults as an example should not be just QueryResults because then you will get QueryResults in each of these search assemblies and it will then need to be aliases if using 2 different ones in the same context. SQLQueryResult with LuceneQueryResult is a possible example. So, I'm not sure to be honest. Elastic is the shortest term. You see why I did not rename them. I don't mind aliases either if that's what we want.

And then yes, the task if for them all if we go that path.

[hyzx86]

Firstly, thank you for the invitation.

Since 2021, I've been using OrchardCore in our business systems and have encountered several issues:

• More detailed error logging: Sometimes, error logs provide insufficient information, making it difficult to quickly identify issues.
• Adding namespace functionality to the Scripting module: This would better differentiate between internal functions provided by OC and JavaScript system functions. This is very well done at Kooboo CMS https://kooboo.cn/en/docs/KScript/kscript-concept
• Refactoring QueryApi response results to return an Object instead of just a collection, such as { items, total }.
• Encapsulating common form components such as checkbox, text Input, dropdown, TextArea, CodeEditor, etc ...
• We now have over 200 projects. Should we consider minimizing the number of projects as much as possible? Some necessary dependencies, like the `OrchardCore.Users' are essential functions of the CMS system and need not be separated.

Data structures and indexes

• Enhancing the openness of Yessql and related configurations: Opening up some interfaces for users to rewrite, for example, my submission regarding dynamic type indexing.
• Additional data management tools: Since Yessql is unique, sometimes we need to adjust or view data directly, which is quite cumbersome.
• Consider implementing dynamic full-table indexing instead of insert index data to each field type. What I mean is to create a separate index table for certain types, where some fields of that type can be stored in independent tables. This facilitates complex business queries and analysis, improving insertion performance.
• Splitting the document database for user-defined collections, optimizing some frequently read/write data types to prevent table locking.

[Piedone]

Splitting the document database for user-defined collections, optimizing some frequently read/write data types to prevent table locking.

This is a big one and something that I pondered for a while too. However, I'm not sure how that would work with indexes (e.g. for ContentItemIndex you still need all content item documents in a single table). But the ability to have custom collections should already be possible, but you need to open your own YesSql sessions from the existing DB connection.

[hyzx86]

If we use a separate content item store and a custom index, we can abstract the fields from the ContentItemIndex, and each dynamic table, like Published and Latest, must contain these fields. ContentItemIndex is not needed for the separate content item

[hyzx86]

but you need to open your own YesSql sessions from the existing DB connection.

You mean open a separate database? No, that's not what I meant, I meant that dynamic indexing on Yessql is related to Collection
sebastienros/yessql#525

[Piedone]

Not a separate DB, but just a new ISession to the same DB.

[hyzx86]

Maybe take a step back and eliminate full-field indexes and just add a field name as Collection to ContentType Management Page , like Stereotype 😁

[hishamco]

IMHO the first thing I need to see - which I fighted from the beginning - is to make our APIs consistent across all the modules as we as UI refreshment which I can take care of it

I suggest moving all existing migrations file(s) into a newly created Migrations folder, along with developing a plan to facilitate smooth data transition from OrchardCore 1.latest to Orchard 2.0.

I remember I made progress on this a long time ago, I could revisit it, this way our migration could be clean and clear if we separated across multiple files

[Piedone]

An admin UI refreshment (i.e. an awesome and good-looking admin theme), perhaps a couple of new frontend themes, would be great.

[ethankershaw]

An idea I've been working on is a minimal theme that really only seeds the tenant with the bare minimum liquid templates and css/js files. Then these would be completely customizable from the admin and only apply to that tenant.

[Piedone]

You might be interested in this: https://github.com/Lombiq/Hosting-Media-Theme

[MikeAlhayek]

An admin UI refreshment

I would love to see more use of modals than having to navigate to different page. For example, editing Content Part settings would be done in a modal instead of a new page.

[onestar1]

I am a worker who is learning to use ORCHARD core 1.8.
In the process of using orchard core, I found that database data processing is a very important thing.
I have always regarded orchard core as a large backend, integrating data from other systems.
So I hope it can play the role of a large platform, because when the data connected to other systems is synchronized to Orchard Core's SaaS for management, I find that the management of the database, reading and writing is a big problem, especially synchronizing data into the context. It often takes a long time.
I am currently building a mall data like NOP - especially users and orders - to be synchronized to the OC backend for management.

I hope that Orchard's Saas can be used to facilitate data access and management of other systems.

thank you!

[Piedone]

I suggest you open a specific discussion about

when the data connected to other systems is synchronized to Orchard Core's SaaS for management, I find that the management of the database, reading and writing is a big problem, especially synchronizing data into the context. It often takes a long time.

because this needn't (shouldn't) be slow.

[hyzx86]

You can schedule and manipulate your external data with some custom script functions, but saving it to OC is not recommended

[rikbosch]

It would be nice to make features (their id's) and their settings more discoverable, using a typed system.

something like

builder.Services.AddOrchardCms(orchard=> 
{
   orchard.EnableFeature<MediaFeature>(feature=> 
       {
          feature.MaxCacheDays = 150;
          feature.AssetsPath = "Media
       });
}

Also, authoring recipe's could be improved in my opinion. Currently it involves a lot of manual json tinkering, Maybe with a custom json schema to enable intellisense or also leveraging some kind of typed system. This would allow code based recipe's.

Third might be an opinionated Aspire component, with best practices configured for production scenario's.

[hyzx86]

It would be nice to make features (their id's) and their settings more discoverable, using a typed system.

It may create some dependency order issues..

[MikeAlhayek]

Add a static string and HTML localizer

[sebastienros]

#4466

[Skrypt]

Added a jsLocalizer in Vue 3 pull request. Pretty simple implementation.

[hishamco]

Why on Vue?

[MichaelPetrinolis]

• A base testing helper library to guide users write tests in their own projects. Introduce OrchardCore.Testing APIs #13018
• More consistent documentation about the View Models for CMS provided parts, like List Part documentation does.
• Lombiq's Shape Tracing should be included in OC under Design features. A chrome addon would be handy to display the Model and info about shape tracing, cache usage etc.
• Some guides on how to discover alternates, use wrappers etc. for easy boarding of FE developers
• A new way to provide documentation and IntelliSense support about built in JS and Liquid functions when using Monaco editor
• OrchardCore Clusters #13633 for supporting large scale installations

[MikeKry]

For us, we use OrchardCore mainly in headless mode, on multiple platforms and with multiple types of databases.

It would be nice to see:

• revision of headless mode - completely disable admin FE, reduce modules that are not necessary for headless, possibility to create non-admin headless with possibility to fetch images, improve graphql (more accessible settings, option to create queries from cms, secured routes). Reduce nesting of queries (e.g. reduce "flow.widgets" -> "flow").
• revision of placement module - check if all admin edit placements really do work, Make it more user friendly - eg. in-place editing, visual selection of tabs, types, wrappers..
• data module - add possibility to create custom tables from admin ui. Maybe also add possibility to create standard relational tables without JSONs for custom data.
• Import - either create import module or expose properties (make public) on content item and content elements, so we could create our own importers easily.
• Workflows - track in which step worklow has ended (visually or text). This could be easy and it would help to track failed workflows.
• Fix alternative db providers - there are some errors in SQLite (unsupported methods in migrations, eg. alter column that throw errors) and in Postgre (case sensitivity and generally more complex way to write queries)
• Media cache - provide a way to selectively cache only certain content. Allow to disable cache even when using blob storage (for given media, based on type or folder).
• Media security - do not cache media in wwwroot (at least not original, before resizing with original path). Add permissions to view media that would be manageable for every role, maybe based on media type/folder.
• Taxonomy Term selector - add content field that could select any taxonomy term from any taxonomy. Useful for filtering etc.
• Healthchecks - add extendable healthchecks with UI.

I will elaborate later on given points, just providing quick guidelines as I do not have time to do it now :)

[Piedone]

Some reflections:

data module - add possibility to create custom tables from admin ui. Maybe also add possibility to create standard relational tables without JSONs for custom data.

Being able to create tables from the admin UI seems like a very curious requirement for me, please elaborate. BTW from code, with migrations, you can create custom tables that are completely independency of YesSql and the document DB.

Import - either create import module or expose properties (make public) on content item and content elements, so we could create our own importers easily.

Please indeed elaborate on this, because I think this is what the Deployment module does.

Media security - do not cache media in wwwroot (at least not original, before resizing with original path). Add permissions to view media that would be manageable for every role, maybe based on media type/folder.

Caching is not only for performance currently but also to be able to serve the files at all, though we should be able to somehow serve files from Blob Storage and S3 directly too. See #14859 for some background info. See #15173 for permissions.

[hishamco]

Fix alternative db providers - there are some errors in SQLite (unsupported methods in migrations, eg. alter column that throw errors) and in Postgre (case sensitivity and generally more complex way to write queries)

This could be due to the limitations in some databases such as SQLite, but feel free to open an issue in YesSQL repo

Healthchecks - add extendable healthchecks with UI.

I already did some useful stuff in OCC modules, also there are two PRs in OC that could open the extensibility for healthchecks

[giannik]

• Jobs Management- Queues.
  -- Use Quartz.NET Use background Job for search indices #760 (comment)
• Elsa workflows to replace existing workflows (already supports Quartz.NET)

[SzymonSel]

I'd love to see more Admin features concerning content mangement ie.

• Display and Editor templating for Admin view
• A kind of WYSIWIG form and display editor for admin.
• Debugging features for workflows
• Forms blocks in workflow editor.

[Piedone]

A big one: follow SemVer. Currently, we allow breaking changes in minor versions (1.x). This goes against SemVer, but more importantly, makes consuming Orchard Core packages, and maintaining apps using OC, much harder.

As an OC user, I should be able to upgrade from 2.0 to 2.1 without worries, knowing that everything will keep on working, and at most I'll get some warnings due to APIs being obsoleted (but still available). Only a jump from 2.x to 3.0 should need migration work. This would also allow us to expect everyone to run the more or less latest version of OC (simplifying issue management).

Now we have enough experience with OC that we can stabilize the APIs for 2.0 (with breaking changes compared to 1.x) and then say that we'll keep to that until 3.0.

Package validation, specifically Baseline Package Validator can help with this for C# APIs, warning when we try to publish a breaking change. However, we have a lot of public interfaces that are not published interfaces, so we'd need to handle them as exceptions.

[hishamco]

This is a big one, I totally agree

[MikeAlhayek]

Yes this is a must for me. Maybe OC is already at a stage that is worth stabilizing. Ideally, we should introduce breaking changes in a major release 1.0, 2.0...

This means we would have to release more major releases more often (annually). In a minor changes, we can introduce changes as long as they support a complete backward compatibility. This will allow library authors to add dependencies on their projects there that can say 1.*.* so if we introduce 2.0, these libraries will ignore out 2.0 release but continue to work with no problems and we ensure that the dependencies are honored without breaking people.

For this to really work, OC needs to be stable enough where we would not need to introduce breaking changes that often so that we can have no more than one annual major release.

[Piedone]

Yep, we shouldn't be afraid of more frequent major versions (annually sounds good) to clean out deprecations and introduce controlled breaking changes. We could actually do that already, but having a v2.0 seems like a good checkpoint to communicate that.

[Piedone]

After sleeping on it, you're right, Mike, we should actually call the next release 2.0 instead of 1.9. What we have under https://docs.orchardcore.net/en/latest/docs/releases/1.9.0/ warrants it. And then, we should follow SemVer rigorously.

Apart from what we have for 1.9 already, I'd do https://docs.orchardcore.net/en/latest/docs/releases/1.9.0/#display-management for every other driver as well, so we have that covered in one go. @Skrypt what do you think?

[MikeAlhayek]

@Piedone I created an issue so we can act on it. #15892

[effapp]

Hi,
Please consider adding following two features:
1 Admin menu can cutomize totally.
2 Add mobile app.

[Piedone]

Can you please elaborate on both points?

[effapp]

1 Admin menu can cutomize totally like front end menus that can add several customizing menus and select one of them as main menu.
It is the best if OrchardCore can make admin left side as FlowPart and add menu widget, then I can add widgets to admin left side.
2 Add mobile app that achive admin features completely .

[MikeAlhayek]

1 Admin menu can customize totally.

The Admin Menu is completely customizable already.

2 Add mobile app.

This is something I am using and is an app around OC. For example, you can download "Full Charge App" in AppStore or PlayStore and you'll be able to see a working example.

[Piedone]

Re 2: any particular reason the admin area is not working for you in a mobile browser?

[MikeAlhayek]

Centralize validation logic between handlers and display drivers. Currently display drivers are used for validating data being processed through the content controller. But we also use handlers which can be used to validate data coming from an API or other ways. Currently, developers have to add validation logic in display drivers and the same validation logic in the handlers to ensure the validation is done to cover all the cases. This force us to duplicate validation logic into two places and maintain validation in two places. We should have a single validation logic that is used any time we want to validate.

[tcobbfis]

Do you anticipate any "breaking" changes to either theme or module creation?

[MikeAlhayek]

Yes. It's a major release and we can have multiple breaking changes. But we are not going to introduce a breaking change unless it solves a problem of course

[hishamco]

Breaking changes is bad for customers unless you bump a major release, otherwise no one will TRUST your library :)

[tcobbfis]

I'd like the ability to install themes and modules as packages. #8346

[lsklodowski]

Hello Orchard Core community,

I have several suggestions for improving Orchard Core:

Admin Panel

1. Ensure it is user-friendly like Strapi (https://www.youtube.com/@Strapi/videos) or Directus (https://www.youtube.com/@DirectusVideos/playlists).
2. Construct it using modern Design System UI Kits such as Fluent 2 (React, Web Components) or Ant Design (React, vue.js).
3. Consider making it and API-driven (headless) and optional, enabling configuration solely through the API and embedding panel functions into our own applications.
4. Enhance the content type builder for a smoother experience (as in the examples above).
5. Provide more no-code examples or ready-made applications built directly on top of the admin panel - samples:
   • https://www.youtube.com/watch?v=dmmN1JY53GU
   • https://www.youtube.com/watch?v=h-6DrDjAm_c
   • https://www.youtube.com/watch?v=e5PurMrJeKg
     • https://www.youtube.com/watch?v=wPWcIFVxShQ
   • https://www.youtube.com/watch?v=EH85i_AFfd0

Backend-as-a-Service

1. Improve the API (REST and GraphQL) and potentially add OData support.
2. Introduce granular access control with filter rules, custom validation, field-level permissions, and row-level permissions.
3. Backend for Frontend - showcase usage for web applications using Vue.js/Nuxt.js and React/Next.js with hosting on Azure Static Websites.
4. Mobile App Backend - examples of its potential as a backend for mobile applications using Flutter or MAUI/Blazor.
5. Backend for AI:

• examples of obtaining data from API and search engine for embedding in AI applications (grounding) +
• Vector Indexing https://techcommunity.microsoft.com/t5/fasttrack-for-azure/grounding-llms/ba-p/3843857 and AI Writer
• AI-supported content creation (LLM integration in the editor),
• creating entire applications in the backend using AI: https://www.youtube.com/watch?v=hGQxD-dnA08

7. Allow data structure creation via API, possibly supporting a standard like the Common Data Model (https://github.com/microsoft/CDM)
8. Implement a notification system with multi-channel support.
9. Transition to Elsa Workflow for workflows and improve UI integration.

CMS

1. Offer headless CMS examples and guidelines.
2. Simplify multilingual content localization through UI and API, and support automatic translations.
3. Enhance the content editor with features like those seen in Medium or provide options for building custom editors.
4. Introduce a hosted forms builder (for data collection).
5. Provide statistics APIs or improve integration with analytics tools like Matomo, PostHog, or Google Analytics.
6. Enable content personalization and recommendations based on user data and statistics.
7. Implement a publication workflow with an editor-friendly interface for content planning.

Azure Integration

Considering deeper integration with Azure services would be valuable. Azure SQL (Storage), Azure AI Search (Search), Azure Blob Storage (Media), Azure Communication Services (Email), and Entra External ID (IdP) could be primary focuses.

[Piedone]

Thank you for elaborating! FYI, the following are already available in Orchard Core from what you listed:

• Content item-level permissions (i.e. "row-level permissions").
• Ability to provide custom editors for everything, and user-configurable ones for some parts/fields (e.g. Html Part).
• Google Analytics integration (but integrating with any external web analytics solution is only a matter of adding a bit of code to the layout, what's trivial).
• Azure SQL, AI Search, Blob Storage, Communication Services, Entra ID support.

[hishamco]

I agree that we need to improve the UI, I have already done some PRs in the past, but you need to realize that almost all of the Orchard Core team are developers :) I'm doing some UI improvements in Orchard Core Contrib but again we need to improve the current UI design system

For Azure integration, we already have a great integration in Azure SQL Server, Azure AI Search, Email through ACZ, and much more

[hishamco]

Offer headless CMS examples and guidelines.

Agree

Simplify multilingual content localization through UI and API, and support automatic translations.

Please elaborate on how we can simplify the multilingual. We already have a content localization module for that. For automatic translation this might be a community project, again it's on my list in Orchard Core Contrib :)

BTW it's not necessary to implement all the things in the framework itself, that's why there's a community, as discussed in many places we need to focus on the stability and quality for the upcoming releases rather than providing a lot of features

Thanks for your suggestions