Blog posts by Johan Björnfot

Blog posts by Johan Björnfot2023-08-31T12:54:35.0000000Zhttps://world.optimizely.com/blogs/Johan-Bjornfot/ Optimizely World Parallel Tasks and BackgroundContextWe have recently (CMS.Core 12.16.0) made a change to better support asynchronous async/await execution flows as well as isolation of service resolving from IOC container in parallel contexts. This change can affect code that spawns up multiple parallel tasks. Such code might face errors like “Cannot create a command without an existing connection” or “The connection is closed”. The reason for this is that to support asynchronous async/await execution is the database context “flowed” together with the other execution context. But as for async/await flows are the execution context also preserved through for example Task.Run or Task.Factory.StartNew calls. This has the consequence that if new tasks are created in parallel then multiple simultaneous tasks will share the same database context, which might cause problem since the database context is not thread-safe. This can for example lead to the exceptions mentioned earlier. <h2>BackgroundContext</h2> To support the scenarios where new tasks/threads are spawned up in parallel we have introduced a service IBackgroundContextFactory (it was introduced in CMS.Core.12.16.0 but there is bug that has been resolved in CMS.Core.12.17.1 so that version or later is recommended). It has a single method like: <code></code> <pre class="language-csharp"><code> /// <summary> /// Used to create a new context that has its own scope for services and request caches. /// Recommended to use for background task/threads /// </summary> public interface IBackgroundContextFactory { /// <summary> /// Creates a new context that has its own scope for services and request caches. /// </summary> /// <returns>A disposable context.</returns> IBackgroundContext Create(); } </code></pre> <code></code><code></code> The created context will contain an isolated context for the execution meaning it will have an own scoped IServiceProvider (that will be disposed when the context is disposed) and an isolated execution context (including database context). The execution within this background context also supports asynchronous async/await execution. The scoped service provider will also ensure the services are preserved as long as the context. This protected from things like ObjectDisposedException which you prior to this could get if you created a parallel task within a http request (like an event handler to for example IContentEvents that starts a background task). Reason for the ObjectDisposedException is that the task will use the scoped container from the http request and then if the http request ends before the background task then you might get ObjectDisposedException. <h2>Recommended usage</h2> If you have code that spawn up new tasks/threads (like for example Task.Run, Task.Factory.StartNew, Task.WhenAll, Parallel.ForEach or unawaited tasks), then if the code to be executed in the task is accessing other services, then the recommendation is to create a background context for the thread. So, say for example you have code like: <pre class="language-csharp"><code> var tasks = new List<Task>(); foreach (var thing in things) { tasks.Add(Task.Run(() => { //Some code that run in parallel })); } Task.WaitAll(tasks.ToArray()); </code></pre> Then the suggestion would be to change it to: <pre class="language-csharp"><code> var tasks = new List<Task>(); foreach (var thing in things) { tasks.Add(Task.Run(() => { using (var backgroundContext = _backgroundContextFactory.Create()) //below is example on how to get a scoped service //ServiceLocator.Current and Injected<> also works with background context (even if usage of those are not recommended as best practice) var isolatedScopedService = backgroundContext.Service.Get<IAScopedService>(); //Some code that run in parallel })); } Task.WaitAll(tasks.ToArray()); </code></pre> So the recommendation is that the first statement within the task/thread should be to create a background context for the task to execute within. Note that you do not need to (and should not) create a new background context within an “normal” async/await execution flow (that is when you are awaiting the tasks and not executing them in parallel). Because in that case is there only one thread executing simultaneously and, in that case, you do want the execution context (including database context) to flow between the potential different threads that are part of the asynchronous async/await execution flow.2023-08-31T12:54:35.0000000Z

Blog post

Upgrade to CMS 12, usage of upgrade-assistant-extensionsAs you might now, there is an upgrade-assistant tool that can help the migration from an ASPNET project to an ASPNET core project, see <a href="https://dotnet.microsoft.com/en-us/platform/upgrade-assistant">upgrade-assistant</a> with <a href="https://github.com/dotnet/upgrade-assistant">source</a>. The tool will convert ASPNET projects to new .csproj style, change target framework and update packages. It then also contains some Roslyn analyzers and code fixers that changes some common code (like changing namespaces containing System.Web or replacing code like HttpContext.Current). There is also an optimizely extension <a href="https://github.com/episerver/upgrade-assistant-extensions/tree/main/src/EpiSourceUpdater">EPiSourceUpdater</a> to the upgrade-assistant tool that includes code analyzers/codefixers that are specific to CMS/Commerce projects. The extension is being continuolsy updated so make sure you download the latest package from the <a href="https://github.com/episerver/upgrade-assistant-extensions/releases">Relase section</a>. <h2>Targeting net5</h2> We are currently working on net6 support for CMS and Commerce but until that is released the upgrade need to target net5. The upgrade-assistant tool itself has been upgraded to net6 and that is what is used if you install the tool using dotnet cli. It seems that some of the built-in code analyzers/fixes will not apply if the project being upgraded is targeting net5, so my recommendation (until CMS support net6) is to instead of installing the upgrade-assistant tool, clone the <a href="https://github.com/dotnet/upgrade-assistant">upgrade-assistant</a> repo and build it locally. The CLI tool is targeting both net5 and net6 so you can then run the executable from the net5 output folder.  <h3>Step 1</h3> Clone the upgrade-assistant repo and build it as described <a href="https://github.com/dotnet/upgrade-assistant/blob/main/CONTRIBUTING.md#get-and-build-source-code">here</a> <h3>Step 2</h3> Download latest CMS/Commerce extension package from <a href="https://github.com/episerver/upgrade-assistant-extensions/releases">here</a> and unzip it to some location.  <h3>Step 3</h3> Open a cmd prompt and navigate to the output location of the cli build from step 1. Typically, <checkout location>\artifacts\bin\Microsoft.DotNet.UpgradeAssistant.Cli\Debug\net5.0 <h3>Step 4</h3> To specify that the project you are upgrading should target net5 you need to run the following in the command prompt <pre class="language-csharp"><code>set DefaultTargetFrameworks__LTS=net5.0</code></pre> <h3>Step 5</h3> Now you can execute the upgrade-assistant tool from the command prompt like: <pre class="language-csharp"><code>Microsoft.DotNet.UpgradeAssistant.Cli upgrade <path_to_your_project_to_update> --extension <path_to_unzipped_cms_extension> --target-tfm-support LTS --ignore-unsupported-features</code></pre> <h2>Expectations</h2> You should not expect an fully converted project after the conversion. But the tool should convert many "standard" things so you can concentrate on the code parts that are specific to your project. A good start after the conversion of the tool is to review the .csproj file and see what packages that are referenced there. If you open the project in Visual Studio and expand the node 'Dependencies' under the project then Visual Stuido will display warnings for dependencies that are not compatible with net5. Then you need to review the packages one by one to figure out if there is a corresponding package that is net5 compatible. If there is then you update the dependency, if not then you can temporarly remove (for example outcomment in .csproj) the dependency. Then after all dependecies are resolvable you can compile the project to find the errors. Then there will likley be an iterative process of fixing errors and compiling. But hopefully since you have run the tool many of the "standard" errors you would have seen if you would not have run the tool is fixed and the remaining ones are specific to your project.  Happy upgrading!2022-01-20T10:47:33.0000000Z

Blog post

A smarter output cacheDuring Ascend I saw on Linus Ekströms whishlist for better CDN support that he would like to be able to get a list of all content items that are part of a pages rendered output. I then recalled that I had done something in a related area before, see <a href="https://github.com/jbearfoot/HtmlCache">Russian doll caching</a>. So now when we had a hackday I decided to see if I could build something that would fulfil Linus wish. So I took some inspiration from my previous work and created a context ContentRenderingTrackerContext that stores information about all content items that are used during rendering of a request. It also keeps track if something on the rendering is personalized (ContentArea or XHtmlString). I then intercepted some components in CMS like PropertyRenderer (used by PropertyFor) to collect data in the context. This component is available in project <a href="https://github.com/jbearfoot/ContentRenderingTracker/tree/master/ContentRenderingTracker">ContentRenderingTracker.</a> <h2>Smarter output cache</h2> Then to test my tracker component I decided to create a ContentAwareOutputCacheAttribute. It works a bit as the built-in attribute ContentOutputCacheAttribute but it is a little smarter. So for example when a content item is changed will it only invalidates the output cache for those pages that actually has used the changed content item, compared to the built-in who invalidates the output cache for all pages (since it does not know where the content item is used). The new attribute also uses the knowledge about usage of personalized content from the context and will not output cache pages that has personalized content (meaning the attribute can be used on all controllers and it will take care of if it should output cache or not due to personalized content usage). The attribute is available in project <a href="https://github.com/jbearfoot/ContentRenderingTracker/tree/master/ContentAwareOutputCache">ContentAwareOutputCache</a>. <h2>Output cache in Redis</h2> The output cache attribute worked nice but it still requires that the page is rendered once (on that specific instance) before it gets output cached. I therefore decided to write a mvc filter that works in a similar way as the ContentAwareOutputCacheAttribute but with the difference that it caches the rendered page in Redis instead. The nice thing with this is that it also adresses the cold-start scenario (for example when a new instance of the web application is spun up due to scaling out). In that case can a new empty instance directly utilize the output cache without the need to do an initial rendering. That implementation is available in project <a href="https://github.com/jbearfoot/ContentRenderingTracker/tree/master/RedisOutputCache">RedisOutputCache</a> I also added two versions of alloy, one that uses the attribute and one that uses the Redis caching. All code is available in repository <a href="https://github.com/jbearfoot/ContentRenderingTracker">ContentRenderingTracker.</a> <h3>Disclaimer</h3> This is nothing offically supported by EPiServer, you are free to use it as you like at your own risk.2019-11-07T20:22:14.0000000Z

