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.

[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 is for them all if we go that path.

[brunoAltinet]

Just upgraded a site from 1.3 to 1.8. I strongly encourage keeping the namespaces, since there are a number of places in database where namespaces are hardcoded (like for queries).

Second, what i suggest is a bit different branding:
Orchard Core should refer to Orchard Framework, a rapid application development platform.
Orchard Cms is built on top of Orchard Core, and it's a full blown CMS.

For 3.0 i'd like to see a bigger differentiation between Core and CMS, and more examples on how to build on top off Core using a relational DB model next to it (or Blazor).

[sarahelsaig]

I would avoid the term "Orchard CMS" because a lot of resources use it to refer to "Orchard" aka "Orchard 1", especially in contrast to Orchard Core. Just like how "ASP.NET MVC" is sometimes used to differentiate classic "ASP.NET" from "ASP.NET Core". Calling the core platform "Orchard Core" would make it less distinct from Orchard 1 and make the already less-than-ideal SEO situation even worse. (I mean if you try to look up basic concepts with the "orchard core" keyword Google still returns some Orchard 1 among the top results to this day. I think any branding change should work to reduce this problem to make the product more approachable to newcomers.)

[MikeAlhayek]

Name spaces typically won’t change unless we have a good reason to change them. And if we do, we would provide that info in the release notes. However, it is completely normal to have such a change “if needed” in a major release. There should be 0 breaking change with in minor releases as of 2.0.

I think we had a discussion a while back about naming Orchard, I think we are sticking with OrcharsCore for a long time to come.

[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.
• Workflow - show where workflow has halted - e.g. when workflow is halting on WaitAll Join, it can not be detected

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

[MikeKry]

@hishamco

I have looked on Code Generation extensions. Thanks, it looks good. That could be very useful to be right in CMS.

Ad. creating custom database tables from CMS - It is basically about creating UI for migrations in CMS. I think it would speed up database modeling process for bigger projects.

Right now, when I need to create a table, my process is:

1. create migration file
2. create model
3. write migration code
4. run migration (build + start solution)
5. check database what has been created
6. modify migration (create new step)
7. repeat from step 3 until there are no problems.

If there was an admin UI, I can imagine you would just:

1. create new table in CMS (I think it could be similiar UI as in ContentTypes - parent object + fields + relations)
2. fill with fields
3. save - that would run migration immediately + generate migration code for deployment + generate model class
4. db should be consistent with CMS definition, but you can check anyway

And I am not talking about indexes, which need to be deleted and created from scratch in migrations :) Just a lot of code that could be simplified

[MikeKry]

@Piedone

No, it is not related to deployment module. I get the confusion, as it is similiar functionality, but I am not using deployment module - I have created custom API for importing from csv files. Which is something deployment module could also support, but I had a very specific usecase anyway.

I tried to elaborate more on that here: #15923

[Piedone]

So, are you looking for #14630?

[MikeKry]

@Piedone
Yes, in big picture, that is it. Fow now, I long for making ContentElement.Data and ContentElement.Elements public :) That would make creating custom implementation seamless, but I do not know if it is not architecture breach for OC :)

[MikeKry]

ad. data module - we are working on internal POC, so I will try to share when we finish it

