Blog posts by Nicklas Israelsson

Blog posts by Nicklas Israelsson2018-12-04T11:47:21.0000000Zhttps://world.optimizely.com/blogs/Nicklas-Israelsson/ Optimizely World Using Vuex in the MusicFestival template siteWe’re rewriting <a href="https://github.com/episerver/musicfestival-vue-template">the music festival template site</a> to use <a href="https://vuex.vuejs.org/">vuex</a> to handle the state of the app. Previously, we’ve been using instance specific properties and mixins to handle and share state in different ways. In my opinion, moving all state handling into a centralized store is a good idea regardless of framework. It makes the code easier to understand and reason about. It’s also worth noting that the available libraries for the different frameworks using flux-like stores are similar enough to make it easy to transition between frameworks. Another positive aspect is that <a href="https://github.com/vuejs/vue-devtools">the available tools</a> for using a state management system make debugging very convenient. <img src="/link/d17f77378c974d1d8e0a076132bd96ae.aspx" alt="Vuex debugging" width="994" height="580" /> <h2>What are the differences?</h2> On the surface, the site should function exactly the same, so the difference only lies in the architecture of the site. We’ve moved the different states we previously had into separate <a href="https://vuex.vuejs.org/guide/modules.html">vuex modules</a>. Modules makes it easier to separate the concerns of the different states but still use a centralized store to get the data that is needed. <h3>Updating the model</h3> In <a href="/link/4a91824ea19e4f3a8fbfb7a953115f1e.aspx">my previous blog</a>, I mentioned a lot about who should own the model. This approach does not fundamentally change that concept since we will still pass the model from a parent component to child components. The difference will be that instead of using the <code>EpiDataModelMixin</code>, the loading and updating of the model will be done in the <code>epiDataModel</code> vuex store module. The parent components will read the model from the store and pass it to child components. Updating the model is initiated from the router. When a route has changed, the router will dispatch an action in the store telling it to update the model. <h3>Keeping track of editing context</h3> The <code>$epi</code> property was used to hide and show the editing overlay in edit mode. The same functionality is now stored in the <code>epiContext</code> module. We’ve changed the old file that defined the <code>$epi</code> instance to something we call <code>epiMessages</code>. The sole responsibility of <code>epiMessages</code> is to register the event handlers for <code>beta/contentSaved</code> and <code>beta/epiStart</code> that will update the new <code>epiContext</code> store module. <h3>Keeping track of application context</h3> The <code>$app</code> property was mainly used on the start page to show/hide a modal window and demonstrate how turning editing on and off in on page edit could be handled in that scenario. This has also been moved into its own vuex module called <code>appContext</code>. <h2>Github repo</h2> This rewrite was merged through a PR on github recently, so if you’re interested in looking into how a transition to using a state management system could look like you can view all commits in the PR here: <a href="https://github.com/episerver/musicfestival-vue-template/pull/4">Use vuex</a> <h2>Related links</h2> Blog series about the template site and SPA sites in OPE: <a href="/link/5ccbe4dbd38c4d76a6dc81e838c70f9d.aspx">https://world.episerver.com/blogs/john-philip-johansson/dates/2018/10/introducing-a-new-template-site-for-spas-musicfestival/</a> Documentation on client side rendering in Episerver: <a href="/link/f80257067ca542288c0b74d4db6ae0c5.aspx">https://world.episerver.com/documentation/developer-guides/CMS/editing/on-page-editing-with-client-side-rendering/</a>2018-12-04T11:47:21.0000000Z

Blog post