Blog post

Disable Visitor Group personalization<!DOCTYPE html> <html> <head> </head> <body> In EPiServer.CMS.Core.11.8.0 we released a feature (that is somewhat related to GDPR) which is the ability to turn of Visitor Group Personalization for all/some requests. We have not changed the default behavior which is that Visitor Group personalization is enabled but made it possible to control it by registering a component implementing IPersonalizationEvaluator in IOC container. The interface has a single method and looks like: <pre class="language-csharp"><code>/// <summary> /// Signature for a component that determine if personalization should be performed or not for the current request /// </summary> /// <remarks> /// Registration of an implementation is done by register the implemenation in IOC container /// </remarks> public interface IPersonalizationEvaluator { /// <summary> /// Determines if current request should be personalized or not /// </summary> bool Personalize(); }</code></pre> There is an builtin implementation for "Do Not Track" header that can be registered. One thing to be aware of for custom implementations is that the implementation is likely to be called once for all request (we cache the request so it is only done once for each request) so any implementation should preferably be fast since it will affect the time on all requests. Read more at <a href="/link/220cccce746a4e7b962f0593e0f259e2.aspx">Disable visitor group personalization</a>   </body> </html>2018-06-01T13:22:44.0000000Z

Blog post

IContentSaveValidate - validation with context<!DOCTYPE html> <html> <head> </head> <body> This time I thought I should share a tip about a component IContentSaveValidate<TContent> that we added a while ago but that perhaps not all are aware of.  In CMS 7 we added the EPiServer.Validation.IValidate<T> interface, which has a signature like: <pre class="language-csharp"><code> /// <summary> /// Defines the signature for a component that validates instances of <typeparamref name="T"/>. /// </summary> /// <typeparam name="T"></typeparam> public interface IValidate<T> : IValidate { /// <summary> /// Validates the specified instance. /// </summary> /// <param name="instance">The instance.</param> /// <returns></returns> IEnumerable<ValidationError> Validate(T instance); }</code></pre> The idea with the interface was to make it possible to extend the validation possibilities offered by validation attributes. So when calling IValidationService.Validate for an item then will the service first locate all registered validators that has a generic type parameter T which the item can be assigned to and then call validate on them. So say for example that we are validating an instance of StandardPage then would validators implementing IValidate<StandardPage>, IValidate<PageData> and IValidate<IContent> be called but not a validator implementing IValidate<IContentMedia>. The IValidate<T> interface does not have any type constraint but it is most commonly used during save of content instances. However there might be cases where you want to do the validation only for certain state transitions, for example when the content is published. With IValidate<T> it is not possible to distinguish which state transition it is (if any). Therefore we introduced the more specialized interface IContentSaveValidate<TContent> that looks like: <pre class="language-csharp"><code>public interface IContentSaveValidate<TContent> : IContextValidate<TContent, ContentSaveValidationContext> where TContent : IContentData { /// <summary> /// Validates the specified instance given specified context /// </summary> /// <param name="instance">The instance that is validate</param> /// <param name="context">The context for the validation</param> /// <returns>A list of validation errors or empty list if instance is valid</returns> IEnumerable<ValidationError> Validate(TContent instance, ContentSaveValidationContext context); }</code></pre> Now in addition to the content item to validate you also get a context where you can get the state transtion from. Below is an example of an implementation that only validates when a StandardPage is published. <pre class="language-csharp"><code> [ServiceConfiguration(IncludeServiceAccessor = false)] public class StandarPagePublishedValidator : IContentSaveValidate<StandardPage> { private readonly IStatusTransitionEvaluator _statusTransitionEvaluator; public StandarPagePublishedValidator(IStatusTransitionEvaluator statusTransitionEvaluator) { _statusTransitionEvaluator = statusTransitionEvaluator; } public IEnumerable<ValidationError> Validate(StandardPage instance, ContentSaveValidationContext context) { var transition = _statusTransitionEvaluator.Evaluate(instance, context.SaveAction); if (transition.NextStatus == VersionStatus.Published) { //do validation for publish here } return Enumerable.Empty<ValidationError>(); } }</code></pre> </body> </html>2018-05-22T14:58:57.0000000Z

Blog post

IObjectInstanceCache.ReadThrough<!DOCTYPE html> <html> <head> </head> <body> I thought I should share a small tip about a feature that we use internally but that perhaps not all are aware of that it exists. It is probably nothing you will use everyday but it can be really handy if you have "expensive" outbound calls to e.g. the database or a Web API. That is the extension method <a href="/link/55fe410f4f65482cab72fb59d47c7561.aspx?documentId=cms/10/A030FFCA">ReadThrough </a>on interface IObjectInstanceCache.  The signature look like (there are some overloads for example to specify CacheEvictionPolicy) <pre class="language-csharp"><code>public static T ReadThrough<T>( this IObjectInstanceCache cache, string key, Func<T> readValue, ReadStrategy readStrategy ) where T : class</code></pre> The generic type parameter T is the expected type of the item to read/cache. The parameter key is the cachekey for the item. readValue parameter is a delegate that will be called to load the item (and putting it in cache) when it does not exist in cache. Now the interesting parameter here is the readStrategy. That is an enum that can have two values Immediate which will call the readValue delegate immediately to load the item in case it is not present in cache. The other readStrategy option is Wait.  A strategy Wait means that when the first request comes in and find that the item queried for is not present in cache then it will put a marker in cache and then call the readValue delegate to load the item. Now if a second request comes in and asks for the same item before the first readValue delegate has finished then the cache will notice that there is a marker for that item (meaning it is being loaded) and then the readValue delegate will not be called for the second request. Instead will it be put to wait for the first request to finish and then it gets the result from the first request. So by using Wait strategy you can avoid that several threads simultaneously makes the same expensive call. Instead one call is made and the result is then shared. So if you have some code where you expect that several parallell request might hit at the same time then this could be useful. A typical such location could be resources loaded from startpage, menus etc that could be hit simultaneously by several threads when site is restarted (and hence the cache is empty). </body> </html>2018-05-11T08:40:58.0000000Z

Blog post

Extended routing for Episerver Content Delivery API<!DOCTYPE html> <html> <head> </head> <body> Episerver Content Delivery API delivers content through Urls like: <a href="http://<your-site-url>/api/episerver/v1.0/site/">http://<your-site-url>/api/episerver/v1.0/content/</a><contentReference>. During my hackday I thought I should extend the CMS routing so that it is possible to use the same "Friendly URLs" as in CMS. My idea was to hook into the CMS routing and after a content has been routed look at the Accept header and in case it was "application/json" rewrite the request to the Web API controller in EPiServer Content Delivery.  So I did not want to do any Json serialization but rely on Content Delivery API for that (same with access checks) and I did not want todo a redirect but stay on the friendly url. It turned out to work quite straightforward. I found a small issue in CMS (which I reported an bug for) that made it a bit more complicated than it should have needed to be, but it was quite easy to workaround. The result looks like this for an alloy site when applying Accept header: <img src="/link/fe0ac111694349838473e8be4af16c5a.aspx" width="1034" alt="Image Content_Json.PNG" height="309" /> One thing that often is a problem with REST is that you often gets huge Json responses even if you are only interested in some property. A nice solution to that problem is Graph QL, for this hackday though I did not have time to look into adding Graph QL support (perhaps a topic for next hackday). What I did instead was adding a partial router that routes to individual properties for content and then I added an action filter to the WebAPI where I filter the Json result to the routed property. So then it is possible to do requests for individual properties like below where Name and MainContentArea are properties on the content item with url http://localhost:63139/en/alloy-track: <img src="/link/7f82e08d4d204f63b0aa24ba4253c4f1.aspx" width="354" alt="Image NameJson.PNG" height="149" /> <img src="/link/2c83188b5e3546e2a23974022c5d519d.aspx" width="973" alt="Image PropertyJson.PNG" height="247" /> The code is available at <a href="https://github.com/jbearfoot/ContentDeliveryExtendedRouting">https://github.com/jbearfoot/ContentDeliveryExtendedRouting</a> (there is also a nuget package there that you can install). The module does not need any configuration or setup of either CMS or ContentDelivery its just reference it and it should just work. Disclaimer: This is nothing offically supported by EPiServer, you are free to use it as you like at your own risk. </body> </html>2018-05-03T13:09:33.0000000Z

Blog post

