Our blog contains the activity stream of Orchard Dojo: general news, new resources or tutorials are announced here.

Orchard Harvest 2026 Early Bird tickets, exploring Orchard Core's Next-Gen Visual Layout Editor Feature - This week in Orchard (05/06/2026)

Explore a powerful new module for Orchard Core by Nick Jackson that lets you visually organize content type editor fields and parts into tabs, cards, and columns via an intuitive drag-and-drop interface, with zero coding or placement.json editing required!

Did you know that with just a few configuration tweaks and a single project reference, you can extend Orchard Core CMS with your very own custom module that is fully integrated into the admin UI and discoverable at runtime? Check out this brand-new guide by Manuel Tamayo Montero!

We're excited to open registration for Orchard Harvest 2026! Secure your spot today for the early bird pricing and get ready to level up your skills!

Latest tutorials

Featured tags

AI
IIS
SMS
MCP
API
SEO
All tags >

Writing an Orchard Owin middleware

So you heard about how fancy Owin is, with all of its loosely-coupled thingies? Well, it's now in Orchard: as you may have heard on this week's Community Meeting, you can now write Owin Middlewares in the Orchard-y way. Let's see how! We won't discuss how Owin works or what a middleware is, so if you don't know these yet, check out the linked meeting video. Also, make sure to grab the latest source from the 1.x branch of Orchard's repository because only the upcoming 1.9 version will have Owin support. First you'll need to get familiar with the IOwinMiddlewareProvider interface. Middleware providers are injected services that return a collection of OwinMiddlewareRegistration objects. The latter ones contain the actual middlewares, i.e. those delegates that will run when the Owin pipeline is executed. This all is where the magic happens: you need to implement IOwinMiddlewareProvider and inside your implementation create OwinMiddlewareRegistration instances. See the following example: public class OwinMiddleware : IOwinMiddlewareProvider { // Mostly you'll only need the WCA, see below why. private readonly IWorkContextAccessor _wca; // Or use Work<T> injections, also see below for the explanation. private readonly Work<ISiteService> _siteServiceWork; public ILogger Logger { get; set; } public OwinMiddleware( IWorkContextAccessor wca, Work<ISiteService> siteServiceWork) { _wca = wca; _siteServiceWork = siteServiceWork; Logger = NullLogger.Instance; } public IEnumerable<OwinMiddlewareRegistration> GetOwinMiddlewares() { return new[] { // Although we only construct a single OwinMiddlewareRegistration here, you could return multiple ones of course. new OwinMiddlewareRegistration { // The priority value decides the order of OwinMiddlewareRegistrations. I.e. "0" will run before "10", but registrations // without a priority value will run before the ones that have it set. // Note that this priority notation is the same as the one for shape placement (so you can e.g. use ":before"). Priority = "50", // This is the delegate that sets up middlewares. Configure = app => // This delegate is the actual middleware. // Make sure to add using Owin; otherwise you won't get why the following line won't compile. // The context is the Owin context, something similar to HttpContext; the next delegate is the next middleware // in the pipeline. // Note that you could write multiple configuration steps here, not just this one. app.Use(async (context, next) => { // Note that although your IOwinMiddlewareProvider behaves like an ordinay Orchard dependency, the middleware // delegate lives on its own and will run detached from the provider! Because of this you'll need to either // access the Work Context as we do here, or inject your dependencies as Work<TDependency> objects. If you // build multiple middlewares with many dependencies here, doing the following is a better choice. var workContext = _wca.GetContext(); // But this would be an alternative: var siteSettings = _siteServiceWork.Value.GetSiteSettings(); var clock = workContext.Resolve<IClock>(); var requestStart = clock.UtcNow; // We let the next middleware run, but this is not mandatory: if this middleware would return a cached page // for example then we could just leave this out. await next.Invoke(); // Think twice when wrapping this call into a try-catch: here you'd catch all exceptions that would normally // result in a 404 or an 503, so it's maybe better to always let them bubble up. But keep in mind that any // uncaught exception here in your code will result in a YSOD. var requestDuration = clock.UtcNow - requestStart; // No need to use the ugly HttpContext, because we have OwinContext! var url = context.Request.Uri; // OK, but what if we _really_ need something from HttpContext? if (context.Environment.ContainsKey("System.Web.HttpContextBase")) // This is Orchard, so should be true... { var httpContext = context.Environment["System.Web.HttpContextBase"] as System.Web.HttpContextBase; if (httpContext != null) { // Voilá, we have the ugly HttpContext again! Like RouteData: var routeDataValues = httpContext.Request.RequestContext.RouteData.Values; // ...you know what to do. } } Logger.Information("The request to " + url + " on the site " + siteSettings.SiteName + " had taken " + requestDuration + "time."); // You see, we've done something useful! }) } }; } } Oh, and you'll see inline documentation for all the Owin interfaces :-). Also this sample will be part of the Training Demo module. Happy Owin'!

Forum favourites: records, database indices and about the necessity of drivers

Forum topics from the Orchard discussion board that we found interesting: "Record persisting advices": checklist if you want to store something in a low-level (non-content part) record "Adding empty part to type fails": always create a driver for your part "Records only in Models namespace: good?": remember to put your records under the Models namespace "Indices with SchemaBuilder": you can add database indices from migrations, but only from AlterTable

Forum favourites: model editors with shapes, accessing a shape's generated html and accessing content fields programmatically

Forum topics from the Orchard discussion board that we found interesting: "Passing my own data types to a view": using form field html helpers with dynamic models and in alternates defined with the shape attribute "Dynamically built html with Clay": capturing the generated html coming from a shape "How to access fields of a content item again?": ways of accessing a content field's value by using dynamic or statically typed extension methods

A small Orchard API reference: Orchard Cheatsheet

The Orchard Cheatsheet is a nice little API reference for some lesser known objects, made by Orchard's lead developer, Sebastien Ros. The cheatsheet's list only contains elements of the API that are accessible from (sometimes very specific) shape templates (well, ExtensionDescriptor seems to be an exception), but e.g. WorkContext is something you definitely encounter elsewhere too.

Orchard extensibility explained - aka why Orchard's flexible content model rocks

Bertrand Le Roy's not-so-recent article "Orchard Extensibility" in MSDN Magazine explains the various aspects of - surprise - extending Orchard. The article mainly covers Orchard's content model, its concepts and flexibility: something we all love in Orchard. Bertrand also lists some other important parts of the Orchard API, all worth knowing.

"Writing an Orchard Webshop Module from scratch" module development tutorial

"Writing an Orchard Webshop Module from scratch" is an excellent, 11-part (planned for 15) tutorial on Orchard module development by Sipke Schoorstra. Everyone who has ever written at least a short tutorial will feel what amount of work such a series contains: not surprisingly it's well worth reading, even for ones already somewhat familiar with Orchard module development.