Represent the concept of "pages" and "blocks" with matching client side components in a SPA<blockquote> To demonstrate some concepts that are useful when creating a SPA with working OPE, we are releasing a new SPA template site on Github, called MusicFestival, together with a series of blog posts. Don’t be discouraged that the SPA is written in <a href="https://vuejs.org/">Vue.js</a> if you’re using React, Angular, or something else, as these concepts will work in any client side framework. <a href="/link/5ccbe4dbd38c4d76a6dc81e838c70f9d.aspx">https://world.episerver.com/blogs/john-philip-johansson/dates/2018/10/introducing-a-new-template-site-for-spas-musicfestival/</a> </blockquote> Episerver CMS uses the concepts of pages and blocks, and this is how editors are trained and used to editing a site in the CMS UI. SPAs could make up one view from multiple page models, but how should an editor know where to edit it? Pages and blocks match their thinking, and are represented in the UI, so create components that match that. An example would be that an editor of the MusicFestival site needs to update the dates for an artist’s performance. The natural way to do that would be to use the page tree to navigate to the artists page and edit it using On Page Edit (OPE). <img alt="edit-artist.gif" src="/link/4fb65998baf542648590743d0fdec78a.aspx" width="1110" height="771" /> As the page data is represented as one model on the server, it makes sense that it is still one model on the client. Otherwise, you might need multiple places to fetch data and patch it together to represent the view that is rendered to visitors of the site. So by having one model on the client, it can trickle down property data, allowing each child component to be developed independently of each other (i.e. <a href="https://storybook.js.org/">story book in React</a>) <h2>Who should own the model on the client?</h2> The <code>beta/contentSaved</code> message tells you when the editor has edited a property in OPE, and that’s the time to re-render the view. The MusicFestival does this in only one place, and gets the full page JSON that in turn updates a model property that each page and block component takes as a <code>param</code>. The alternative is to have components own their own data updating, which will require more work per component. Having the data update in one place while editing, just as it would update while loading data in view mode, can make your API simpler. The way pages and blocks are shown in OPE is slightly different. <ul> <li>A page will have a friendly URL in view mode; otherwise, it will have an Episerver URL that includes the content link.</li> <li>A block does not have any friendly URLs, but can be previewed in OPE if you implement an <a href="http://ASP.NET">ASP.NET</a> MVC controller. They will always rely on content links.</li> <li>The <code>beta/contentSaved</code> message includes the content link to the model version that is being edited, but no URL.</li> </ul> The friendly URL always gets the published model, while the content link can get any version of the model. This means that pages will initially get their data with a friendly URL, while blocks get it with a content link. Both will update in OPE using content links. So your API needs to support both cases, and it’s helpful for the client side to expose both. In MusicFestival we use a <a href="https://vuejs.org/v2/guide/mixins.html">Vue.js mixin</a> to set up a <code>model</code> property that represents the serialized page or block model, and automatically registers for the <code>beta/contentSaved</code> message that in turn updates the model with <code>updateModelByContentLink</code>. Block components initiate themselves with the same method, while page components use <code>updateModelByFriendlyUrl</code> instead. The key point is that there is only one instance of the page or block model on the client side, and it’s updated in one place. This allows the client side components to be written as if they weren’t in a CMS. An excerpt from the <code>EpiDataModelMixin</code> shows how it registers for the <code>beta/contentSaved</code> message, how it owns the model as data it makes available to pages and blocks, and which methods it exposes: <pre class="hljs"><code>export default { // registers for the `beta/contentSaved` message watch: { '$epi.isEditable': '_registerContentSavedEvent' }, // it owns the model as data it makes available to pages and blocks data: function () { return { modelLoaded: false, model: {} }; }, // which methods it exposes methods: { updateModelByFriendlyUrl: function (friendlyUrl) { /* Updating a model by friendly URL is done when routing in the SPA. */ }, updateModelByContentLink: function (contentLink) { /* Updating a model by content link is done when something is being edited ('beta/contentSaved') and when previewing a block. */ }, _registerContentSavedEvent(isEditable) { if (isEditable) { window.epi.subscribe('beta/contentSaved', message => { this.updateModelByContentLink(message.contentLink); }); } } } }; </code></pre> See the full source for the <code>epiDataModelMixin.js</code> mixin <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/Mixins/epiDataModelMixin.js">here</a>. The pages rely on friendly URLs, and are loaded by the <code>PageComponentSelector</code>, so it owns the model through the <code>EpiDataModelMixin</code> while getting the page URL from the router as a prop: <pre class="hljs"><code><script> export default { mixins: [EpiDataModelMixin], created() { this.updateModelByFriendlyUrl(this.$props.url); } }; </script> </code></pre> See the full source for the <code>PageComponentSelector.vue</code> component <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/components/PageComponentSelector.vue">here</a>. The blocks rely on content links, and need a view to decide how to preview blocks. In MusicFestival, we have a <code>Preview</code> component that loads multiple instances of <code>BlockComponentSelector</code> in different sizes, so <code>Preview</code> is the component owning the model through the <code>EpiDataModelMixin</code>: <pre class="hljs"><code><script> export default { mixins: [EpiDataModelMixin], created() { this.updateModelByContentLink(this.contentLink); } }; </script> </code></pre> See the full source for the <code>Preview.vue</code> component <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/components/Preview.vue">here</a>. <h2>Avoiding unnecessary Razor files</h2> As you might have seen in our <a href="https://github.com/episerver/AlloyReact/blob/master/AlloyReact/Helpers/HtmlHelpers.cs#L43-L63">AlloyReact template site</a>, or as we’ve seen in partner solutions, it’s common to have a client side component render helper on the server side. They make it easier to get a React, or other, component where one would usually have written HTML in the various */Index.cshtml files. This is sometimes partly because of SEO, but that requires that the client side code is rendered on the server. So usually it’s done because the frontend developer prefers to write all of the visual components separate from the CMS, and then just deliver the page as set of client side resource files. This leads to creating mostly empty <a href="http://ASP.NET">ASP.NET</a> MVC controllers and Razor views that just include one element that is then bootstrapped by the client side: <pre class="hljs"><code>// There's a better way to handle this. @using AlloyTemplates.Models.Blocks @model ThreeKeyFactsBlock @Html.ReactComponent("ThreeKeyFacts", Model) </code></pre> We’ve seen examples where developers have pasted their entire client side code into razor views because they believe that is required to get OPE working, but that is not the case. Read more about it <a href="/link/f80257067ca542288c0b74d4db6ae0c5.aspx">in our developer guide</a>. If you use the concepts we introduced in the previous section, such as an Episerver page having a corresponding client side component, then it’s enough to have one <a href="http://ASP.NET">ASP.NET</a> MVC controller for all pages that will delegate the responsibility of choosing the right page or block view to the client side. The architectural overview described below will show the differences and similarities between rendering blocks and pages. Note that blocks will never be rendered by themselves outside of edit mode. <pre class="hljs"><code>// Handling pages DefaultPageController.cs DefaultPage/Index.cshtml DefaultPage.vue router-view (Vue.js) router.js PageComponentSelector.vue (owns the model) ArtistContainerPage/ArtistDetailsPage/LandingPage.vue // Handling blocks PreviewController.cs Preview/Index.cshtml Preview.vue (owns the model) BlockComponentSelector.vue BuyTicketBlock/ContentBlock/GenericBlock.vue </code></pre> <h3>Handling pages</h3> If all the pages are to be rendered on the client, you can avoid having boilerplate Razor files for each page by having a default page controller that will always load the same Razor view. That view will simply bootstrap the router view used by your client side framework. DefaultPageController.cs See the <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Controllers/DefaultPageController.cs">whole source on github</a>. <pre class="hljs"><code>public class DefaultPageController : PageController<BasePage> { public ViewResult Index(BasePage currentPage) { return View("~/Views/DefaultPage/Index.cshtml", currentPage); } } </code></pre> DefaultPage/Index.cshtml See the <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Views/DefaultPage/Index.cshtml">whole source on github</a>. <pre class="hljs"><code>@model MusicFestival.Template.Models.Pages.BasePage @{ Layout = "~/Views/Shared/_BaseLayout.cshtml"; } <default-page></default-page> </code></pre> <code>BasePage</code> is just an empty abstract class inheriting from <code>EPiServer.Core.PageData</code>. DefaultPage.vue See the <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/components/DefaultPage.vue">whole source on github</a>. <pre class="hljs"><code>// example in Vue.js <template> <router-view></router-view> </template> </code></pre> The <code>router-view</code> component is a part of the <a href="https://router.vuejs.org/">Vue.js router</a> framework and will load the component that matches a route inside of it. Since the <code>PageComponentSelector</code> can render every page component we only need to register this one simple route on the client: router.js See the <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/router.js">whole source on github</a>. <pre class="hljs"><code>routes: [ { path: '*', component: PageComponentSelector } ] </code></pre> PageComponentSelector See the <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/components/PageComponentSelector.vue">whole source on github</a>. The <code>model</code> holds a serialized version of the page data. The helper method <code>getComponentTypeForPage</code> iterates through all globally registered Vue.js components and returns the one with the same name as the <code>contentType</code> of the model. The <code><component></code> element is <a href="https://vuejs.org/v2/guide/components.html#Dynamic-Components">how Vue.js handles dynamic components</a> (basically just a placeholder to load a real component). <pre class="hljs"><code><template> <component :is="getComponentTypeForPage(model)" :url="url" :model="model"></component> </template> <script> export default { methods: { getComponentTypeForPage(model) { // this.$options.components will contain all globally registered components from main.js return getComponentTypeForContent(model, this.$options.components); } } }; </script> </code></pre> See the full source for the <code>getComponentTypeForContent.js</code> <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/api/getComponentTypeForContent.js">here</a>. <h3>Handling blocks</h3> As with pages, the CMS UI is built with the concept of blocks and it’s easier to make a coherent editing experience for your users if your client side components have an equivalent concept. It’s also recommended to have a preview for blocks so your users can still enjoy OPE. The preview page can be done similarly to the default page, and even when it’s a regular <a href="http://ASP.NET">ASP.NET</a> MVC application, it’s only one Razor view for the block preview. To get it to work with blocks, we need a similar concept to select the block component in the SPA as we did for pages, but with some differences. First, you’ll need to figure out the content-link, as blocks don’t have a public URL, and your API will need to return the block type name. The Razor view for the Preview controller will set the content-link. The MusicFestival site uses the ContentDeliveryAPI that will include the block type name in the <code>JSON</code> response so we can use a very similar approach as the <code>PageComponentSelector</code> in our <code>BlockComponentSelector</code>. PreviewController.cs See the <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Controllers/PreviewController.cs">whole source on github</a>. Remember to use the RequireClientResourcesAttribute as described in <a href="/link/4552b6ecd7504771b9f3aae5832cb3a6.aspx">this blog post</a>. <pre class="hljs"><code>[RequireClientResources] public class PreviewController : ActionControllerBase, IRenderTemplate<BlockData> { public ActionResult Index(IContent currentContent) { var startPage = _contentRepository.Get<PageData>(ContentReference.StartPage); var model = new BlockEditPageViewModel(startPage, currentContent); return View(model); } } </code></pre> PreviewBlock.cs See the <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Models/Preview/PreviewBlock.cs">whole source on github</a>. <pre class="hljs"><code>public class PreviewBlock : PageData { public IContent PreviewContent { get; } } </code></pre> Preview/Index.cshtml See the <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Views/Preview/Index.cshtml">whole source on github</a>. For the razor view for the block preview, we need to pass the content link because the client side cannot just look at the URL to load the correct content (as the page can). <pre class="hljs"><code>@model MusicFestival.Template.Models.Preview.BlockEditPageViewModel @{ Layout = "~/Views/Shared/_BaseLayout.cshtml"; } <Preview content-link="@Model.PreviewBlock.PreviewContent.ContentLink"></Preview> </code></pre> Preview.vue See the <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/components/Preview.vue">whole source on github</a>. <pre class="hljs"><code><template> <BlockComponentSelector :model="model"></BlockComponentSelector> </template> <script> export default { props: ['contentLink'], mixins: [EpiDataModelMixin], components: { BlockComponentSelector } }; </script> </code></pre> BlockComponentSelector.vue See the <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/components/BlockComponentSelector.vue">whole source on github</a>. Finally, we come to the <code>BlockComponentSelector</code> that, as you can see, is very similar to the <code>PageComponentSelector</code> that we have shown before. A notable difference is that the <code>BlockComponentSelector</code> does not “own” the model. The reason for that is that the <code>Preview</code> component will render multiple <code>BlockComponentSelector</code> for the same model. <pre class="hljs"><code><template> <component :is="getComponentTypeForBlock(model)" :model="model"></component> </template> <script> export default { props: ['model'], methods: { getComponentTypeForBlock: function (block) { // this.$options.components will contain all globally registered components from main.js // Load the "GenericBlock" in the case that no block is found. return getComponentTypeForContent(block, this.$options.components) || 'GenericBlock'; } } }; </script> </code></pre> See the full source for the <code>getComponentTypeForContent.js</code> <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/api/getComponentTypeForContent.js">here</a>. I hope you can see that there are a lot of advantages to keeping to the concept of one content (page, block, or even media) representing one component on the client side in Episerver. <h2>Related links</h2> Blog series about the template site and SPA sites in OPE <a href="/link/5ccbe4dbd38c4d76a6dc81e838c70f9d.aspx">https://world.episerver.com/blogs/john-philip-johansson/dates/2018/10/introducing-a-new-template-site-for-spas-musicfestival/</a> Template site using the techniques discussed in this blog: <a href="https://github.com/episerver/musicfestival-vue-template/">https://github.com/episerver/musicfestival-vue-template/</a> Documentation on client side rendering in Episerver: <a href="/link/f80257067ca542288c0b74d4db6ae0c5.aspx">https://world.episerver.com/documentation/developer-guides/CMS/editing/on-page-editing-with-client-side-rendering/</a>2018-11-05T07:37:07.0000000Z

