You have several options to send an HTTP request to an external API in Orchard Core, but maybe you haven't tried the Http Request Task. Let's see quickly how you can hook up a workflow! The HTTP Request Task comes from the HTTP Workflows Activities feature, so before doing anything, don't forget the enable that module. Now navigate to the Workflows option from the menu and hit Create Workflow Type to add your workflow. JSONPlaceholder is a nice fake online REST API that you can use whenever you need some fake data. It comes with a set of 6 common resources and we are going to use the first one and making a GET HTTP request to get 100 user posts in a JSON format. Choose the Add Task button in the Workflow editor and select the HTTP Request one from the HTTP category. Here you can see a nice editor where you can provide the details of your request. We added a custom title to our activity as Get 100 posts. The URL will be the URL provided by the JSONPlaceholder API. To get the posts we have to make a GET request. If you would like to add a new post, make a POST request to the same endpoint, and provide the body to send. Don't forget to handle the 201 HTTP response code, because this will be the number that will show you that you are good to go and the server faked that your content was created. You may notice that you can type Liquid code everywhere in this editor. Let's say that the title of our new post will be the name of our site. To do that, we can pass the {{ Site.SiteName }} Liquid expression. As we mentioned, we get 201 if everything goes well. If the server returned with anything else, then something bad happened and we should handle that in our workflow of course. To handle the failed requests, we can use the Unhandled HTTP Status branch of the HTTP Request Task (we named in Create a new post) and notice the user somehow. OK, it's not a useful workflow, because we are only dealing with the response codes, but not with the response body. But how can we use the response details? To find the answer we have to check the source code of the HTTP Request Task activity and take a look at the ExecutyAsync method. Here you can see that the code uses the LastResult of the workflowContext and the LastResult has a Body property where you can find the response body itself. The LastResult property of the WorkflowExecutionContext is an object, that means you can easily put everything into the LastResult, but it could be a little bit harder to get the content from it. public override async Task<ActivityExecutionResult> ExecuteAsync(WorkflowExecutionContext workflowContext, ActivityContext activityContext) { using (var httpClient = new HttpClient()) { var headersText = await _expressionEvaluator.EvaluateAsync(Headers, workflowContext); var headers = ParseHeaders(headersText); foreach (var header in headers) { httpClient.DefaultRequestHeaders.TryAddWithoutValidation(header.Key, header.Value); } var httpMethod = HttpMethod; var url = await _expressionEvaluator.EvaluateAsync(Url, workflowContext); var request = new HttpRequestMessage(new HttpMethod(httpMethod), url); var postMethods = new[] { HttpMethods.Patch, HttpMethods.Post, HttpMethods.Put }; if (postMethods.Any(x => string.Equals(x, httpMethod, StringComparison.OrdinalIgnoreCase))) { var body = await _expressionEvaluator.EvaluateAsync(Body, workflowContext); var contentType = await _expressionEvaluator.EvaluateAsync(ContentType, workflowContext); request.Content = new StringContent(body, Encoding.UTF8, contentType); } var response = await httpClient.SendAsync(request, HttpCompletionOption.ResponseContentRead); var responseCodes = ParseResponseCodes(HttpResponseCodes); var outcome = responseCodes.FirstOrDefault(x => x == (int)response.StatusCode); workflowContext.LastResult = new { Body = await response.Content.ReadAsStringAsync(), Headers = response.Headers.ToDictionary(x => x.Key), StatusCode = response.StatusCode, ReasonPhrase = response.ReasonPhrase, IsSuccessStatusCode = response.IsSuccessStatusCode }; return Outcomes(outcome != 0 ? outcome.ToString() : "UnhandledHttpStatus"); } } Imagine you are implementing a custom activity that creates content items based on the response body. For that, you need to get the JSON then serialize it to a typed class. That makes the data easier to work with. In the ExecutyAsync method of your custom activity you can get the JSON like: var responseBody = workflowContext.LastResult.GetType().GetProperty("Body").GetValue(workflowContext.LastResult).ToString(); Here the responseBody variable will contain a JSON in a string. You may notice that the value of the title here is Orchard Core, which comes from the {{ Site.SiteName }} Liquid value. To deserialize the response to typed classes you can use the built-in Json.NET package in Orchard Core and for instance, use the JsonConvert.DeserializeObject method of it. And that's it, now do what you want with the data. Did you like this post? It's part of our Orchard Core Nuggets series where we answer common Orchard questions, be it about user-facing features or developer-level issues. Check out the other posts for more such bite-sized Orchard Core tips and let us know if you have another question!