Russian doll caching - lightning fast rendering<!DOCTYPE html> <html> <head> </head> <body> I spent a hackday with looking at implementing a russian doll based html cache for CMS. I think the result was so interesting so I thought I should share it. I will describe russian doll caching more later but in short the idea is to cache chunks of already rendered html. It is a fairly long post but I hope you will find it worth reading, it offers a huge performance boost! A specific usecase I had in mind was large sites where the rendering is dependent on a lot of content items. One such example could be a commerce site where the start page could contain several product listings and menus which require a lot of content items to be rendered. Such sites is very dependent on the content cache to perform well. That means that when a new instance of the application is started (for example due to autoscale in Azure) it must first load up alot of content items in cache before it perform well. <h2>Russian Doll caching</h2> The idea with russian doll caching is to cache items in several layers where each layer has a dependency on next layer, it is used for example in <a href="http://edgeguides.rubyonrails.org/caching_with_rails.html#russian-doll-caching">Ruby on Rails</a>. As an example we can look at the Content area rendered in picture below. The output of the content area as a whole will be cached at layer 1. The output of each item in the content area will then be cached at layer 2 and then individual properties for a content item will be cached in layer 3. <img src="/link/d9c091f54a3746d393654eb645a9508b.aspx" width="792" alt="Image HtmlLayers.png" height="660" /> There will be quite alot of redundance with meaning a specific html element might be cached several times in different layers however there are some good benefits with this. The first is that since layers are dependent on next layer then cache evictions can be propagated quite nicely. If we take the content area as an example then if a content item in an area is changed then the html for that specific item is evicted and then that is propagated to next layer meaning the html for the content area as a whole is evicted as well. The next nice thing with this caching teqnique is if we take the content area again as example. When one item is changed the output for that item and the content area as whole gets evicted however the output for all other items in the content area are still valid. That means that the next time the area is to be rendered it only needs to render that specific item and then put together that output with the other already cached items to render the area as whole. <h2>Distributed cache</h2> Altough it is possible to use this caching technique with an in-process cache I think it is much better suited for an out of process distributed cache. One reason is that the caching will likely contain quite alot of large html strings that will fill up the memory but also for the usecase above. In that case when a new instance of the site is spinned up it can serve html chuncks fetched from cache without having to fill up the object cache with alot of content items. Probably those large sites could run with much less RAM as well due to that. So I have looked at Redis for this. One common way to use Redis is to use it as a distributed object cache. The usecase above could probably be helped with a distributed content cache. In my case I however use Redis as a cache for Html. Then the cost for serializing/deserializing can be avoided and it also makes it possible to cache at a much higher level than with a distributed object cache.  <h2>IHtmlCache</h2> I have created an interface IHtmlCache that can be used to get/add html to the cache. The interface is registered in the IOC container. The interface has a single method like: <pre class="language-csharp"><code>string GetOrAdd(string key, Func<IRenderingContext, string> renderingCallback);</code></pre> The way to use the method is to first create a cache key that should be unique for the context (colud be built from e.g. current content, current property and current template). Then a call is maid against the method GetOrAdd. If the item is already cached you get the html result back otherwise the renderingCallback Func is called where you specify how to render the html. Then the result is cached and returned. The argument IRenderingContext that gets passed to the callback makes it possible to for example add content dependencies. The current IRenderingContext can also be retrieved from IOC container using IRenderingContextResolver. This can be useful if you have for example a listing block that is dependent on some listing, then you can add a dependecy to that listing in for example the block controller (see PageListBlockController in my Alloy project). <h2>PropertyFor and Content rendering</h2> To inject the html cache in the CMS rendering I choosed to intercept PropertyRenderer, ContentAreaRenderer and IContentRenderer. The interceptors basically checks if the html output for the item to be rendered is already cached. If so the html is returned else the default renderer is called and the output is captured and cached. During the rendering it also creates dependencies to the content item(s) that the output is dependent on. That is so the right html elements gets evicted for example when a content item is published. <h2>Personalization</h2> This caching technique is somewhat related to output cache, but in that case is the whole html for a page cached as whole. One problem is that is hard to know which content item that affected the rendering and hence is the whole output cache evicted (for all pages) when some content is published. Also output cache is hard to use with personalization since it is all or nothing that gets cached. With russian doll caching it was possible to handle personalization much nicer. Say for example that a page contains a content area or a xhtmlstring that is personalized. Then we can avoid to cache that specific property but still cache the html for other items on that page such as menus, listings and other contentareas or xhtmlstrings. <h2>Alloy modifications</h2> I have uploaded a somewhat modified Alloy site together with the code for the html cache to my <a href="https://github.com/jbearfoot/HtmlCache">git hub repository</a>. I have added a Block type NowBlock which can be used to verify that personalization of ContentArea and XhtmlString works as expected. I have also added an action filter that writes out the rendering time for request in the bottom left of the page. There are also a noop and an in-process implemenation of IDistributedCache that can be registered by selecting which IDistributedCache implementation that is registered in Alloy/HtmlCache/DistributedCacheConfigurationModule.cs. That can be used to compare the rendering time for inprocess-cache, redis cache and no html cache (it still uses the content cache in this case). <h3>Menu</h3> I have changed the Menu in Alloy/Helpers/HtmlHelpers.cs so it uses the html cache. You can see in the code that it also caches at several layers, first the menu as whole but also individual menu items. Meaning if one item would be evicted then that item and the menu as whole needs to get re-rendered but the html output from all other items remains and can be reused to render the menu as whole. <h3>Footer</h3> On Alloy all pages uses the same footer that has some page listings. However those page listing is not dependent on the current rendered page, instead those are defined on start page. Therefore has the PropertyFor calls in Footer.cshtml been modified to the pass in which content it is dependent on(the default behaviour is current rendered content). <h2>Async</h2> Since calls to Redis is out of process calls I initially thought it would make sense to use the async overloads of the methods. However my impression was that the sync calls where much more stable and also since the MVC 5 APIs I interact with is synchronus I choosed the sync methods. However my impression is that Redis is lightning fast so I have not seen any problems with it. But if this where to be implemented for ASP.NET Core I would probably look at the async alternatives again. <h2>Performance</h2> I measure the rendering tims by adding an action filter (defined in Alloy/HtmlCache/RenderTimeFilter.cs), it starts a stopwatch in OnActionExecuting and stops it at OnResultExecuted. So the measurement is the time for serverside rendering (it does not include the time for network transfer). The actual figures are not that interesting since it dependens on your machine etc, but the comparsion between the different options are insteresting. Also running Alloy locally on the machine is fast anyway so it can be hard to see/feel the difference. When comparing the results for page "About us" that does not have any personalizaton, but a top and left menu and some listings in footer and some content properties.  No html cache ~20-25 ms Redis ~ 5-8 ms In-Memory 3-5 ms When testing on News&Events which has a PageListBlock instance that prevents caching I get result as: No Html cache ~25-30ms Redis ~15-18 ms In-memory ~12-15 ms In this case the page list block prevents caching of the content area. Also the page list block is rendered through a partial controller so the effect is not as significant for this page (the same applies for pages Alloy Plan, Alloy Track and Alloy Meet which all has PageListBlock instances). So the result is that when no personalization is used the improvment is massive! And when there is personalization we also see a significant improvment even though it is not equally impressive (especially when the non cached item is a block rendered through a partial controller). Another thing to notice is that using Redis as a distributed cache is not that much less performant than an in-memory cache. <h2>Thougths</h2> In my implementation I went "All-In" meaning it caches a whole lot for example the output all properties. It would be possible to adjust it to just cache some specific property types (e.g. ContentArea and XhtmlString) or to avoid caching property output at all. A suggestion could be to profile the application to see what gives most benefit (menus and listings are good candidates) and start with that. Especially if you cache in-process you might want to limit what to cache. However I strongly suggest a distributed cache, that also addresses the cold start scenario.  <h2>Give it a spin</h2> The code can be cloned from my <a href="https://github.com/jbearfoot/HtmlCache">git hub repository</a>. It includes an Alloy site that you can run to test the code on, should be just to press F5. I have not tested it on any larger site but as I see it those sites should be the ones that has most benefit of this (especially if you use the distributed cache). To run the Redis implementation you need to install Redis locally or on some other machine. You could create it in Azure as well but that is probably a bit unfair (when you compare with e.g. in-process) unless you deploy the application to Azure as well. <h2>Disclamiers</h2> This is nothing offically supported by EPiServer, you are free to use it as you like at your own risk. It is currently not in production quality, for example are there no tests or fault handling. </body> </html>2017-12-14T20:44:53.0000000Z

Blog post