Blog post

Routing in a SPA with a working On-Page Editing experienceSince 11.24.0 the features described in this blog post are no longer considered beta features and are available to every user. The code examples have been updated to reflect that. <blockquote> To demonstrate some concepts useful when creating a SPA with working OPE we are releasing a new SPA template site on Github, called MusicFestival, together with a series of blog posts. Don’t be discouraged that the SPA is written in <a href="https://vuejs.org/">Vue.js</a> if you’re using React, Angular or something else, as these concepts will work in any client side framework. <a title="Introducing a new SPA template site: MusicFestival" href="/link/5ccbe4dbd38c4d76a6dc81e838c70f9d.aspx">Introducing a new SPA template site: MusicFestival</a> </blockquote> When creating a SPA and navigating inside the CMS UI, you might notice that the context isn’t what you expect, or that the page navigation tree isn’t updated. <img alt="Example of failing context switching" src="/link/c21c5245ef4748cda3e7b5fcb00d1c5d.aspx" width="970" height="462" /> In this gif we demonstrate that the page tree does not update when clicking links inside the editing iframe. Thanks to ‘Andreas J’ that commented on <a href="/link/4552b6ecd7504771b9f3aae5832cb3a6.aspx">our first OPE and client-side rendering blog post</a> with this scenario. The answer to the scenario presented above is: <ul> <li>Use regular anchor tags in edit mode with the expected URL format.</li> <li>Present page and block models as client side components.</li> </ul> This blog will go in depth on how to create the expected URL formats as there are several things you need to consider and watch out for. We will also show you how to use the new features included in the CMS UI 11.24.0 release to solve the more advanced scenarios. Those features are: <ul> <li>New <code>epiReady</code> message.</li> <li>Updated the global <code>epi</code> object with properties <code>isEditable</code>, <code>inEditMode</code> and <code>ready</code>.</li> </ul> We will talk a lot about routing, so if you’re not very familiar with it see our <a href="/link/8c6833b05a50458383427448e3277d4c.aspx">learning path article for an introduction</a>. <h2>Routing table on the client</h2> When using client side routing, you need to consider URLs on your site. If you want to use a client side routing framework, you are free to write your own routing table and take responsibility for creating URLs and matching them with your content. There are, however, a number of advantages to making sure that you use the same routes in your client side routing as Episerver does when it comes to URLs, so we strongly recommend it. We also recommend that you keep the notion that one URL represents one page model in the CMS. This is the concept that the UI is built upon and following that concept will make the editing experience nicer and easier to get right. The biggest upside to keep the default routing is probably that you can use the URL to get the content JSON that matches the path. You can use a solution similar to the one that Johan Björnfot created called <a href="https://github.com/jbearfoot/ContentDeliveryExtendedRouting">ContentDeliveryExtendedRouting</a> to get content from any Episerver URL by just setting the <code>accept-header</code> to <code>JSON</code>. (You don’t need to use the ContentDeliveryAPI to use his code as long as your API accepts content links and you use the same URLs that Episerver does). Another upside with using the default routing that is easily overlooked, is how to deal with languages and different versions of content. This affects editing and can be complicated to get right with a custom routing implementation. Here is an example of how simple the routing table on the client becomes if the SPA uses the same URLs as Episerver. Simply route all URLs to one component that has the responsibility to load the correct SPA page-component. <pre class="hljs"><code>// example in Vue.js routes: [ { path: '*', component: PageComponentSelector } ] </code></pre> The whole file can be viewed in our <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/router.js">new template site on Github</a>. <h2>Getting the page navigation tree to match the current viewed page</h2> As you noticed in the above GIF, the links you have in your template will look like they work when clicked in OPE, but the page tree and other widgets will not update if you use a framework like <a href="https://router.vuejs.org/">Vue.js router</a>  or <a href="https://reacttraining.com/react-router/">React router</a>. This is because no page request is going to the server, so the CMS UI doesn’t change context We considered adding a communication path for templates to request a page tree update, but then the client would need to know how to map between the Episerver URLs and the sites client side URLs and it’s less work for the template to not duplicate the routing table (see previous section "Routing table on the client"). There are two ways of solving this: <ul> <li>Disable all links, or make them editable, so the user can only navigate the site with the page tree.</li> <li>Keep them working, which we recommend as some users have very large websites.</li> </ul> To make the second option work, you can disable client side routing and instead use regular anchor tags whenever the site is rendered in edit mode. In order for anchor tags to work, you need to make sure that the URL is the correct URL for the mode that the content is rendered in. <img alt="Links" src="/link/b2bc28a55a6348c5b1e48e048cdd8ed3.aspx" width="1186" height="788" /> <h2>Consider the different view modes: View, Edit, Preview</h2> In Episerver, there are three modes available: Edit-, preview- and regular view-mode. A page has different URL in each mode when Episerver resolves them. <ul> <li>View mode: When the content is delivered to the site visitor.</li> </ul> <pre class="hljs"><code>url: "/en/artists/" </code></pre> <ul> <li>Edit mode: When the content is loaded in the CMS UI, and the content is editable in OPE.</li> </ul> <pre class="hljs"><code>url: "/EPiServer/CMS/Content/en/artists,,6_7/?epieditmode=True" </code></pre> <ul> <li>Preview mode: When the content is loaded in the CMS UI, but rendered as it would in View mode.</li> </ul> <pre class="hljs"><code>url: "/EPiServer/CMS/Content/en/artists,,6_7/?epieditmode=False" </code></pre> In a standard site using regular MVC controllers, you can, for example, use something like this to get the current mode for a request: <pre class="hljs"><code>EPiServer.Web.IContextModeResolver contextModeResolver; var currentMode = contextModeResolver.CurrentMode; </code></pre> This option is unfortunately not available in a site using AJAX requests to an API to get the data to render since traditional Episerver routing is not used. This makes it hard to know what kinds of URLs to resolve when serializing the models. URLs resolved by Episerver use a query string parameter called <code>epieditmode</code> to keep track of this. The value will be True if the content is in edit mode. The value will be False if the content is in preview mode. If the value does not exist, we assume that we’re in regular view mode. There are two parts that need this query string: the request from the SPA’s client code and the response from the server’s API. <img alt="Point of views" src="/link/b199fc3329de4b02921508894c9070b5.aspx" width="1217" height="422" /> <h3>Responsibilities of the client</h3> In the SPA, you can figure out what mode it’s loaded in by looking at the <code>epieditmode</code> query string on the <code>window.location</code>. The client should include this information in the requests to the server API. Without regular MVC Razor views, the SPA becomes responsible for rendering the correct mode. It should not render OPE attributes (e.g. <code>data-epi-property-name</code>) in View mode for example. To set the right editing context in CMS UI (to update the page tree, etc), the SPA site needs to have disabled the router links and use regular <code><a></code>-tags, but it also needs to set the correct URL in the <code>src</code> attribute. To save you some work on parsing URL queries, we’re introducing some new properties, including a <code>isEditMode</code>, and a new topic message on the injected <code>epi</code> object. We’ll introduce the <code>epi</code> object in the section called "New features in CMS UI". For the API to respond with URLs for the correct mode, the client needs to send its current mode in the request, such as including it as a query parameter. In our new template site, you can see it looks like this: <pre class="hljs"><code>GET /EPiServer/CMS/Content/en/artists,,6/?epieditmode=True&expand=* HTTP/1.1 Accept: application/json </code></pre> <h3>Responsibilities of the API</h3> For the client to be able to render correct links, the JSON returned by your API needs to have URLs with the content link (including work id) and the right context query on it whenever serializing a page’s URL. Using the <a href="/link/55fe410f4f65482cab72fb59d47c7561.aspx?documentId=cms/11/8F74D57D">IUrlResolver interface</a>, this will be easy. <pre class="hljs"><code>_urlResolver.GetUrl(contentLink, language, new UrlResolverArguments { ContextMode = contextMode }); </code></pre> For example, a response to the request shown above (with query parameter <code>epieditmode=True</code>) would look like this in our new template site: <pre class="hljs"><code>HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Content: { "name": "Artists", "url": "/EPiServer/CMS/Content/en/artists,,6_7/?epieditmode=True" } </code></pre> You can see <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Models/ExtendedContentModelMapper.cs">how this can be implemented when using the ContentDeliveryAPI and the ContentDeliveryExtendedRouting in our new template site</a>. <h3>Compare mode shows two views at the same time</h3> Compare mode is not really a mode of its own since it’s an extension of edit mode that shows two different versions at the same time, but it is still good to consider it since you might need to make some adjustments for that in your client side rendering in order for it to work properly. For instance, you will want to turn off any event handler for the <code>contentSaved</code> topic message in the right hand side iframe so that you don’t update the version shown there when the left iframe is being edited. In version 11.24.0, we’re introducing some new properties, including an <code>isEditable</code> on the injected <code>epi</code> object that can be used to know when to listen to the <code>contentSaved</code> topic message. This we’ll introduce in the section called "New features in CMS UI". Note that compare mode URLs looks the same as edit, which can be confusing when the loaded content version (such as “Published”) is usually rendered as in preview mode. <ul> <li>Compare mode: When the content is loaded in the CMS UI alongside another version of the content that is also being loaded in the CMS UI. The left side view can be editable in OPE if it’s a draft version.</li> </ul> <pre class="hljs"><code>left side (draft) url: "/EPiServer/CMS/Content/en/artists,,6_139/?epieditmode=True" right side (published) url: "/EPiServer/CMS/Content/en/artists,,6_7/?epieditmode=True" </code></pre> <h2>New features in CMS UI 11.24.0</h2> We’re introducing a new event that we call <code>epiReady</code>. This event will be raised as soon as the iframe inside the UI is loaded. The event will contain information regarding if the current content is editable. In addition to that event, we will also set a few properties on the global epi object that is available in edit mode. It’s the same epi object that you use to subscribe to the different events such as <code>contentSaved</code> and the aforementioned <code>epiReady</code>. The epi object will look like this: <pre class="hljs"><code>epi: { isEditable: true, inEditMode: true, ready: true } </code></pre> The object is constructed using the info from the <code>epiReady</code> event and will not get the correct <code>isEditable</code> value until the event has been raised. By looking at the <code>ready</code> property you will know if the beta object has been initialized or not. Here is a sample of how this event and object could be used: <pre class="hljs"><code>const context = { inEditMode: false, isEditable: false }; // Listen to the `epiReady` event to update the `context` property. window.addEventListener('load', () => { // Expect `epi` to be there after the `load` event. If it's not then we're // not in any editing context. if (!window.epi) { return; } function setContext() { // The event only has `isEditable`, but the epi object has both. context.inEditMode = window.epi.inEditMode; context.isEditable = window.epi.isEditable; } // Check for beta and that ready is an actual true value (not just truthy). if (window.epi.ready === true) { // `epiReady` already fired. setContext(); // The subscribe method won't be available in View mode. } else if (window.epi.subscribe) { // Subscribe if the `epiReady` event hasn't happened yet. window.epi.subscribe('epiReady', () => setContext()); } }); </code></pre> <h2>Related links</h2> Template site using the techniques discussed in this blog: <a href="https://github.com/episerver/musicfestival-vue-template/">https://github.com/episerver/musicfestival-vue-template/</a> Documentation on client side rendering in Episerver: <a href="/link/f80257067ca542288c0b74d4db6ae0c5.aspx">https://world.episerver.com/documentation/developer-guides/CMS/editing/on-page-editing-with-client-side-rendering/</a> Learning path documentation on page tree and routing: <a href="/link/8c6833b05a50458383427448e3277d4c.aspx">https://world.episerver.com/documentation/developer-guides/CMS/learning-path/page-tree-and-routing/</a> Documentation on routing: <a href="/link/0981d69123d04f5c9609fb22bd68e10c.aspx">https://world.episerver.com/documentation/developer-guides/CMS/routing/</a>2018-10-30T14:09:23.0000000Z