Let's suppose you're building your shiny new Orchard Core website. In there you're also building a shiny new page, with Flow Part obviously. You throw together a lot of widgets to get all the bells and whistles on the page, then you save it and BAM! Internal Server Error: "InvalidDataException: Form value count limit 1024 exceeded." What's this, did I break Orchard? Is Orchard trying to break me? Let's fix this! The exception happens because the structure you've built with Flow Part is simply too large for the default ASP.NET Core limits. This is not something that would be too extreme to achieve, actually: If you have more complex widgets (with a lot of fields each) and you put several of them into a complex nested structure you can quite possibly build something by hand that would fail like this. Ask how I know! You can increase the limits restricting posted form value sizes, and in this particular case you'd need to change the ValueCountLimit value of FormOptions. Put this into the Startup class of your Orchard-based web app project (it won't work in a module or theme!): services.Configure This increased the limit to 4096, plenty more than the default. However, keep in mind that these limits have their uses: Malicious users could try to post large pieces of data to your server, trying to overwhelm it for example. So only increase this as much you only need! Note BTW that we're using the ASP.NET Core configuration API here, something which is also demonstrated in detail in our Training Demo Module, so follow up learning there! Did you like this post? It's part of our Orchard Core Nuggets series where we answer common Orchard questions, be it about user-facing features or developer-level issues. Check out the other posts for more such bite-sized Orchard Core tips and let us know if you have another question!

So you're building a localized Orchard Core site and want all URLs to be in the form of /culture-name/rest/of/the/url, e.g. /hu-HU/my-page. (Figure out what "hu-HU" is! Hint: It's not an owl, neither a rock band from Mongolia!) What do you need to achieve this? Well, we've already seen how to localize content items to achieve this, but that's just for content pages. There is one small piece missing though: How to get the same functionality for controller actions, i.e. coded pages? There is nothing built into Orchard Core for this, actually. And the reason is that all you need is available in ASP.NET Core MVC already. First, you'll need to set up RouteDataRequestCultureProvider so the URL segment indicating the culture will be used to set the culture of the current request. Just add this to your module's or theme's Startup class (if you don't yet know how to build a module, check out our Training Demo!): services.Configure So far so good. Next, you'll need the controller actions you want to be culture-aware to be routed in a way that the culture name is included in the URL: public class CultureAwareController : Controller { [Route("{culture}/culture-aware"] public ActionResult CultureAwareAction() { // Build the result here. } } So now you'll be able to reach this action from under /hu-HU/culture-aware for example. There's one final part missing: Building URLs for these actions. This is quite simple too, you'd e.g. create a link for this action like following: <a asp-action="CultureAwareAction" asp-controller="CultureAware" asp-area="CultureAwareModule" asp-all-route-data="routeParams">Click here</a> That's it! Of course, this can get more complex. You can make route configuration as well as URL generation easier by centralizing this culture parameter handling, which is useful if you have loads of such controllers and links. Did you like this post? It's part of our Orchard Core Nuggets series where we answer common Orchard questions, be it about user-facing features or developer-level issues. Check out the other posts for more such bite-sized Orchard Core tips and let us know if you have another question!