EPiServer.ServiceLocation.StructureMap 2<!DOCTYPE html> <html> <head> </head> <body> We have now released version 2 of EPiServer.ServiceLocation.StructureMap. This version has a dependency against version 4.5.2 of the unsigned version of StructureMap. According to <a href="http://structuremap.github.io/release-notes/">release notes</a> in StructureMap documentation the newer version contains (among other things) performance improvments.  There are some nuget issues that could be good to know about when updating EPiServer.ServiceLocation.StructureMap. Nuget will not remove references to the packages  structuremap-signed and structuremap.web-signed used by version 1 of EPiServer.ServiceLocation.StructureMap during update. So a recommendation after updating is to uninstall those packages. Also any existing binding redirects to the signed version of StructureMap assembly will remain in web.config. An alternative to update package is to first uninstall package EPiServer.ServiceLocation.StructureMap, make sure to select option "Remove dependencies". If you have an dependency to package EPiServer.CMS you must also select option "Force uninstall". Then install version 2 of package EPiServer.ServiceLocation.StructureMap. Even in this case there might be old binding redirects left in web.config. The package has been tested with CMS and we are currently testing it with other products such as Commerce and Find, to make sure it is compatible with other products as well. </body> </html>2017-12-04T11:36:45.0000000Z

Blog post

CMS 11 - A package breaking release <!DOCTYPE html> <html> <head> </head> <body> At Episerver we are using continuous releases and we follow <a href="https://semver.org/">semantic versioning</a>. That means that we release features and bugfixes continuously. A major release indicates that there is breaking change compared to the previous version. The main breaking change we have introduced in CMS 11 is that we have separated our packages in "core" runtime packages and packages dependent on specific technologies. Some of the new packages are: <ul> <li>EPiServer.Framework.AspNet, EPiServer.CMS.AspNet - Contains the ASP.NET specific implementations of CMS like WebForms and MVC 5 support.</li> <li>EPiServer.ServiceLocation.StructureMap - A StructureMap based IOC implementation. Having this as a separate package opens up for newer version of unsigned StructureMap (planned to be release in a near future) but also for other implementations of IOC containers.</li> <li>EPiServer.XForms - Optional package that can be used if xforms is used. </li> <li>EPiServer.DynamicContent - Optional package that can be used if dynamic content is used</li> <li>EPiServer.Search.Cms - Optional package if EPiServer Search is used.</li> </ul> The main purpose is to achieve a better separation of concern. One goal was to have a core runtime that is not dependent to be executed in a specific environment like ASP.NET but instead can be setup in for example an integration test. <h2>.NET Standard</h2> The <a href="https://docs.microsoft.com/en-us/dotnet/standard/net-standard" data-linktype="external">.NET Standard</a> is a formal specification of .NET APIs that are intended to be available on all .NET implementations. The specification is maintained by .NET implementors, specifically Microsoft (includes .NET Framework, .NET Core and Mono) and Unity. The idea is that a library that is compliant with NET standard can be consumed and executed on all environments where .NET is supported (a.k.a. cross-platform library). Previous to CMS 11 all Episerver CMS packages (e.g. EPiServer.Framework, EPiServer.CMS.Core) where dependent on assemblies only available on .NET Framework and could hence only execute on environments where .NET Framework is installed. In CMS 11 our "core" packages EPiServer.Framework and EPiServer.CMS.Core are now .NET Standard 2.0 compliant. The packages EPiServer.Framework.AspNet and EPiServer.CMS.AspNet that contain the ASP.NET specific implementation (e.g. with dependecies to System.Web, System.Web.Mvc and System.Configuration) still requires .NET Framework. An overview of the packages are shown below: <img src="/link/29130338691f4ecc90e1bbd46df02f28.aspx" width="736" alt="Image CMS11.png" height="414" /> The existing applications today that are ASP.NET application will require the EPiServer.CMS.AspNet package (supporting both WebForms and MVC 5) and will execute on ASP.NET on .NET Framework. However the separation of packages also opens up for example for integration tests (that do not require ASP.NET) and also since core packages are now .NET Standard compliant it is also possible to build other types of applications (e.g. Console application or Web API) based on .Net Core.  We aim to release a package that will assist with setting up CMS runtime in an ASP.NET Core application within a near future. This package will for example contain an implementation of our IOC abstraction based on the default dependency injection implementation in .Net Core.  </body> </html>2017-11-22T14:23:28.0000000Z

Blog post

Export/Import improvementsThere have been some improvements done regarding Import/Export functionality in CMS 10.2.0. Since Copy is based on same functionality as Export/Import features like point 3 below will affect Copy as well. Here is a summarized list of improvements: 1. Possible to select other source/destination than pages during export/import. Meaning it is for example possible to export/import parts of the asset structure.  <img alt="Image Export.png" src="/link/9e97a907634245268d231f73cc6c76e0.aspx" /> 2. Possible to specify if export should include descendents or just take a single content item. 3. Better handling of "duplicate" content. For folders, it means no dupliate folders are created - instead content items are merged into the existing folder. For other items (like pages, media, blocks) the name will be unique. So for example if there already exists a page or block (at same location and language) named "News," then the imported will be named "News(2)" and for media it would be for example "SomeMedia(2).png". 4. Possible to specify to import a single language branch. Export will always include all language versions for content items. However during import it is possible to select to import a single language branch. A bonus feature is a new admin tool "Manage Content" <img alt="Image ManageContent.png" src="/link/4b817f7ac40a43dea05f01c6cc330e7a.aspx" /> One use case is if the site uses custom content types (IContent implementations) since the edit UI by default only shows "known" types (like pages, media, blocks) there is no way to delete custom content items from the UI. The "Manage Content" tool will show custom content types as well, and hence make it possible to delete them. Another use case: since export/import now can be done across the content structure, there may be cases where an import "goes wrong" meaning the content ends up in the wrong structure. There is validation that items should be imported in same "known" structure (for example is it not possible to export from page structure and import into asset structure.) But since the system has no knowledge about all custom types and custom structures, the validation might fail. In that case, the "Manage Content" tool can be handy.2016-12-05T20:19:28.8330000Z

Blog post

Internationalized Resource Identifiers (IRIs)An Internationalized Resource Identifier (IRI) is a network address that contain non ASCII characters as below: <img alt="Image IRI.png" src="/link/8c5184c2a345494693d4eb1965579599.aspx" /> EPiServer CMS has previously (prior to 10) only allowed characters in url segments according to <a href="http://www.faqs.org/rfcs/rfc1738.html">RFC 1738</a> which basically allows ALPHA / DIGIT / '-'/ '_'/ '~' / '.'/ '$'/.  It is now (from CMS.Core version 10.1.0) however possible to define a custom character set that are used for url segments and simple address. This is done by registering an instance of UrlSegmentOptions with a custom regular expression in IOC container. When an expression is set that allows characters outside RFC 1738 the setting UrlSegementOptions.Encode is recommended to be set to true so that url:s gets properly encoded. Below is an example of how a character set that allows unicode characters in the letter category. <pre class="language-csharp"><code>using EPiServer.ServiceLocation; using EPiServer.Framework.Initialization; using EPiServer.Framework; using EPiServer.Web; namespace EPiServerSite6 { [ModuleDependency(typeof(EPiServer.Web.InitializationModule))] public class IRIConfigurationModule : IConfigurableModule { public void ConfigureContainer(ServiceConfigurationContext context) { context.Services.RemoveAll<UrlSegmentOptions>(); context.Services.AddSingleton<UrlSegmentOptions>(s => new UrlSegmentOptions { Encode = true, ValidUrlCharacters = @"\p{L}0-9\-_~\.\$" }); } public void Initialize(InitializationEngine context) {} public void Uninitialize(InitializationEngine context) {} } }</code></pre> UrlSegmentOptions also exposes a CharacterMap property where it is possible to define a mapping for unsupported characters, for example 'ö' => 'o'.  <h2>Internationalized Domain Names (IDN)</h2> As explained in <a href="https://www.w3.org/International/articles/idn-and-iri/">IDN and IRI</a> are internationalized domain names registered in its punycode format (a way of representing Unicode characters using only ASCII characters).  Internationalized domain names should be registered in admin mode under Manage Websites in their punycode format. 2016-11-15T14:59:39.2530000Z

Blog post