Blog post

Episerver Image Tools in TinyMCE<a href="https://nuget.episerver.com/package/?id=EPiServer.CMS.TinyMce">EPiServer.CMS.TinyMce</a> versions 2.3.0 and 2.4.0 bring two Image Tools features inside the XHTML editor. Go to media (version 2.3.0) <img alt="Image gotomedia.PNG" src="/link/a61ada03ec994cad8e9348de61560f2e.aspx" /> This new button will make it easier for the editors to locate and navigate to the image that is included in the HTML property. Additionally, after hovering it will show a tooltip with a full path to the image. Drag & Drop from local disk (version 2.4.0) It is possible to drag and drop an image from a local disk directly onto the editor. An image preview will be shown immediately upon dropping while the image is being uploaded to the server. All dropped images are automatically placed in the "For this page" or "For this block" folder.  Please note that although it is technically possible to drag & drop multiple images at the same time, it does not work deterministically. There is a bug reported in TinyMCE <a title="#4055" href="https://github.com/tinymce/tinymce/issues/4055" target="_blank">#4055</a> that EPiServer has already submitted a <a title="Bugfix #4055" href="https://github.com/tinymce/tinymce/pull/4406" target="_blank">bugfix </a> to. The bug is still pending review.   The Image Tools are enabled by the default configuration, but they can be disabled. To disable or re-enable the features, you should use the EnableImageTools/DisableImageTools methods available when you are configuring your properties: <pre class="language-csharp"><code>context.Services.Configure<TinyMceConfiguration>(config => { ... // Disable the image tools config.For<ArticlePage>(t => t.MainBody) .DisableImageTools() ... // Enable the image tools for a property (if the property does not have it already) config.For<ArticlePage>(t => t.MainBody) .EnableImageTools(); ... }</code></pre> The information about enabling and disabling the features is included in the SDK - <a href="/link/bd2ec65225f94701b55beb5bc5bbf70f.aspx#epiplugins">Episerver Plugins</a>.2018-06-18T15:47:28.0000000Z