Every website needs a favicon of course and you can easily add one to your Orchard Core site from a theme or module with a link tag in a template. However, there's a catch: Certain browsers will still search for it (as a first attempt) under the path /favicon.ico. This can be a tiny bit detrimental to the client-side performance, and show up as annoying errors in your logs. So what can you do to serve a favicon under that path too? You could do e.g. the following: Add an actual file to your web project's wwwroot folder directly. This will work but you'll most likely have more than one icon for the site, and you'll keep them in a theme. So having two places with icons is less than ideal. Serve the same file that you have in your theme with a middleware or something. Doable but you'd teach the affected browsers that what they're doing is actually acceptable :). Redirect a /favicon.ico request to the actual favicon. This is what we'll do with the code snippet below! Open up your theme's Startup class and add this to its Configure() method (or add the method first if you haven't used it otherwise): public override void Configure(IApplicationBuilder app, IEndpointRouteBuilder routes, IServiceProvider serviceProvider) => app.Map("/favicon.ico", appBuilder => appBuilder.Run(context => { context.Response.Redirect("/My.Theme/favicon.ico", true); return Task.CompletedTask; })); As you can see this simple snippet will listen on the /favicon.ico path and redirect the client to the favicon you have in your theme (in this case we assumed it's in the root of your theme's wwwroot folder but of course it can be in any subfolder). Very simple! Did you like this post? It's part of our Orchard Core Nuggets series where we answer common Orchard questions, be it about user-facing features or developer-level issues. Check out the other posts for more such bite-sized Orchard Core tips and let us know if you have another question!

A common question during Orchard Core development, something that came up again recently, is how to display something within the context of an Orchard page when that piece of data comes from your module? How can you "inject" something into the Orchard layout when you want to display e.g. a list of products retrieved from an external API? There are a couple of ways to do this depending on what exactly you need. All are fairly straightforward so let's see a quick rundown! Creating a whole page from you module If you want a whole page served by just your module then it's really simple: Create a module, add a controller as you'd do in standard ASP.NET Core MVC, make an action produce a view and that's it! The view will be wrapped into the Orchard layout so the theme you've selected will be visible around it: The basic styling will be there, the header and menu, any widgets you have put onto layers... Our Training Demo module has a simple sample exactly for this, just check it out and you'll see what we're talking about. The above screenshot comes from our Open-Source Orchard Core Extensions solution BTW. Creating a widget Widgets (see official docs) are basically little boxes of content or other functionality that you can put anywhere on the site. For example, an infobox about the site, a search box, a recent articles box, a footer can all be widgets. You can use them in two ways: Add a widget to a content item with Flow Part: Flow Part can be used to build flexible layouts out of various widgets, including nesting them (like putting widgets into a Container Widget). When you set up Orchard with the built-in Agency recipe and theme then you'll get a Page content type that has Flow Part out of the box: You can get the same content type from our Helpful Extensions Orchard Core module too. Another option to use widgets is to put them onto a layer, a sort of container of widgets. There you can place the widget into a global zone, an area of the Orchard layout, like the header, footer, or sidebars. The widgets on a layer will be displayed whenever the layer rule of that layer matches (you can think of it as a logic expression producing a boolean value), like on every page except the home page or on every page but only for authenticated visitors. For more info check out the docs. OK, but how can you create a widget? A widget is just a content item whose content type has its stereotype set as "Widget". You can change this value from the admin from under Content / Content Definitions and also from code. So, basically, the task is to create a content part of yours that'll display the data you want to show from its driver, then create a widget content type where that part is attached. Seems like a lot? It isn't, check out the relevant content part development tutorial again from the Training Demo, including creating a widget. Injecting a shape into the layout This can be a lot easier than developing a widget but also less flexible to use. You can also write your own code in a template (like a cshtml Razor file) and inject that into the Orchard layout directly. You can see an example of injecting a shape in the Training Demo module too. Displaying a shape from a Liquid Widget The Liquid Widget is a widget that can render a piece of Liquid markup. While there is such a widget in the Agency theme and you can throw it together from the admin quickly too the Helpful Libraries module has it built-in as well. With this widget and Orchard's pretty advanced Liquid support you can of course just write Liquid directly. However, for more complex apps maintaining templates editable from the admin quickly becomes an issue so we'd recommend keeping code in your modules and themes. The good news is that once you have a piece of Razor code in a cshtml template (or Liquid in a .liquid template) then you can just display it from a Liquid Widget! For example, if you have a WeatherData.cshtml template fetching some weather information from an external API then you can display it from a Liquid Widget, and thus use it just as any widget with this little piece of code: {% shape "WeatherData" %} There's more to it, check out the docs on the shape Liquid tag. Conclusion Pretty much that's it. There are other ways too but these are the most straightforward and most flexible ones. Do you have another technique you'd like others to know? Add below in the comments! Did you like this post? It's part of our Orchard Core Nuggets series where we answer common Orchard questions, be it about user-facing features or developer-level issues. Check out the other posts for more such bite-sized Orchard Core tips and let us know if you have another question!

Build processes of .NET Core apps like Orchard Core are getting quite complex nowadays, and the MSBuild build pipeline also commonly includes steps for building client-side resources or doing a lot of things out of the .NET world. What can you do if something goes off course with all those targets and props files and you're just scratching your head? How to figure out what happens during the build if you can only see that the results are incorrect? When publishing a .NET Core app or running a build directly use the MSBuild switch /bl. This will create a binary log that exposes a lot of the internal info of the build process. You can pass such build parameters to dotnet publish too. Open the binary log with MSBuild Structured Log Viewer. The tool will show you how exactly the build process runs, what the order of the steps is, how long everything takes… You’ll even be able to see the values of all variables! If you want to check out what was actually included in the assembly, including static resources being embedded, then you can use ILSpy to decompile it. It’s also available as a handy Visual Studio extension. Oh, and BTW if you want to add NPM and Gulp operations to the build pipeline check out our open-source NPM MSBuild Targets project! Did you like this post? It's part of our Orchard Core Nuggets series where we answer common Orchard questions, be it about user-facing features or developer-level issues. Check out the other posts for more such bite-sized Orchard Core tips and let us know if you have another question!

Let's imagine you've already created an Orchard Core app and now it's time to show it to the world. How do you publish it, or rather, how do you create its publish package? When publishing an Orchard Core, or any .NET Core app (be it a desktop app for release or deploying a web app) you need to use the dotnet publish command (see its docs). For web apps running on Azure App Service our usual practice is to do a self-contained deployment, see the .NET Core publishing guidelines. A standard publish command for a 32b Windows App service is as following: dotnet publish SolutionName.sln --configuration Release --runtime win10-x86 --output C:\path-to-package-folder --self-contained true For a 64b App Service the runtime would be win10-x64. If you just want to do a quick debug publish then running dotnet publish in the folder of an Orchard-based web app’s solution without any parameters will create a published app in the YourWebApp\bin\Debug\netcoreapp3.1\publish folder. For a PowerShell script that does a publish and then zips up the package see this script in our HipChat to Microsoft Teams Migration Utility. Did you like this post? It's part of our Orchard Core Nuggets series where we answer common Orchard questions, be it about user-facing features or developer-level issues. Check out the other posts for more such bite-sized Orchard Core tips and let us know if you have another question!

So you want to create an Orchard Core website that presents its content in multiple languages. There are many parts of this, but what about content items? How do you make them ready for localization? We'll assume that you have your site already set up. We'll use the Page content type found in e.g. the Agency setup recipe as an example. First, make sure that you've set up available site cultures on the Orchard dashboard. This is under Configuration, Settings, Cultures (or the /Admin/Settings/localization URL). Set up LocalizationPart for content types to be localized as mentioned in the docs. Now comes the hard part: You need content items' URLs to be generated with the culture in it, so something like "en-US/demo". This is so you can have two versions of a content item, in different languages but with the same slug ("demo"). So, edit the settings of the Autoroute part from under the content type's editor under the Content menu on the admin, Content Definition, Content Types. For the Page type it's here: /Admin/ContentTypes/Page/ContentParts/AutoroutePart/Edit. There you need to change the default Autoroute pattern to include the culture's ID. This you can do by accessing the culture set in LocalizationPart, so the whole pattern will be something like this: {{ Model.ContentItem.Content.LocalizationPart.Culture }}/{{ Model.ContentItem | display_text | slugify }}. That's pretty much it. Now when you create a new Page you'll be able to tell Orchard which culture it belongs to and the URL will automatically reflect that. This is of course not the complete localization story. You'll also need to display the culture options to the user which you can do with the ContentCulturePicker shape as explained here. Other UI labels coming from code need to be localized too with PO files, as you can read about in the docs too. Have fun with your multi-language sites! We also have a follow-up post on how to add a culture URL segment for non-content pages. Did you like this post? It's part of our Orchard Core Nuggets series where we answer common Orchard questions, be it about user-facing features or developer-level issues. Check out the other posts for more such bite-sized Orchard Core tips and let us know if you have another question!

Try to reference the OrchardCore.Application.Cms.Core.Targets NuGet package instead of the OrchardCore.Application.Cms.Targets in your ASP.NET Core web application, that will only add the TheAdmin theme to your solution. Orchard Core has many built-in themes that can be useful, for instance, if you are searching for a way about how to override your templates using Liquid or Razor. By checking the code of these templates you can see the different custom Liquid helpers and Razor tag helpers in action. But if you would like to deploy your application it could be unnecessary to add these themes to your solution. The Getting started with Orchard Core as a NuGet package page of the Orchard Core documentation mentioned to reference the OrchardCore.Application.Cms.Targets package. However, if you reference the OrchardCore.Application.Cms.Core.Targets you can modify your Startup.cs file the same way, but when you set up your application, you will only be able to use the Blank site recipe, that allows you to set up your site with additional pre-configured options, features, and settings out of the box. Head to the bottom of the content of the OrchardCore.Application.Cms.Core.Targets.csproj file, where you can see that only the TheAdmin theme is referenced. And the only difference is that the OrchardCore.Application.Cms.Targets referencing the themes also among with the OrchardCore.Application.Cms.Core.Targets project. This way you would get a smaller solution without the themes and have a smaller and faster-deployed app to your server with the complete CMS functionality! Did you like this post? It's part of our Orchard Core Nuggets series where we answer common Orchard questions, be it about user-facing features or developer-level issues. Check out the other posts for more such bite-sized Orchard Core tips and let us know if you have another question!

You have your own ASP.NET Core project that using Orchard Core NuGet packages, but every time when you update them you have to do it one-by-one across the whole solution? Wouldn't it be easier to just update the package versions in one place? Then you may need to have a Directory.Build.targets file to define the versions! MSBuild projects that use the standard build process (importing Microsoft.Common.props and Microsoft.Common.targets) have several extensibility hooks that you can use to customize your build process. Directory.Build.targets is imported from Microsoft.Common.targets after importing .targets files from NuGet packages. So, it can override properties and targets defined in most of the build logic, but sometimes you may need to customize the project file after the final import. Without going into too much detail, Directory.Build.targets can be used to provide customizations to project files located under a certain directory, this means that if you create such a file at the root of your solution, it would normally be able to customize all the .csproj files in your solution as they would exist in the child directories. Let's see a small example! Imagine you have an ASP.NET Core web application with a MyAwesomeWebApp.Web.csproj file. If you referenced Orchard Core in this project, your file contains a similar section: <ItemGroup> <PackageReference Include="OrchardCore.Logging.NLog" Version="1.0.0-rc1-10106" /> <PackageReference Include="OrchardCore.Application.Cms.Targets" Version="1.0.0-rc1-10106" /></ItemGroup> I assume you also have some custom modules and themes in your solution. The .csproj file of your module (MyAwesomeModule.csproj) could contain a section like: <ItemGroup> <PackageReference Include="OrchardCore.ResourceManagement" Version="1.0.0-rc1-10106" /> <PackageReference Include="OrchardCore.DisplayManagement" Version="1.0.0-rc1-10106" /> <PackageReference Include="OrchardCore.Module.Targets" Version="1.0.0-rc1-10106" /></ItemGroup> where the OrchardCore.Module.Targets is mandatory if it is a module. Imagine that your theme (MyAwesomeTheme.csproj of course) has the following: <ItemGroup> <PackageReference Include="OrchardCore.Theme.Targets" Version="1.0.0-rc1-10106" /> <PackageReference Include="OrchardCore.DisplayManagement" Version="1.0.0-rc1-10106" /> <PackageReference Include="OrchardCore.ResourceManagement" Version="1.0.0-rc1-10106" /></ItemGroup> You can see that we referenced OrchardCore.DisplayManagement and OrchardCore.ResourceManagement packages multiple times. If there will be a new release of Orchard Core we have to make sure that we use the same versions of every package across the whole solution. And if we have several projects we have to change the version numbers in every project one by one. To solve this issue add a Directory.Build.targets file at the root of your solution. We set the version in this file and specify how each <PackageReference /> should be updated by MSBuild. Note that here we have to use Update instead of Include. <?xml version="1.0" encoding="utf-8"?><Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <ItemGroup> <!-- Implicit Package References --> <PackageReference Update="OrchardCore.Application.Cms.Targets" Version="1.0.0-rc1-10106" /> <PackageReference Update="OrchardCore.DisplayManagement" Version="1.0.0-rc1-10106" /> <PackageReference Update="OrchardCore.Logging.NLog" Version="1.0.0-rc1-10106" /> <PackageReference Update="OrchardCore.Module.Targets" Version="1.0.0-rc1-10106" /> <PackageReference Update="OrchardCore.ResourceManagement" Version="1.0.0-rc1-10106" /> <PackageReference Update="OrchardCore.Theme.Targets" Version="1.0.0-rc1-10106" /> </ItemGroup></Project> Now let's rewrite the content of all the .csproj files and see the result of the MyAwesomeTheme.csproj for an example! The Include attribute specifies the package ID and the Version attribute specifies the version of the package to restore. But as you can see here the only change we did is to remove the Version attribute. <ItemGroup> <PackageReference Include="OrchardCore.Theme.Targets" /> <PackageReference Include="OrchardCore.DisplayManagement" /> <PackageReference Include="OrchardCore.ResourceManagement" /></ItemGroup> Now nothing will stop you from easily update the Orchard Core NuGet packages of your ASP.NET Core website! Did you like this post? It's part of our Orchard Core Nuggets series where we answer common Orchard questions, be it about user-facing features or developer-level issues. Check out the other posts for more such bite-sized Orchard Core tips and let us know if you have another question!