Changes regarding language handling during content loading in CMS8<h2>Background</h2> Previously there were overloads to content loading methods in IContentLoader that took an ILanguageSelector as a parameter. When working on multilingual sites these overloads could be used to load content in a specific language, and/or define if language fallback rules should apply. The way it worked behind the scenes during load was that first the content provider could operate on the passed in language selector to decide which language to return. Then the language selector was used again to select which language version to return according to defined language fallback rules. The main implementation of ILanguageSelector is LanguageSelector. It is a fairly complex class that previously both acted as a data carrier as well as a service. It can be hard to handle in unit tests, mainly due to a static dependency to ContentLanguage.PreferredCulture but also complexity to mock. Another feedback we heard was from implementers of content providers was that the language selector is complex to work with. We finally ran into some issue with the language selector and the Preview functionality in the recently introduced Project feature (<a href="/link/18c5228d9fcb4922976c83db606c4ab0.aspx">beta description of projects</a>). As the language fallback functionality in the LanguageSelector was run after the project version was selected it would not take projects into consideration and the two features would not work well together. So the current language handling using LanguageSelector which already was complex did not work very well in the project preview scenario. We did not want to add project awareness to LanguageSelector, due to the tight coupling this would mean, also considering that LanguageSelector was already complex in its own. <h2>New loading handling</h2> So we decided to do some improvements regarding language handling during content loading. Some of the goals we set up where: <ol> <li>Possibility to specify options for language that does not have static dependencies such as ContentLanguage.PreferredCulture or the inversion of control magic (SelectPageLanguage etc)</li> <li>Make a smooth upgrade from CMS7, preferably just a recompile without changing any code</li> <li>Simplify language selector and how to use it</li> </ol> We moved the language selection from the content provider level to the loader above the providers. We have changed IContentLoader by replacing the ILanguageSelector with LoaderOptions instead. We have also added simpler overloads that just take a CultureInfo. LoaderOptions is basically just a collection of LoaderOption (currently there are LanguageLoaderOption and ProjectLoaderOption). During loading there are specific components that acts on the different loader options, affecting which language/version of a content to return. <h2>What about LanguageSelector?</h2> To minimize the impact on existing code, we have changed LanguageSelector to inherit from LoaderOptions. This means you can still pass in a LanguageSelector to the overloads that take a LoaderOption. We have changed the implementation of LanguageSelector so that the constructor and the static methods (like MasterLanguage) creates corresponding LoaderOptions instances. This means there is no immediate demand to replace current usage of LanguageSelector as parameter to loading methods. <h2>Usage of IContentLoader</h2> Below are some examples on how to load content with some different fallback strategies applied. The examples shows usage of LanguageSelector and alternatives using CultureInfo and LoaderOptions instead. <h3>Loading specific language</h3> Loading a page in a specific language, using LanguageSelector: <pre class="language-csharp"><code>var swedishPage = contentLoader.Get<StandardPage>(contentLink, new LanguageSelector("sv"));</code></pre> Using the new overload that takes a CultureInfo, the same page can be loaded as: <pre class="language-csharp"><code>var swedishPage = contentLoader.Get<StandardPage>(contentLink, CultureInfo.GetCultureInfo("sv"));</code></pre> This is equivalent to: <pre class="language-csharp"><code>swedishPage = contentLoader.Get<StandardPage>(contentLink, new LoaderOptions(){ LanguageLoaderOption.Specific(CultureInfo.GetCultureInfo("sv")) });</code></pre> <h3>Loading master language</h3> To load the master language version of a content (the master language version is the language version in which the common non-language specific properties are stored) using LanguageSelector: <pre class="language-csharp"><code>var master = contentLoader.Get<StandardPage>(contentLink, LanguageSelector.MasterLanguage());</code></pre> Using the new overload that takes a CultureInfo the master version can be loaded as: <pre class="language-csharp"><code>master = contentLoader.Get<StandardPage>(contentLink, CultureInfo.InvariantCulture);</code></pre> This is equivalent to: <pre class="language-csharp"><code>master = contentLoader.Get<StandardPage>(contentLink, new LoaderOptions() { LanguageLoaderOption.MasterLanguage() });</code></pre> <h3>Loading in current language with fallback</h3> Using LanguageSelector to load a content instance in the same language as the current request was routed to: <pre class="language-csharp"><code>var current = contentLoader.Get<StandardPage>(contentLink, LanguageSelector.AutoDetect());</code></pre> LanguageSelector.AutoDetect() uses language fallback settings, which means that if the content does not exist in the requested language or if the language is not published, then another language version might be returned (according to defined fallback rules). Using LoaderOptions the call would look like: <pre class="language-csharp"><code>current = contentLoader.Get<StandardPage>(contentLink, new LoaderOptions() { LanguageLoaderOption.Fallback() });</code></pre> <h3>Loading specific language with fallback (including master)</h3> Loading content in a preferred culture with fallback rules applied, including a final fallback to master (if no other fallback rules apply) can be done using LanguageSelector: <pre class="language-csharp"><code>var fallback = contentLoader.Get<StandardPage>(contentLink, LanguageSelector.Fallback("sv", true));</code></pre> The equivalent call using LoaderOptions is: <pre class="language-csharp"><code>fallback = contentLoader.Get<StandardPage>(contentLink, new LoaderOptions(){ LanguageLoaderOption.FallbackWithMaster(CultureInfo.GetCultureInfo("sv")) });</code></pre> <h2>Related changes</h2> <h3>Changes in IContentRepository</h3> The methods CreateLanguageBranch and GetDefault have been simplifed to take a CultureInfo as parameter, instead of an ILanguageSelector. <h3>ILanguageSelector and content providers</h3> The interface ILanguageSelector has been simplified to only contain a single property Language of type CultureInfo. This means content provider implementations no longer needs to call any methods on ILanguageSelector to decide which language version to return. Instead they can just return the language version specified by ILanguageSelector.Language. If CultureInfo.InvariantCulture is passed in, the provider should return content in the master language. If the content does not exist in the specified language, then the master language should be returned. <h3>ContentReference.GetPublishedOrLatest</h3> ContentReference has a property GetPublishedOrLatest that loads the published version or the latest version if no published version exists. When using this property with language fallback previously it only loaded published versions in the fallback chain. This has been corrected to select the published or latest version in the fallback chain as well. This property is normally not used in templates. <h3>ILanguageSelectionSource</h3> In previous versions of CMS, it was possible to cast the passed in LanguageSelector to ILanguageSelectionSource after content retrieval. That interface contained information about why the content was selected, for instance that the content was selected due to language fallback or replacement rules. The same information can now be retrieved after content retrieval by calling MatchLanguageSettings on IContentLanguageSettingsHandler passing in the retrieved content instance and the requested language.2015-02-20T09:51:32.0000000Z

Blog post

Changes in simple address routingIn package EPiServer.CMS.Core.7.13.3 we have solved an issue that causes a slightly different behaviour in how simple addresses are routed. As a background: for “ordinary” content routing we introduced a more strict handling in 7.5 where for example it was not possible to have a language segment specifying one language while the segment it self was on a content instance on another language. Like for example: <a href="http://mysite/en/produkter">http://mysite/en/produkter</a> (where “produkter” is the segment on the swedish version) In CMS 7 that was possible to route and resulted in the english version of the page. In CMS 7.5 that results in a 404. We also introduced a configuration setting strictLanguageRouting that can be set to false to get the more tolerant behaviour as in CMS 7. Now we have also changed simple address routing so it is more strict. So given that a page exist in both language "en" and language "sv" and has simple addresses "ensimple" and "svsimple" the following scenarios apply. For those scenarios that differs from previous version a parenthesis is added describing the old behaviour: No host language mapping, strictLanguageRouting=true <ol> <li> http://sitehost/ensimple => english page </li> <li> http://sitehost/svsimple => swedish page </li> <li> http://sitehost/en/ensimple => english page </li> <li> http://sitehost/sv/svsimple => swedish page </li> <li> http://sitehost/sv/ensimple => 404 (this gave swedish page in previous version) </li> </ol> No host language mapping, strictLanguageRouting=false <ol> <li> http://sitehost/ensimple => english page </li> <li> http://sitehost/svsimple => swedish page </li> <li> http://sitehost/en/ensimple => english page </li> <li> http://sitehost/sv/svsimple => swedish page </li> <li> http://sitehost/sv/ensimple => swedish page </li> </ol> Host "sitehost" mapped to language "en", strictLanguageRouting=true <ol> <li> http://sitehost/ensimple => english page </li> <li> http://sitehost/svsimple => 404 (this gave english page in previous version) </li> <li> http://sitehost/en/ensimple => 404 (this gave english page in previous version) </li> <li> http://sitehost/sv/svsimple => swedish page </li> <li> http://sitehost/sv/ensimple => 404 (this gave swedish page in previous version) </li> </ol> Host "sitehost" mapped to language "en", strictLanguageRouting=false <ol> <li> http://sitehost/ensimple => english page </li> <li> http://sitehost/svsimple => swedish page </li> <li> http://sitehost/en/ensimple => english page </li> <li> http://sitehost/sv/svsimple => swedish page </li> <li> http://sitehost/sv/ensimple => swedish page </li> </ol> To get the more tolerant behaviour as in previous versions you can either set the strictLanguageRouting attribute (on configuration element applicationSettings) to false. That will however not only affect simple address but also "ordinary" routing so it works as in EPiServer 7. To only affect simple address you could have an initialization module that configures simple address routing to not use strict language routing as the following code: <pre class="language-csharp"><code>using EPiServer.Framework; using EPiServer.Web.Routing; using System; using System.Collections.Generic; using System.Linq; using System.Web; namespace MvcPreview { [InitializableModule] public class SimpleAddressModule : IInitializableModule { public void Initialize(EPiServer.Framework.Initialization.InitializationEngine context) { EPiServer.Global.RoutesRegistered += delegate(object source, RouteRegistrationEventArgs args) { var simpleAddressRoute = args.Routes.OfType<ContentRoute>().FirstOrDefault(r => r.Name.Equals("simpleaddress")); if (simpleAddressRoute != null) { simpleAddressRoute.StrictLanguageRoutingResolver = () => false; } }; } public void Preload(string[] parameters) { } public void Uninitialize(EPiServer.Framework.Initialization.InitializationEngine context) { } } }</code></pre>2014-09-08T15:32:57.0000000Z

Blog post