Blog post

Introducing EPiCommerce.Integration.SampleIntegration testing a EPiServer Commerce site can be tricky. How would you know how to initialize everything in a way so that your tests behaves similar to how your site behaves? In an attempt at answering this question for you I’ve created a sample project for integration testing EPiServer Commerce projects. It’s posted on github.com under the MIT-license and you can find it here: <a href="https://github.com/nicklasisraelsson/EPiCommerce.Integration.Sample" target="_blank">EPiServer Commerce Integration Test Sample</a> This sample project doesn’t use selenium or any other web driver to test the UI but instead it aims to initialize an EPiServer Commerce site in a test context so that you can test your business logic below your UI layer. The README for the project should help you get started but I still want to highlight the requirements. EPiServer Commerce requires the <a href="http://technet.microsoft.com/en-us/library/ms142571.aspx" target="_blank">Full-Text Search feature</a> to be enabled on your SQL server and you need a version that supports <a href="http://technet.microsoft.com/en-us/library/ms175158.aspx" target="_blank">snapshots</a>. The user running the tests also need access to the master database to be able to create databases. I’ve tried isolating most of the database specific code in the <a href="https://github.com/nicklasisraelsson/EPiCommerce.Integration.Sample/blob/master/TestSupport/Database.cs" target="_blank">Database class</a> so that if you want a different approach on how to reset state between tests you can replace that one class.2014-03-07T14:38:49.0000000Z