[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.

[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?

[effapp]

1 Admin menu can customize totally.

The Admin Menu is completely customizable already.

Hi @MikeAlhayek ,
I meant the admin menus can customize order, hierarchy and display/hide.

[effapp]

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.

May I ask for an introduction to the technical architecture of "Full Charge App"?

[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

[ns8482e]

Co-authoring, headless/themeless admin apis,light themes and theming module that does not require build

[Piedone]

Please elaborate.

[willnationsdev]

TLDR: support a single set of database tables for all tenants with TenantId indexing/filtering automatically associated with Documents and applied when operating within a non-Default tenant. Plus corresponding updates to session/shell C# APIs to facilitate leveraging of this data as needed.

The biggest pain point for our use of OC has by far been it's database structure and tenant isolation. To the point that we don't have the manpower/resources to even bother doing anything other than manually syncing data / troubleshooting issues as they arise.

My organization seeks to centrally manage data while preserving tenant isolation with respect to content in the UI. Our clients are all people that work within the single organization (so there's only one "account") but who also have diverging roles & managed content across many departments (for which we use OC's tenant system and which our team manages). The manner in which OC splits up all of the tables per tenant, however, causes many problems for us.

• If we create a user in one tenant, they still need to be made in other tenants and/or synchronized.
• Likewise, synchronization is needed if we ever have to make changes to the permissions associated with a given role (but we DO want to allow different roles to be assigned to the same user in different tenants).
• If a user logs in, they are not automatically logged in across all tenants and likewise logged out everywhere should they do so.
• because the data is spread across so many different Document tables, constructing SQL queries that aggregate data from all tenants is exceedingly frustrating (resorting to procedurally generated SQL stored procedures).

When attempting to look up centralized solutions for these problems, all of my research indicated that the recommended approach is stick to full tenant isolation and synchronization processes; however, for our team (and possibly others?), it would be extremely convenient if OC offered a database infrastructure option that enabled everything to be centralized in one set of tables and then rely on indexes & filtering to present the tenant isolation experience.

For example:

• there is only one "tenant" as far as the database tables are concerned (no table prefix).
• all Documents are indexed with a TenantId corresponding to the tenant in which it was created. The Default tenant then represents a top-level or global view of whatever data exists in the system (for SaaS cases) with custom admin UI and/or APIs for managing data across and/or in between all tenants.
• When routing determines that you are within a non-Default tenant, all admin views provide corresponding tenant-filtered views of users/roles/content automatically.
• there is a Default-tenant-only admin interface for managing the addition/removal of existing centralized users across other tenants, that way someone already created in tenant A can be granted access to tenant B. Unless, I suppose, a dev wanted to make all tenants publicly open to all users (in which case, it would just happen automatically rather than the user being denied access).

Optional features which supplemental modules could then build on top of this infrastructure:

• Content definitions outlined in the Default tenant could be displayed as "core" in other tenants with UIs highlighting any differences and providing options to revert changes on an individual basis.
• The default tenant may mark certain content definitions as read-only so that other tenants cannot modify any part of the definition (perhaps also an extend-only setting value so they are only restricted from removing or mutating existing properties/sections).
• Content syndication subscriptions where content lives in the original tenant, but then tenants can form subscriptions to content from other tenants, thereby allowing certain views to showcase content from the current tenant and all subscribed tenants (which, when clicked on, link to the other tenant rather than displaying a local copy of said content). Any changes made to the source content are then immediately visible from other tenants' views of subscribed content.
  • Now that I think about it, this is quite similar to the proposed inter-tenant user access management, if you abstracted users to just documents in general. Might be good if there were a lower-level primitive representing such a relation and then having users built on top of that which this content syndication concept could then leverage.

[Piedone]

I'm not arguing for/against this yet, just FYI some notes:

• The SQL tables are kind of an internal API, and thus using them is unsupported and anything can change at any time. Fetching content from a tenant via the GraphQL (and in certain cases RESTful) web API is the designed API for this.
• You can effectively share user accounts and logins (including auto-logins) across tenants if you externalize logins to an external SSO provider, or an OpenID provider set up on one of the tenants.

[willnationsdev]

The SQL tables are kind of an internal API, and thus using them is unsupported and anything can change at any time. Fetching content from a tenant via the GraphQL (and in certain cases RESTful) web API is the designed API for this.

I would be fine with the SQL tables themselves continuing to be abstracted on the side of those using the framework/CMS, but the API itself is built on assumptions about the segregated nature of the underlying tenants' data, regardless of how they are stored or configured. That's really the crux of the issue for us. There's no real option available to us to fix these underlying structural issues since the only way to truly do it (centrally & globally) would be to fully hijack and manipulate the ISession and IStore interfaces. And even that wouldn't be truly safe given how likely it would be for such invasive changes to silently introduce logical/design errors into core modules' behavior.

You can effectively share user accounts and logins (including auto-logins) across tenants if you externalize logins to an external SSO provider, or an OpenID provider set up on one of the tenants.

This is what we have done, and it satisfies the minimal need, but it has its own issues. For example, just because the username and/or email is shared across tenants doesn't mean that the Id or UserId is shared across tenants, so there are cases where the same person may not be formally recognized as the same individual by the system, depending on what is being compared. In the same vein, even within a single tenant, if you remove the user from the tenant as a functional equivalent to revoking access and then re-add the same user later, it again generates all new ids despite them being the same person (as expected). When what you want is a centralized and persistent system, it's very unintuitive and requires all sorts of extra logic to handle proper synchronization. The maintenance burden for the code would be so large that we just don't even bother; therefore we have to manually do cleanup/maintenance of data over time rather than the system handling things automatically.

[DotCat1985]

I suggest:

• integration with OpenAI API
• SSO authentication using TikTok and LinkedIn
• reduction of number of the projects
• more detailed error logging: sometimes, error logs provide insufficient information, making it difficult to quickly identify issues

[hyzx86]

If you're interested in the same thing, check out chat-ollama
If integrated via the rest api, the cost of change is not that great.

[hyzx86]

I am not sure About TickTok but LinkedIn why not.

@MikeAlhayek Is it possible that TikTok will be taken down in the US? I don't know, is it likely? I heard they're probably working on a special US version of TikTok .

[Piedone]

I think generating full features (especially reliably) is a long way away, but maybe generate Workflows Scripts with some grounding?

BTW is there's a TikTok or LinkedIn auth provider for ASP.NET Core, it should be simple to integrate them from a module, also a community one.

[DotCat1985]

What kind of ChatGPT integration would you like to see, exactly?

Sending prompt commands.

[MikeAlhayek]

@DotCat1985 I don’t think this is something we would had in the framework. However, we have Azure Search integrated already in OC. You can use that to easily integrate using AI models and create ChatGPT. I actually did the same thing in my project

[rikbosch]

Adding JsonSchema (https://json-schema.org/) support to recipe's could help a lot in the manual editing of json recipe files. Maybe add a /schema endpoint to download the json schema from a tenant.

Maybe json schema validation could also be a nice feature to bake into yessql?

Each field / part and content definition can also publish it's own json schema, to make everything more discoverable for other tools.

[Piedone]

We have an open issue for this: #1866

[hyzx86]

Would anyone be interested in recipe execution history?
Includes basic audit information and the ability to re-execute historical recipes.

[sarahelsaig]

That could be very useful, especially when it comes to ad-hoc recipes from the "JSON Import" function. Also if the whole recipe is stored in an Audit Trail entry then re-execute is as simple as sending it over to ImportController.Json as an HTTP POST request.

[effapp]

It would be nice to add the feature of mobile registration

[hishamco]

Please elaborate

[effapp]

1. Input mobile phone in user registration form.
2. Click 'Send SMS verify code' button then send the code to mobile phone.
3. Input the sms verify code received.
4. Submit registration form to register

[hishamco]

I think we already have something similar with email verification, I am not sure if @MikeAlhayek added SMS verification support

[MikeAlhayek]

When enabling two-factor authentication using the SMS provider, we send a verification code. One could add phone number to the registration form and then use event handler to verify the phone number. I think the code in OC may need to be tweaked a little to require phone number confirmation "similar to what we do with email". It's not a bad option to have in the registration module since we already have full support for phone number.

[bashuss]

Improvement of Documentation.
I am still stumbling upon features, which sound like the ones I need, but then it is really hard to find out, what they actually do or how they actually work. Sometimes even though there is an example - just the example is missing the bigger context.

E.g. liquid "shape_add_..." have examples that show how to write the tag properly, but it is really hard to find out how this works inside a full example. So what is a wrapper, a property, an attribute of a shape and under what conditions are they used or show up in rendered html code?

It is too hard (or impossible?) to answer these questions from within the documentation currently. I often end up searching and reading the OC source code - which in case of Liquid features is not always a successful search, as there is only the documentation and the implementation of the feature, but no usage examples to be found.

[Piedone]

If you find any missing pieces in the docs, please contribute: https://docs.orchardcore.net/en/latest/guides/contributing/contributing-documentation/. Contributing docs is perhaps the easiest, and you as somebody who just learned about something are in the best position to tell other newcomers about it.

[bashuss]

In many cases, the problem is, that I still do not know the intended way of things. When finding my way thru things like I do, I often end up with "off-label-use", which is not the best idea for documentation, but maybe good for discussion.

[DanielMPries]

A little late to this thread but there are a couple of things I'd like to see some improvements on

1. Decouple admin views from Bootstrap. While is possible to change the theme of the admin, a theme alone isn't enough. Its tightly coupled to bootstrap via views that are in OrchardCore.Admin, OrchardCore.AdminDashboard and OrchardCore.AdminMenu. Ideally, being able to bring your own design system or use an off the shelf utility/system like Tailwind enables the administration to match the branding should the end user so desire. Or alternatively libraries like OrchardCore.Admin provide support up to the view model; however a new library like OrchardCode.Admin.Views provides the layouts. That enables a variant layout library like OrchardCore.Admin.MaterialViews to share view models but provide its own layout implementation.

2. Provide an integration to Elsa Workflows with Orchard specific activities. I get that there are some shared origins but Elsa really does provide a fantastic set of integrations for various kinds of SaaS workflows as well as journaling of instantiated sagas for auditing purposes. This is particularly useful when support a large system that has content flows as well as something like a payment flow where inventory is checked before payment or the there's a compensation flow to give the customer an opportunity to change state, like cancel a transaction if inventory wont meet the target SLA.

3. Conformance to health checks that match the IETF RFC for healthchecks. With modular registration of dependencies in the checks. This enables a single probe to cascade to dependencies for liveliness and inform when an attached dependency is unavailable. The goal being able to improve MTTR in an outage situation

4. OPA support for Attribute Base Access Control (ABAC Authorization) on content types for more fine grained control beyond Authentication based on complex conditions

[MikeAlhayek]

Decouple admin views from Bootstrap.

This is not an easy ask but should be a goal. I agree that it's hard to replace the TheAdmin theme if needed. I think we should continue to support Bootstrap by default without having to use a different framework. However, it should be much easier for one to change the default. One way I can think of here to make this easier would be to create components and recuse them. There are some advantages of using components (maybe there is more advantages and disadvantages that I am not thinking about too)

• To replace Bootstrap with any other framework, one will only need to override the default components. Still work to be done, but not as much as replacing every single view OC uses.
• We create more reusable code that we can use and allow others to use. For example, we can have media component that we can use in the media field, media part, and any other place one need to inject media into their application "outside of the contents".

I think @sebastienros at some point was against using components. Do you still think we should not entertain the components option? Why?

Can someone share a better idea on how to decouple our views to make overriding the TheAdmin theme easier? @Piedone @Skrypt @deanmarcussen @BenedekFarkas @agriffard @Jetski5822 @ns8482e @MichaelPetrinolis @gvkries @sarahelsaig

[Piedone]

I can't, I think this is infeasible. We either make the default admin theme (and every built-in and third-party module extending the admin) a lot more complex so they don't (directly) depend on Bootstrap, or you'll need to pretty much override every admin template that your site uses. I don't think the first option makes sense to put time into, unless a lot more people come forward with compelling use cases they'd work on right away if this way available, and where the override option (or just cohabitating with Bootstrap) is prohibitive.

Client-side development is not my strong suit though, so I welcome learning about approaches that right now I can't imagine.

[DanielMPries]

Maybe the journey about how I arrived at the suggestion would help. I actually ran through the tutorial last night to create a new admin theme. Got a nice liquid template, added tailwind from the cdn and then loaded the site. I got nothing but a title. So I started looking at the razor views and tried implementing in liquid. Didn't get anywhere. Maybe it's that it's hard to know what to replace. So I looked a what Etch has done. Honestly, it's a ton of work and in that case you're locked into the agency's theme and not the organization your deploying into. So I thought it would be a compelling idea to eject bootstrap in favor of supporting the design systems of the target org. Bootstrap can meet the need but it still felt highly coupled hence the suggestion

[sarahelsaig]

My first thought was that this is a huge uphill battle with third party modules, much like @Piedone said. The presumption of Bootstrap in admin is well entrenched in the OC ecosystem. Also I don't think the admin and front end themes should be locked together. It's better for admin experience that they are clearly distinct to avoid confusion. I can understand changing logos and adjusting colorways via CSS variables to match the organization branding (and that's very doable right now) but I think going much deeper has extreme diminishing returns.

@MikeAlhayek if by components you mean standard web components then I'm all for it. It will have major benefits beyond this topic. Using web components was problematic up until 2022 because Internet Explorer didn't support it, but IE is dead so that's not an issue any more and everything else supports the technology.

[hishamco]

I did some experiments in the past to switch between two UI frameworks, I hope I will show a demo one day

[MikeAlhayek]

For anyone interested in the OrchardCore 3.0 face-to-face discussion, please join us at the Orchard Harvest 2024 conference in Las Vegas! This conference is a unique opportunity to shape the future of the OrchardCore framework. It's a must-attend event for any company using OrchardCore, as your participation can significantly influence the direction of the framework to meet your specific needs. Don't miss this chance to be part of the conversation and drive the momentum forward!

[ns8482e]

Rewrite admin controller logic into domain services on its own feature, and have separate features for api only and integrated ui as its own feature that depends on that domain service

[MikeAlhayek]

You suggest wrapping the controller logic into a service and then creating an API for each corresponding controller action to enable microservice communication. This approach would involve developing a core/service feature within every module that exposes a Minimal API and registers the service. The main feature would then depend on this core feature and register only UI related service like AdminMenu, DisplayDrivers, etc. Correct?

[DanielMPries]

I haven't given the implementation a ton of thought but that sounds like a clean way of accomplishing that effort. I first read this as, "another layer of abstractions and another dependency" but that's kind of the idea, the administration console is an attached dependency that could be optional if abstracted away, replaced with a REPL or a brand consistent administrative UI.

In theory being able to interact with an administrative API surface gives additional automation opportunities as well.

[aboweFIS]

I am new to this and a front-end designer/developer, and as such am finding it very difficult to learn. Your documentation is very thorough but is written for an advanced audience. I would request much more information surrounding theming (since what's the point of a website if you can't design it?), geared towards an audience with less programming background. I imagine there are plenty of teams out there split into front-end/back-end developers that this could be beneficial to.