LocalMediaProviderIn the nuget package EPiServer.CMS.Core.7.13.0 is a new service IdentityMappingService introduced. The purpose of the service is to support external integrations (like a content provider or an asset importer) to manage a mapping between the external identity and the content references and GUID:s used in EPiServer CMS to ensure that any links that exists or are created with this data, always reference the same external content. The external identifier should be of type Uri (which can be built from for example guid, int, string etc). To test this new service I built a custom content provider called LocalMediaProvider. The idea is that it maps a local file system (like your harddrive) into the asset gadget in EPiServer CMS. It’s similar to the VirtualPathNativeProvider that existed in previous versions of EPiServer. Easiest way to integrate the local files would be to create a folder under GlobalAssetsRoot and set the entry point for the provider to that folder. However in my case I wanted to distinguish the local files from other files so I created the entry point outside the asset root. And instead registered an UI component so the local files appears as a separate "tab" in the asset panel. If you try the code and the tab does not show up try to go to "My settings" and select "Reset Views" under "Display options". When going in to the media gadget you can see your local folder structure. In my case I set “C:\” when configuring my provider, in reality you would probably point out a folder structure with for example images.   <a href="/link/74511341fd144b1494305b3253b84479.png"><img title="Localmediagadget" style="display: inline; background-image: none;" border="0" alt="Localmediagadget" src="/link/219ee490005645039a4e0ec1405f2429.png" width="331" height="573" /></a> If you want to try it out the source code is located in <a href="https://github.com/jbearfoot/LocalMediaProvider">https://github.com/jbearfoot/LocalMediaProvider</a>. There you will also find a built nuget package that you can add to your project. It will then include the code to your project in a folder LocalMediaProvider. Note that this was just a sample I wrote to test the IdentityMappingService and hence it is not “productified” and all usage of the code is at own risk <img class="wlEmoticon wlEmoticon-winkingsmile" alt="Blinkar" src="/link/9813303ce02042d58f7fb7da4e8b7a63.png" />. The code consists of three components. First there is a content provider that reads files and folders from the local file system and presents them as ContentFolders and IContentMedia instances. Then there is a UI component that registers a “new” tab in the media gadget. And finally a Initialization module that creates an entry point for the provider, registers the provider and registers some routes for the media.2014-08-21T10:16:07.0000000Z

Blog post