Blog post

PageEntity for Community 4.0PageEntities is a custom entity that links EPiServer Community functionality (rating, visits, comments etc) to ordinary EPiServer pages. It was first introduced by Per Hemmingson in <a href="http://world.episerver.com/Blogs/Per-Hemmingson/Dates/2009/6/Do-you-want-Community-features-on-your-CMS-pages-PageEntity-to-the-rescue/">this blog post</a> and have since then been a popular addition for several projects. We use it on this website for instance. The problem is that the code attached in his post is for Community 3.2 and doesn’t work together with the new Community 4 because of changes to the API. For details on the API changes, look for the tech note named: <a href="http://world.episerver.com/Documentation/Items/Tech-Notes/EPiServer-Community/EPiServer-Community-32/Migrating-EPiServer-Community-32-to-40-and-EPiServer-Mail-44-to-50/">Migrating EPiServer Community 3.2 to 4.0 and EPiServer Mail 4.4 to 5.0</a> Since last week we’re running Community 4 on world and in order to do the upgrade we needed to update the code for PageEntities. And since I’m such a friendly fellow I thought I’d share the changes made to the rest of the community. Hopefully I can save time for someone looking to do the same upgrade or adding PageEntities to a new community 4 project. <h2>Changes made</h2> The “big” change is that I removed the usage of SiteId in the code completely. Sites have been removed in favor of the category system in Community 4 and since we used the same SiteId for all our saved PageEntities we didn’t really need it. If you need it you need to make the appropriate changes to the code. Most of the changes made were similar to this one: <h3>From:</h3> <div id="codeSnippetWrapper" style="text-align: left; line-height: 12pt; background-color: #f4f4f4; margin: 20px 0px 10px; width: 97.5%; font-family: 'Courier New', courier, monospace; direction: ltr; max-height: 200px; font-size: 8pt; overflow: auto; cursor: text; border: silver 1px solid; padding: 4px;"> <div id="codeSnippet" style="text-align: left; line-height: 12pt; background-color: #f4f4f4; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> <pre style="text-align: left; line-height: 12pt; background-color: white; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 1: DatabaseHandler.RunInTransaction(delegate</pre>  <pre style="text-align: left; line-height: 12pt; background-color: #f4f4f4; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 2: {</pre>  <pre style="text-align: left; line-height: 12pt; background-color: white; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 3: DatabaseHandler.GetScalar("spUpdatePageEntity",</pre>  <pre style="text-align: left; line-height: 12pt; background-color: #f4f4f4; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 4: tpr.ID, (int) tpr.EntityType, tpr.SiteID);</pre>  <pre style="text-align: left; line-height: 12pt; background-color: white; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 5: UpdateEntity(tpr);</pre>  <pre style="text-align: left; line-height: 12pt; background-color: #f4f4f4; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 6: });</pre> </div> </div> <h3>To:</h3> <div id="codeSnippetWrapper" style="text-align: left; line-height: 12pt; background-color: #f4f4f4; margin: 20px 0px 10px; width: 97.5%; font-family: 'Courier New', courier, monospace; direction: ltr; max-height: 200px; font-size: 8pt; overflow: auto; cursor: text; border: silver 1px solid; padding: 4px;"> <div id="codeSnippet" style="text-align: left; line-height: 12pt; background-color: #f4f4f4; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> <pre style="text-align: left; line-height: 12pt; background-color: white; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 1: DatabaseHandler.Instance.RunInTransaction(delegate</pre>  <pre style="text-align: left; line-height: 12pt; background-color: #f4f4f4; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 2: {</pre>  <pre style="text-align: left; line-height: 12pt; background-color: white; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 3: DatabaseHandler.Instance.GetScalar("spUpdatePageEntity",</pre>  <pre style="text-align: left; line-height: 12pt; background-color: #f4f4f4; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 4: tpr.ID, (int) tpr.EntityType);</pre>  <pre style="text-align: left; line-height: 12pt; background-color: white; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 5: UpdateEntity(tpr);</pre>  <pre style="text-align: left; line-height: 12pt; background-color: #f4f4f4; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 6: });</pre> </div> </div> In other words, we started using the new static instances of the handlers. That was needed on several places but you get a lot of help from the compiler when doing this. Another thing that was needed was a couple of methods to the PageEntityProvider class. This is because the interface IEntityProvider had gotten a few more methods. Namely: AddEntityInstance, RemoveEntityInstance, UpdateEntityInstance and GetSupportedOperations. They were all implemented similar to this (the difference is what method to use in the return statement): <div id="codeSnippetWrapper" style="text-align: left; line-height: 12pt; background-color: #f4f4f4; margin: 20px 0px 10px; width: 97.5%; font-family: 'Courier New', courier, monospace; direction: ltr; max-height: 200px; font-size: 8pt; overflow: auto; cursor: text; border: silver 1px solid; padding: 4px;"> <div id="codeSnippet" style="text-align: left; line-height: 12pt; background-color: #f4f4f4; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> <pre style="text-align: left; line-height: 12pt; background-color: white; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 1: public IEntity AddEntityInstance(IEntity entity)</pre>  <pre style="text-align: left; line-height: 12pt; background-color: #f4f4f4; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 2: {</pre>  <pre style="text-align: left; line-height: 12pt; background-color: white; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 3: if (!(entity is PageEntity))</pre>  <pre style="text-align: left; line-height: 12pt; background-color: #f4f4f4; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 4: {</pre>  <pre style="text-align: left; line-height: 12pt; background-color: white; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 5: throw new EPiServer.Common.Exceptions.NonCommittedEntityException(entity);</pre>  <pre style="text-align: left; line-height: 12pt; background-color: #f4f4f4; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 6: }</pre>  <pre style="text-align: left; line-height: 12pt; background-color: white; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 7: return PageEntityHandler.AddPageEntity((PageEntity)entity);</pre>  <pre style="text-align: left; line-height: 12pt; background-color: #f4f4f4; margin: 0em; width: 100%; font-family: 'Courier New', courier, monospace; direction: ltr; color: black; font-size: 8pt; overflow: visible; border-style: none; padding: 0px;"> 8: }</pre> </div> </div> All changes are available in  the attached .zip file at the bottom of this post. <h2>SQL changes</h2> Observe that the SQL script (PageEntityProviderSQL.sql) is changed so that all created stored procedures doesn’t use any SiteId any more. Also note that I included a script to move data from one database to another in the same way that the migration script for community work. That script is called: PageEntity-MoveDataInTblPageEntityWithoutSiteId.sql The script moves all data in your old database to the new excluding any values in the SiteId column. There is no error handling in that script and it requires you to run the PageEntityProviderSQL script first to create the correct table in the new database. Remember to backup any database affected before attempting to run these scripts. The script don’t delete anything, but it’s better to be safe than sorry. <h2>Files</h2> <div id="scid:fb3a1972-4489-4e52-abe7-25a00bb07fdf:efd4e928-0617-40fb-a904-7e5cdc01ef1b" class="wlWriterEditableSmartContent" style="margin: 0px; display: inline; float: none; padding: 0px;"> <a href="/link/4ec0e260c9f7450d8bea5a8398e07487.zip" target="_blank">PageEntity for Community 4</a> </div>2010-11-15T14:01:00.0000000Z

Blog post

EPiServer log: Excluding rows from selected namespacesWhenever I encounter a problem with EPiServer I can't really figure out, usually the first thing I do is <a href="http://world.episerver.com/en/FAQ/Items/How-do-I-create-a-log-in-EPiServer/">create a log</a> while reproducing the error. Logs are one of my best friends when it comes to troubleshooting. Often I don't know what I'm looking for so I set the level to either "Debug" or "All". This will output a lot of information and create large log files really fast. I have no problem with this since I asked for all information available. But some parts of EPiServer are chattier than others and thus create a lot of noise in my logs. I’m especially thinking of the EPiServer.Core.OptimisticCache namespace. It outputs lots of rows similar to these below: <div style="BORDER-RIGHT: gray 1px solid; PADDING-RIGHT: 4px; BORDER-TOP: gray 1px solid; PADDING-LEFT: 4px; FONT-SIZE: 8pt; PADDING-BOTTOM: 4px; MARGIN: 20px 0px 10px; OVERFLOW: auto; BORDER-LEFT: gray 1px solid; WIDTH: 97.5%; CURSOR: text; MAX-HEIGHT: 200px; LINE-HEIGHT: 12pt; PADDING-TOP: 4px; BORDER-BOTTOM: gray 1px solid; FONT-FAMILY: consolas, 'Courier New', courier, monospace; HEIGHT: 39px; BACKGROUND-COLOR: #f4f4f4"> <div style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: #f4f4f4; BORDER-BOTTOM-STYLE: none"><pre style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; MARGIN: 0em; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: white; BORDER-BOTTOM-STYLE: none">2009-01-21 12:17:53,942 [1] INFO EPiServer.Core.OptimisticCache [(null)] - cacheKey=EPChildrenData:3292</pre><pre style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; MARGIN: 0em; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: #f4f4f4; BORDER-BOTTOM-STYLE: none">2009-01-21 12:17:53,942 [1] INFO EPiServer.Core.OptimisticCache [(null)] - cacheKey=EPChildrenData:3292</pre><pre style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; MARGIN: 0em; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: white; BORDER-BOTTOM-STYLE: none">2009-01-21 12:17:53,942 [1] INFO EPiServer.Core.OptimisticCache [(null)] - cacheKey=EPChildrenData:3292, retry 1, calling CacheManager.RuntimeCacheGet for key</pre><pre style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; MARGIN: 0em; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: #f4f4f4; BORDER-BOTTOM-STYLE: none">2009-01-21 12:17:53,942 [1] INFO EPiServer.Core.OptimisticCache [(null)] - cacheKey=EPChildrenData:3292, retry 1, CacheManager.RuntimeCacheGet returned null for key</pre><pre style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; MARGIN: 0em; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: white; BORDER-BOTTOM-STYLE: none">2009-01-21 12:17:53,942 [1] INFO EPiServer.Core.OptimisticCache [(null)] - cacheKey=EPChildrenData:3292, retry 1, returning null</pre><pre style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; MARGIN: 0em; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: #f4f4f4; BORDER-BOTTOM-STYLE: none">2009-01-21 12:17:53,942 [1] INFO EPiServer.Core.OptimisticCache [(null)] - cacheKey=EPChildrenData:3292, inserting a RefCountedEvent object in cache</pre><pre style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; MARGIN: 0em; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: white; BORDER-BOTTOM-STYLE: none">2009-01-21 12:17:53,942 [1] INFO EPiServer.Core.OptimisticCache [(null)] - cacheKey=EPChildrenData:3292, calling ReadAndCacheObject delegate passed</pre><pre style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; MARGIN: 0em; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: #f4f4f4; BORDER-BOTTOM-STYLE: none">2009-01-21 12:17:53,942 [1] INFO EPiServer.Core.OptimisticCache [(null)] - cacheKey=EPChildrenData:3292, ReadAndCacheObject delegate returned object of type TObject</pre></div></div> And even though I’m not quite sure what I’m looking for, I can often rule out if the cache might have anything to do with it or not. So to remove all rows that come from this namespace I just add the following lines to my EPiServerLog.config: <div style="BORDER-RIGHT: gray 1px solid; PADDING-RIGHT: 4px; BORDER-TOP: gray 1px solid; PADDING-LEFT: 4px; FONT-SIZE: 8pt; PADDING-BOTTOM: 4px; MARGIN: 20px 0px 10px; OVERFLOW: auto; BORDER-LEFT: gray 1px solid; WIDTH: 97.5%; CURSOR: text; MAX-HEIGHT: 200px; LINE-HEIGHT: 12pt; PADDING-TOP: 4px; BORDER-BOTTOM: gray 1px solid; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BACKGROUND-COLOR: #f4f4f4"> <div style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: #f4f4f4; BORDER-BOTTOM-STYLE: none"><pre style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; MARGIN: 0em; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: white; BORDER-BOTTOM-STYLE: none"></pre><pre style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; MARGIN: 0em; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: #f4f4f4; BORDER-BOTTOM-STYLE: none"><logger name="EPiServer.Core.OptimisticCache" additivity="false"></pre><pre style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; MARGIN: 0em; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: white; BORDER-BOTTOM-STYLE: none"> <level value="Off"/></pre><pre style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; MARGIN: 0em; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: #f4f4f4; BORDER-BOTTOM-STYLE: none"> <appender-ref ref="fileLogAppender" /></pre><pre style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; MARGIN: 0em; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: white; BORDER-BOTTOM-STYLE: none"></logger></pre></div></div> This helps keep the logs clean from thousands of rows like the ones above and makes it a bit easier to read through. Just remember what namespaces you exclude. At one time or another you might want one of those lines and then you’ll have to change the EPiServerLog.config again. 2009-02-01T15:08:00.0000000Z

Blog post

Scheduler not active when using Extension (X3)When using X3 on your CMS 5 sites (mainly SP2) you might find out that your scheduled jobs doesn't run. When looking at the jobs in admin mode you get this message: "The EPiServer Scheduler Service does not appear to be active, it may have been stopped." On a regular site you follow <a href="http://world.episerver.com/FAQ/Items/Scheduler-does-not-run-scheduled-jobs-automatically/">this FAQ</a> and the scheduler starts to work for your site. But when using X3 this might not work. We've found out that the problem is caused by the installation package. It adds the extension httpmodule on the same row as the scheduler initialization module and thus removing it. Your httpmodules section in web config might look something like this: <div style="BORDER-RIGHT: gray 1px solid; PADDING-RIGHT: 4px; BORDER-TOP: gray 1px solid; PADDING-LEFT: 4px; FONT-SIZE: 8pt; PADDING-BOTTOM: 4px; MARGIN: 20px 0px 10px; OVERFLOW: auto; BORDER-LEFT: gray 1px solid; WIDTH: 97.5%; CURSOR: text; MAX-HEIGHT: 200px; LINE-HEIGHT: 12pt; PADDING-TOP: 4px; BORDER-BOTTOM: gray 1px solid; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BACKGROUND-COLOR: #f4f4f4"><pre style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; MARGIN: 0em; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: #f4f4f4; BORDER-BOTTOM-STYLE: none"><httpModules>  <add name="Dropit.Extension" type="Dropit.Extension.Handlers.HttpModule, Dropit.Extension" /> <add name="WorkflowRuntime" type="EPiServer.WorkflowFoundation.WorkflowSystem, EPiServer.WorkflowFoundation" /> <add name="UrlRewriteModule" type="EPiServer.Web.UrlRewriteModule, EPiServer" /> ... </httpModules></pre></div> To fix this you'll need to manually re-add the scheduler initialization module. After adding it your httpmodules it might look something like this: <div style="BORDER-RIGHT: gray 1px solid; PADDING-RIGHT: 4px; BORDER-TOP: gray 1px solid; PADDING-LEFT: 4px; FONT-SIZE: 8pt; PADDING-BOTTOM: 4px; MARGIN: 20px 0px 10px; OVERFLOW: auto; BORDER-LEFT: gray 1px solid; WIDTH: 97.5%; CURSOR: text; MAX-HEIGHT: 200px; LINE-HEIGHT: 12pt; PADDING-TOP: 4px; BORDER-BOTTOM: gray 1px solid; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BACKGROUND-COLOR: #f4f4f4"><pre style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; MARGIN: 0em; OVERFLOW: visible; WIDTH: 100%; COLOR: black; BORDER-TOP-STYLE: none; LINE-HEIGHT: 12pt; PADDING-TOP: 0px; FONT-FAMILY: consolas, 'Courier New', courier, monospace; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BACKGROUND-COLOR: #f4f4f4; BORDER-BOTTOM-STYLE: none"><httpModules>  <add name="Initializer" type="EPiServer.Scheduler.Initializer, EPiServer.Scheduler" /> <add name="Dropit.Extension" type="Dropit.Extension.Handlers.HttpModule, Dropit.Extension" /> <add name="WorkflowRuntime" type="EPiServer.WorkflowFoundation.WorkflowSystem, EPiServer.WorkflowFoundation" /> <add name="UrlRewriteModule" type="EPiServer.Web.UrlRewriteModule, EPiServer" /> ... </httpModules></pre></div> After adding this you can follow the above mentioned FAQ and your scheduler should now once again be active. 2009-01-22T11:05:00.0000000Z

Blog post