Centralize the Indexing process, Remove Media files for a removed tenant when using Azure Blob Storage - This week in Orchard (20/06/2025)
This time, you can see a demo about centralizing the Indexing process and having a unified UI for managing Indexes and the Search Settings! But first, let's look at our other topics, like removing Media files for a removed tenant when using Azure Blob Storage, and adding RouteEndpoint cache. Don't forget that you can still fill out our Orchard Core Admin UI experience renewal survey to help shape the future of Orchard Core!
Orchard Core updates
Remove Media files for a removed tenant when using Azure Blob Storage
If you remove a tenant, its Media files are only removed if they use the default local storage in App_Data. When using Azure Blob Storage, though, they remain. To account for this, the existing settings are now extended with an additional flag (RemoveFilesFromBasePath option), which could then determine whether to delete the container or only the files associated with the given base path. You can set up this flag using the appsettings.json file, but you can also use the admin UI.
If you want to store your files in Azure Blob Storage, you must enable the Azure Media Storage feature under Tools -> Features. Here, you can see two new checkboxes called Remove Container and Remove Files From Base Path to control what should happen to the blob container and the media files once you delete a tenant.
Add RouteEndpoint cache
There is a class called DefaultLinkGenerator.cs, which we use in Orchard Core as well when we generate links for a route. It caches the TemplateBinder instances. When the source of an endpoint changes, we reset the cache. It's a ConcurrentDictionary indexed by RouteEndpoint. This means that if the endpoint exists, it returns the TemplateBinder; if it doesn't exist, it will create a new one.
The issue here is that we generate new RouteEndpoint instances every time, and this cache just adds the new RouteEndpoints every time to the collection. This creates a memory leak, meaning we keep adding new RouteEndpoints and TemplateBinders every time we generate a URL. Every time you display a page, the memory grows until there is no free memory anymore, and the application crashes.
The fix is to create a new RouteEndpoint and return that endpoint everywhere we implement the IShellRouteValuesAddressScheme interface. So, instead of creating a new one, we have a local cache of RouteEndpoint references, and we won't create new endpoints every time we want to generate a link; we reuse the same instances every time. And this cache will only grow if you add new routes or pages. We won't double the size; we create one RouteEndpoint for every page you have, which is totally fine. It's also important that we use a custom RouteEndpointKey here to index that thing, which will match based on the route's properties.
Demos
Centralize the Indexing process
This demo is about creating indexes for non-content. How can we store non-content information in Elasticsearch using Orchard for those that won't utilize Orchard to manage other data on top of content items? We also do that today in Azure Search, but we don't have a central place for this. Currently, we have a UI for Azure admin, a UI for Elasticsearch admin, and another UI for Lucene. These search providers have their UI, and someone has to manage those indexes in different UIs. This means we have redundant code, and another issue is the limitation that the indexes are completely tied to content items. This means you can't create an index for data from other places. For example, if you want to pull data from an API, you cannot store that data using what we have today. Taking all these things into account, Mike Alhayek moved all these UIs under one UI, and this UI will allow us to manage all indexes (regardless of the provider) and give us the ability to have index sources that are not content.
We enabled all search providers under Tools -> Features (Azure AI Search, Elasticsearch, Lucene) to demo it. If you navigate to Search -> Indexes, you will see a new UI, which is very similar to what we saw in the past. Now you have the option to add an index. Once you click on the Add Index button, you can select whichever provider you want, along with its type. If the data comes from a custom API, you can add your own custom source and store it in e.x. Lucene and you have the option here.
Select the Content in Lucene provider to create a Lucene index based on the site contents. Here, you have to provide the name of the index, the content types to index, the fields to use for the query, and so on. As you can see, we are listing the fields you can select from. The same goes for Elasticsearch, but in that case, you can use a custom Elasticsearch query that will be utilized for each search request.
The Actions drop-down button near each index provider contains more options. You can run the query from here, trigger the synchronization process, reset, rebuild, or force-delete the index.
Another thing is how we did the search settings on the front end. Once you enable the Search feature, you can go to Settings -> Search -> Site Search, and you can configure the settings. In the past, we had different tabs for each provider, and you had to specify the default query for each provider. So, you had to select an index, and for each index, you had to say I want that behavior to be queried. This has been changed, and from here, you can select whichever index you want to have as a default index.
And that's not all of it! To learn more about the changes around search, watch a recording on YouTube!
News from the community
Orchard Core Admin UI experience renewal survey
At the beginning of this year, we started a discussion about renewing the admin area with the help of a UX professional. We aim to have a modern admin UX that’s functional, convenient, unobtrusive, and something that ordinary contributors can extend by following patterns. The point is to improve the usability of the admin, not just making it prettier (though making it prettier would be nice too). The first step of the admin area renewal is to explore how people use the admin UI of Orchard Core and what their needs look like. Combined with contributor input, this will help us improve usability, guide design decisions, and align with long-term platform goals.
For that, we have conducted a survey. Please take a few minutes to fill out our survey and help shape the future of Orchard Core. Feel free to share it with anyone you know who uses or has used Orchard Core, including colleagues, clients, or contributors you've worked with.
Orchard Dojo Newsletter
Lombiq's Orchard Dojo Newsletter has 452 subscribers! We have started this newsletter to inform the community around Orchard of the latest news about the platform. By subscribing to this newsletter, you will get an e-mail whenever a new post is published to Orchard Dojo, including This week in Orchard of course.
Do you know of other Orchard enthusiasts who would like to read our weekly articles? Tell them to subscribe here!