Blob propertyTo be able to support media as content (IContentMedia) we introduced a new property type Blob that makes it possible to store binary data related to a content instance. The most obvious usage is through IContentMedia.BinaryData which stores the binary data for a media item. <h4> </h4> <h2>ImageDescriptor attribute</h2> Another usage of blobs for media is the Thumbnail property for IContentMedia where a thumbnail format of the media is stored. For images the thumbnail is auto generated due to the usage of ImageDescriptor attribute. The base class ImageData looks like: <pre class="language-csharp"><code> public class ImageData : MediaData, IContentImage { /// <summary> /// Gets or sets the generated thumbnail for this media. /// </summary> [ImageDescriptor(Width = 48, Height = 48)] public override Framework.Blobs.Blob Thumbnail { get {return base.Thumbnail;} set {base.Thumbnail = value;} } }</code></pre> Here we can see that the ImageDescriptor attribute specifies that it should generate a thumbnail in size 48*48. You can override the property and specify the size as you wish. You can also have additional Blobs properties like LargeThumbnail, MediumThumbnail etc. with ImageDescriptor attribute on your media type. They will then be autogenerated like Thumbnail. <h2>Lazy loading</h2> The actual Blob is stored by the configured BlobProvider so in the content database only the URI to the blob is stored. The actual binary data for the blob will not be loaded before OpenRead method is called on the blob instance. <h4> </h4> <h2>Blob routing</h2> There is a partial route registered that makes it possible to route directly to a blob property on a content instance. The URL pattern is <content URL>/BlobPropertyName. So for example if there is an image with url <a href="http://mysite/globalassets/myimage.png">http://mysite/globalassets/myimage.png</a> then I can route to the thumbnail as <a href="http://mysite/globalassets/myimage.png/thumbnail">http://mysite/globalassets/myimage.png/thumbnail</a>. You can try this by adding “/thumbnail” to any image URL in a CMS 7.5 site. <h2>Export-Import support</h2> Blob properties are included/handled in export-import meaning the Blobs referenced from Blob properties will automatically be included in the export package. This means e.g. that it is possible to transfer content (including media/blobs) from one site with a specific blob provider (e.g. FileBlobProvider) to a site with another blob provider (e.g. blob provider for Amazon or Azure). <h2>PDF version of page</h2> The Blob property is not restricted to be used by only media. It is possible to add a Blob property to any IContent instance. In the example (I used Alloy templates) below I have added a property of type Blob to SitePageData as: <pre class="language-csharp"><code>public virtual Blob PDF { get; set; }</code></pre> I then added an eventhandler for IContentEvents.PublishedContent where I generate a PDF for the page and stores the PDF in the blob property. I can then view the PDF version of the page by appending “/pdf” to the URL for the page. The code for the example is below. Note: In the example a package called Pechkin is used to generate the PDF but there are many different PDF generators to choose from. <pre class="language-csharp"><code> [ModuleDependency(typeof(EPiServer.Web.InitializationModule))] public class PDFCreatorModule : IInitializableModule { public void Initialize(InitializationEngine context) { var globalConfig = new GlobalConfig(); globalConfig.SetMargins(new Margins(300, 100, 150, 100)) .SetDocumentTitle("Test document") .SetPaperSize(PaperKind.A3Rotated); var contentEvents = context.Locate.Advanced.GetInstance<IContentEvents>(); contentEvents.PublishingContent += (sender, args) => { var page = args.Content as SitePageData; if (page != null && !page.ProcessedPDF) { args.Items["ProcessPDF"] = true; } }; contentEvents.PublishedContent += (sender, args) => { var page = args.Content as SitePageData; if (page != null && args.Items["ProcessPDF"] != null) { context.Locate.Advanced.GetInstance<PDFCreator>() .CreatePDF(page, globalConfig, new WebClient()); } }; } public void Preload(string[] parameters) {} public void Uninitialize(InitializationEngine context) {} } public class PDFCreator { private IContentRepository _contentRepository; private BlobFactory _blobFactory; private UrlResolver _urlResolver; public PDFCreator(IContentRepository contentRepository, BlobFactory blobFactory, UrlResolver urlResolver) { _contentRepository = contentRepository; _blobFactory = blobFactory; _urlResolver = urlResolver; } public virtual void CreatePDF(SitePageData page, GlobalConfig gc, WebClient webClient) { page = page.CreateWritableClone() as SitePageData; page.PDF = _blobFactory.CreateBlob(Blob.GetContainerIdentifier(page.ContentGuid), ".pdf"); var pageUrl = UrlResolver.Current.GetUrl(page.ContentLink, page.Language.Name); var absolutePageUrl = UriSupport.CreateAbsoluteUri(pageUrl); var htmlText = webClient.DownloadString(absolutePageUrl); var htmlWithAbsoluteUris = MakeUrisAbsoulte(htmlText, SiteDefinition.Current.SiteUrl); var pechin = new SynchronizedPechkin(gc); var oc = new ObjectConfig(); oc.SetCreateExternalLinks(false) .SetFallbackEncoding(Encoding.Unicode) .SetLoadImages(true); using (var writeStream = page.PDF.OpenWrite()) { var convertedData = pechin.Convert(oc, htmlWithAbsoluteUris); writeStream.Write(convertedData, 0, convertedData.Length); } page.ProcessedPDF = true; _contentRepository.Save(page, SaveAction.Publish | SaveAction.ForceCurrentVersion | SaveAction.SkipValidation, AccessLevel.NoAccess); } const string pattern = @"(?<name>src|href)=""(?<value>/[^""]*)"""; private string MakeUrisAbsoulte(string html, Uri baseUri) { var matchEvaluator = new MatchEvaluator( match => { var uri = new Uri(match.Groups["value"].Value, UriKind.RelativeOrAbsolute); Uri absoluteUri; if (!uri.IsAbsoluteUri && Uri.TryCreate(baseUri, uri, out absoluteUri)) { var name = match.Groups["name"].Value; return string.Format("{0}=\"{1}\"", name, absoluteUri.AbsoluteUri); } return null; }); return Regex.Replace(html, pattern, matchEvaluator); } }</code></pre>2013-12-16T09:15:34.0000000Z

Blog post

Multisite feature in EPiServer 7.5Even in previous version it was possible to have several EPiServer sites sharing the same database and configuration files (often referred as Enterprise setup). However there was a one to one relationship between IIS instance and EPiServer site meaning each EPiServer site needed to have an own IIS instance configured. So even when using same IIS application pool the sites run in different AppDomains. One consequence of running in separate AppDomains is that static properties like PageReference.StartPage or Configuration.Settings.Instance will not be shared between sites and hence have different static values in each AppDomain. It also has the consequence that event replication was needed to be configured between the sites to get cache invalidation to work. <h3> </h3> <h2>Multisite in 7.5</h2> In EPiServer 7.5 multi-site handling has been changed so now a running EPiServer instance is multi-tenant meaning a single EPiServer application running in one AppDomain can contain several EPiServer sites. The take advantage of this the DNS/IIS should be configured so the requests are routed to that IIS application. You can e.g. have a wildcard configuration so all request of *.mydomain.com is routed to the IIS application. Then it will be possible to dynamically create/delete new sites like newcampaign.mydomain.com without doing any IIS/DNS configuration at all. It is of course still possible to configure to run sites that share database in separate IIS instances. For example it can be good to separate large sites to different machines (to avoid that they share the same resources like memory). When doing so you need to configure remote events though. <h3> </h3> <h2>Configuration changes</h2> Previously site settings (like e.g. SiteUrl, StartPage) where defined in the configuration files. That had the consequence that when a site was added/removed the configuration file had to be updated and hence the applications where restarted. We have removed away site settings (like SiteUrl, StartPage, host mappings etc.) from the configuration files and instead those values are stored in database. This make it possible to add/remove sites dynamically without having to update configuration files and hence application restarts can be avoided This also simplifies deployment/development scenarios since the configuration files does not need to contain as much environment specific settings. <h3> </h3> <h2>SiteDefinition</h2> To be able to run several sites in the same domain static properties like ContentReference.StartPage and Settings.Instance.SiteUrl must return differently depending on context (in previous versions these properties where “truly” static throughout the application). We have achieved this by letting those properties delegate to SiteDefinition.Current (resides in namespace EPiServer.Web). SiteDefinition.Current is resolved from the request, meaning a comparison will be done where the host from the request will be matched against all sites from SiteDefintionRepository. The site with a host matching the request will be returned. If no match is found or if the current thread is not executing on a web request the site registered with wildcard host '*' will be returned. If no wildcard site is defined a default SiteDefinition is returned where common settings like e.g. RootPage is set but StartPage will be ContentReference.EmptyReference and SiteUrl will be null. That means that you can add host '*' to one site if you want that site to be returned from SiteDefintion.Current when there is no web request, this can be useful e.g. when running scheduled jobs. Another possibility for code that is not running on a web request (like scheduled jobs) is to assign SiteDefinition.Current then that assignment will be set for that context. Also worth noticing is that there is one initialization for the application where all sites are initialized (unlike before where the initialization where for a specific site since each site run in a separate AppDomain). So if you have some custom initialization module that are site dependent you could use SiteDefinitionRepository.List() to get a list of all defined sites. <h3> </h3> <h2>Site Management</h2> Sites are managed in admin mode under “Manage Websites” in admin mode. Here you can create new sites, delete unused sites and configure sites (for example specify language-host mappings). So by default is site handling a task for administrators. However it is possible to let site creation be done by editors. One way to achieve this is to set up an event handler for IContentEvents.PublishedContent and in the event handler check if the content is of your StartPage type and if so creating a new site by storing a new instance towards SiteDefinitionRepository.2013-12-11T17:50:10.0000000Z

Blog post

Routing changes in 7.5There are some changes that have been done regarding routing and template selection in EPiServer 7.5. Here is a summary of the most significant changes. <h3> </h3> <h2>Routing to files/media</h2> In EPiServer 7.5 the handling of files used in content (typically handled through FileManager) have been changed from being based on VirtualPathProviders to be based on content (IContent implementations). This means files share much of the functionality like access rights, versioning etc. as other content types (as e.g. Pages, Blocks). This also means that files are routed to in the same way as e.g. pages. <h3> </h3> <h2>Lower-Case URLs</h2> By default in EPiServer 7.5 URL segments for content will be generated in lower-case. It is possible to allow upper case characters in URL segments by setting EPiServer.Web.UrlSegment.UseLowerCaseSegments to false. <h3> </h3> <h2>Trailing slash</h2> By default URLs in EPiServer is ended with a trailing slash (except for media/files). It is possible change the behavior by setting EPiServer.Web.Routing.ContentRoute.UseTrailingSlash to false. <h3> </h3> <h2>Direct routing to Blobs</h2> We have introduced a partial router that handles direct routing to Blob properties. You can try this by adding “/thumbnail” to any image url. I will in a later post go into Blobs in more detail. <h3> </h3> <h2>Performance improvements</h2> If you run SQL profiler while doing some request against a CMS 7 site you can notice some calls to a stored procedure to match for simple address. You do not be to worried over this since that stored procedure is fast but in 7.5 we have introduced a cache for this calls. Another change is that incoming routing is not using IContentLoader.GetChildren (which is the case in CMS7), instead it uses a new method IContentLoader.GetBySegment. This method is not dependent on the number of items on a certain level in the content tree, so especially  when routing through a structure with many items at the same level 7.5 routes much faster. This new method is also used when generating URL segments so creating/saving content instances(especially where there are many items on the same level) is also faster. <h3> </h3> <h2>UrlResolver</h2> The class EPiServer.Web.UrlResolver can be used both to generate URLs for content items and also get the content item for a given URL. We have added some methods to make it easier to control the URL generation. For example it is possible to specify for which context (View, Edit, Preview) the URL should be constructed for. We have also added a static property Current to UrlResolver make it easier to use in cases where testability is not applicable/important. <h3> </h3> <h2>Partial routing to IContent instances</h2> Some changes have been done in the case where partial routing is used to route to IContent instances. Now the extension method RequestContext.GetContentLink() will return the link to the partial routed content instance (and not the “ordinary routed content” as in CMS7). You can however get the “ordinary routed content” that was routed to by using extension method RequestContext.GetOriginalRoutedLink(). This has the consequence that ContentRouteHelper will also give the partial routed content while PageRouteHelper will give either the partial routed content (if it is a page) or the page where partial routing took of (given that it was a page) or StartPage as final fallback. The reason for this is that it should be possible to use for example the new base class ContentPageBase<TContent> or ContentPageBase<PageData, TContent> which then will offer both a CurrentPage and a CurrentContent. In MVC the similarity is to have two parameters currentPage and currentContent that will be assigned by the model binder. <h3> </h3> <h2>Routing to “classic” links</h2> Previously it was possible to make a request to a webform page with a classic link like e.g. <a href="http://localhost:17000/Templates/Page.aspx?id=17&epslanguage=en">http://localhost:17000/Templates/Page.aspx?id=17&epslanguage=en</a>. By default this will not work anymore since the implementation of CurrentPage in PageBase does not pay attention to query parameters any more (instead it relies that the routing has set the routed content), It is however possible to register a special route to handle “classic” links, this can be done like: <pre class="language-csharp"><code> protected override void RegisterRoutes(System.Web.Routing.RouteCollection routes) { base.RegisterRoutes(routes); routes.Insert(0, ServiceLocator.Current.GetInstance<ClassicLinkRoute>()); }</code></pre> <h3> </h3> <h2>Template selection for on-page edit and preview</h2> Previously when a template was selected for on-page edit the system first tried to select the default template (that is without any tag). If no such template was found a selection was done for a template with tag “Preview” (this is how on-page editing for shared blocks work). This has been changed so now in on-page edit mode a selection is first done for a template with tag “Edit”, if no such is found a fallback is done for first default template(no tag) and finally a template with tag “Preview”. And in preview mode a selection is done for a template with tag “Preview” with fallback to default. This makes it possible to for example have three different templates for a page, one tagged with “Edit”, one with “Preview” and one default. In most cases a “Preview” template is probably not needed but a “Edit” template can be useful. One use case is to expose properties on the “Edit” template that is not part of the normal template used in view mode. This makes it possible for editors to edit these properties directly on page without having to go to “All properties”/Forms mode. <h3> </h3> <h2>Strict language routing</h2> The routing has been changed so it is more strict due to language handling (partly introduced already in patches to EPiServer 7). As an example say that there is a page under start page named "News" in English and "Nyheter" in Swedish. Previously the following URLs where handled like (given that no language mapping is defined for site hosts): <ol> <li>http://sitehost/News/ (page in language given by context typically globalization setting in web.config e.g. en) </li> <li>http://sitehost/en/News/ (page in english) </li> <li>http://sitehost/sv/Nyheter/ (page in swedish) </li> <li>http://sitehost/Nyheter/ (page in english since no language info in URL get language as in point 1) </li> <li>http://sitehost/en/Nyheter/ (page in english since language segment states english) </li> </ol> With the new strict language routing the above URLs will be handled as: <ol> <li>http://sitehost/News/ (404 since when not having language-host mapping in config language segment must be present, unless site have only one language) </li> <li>http://sitehost/en/News/ (page in english) </li> <li>http://sitehost/sv/Nyheter/ (page in swedish) </li> <li>http://sitehost/Nyheter/ (404 as in 1.) </li> <li>http://sitehost/en/Nyheter/ (404 since language for page with URL segment does not match language segment). </li> </ol> Another change is that when a language mapping is defined for a host, say for example that host “sitehost” is mapped to “en” then an URL like http://sitehost/en/News/ will give a 404 since when there is a host mapping that defines a language then that language should not be present in URL. There is a configuration setting "strictLanguageRouting" on configuration element applicationSettings that can be set to false to get old more tolerant behavior.2013-12-06T21:35:36.0000000Z

Blog post

Deployment and Cloud supportThis post is most an overview of the changes we have done around deployment and how a site is “packaged”. There are much more information about deployment and cloud support in the CMS SDK under “Developer Guide/Deployment”. For example can information/examples about deployments to Azure and Amazon be found there. <h2>XCopy enabled deployment</h2> In EPiServer 7.5 we have changed how a site is “packaged” so deployment of an EPiServer CMS site can be done through XCOPY deployment simply by copying application files. An XCOPY-style file transfer simplifies deployment and maintenance of EPiServer sites since no registry entries are created, and no shared components are registered. Examples of XCOPY-style hosting is Azure Web Sites and Amazon Elastic Beanstalk, where basically only a IIS instance is provided, and it is not possible to run an installation setup procedure. Note: We do not say that you should use XCOPY deployment as such, you should of course use the deployment that suits your hosting environment. But making deployment copy enabled should benefit other deployments as well like e.g. MSDeploy, FTP and external deployment tools. Another benefit of the XCOPY architecture in EPiServer CMS is that there is no machine- or site-specific information stored in configuration files, making it possible to use a shared folder for multiple servers. During development in a shared environment with source control, developers can keep configuration files checked in and still be able to create a site which can be duplicated in a multi-site deployment. Another change that is related to copy enabled deployment is that we have removed the usage of Windows service for CMS. This means that the scheduled jobs are maintained within the web application it self. <h3> </h3> <h2>Cloud support</h2> Another change we have done to make it easier to scale an EPiServer installation by adding/removing IIS instances/machines is that we have changed so “services” like Blob storage (replaces previously used VPP based files) and event management (between sites) is provider based. The idea is that one IIS instance running the site only have knowledge about the services and not direct knowledge about other running web site instances. Then it is possible to add/remove one instance without having to touch the other running instance. A conceptual picture of this is: <a href="/link/bc50e7747f624cc1862af43343d6bbc2.jpg"><img title="clip_image002" style="border-left-width: 0px; border-right-width: 0px; background-image: none; border-bottom-width: 0px; padding-top: 0px; padding-left: 0px; display: inline; padding-right: 0px; border-top-width: 0px" border="0" alt="clip_image002" src="/link/72b540bddef941d7bce8e5b8790f6767.jpg" width="522" height="382" /></a> There are separate NuGet packages EPiServer.Azure and EPiServer.Amazon in our feed that contain Blob providers and event providers for each of those environments. 2013-12-05T09:55:34.0000000Z

Blog post

Working with Media programmaticallyPrior to version 7.5, files in EPiServer CMS (as exposed in the old file manager) were handled by a VPP (Virtual Path Providers) system. In the latest version of EPiServer a new media file system with a new user interface is introduced. Content stored in this system is referred to as “media”. This system is based on the same content (IContent implementations) system used for blocks and pages, as well as products from the catalog in Commerce. This means that files shares same support for routing, custom properties, typed models, custom renderings, security etc. as other content types. To work programmatically with media is much like working with other content types (e.g. pages). For example are the CRUD operations done through IContentRepository. In this post I will go through some of the interfaces/base classes used for media and give some examples on how to programmatically work with media. <h2> </h2> <h2>IContentMedia</h2> The requirement for a media type is that it implements IContentMedia which is defined as: <pre class="language-csharp"><code> public interface IContentMedia : IContent, IBinaryStorable { Blob Thumbnail { get; set; } string MimeType { get; } }</code></pre> We can see that IContentMedia extends IContent and also IBinaryStorable which is defined as: <pre class="language-csharp"><code> public interface IBinaryStorable { Blob BinaryData { get; set;} Uri BinaryDataContainer { get; } }</code></pre> The Property BinaryData of type Blob (see class below) is used to handle the actual binary content of the media. The property BinaryDataContainer is the Uri for the container containing the Blob. All binaries for a content instance (including versions and languages) are stored in a common container. The definition of Blob looks like (I have omitted the static methods): <pre class="language-csharp"><code>public class Blob { public Uri ID { get; } public virtual Stream OpenRead(); public virtual Stream OpenWrite(); public virtual void Write(Stream data); }</code></pre> So a blob instance basically contains stream based Read and Write operations. The actual Blob instance is delivered by the configured BlobProvider. The default blob provider stores the binary data on disk (there is a subfolder blobs in the folder specified by attribute basePath on configuration element appData). The NuGet packages EPiServer.Azure and EPiServer.Amazon contains provider to store binary data in Azure Blob storage respectively Amazon S3. <h2> </h2> <h2>Defining a media type</h2> A media type is defined by having a class implementing IContentMedia and decorated with ContentTypeAttibute. The attribute MediaDescriptorAttribute can be used to map which extensions a certain type handles. There are some base classes MediaData, ImageData and VideoData that can be used to specify media types. So for example a project can have types defined as: <pre class="language-csharp"><code> [ContentType(GUID = "EE3BD195-7CB0-4756-AB5F-E5E223CD9820")] public class GenericMedia : MediaData { public virtual String Description { get; set; } } [ContentType(GUID = "0A89E464-56D4-449F-AEA8-2BF774AB8730")] [MediaDescriptor(ExtensionString = "jpg,jpeg,jpe,ico,gif,bmp,png")] public class ImageFile : ImageData { public virtual string Copyright { get; set; } } [ContentType(GUID = "85468104-E06F-47E5-A317-FC9B83D3CBA6")] [MediaDescriptor(ExtensionString = "flv,mp4,webm")] public class VideoFile : VideoData { public virtual string Copyright { get; set; } [UIHint(UIHint.Image)] public virtual ContentReference PreviewImage { get; set; } }</code></pre> <h2> </h2> <h2>Creating a new media instance</h2> Below is an example on how to create a new media instance. Here the media item is created under SiteDefinition.Current.GlobalAssetRoot which is the folder for assets that is shared between sites (this is the root for the media gadget). To structure media instances of EPiServer.Core.ContentFolder can be created. <pre class="language-csharp"><code>var contentRepository = ServiceLocator.Current.GetInstance<IContentRepository>(); var blobFactory = ServiceLocator.Current.GetInstance<BlobFactory>(); //Get a new empty file data var file1 = contentRepository.GetDefault<GenericFile>(SiteDefinition.Current.GlobalAssetsRoot); file1.Name = "Readme.txt"; //Create a blob in the binary container var blob = blobFactory.CreateBlob(file1.BinaryDataContainer, ".txt"); using (var s = blob.OpenWrite()) { StreamWriter w = new StreamWriter(s); w.WriteLine("Hello world"); w.Flush(); } //Assign to file and publish changes file1.BinaryData = blob; var file1ID = contentRepository.Save(file1, SaveAction.Publish);</code></pre> <h2> </h2> <h2>Get media type from extension</h2> There is a ContentMediaResolver that can be used to resolve which content type to use for a certain extension. See below: <pre class="language-csharp"><code>var contentRepository = ServiceLocator.Current.GetInstance<IContentRepository>(); var contentTypeRepository = ServiceLocator.Current.GetInstance<IContentTypeRepository>(); var mediaDataResolver = ServiceLocator.Current.GetInstance<ContentMediaResolver>(); //Get a suitable MediaData type from extension var mediaType = mediaDataResolver.GetFirstMatching(".txt"); var contentType = contentTypeRepository.Load(mediaType); //Get a new empty file data var media = contentRepository.GetDefault<IContentMedia>(SiteDefinition.Current.GlobalAssetsRoot, contentType.ID);</code></pre> <h2> </h2> <h2>Replace the binary data for a media item</h2> When a binary data is to be replaced for a media item a new Blob instance should be created. That is you should not call OpenWrite on the existing blob instance. The reason for this is to support versioning so that if an editor reverts back to an old version the binary data should follow. Normally you should not need to bother about deleting Blobs, there is a scheduled jobs that takes care of deleting unused Blobs. Below is an example on how to replace the binary data for a media in a new version: <pre class="language-csharp"><code>var contentRepository = ServiceLocator.Current.GetInstance<IContentRepository>(); var blobFactory = ServiceLocator.Current.GetInstance<BlobFactory>(); //the file to update, not hardcoded of course var fileID = new ContentReference(444); //Get the file var file1 = contentRepository.Get<GenericFile>(fileID).CreateWritableClone() as GenericFile; //Create new blob file1.BinaryData = blobFactory.CreateBlob(file1.BinaryDataContainer, ".txt"); using (var s = file1.BinaryData.OpenWrite()) { StreamWriter w = new StreamWriter(s); w.WriteLine("Hello world"); w.Flush(); } //publish new version var file1ID = contentRepository.Save(file1, SaveAction.Publish);</code></pre> <h2>Working with content assets</h2> In previous versions it was possible to have a local VPP folder for a content where files related to that content could be stored. Now with media based assets a content instance that implements EPiServer.Core.IResourcable can have related assets (media, blocks etc.) stored in an instance of EPiServer.Core.ContentAssetFolder. Resources stored as content assets are to be seen as exclusive assets for that content instance and hence the resources are not selectable from other content instances. The method GetOrCreateAssetFolder on class EPiServer.Core.ContentAssetHelper can be used to get the asset folder for a content item.2013-12-03T19:36:48.0000000Z

Blog post