Blogs

DropDownList Category Picker in EPiServer 7

2013-05-17T14:18:00.0000000Z

A client needed the editors to be able to select one category from a SELECT box. I knew there were some built-in controls to make things like this easy in EPiServer 7.

Looking around these two posts helped me to find what I think is the best way:

In my case I needed the children and grandchildren of a configured root category as possible items.

namespace Krompaco.Project.Site
{
    using System.Collections.Generic;
    using EPiServer.DataAbstraction;
    using EPiServer.Shell.ObjectEditing;

    public class CategorySelectionFactory : ISelectionFactory
    {
        public IEnumerable GetSelections(ExtendedMetadata metadata)
        {
            var list = new List<SelectItem>();
            var root = Category.Find(yourIdInteger);

            foreach (Category country in root.Categories)
            {
                list.Add(new SelectItem
                  {
                     Text = country.LocalizedDescription.ToUpper(),
                     Value = country.ID.ToString()
                  });

                foreach (Category region in country.Categories)
                {
                    list.Add(new SelectItem
                      {
                        Text = region.LocalizedDescription,
                        Value = region.ID.ToString()
                      });
                }
            }

            return list;
        }
    }
}

Then you need to do this to make the UIHint mean something. Seems like there are problems having an int TargetType but I can live with having the property stored as a string.

namespace Krompaco.Project.Site
{
    using System;
    using System.Collections.Generic;
    using EPiServer.Shell.ObjectEditing;
    using EPiServer.Shell.ObjectEditing.EditorDescriptors;

    [EditorDescriptorRegistration(
        TargetType = typeof(string),
        UIHint = "project-category-select")]
    public class CategorySelector : EditorDescriptor
    {
        public override void ModifyMetadata(ExtendedMetadata metadata, IEnumerable attributes)
        {
            SelectionFactoryType = typeof(CategorySelectionFactory);
            
            // If on 7.0 and not 7.1 this has a slightly different syntax (more dots)
            ClientEditingClass = "epi-cms/contentediting/editors/SelectionEditor";

            base.ModifyMetadata(metadata, attributes);
        }
    }
}

Then just decorate properties with the same UIHint like this:

[UIHint("project-category-select")]
[Display(
  Name = "Primary category",
  GroupName = SystemTabNames.Content,
  Order = 900)]
public virtual string PrimaryCategoryId { get; set; }

In Edit Mode you'll then get a sleek DropDownList like this.

Unsupported languages: Arabic, Tigrinya or Chinese characters in SiteSeeker search result using EPiServer

2013-05-16T19:38:09.0000000Z

The latest version of the SiteSeeker search engine supports indexing and searching in a variety of different languages; however, languages that are not using the latin alphabet, for instance arabic, hebrew, japanese as well as chinese, cannot be indexed. If … Continue reading →

Texts missing inTinyMCE?

2013-05-16T11:37:48.0000000Z

If all captions and tooltips are missing in tinyMCE, there’s good chance you are using themed CSS. Over the years I’ve learned that EPiServer make some assumptions, that not always applies to your reality. One of them is that it’s assumed your not using themed CSS on your site. There has been some minor issues with themed CSS over the years, and a new one seems to apply to tinyMCE.

When I first configured the site to use tinyMCE, it looked like this:

Firebug to the rescue! Error 500 when loading TinyMCEi18n.aspx canätbe good, so whats the reason?

So how to solve this?

Well, you could edit the aspx-page and turn of theming, but chances are you apply a hot fix or service pack that overwrites your custom changes. I thought a better way was to turn theming off for that specific location using web.config. Since the file resides in /util/, you can solve this by editing the <location path="util">-section as below:

Save the file, and then tinyMCE should look great!

Using the REST API of ImageVault

2013-05-16T09:32:00.0000000Z

In ImageVault 4 we introduced a REST API for the ImageVault Core service. This will show a small example on how to use that.

Javascript

This example uses javascript and the javascript classes that are included in the ImageVault installation (in the UI). I will use the scripts that are located on the beta installation but you can use the ones that are on your installation as well.

We need three scripts, jquery, json2 and ImageVault.Client. ImageVault.Client handles authentication and CORS logic for the app.

<script type="text/javascript" src="https://imagevault.se/beta/ImageVault/Scripts/lib/jquery-1.6.1.js" ></script>
<script type="text/javascript" src="https://imagevault.se/beta/ImageVault/Scripts/lib/json2.js"></script>
<script type="text/javascript" src="https://imagevault.se/beta/ImageVault/Scripts/ImageVault.Client.js"></script>

Client

To connect to core we need the javascript client.

var core = new ImageVault.Client({
 authUrl: "https://imagevault.se/beta/ImageVaultIdp/http.issue",
 realm: "https://imagevault.se:1234",
 username: "demouser",
 password: "P@55w0rd!"
});

The core client is created using the following parameters

authUrl: This is the url to the Idp endpoint that can issue a ticket to be used with the core calls. Authentication uses federated authentication
realm: This is the url to core and also instructs the Idp on who the recipient of the ticket is.
username/password: the username and password of the user.

Authentication

We use federated authentication and to be able to call the services you need to have an authentication ticket. To get the ticket you need to authenticate vs the IdentityProvider (Idp). This is handled by the ImageVault.Client script. Also reissuing of tickets when they exipire are handled by the client script.

API calls to Core

To call the REST API we use the json method of the client that performs an authenticated call to the core.

core.json("MediaService/Find", {
  Filter: { SearchString: searchString },
  Populate: {
    MediaFormats: [
      //Thumbnail format
      {  
        $type: "ImageVault.Common.Data.ThumbnailFormat,ImageVault.Common", 
        Effects:[
          {$type:"ImageVault.Common.Data.Effects.ResizeEffect, ImageVault.Common",Width:200,Height:200,ResizeMode:'ScaleToFill'}
        ]
      }
    ]
  }    
}, function (d) {
  alert(JSON.stringify(d));
});

The json call uses the following parameters

path: The service/method to call. Name of the service is the same as the interface (omit the leading I)
arguments: the arguments to the service method as a javascript object. If the method takes multiple arguments, wrap them in a single object (.e {arg1:'test',arg2:'test2'} )
success callback: The function to call when the service call is done. The argument to the function is the return value of the service method.

The services are documented at the ImageVault API reference documentation. The full ImageVault developer documentation can be found at http://imagevault.se/doc

You can test a fully fledged demo below that uses the ImageVault demo site scripts and content that performs a search and displays the thumbnail media

Demo

5 years of EPiServer World awesomeness

2013-05-10T12:54:34.0000000Z

Celebrating its 5th online anniversary by passing 19000 members, EPiServer World continues to be a hub of great resources for developers, site owners and marketers.

Adding Cross Site Scripting protection in EPiServer CMS with .NET 4.0

2013-05-10T06:31:22.0000000Z

The built-in Request Validation feature in .NET 4.0 can help protect your EPiServer sites from Cross Site Scripting (XSS) attacks.

Render ContentArea with temporarily content

2013-05-08T07:16:31.0000000Z

One nice feature in EPiServer 7 is the ability to render content based on tags and type. But sometimes you want to add temporary items to a collection and then render them. This can be a RSS feed, or if you want to add one link list with and existing ContentArea.

The problem is that temporary items will not be rendered thru the PropertyContentAreaControl. So if you add some temporarily items like some RSS articles it will not render.

You can add IContent to a ContentArea, but internally it is stored as content reference, and the object is not preserved. It basically add the content Reference ID, and then when you render it it gets the content again. That means you cant manipulate the IContent items before you render them. Personally I think this behaviour is a bit odd, and makes it a bit harder to do cool stuff

Create temporarily content

Before it was possible to create pages and add them to a page list. You had to add the ACL to the page so it was not filtered out.

Code Snippet
var page = new TempPageType();
page.Property.Add("PageTypeID", new PropertyNumber(pageID));
page.Property.Add("PageLink", new PropertyPageReference(PageReference.EmptyReference));
 
page.Property.Add("PagePendingPublish", new PropertyBoolean(false));
page.Property.Add("PageWorkStatus",
                    new PropertyNumber(Convert.ToInt32(VersionStatus.Published)));
page.ACL.Add(new AccessControlEntry("Everyone", AccessLevel.Read));

In EPiServer 7 you have to register this page type and also add the PageTypeID to the temporarily page

Code Snippet
var repository = ServiceLocator.Current.GetInstance<IContentTypeRepository<PageType>>();
var pageType = repository.Load(typeof(TempPageType));
var pageID=-1;
if (pageType!=null)
    pageID=pageType.ID;
page.Property.Add("PageTypeID", new PropertyNumber(pageID));

And then register the page type.

Code Snippet
[ContentType(GUID = "454E47D6-BC76-4596-BC03-8BA519BB4650", GroupName = "Default",AvailableInEditMode=false)]
public class TempPageType : SitePageData
{
    [Ignore]
    public virtual object InnerObject { get; set; }
 
    public override EPiServer.Security.ISecurityDescriptor GetSecurityDescriptor()
    {
        if (PageReference.IsNullOrEmpty(PageLink))
            return new OwnSecurityDescriptor();
        return base.GetSecurityDescriptor();
    }
       
}
  public classOwnSecurityDescriptor:ISecurityDescriptor
{
    public AccessLevel GetAccessLevel(IPrincipal principal)
    {
        return AccessLevel.FullAccess;
    }
    public bool HasAccess(IPrincipal principal, AccessLevel access)
    {
        return true;
    }
}

To render

The solution is to make your own render of a List of IContent

Lucky for us it’s still easy to look at the current code using Reflector or some other app.

This code will take a list of IContent and render them accordingly to the tags. So you can use it like this, where Result is a List<IContent>

Code Snippet
  publicbool AddResult2Container(Control container,  string tag, bool add_Ul_Li)
{
    var haveContent = false;
    var result = new RenderContentArea() { Data = Result };
    result.Tag = tag;
    if (add_Ul_Li)
    {
        result.TagName = "ul";
        result.TagChildName = "li";
    }
    container.Controls.Add(result);
    haveContent = result.CreateContent();
    return haveContent;
}

The code that runs is this

Code Snippet
public class RenderContentArea : PlaceHolder
{
    public List<IContent> Data { get; set; }
    public string TagName { get; set; }
    public string TagChildName { get; set; }
 
    public string ItemCssClass { get; set; }
    public string ItemChildCssClass { get; set; }
 
    public string Tag { get; set; }
 
    private ContentControlResolver _contentControlResolver;
    public ContentControlResolver ContentControlResolver
    {
        get
        {
            ContentControlResolver arg_1D_0;
            if ((arg_1D_0 = this._contentControlResolver) == null)
            {
                arg_1D_0 = (this._contentControlResolver = ServiceLocator.Current.GetInstance<ContentControlResolver>());
            }
            return arg_1D_0;
        }
        set
        {
            this._contentControlResolver = value;
        }
    }
 
    protected IList<Control> GetContentRenderers2()
    {
        if (Data == null || Data.Count<IContent>() == 0)
        {
            return new List<Control>();
        }
        string itemTagName = TagChildName;
        string itemCssClass = ItemChildCssClass;
 
        return ResolveContentControls(this, this.Tag, itemCssClass, itemTagName);
    }
    public virtual Injected<TemplateControlLoader> TemplateControlLoader
    {
        get;
        set;
    }
    private WebFormsContentValidator _contentValidator;
    public virtual WebFormsContentValidator ContentValidator
    {
        get
        {
            WebFormsContentValidator arg_1D_0;
            if ((arg_1D_0 = this._contentValidator) == null)
            {
                arg_1D_0 = (this._contentValidator = ServiceLocator.Current.GetInstance<WebFormsContentValidator>());
            }
            return arg_1D_0;
        }
        set
        {
            this._contentValidator = value;
        }
    }
    public virtual IList<Control> ResolveContentControls( Control parentControl, string tag, string itemCssClass, string itemTagName)
    {
 
        IContentFilter filter = new FilterContentForVisitor(TemplateTypeCategories.WebFormsPartial, tag);
        List<Control> list = new List<Control>();
        IEnumerable<IContent> source = Data;
        IEnumerable<IContent> enumerable =
            from c in source
            where  !filter.ShouldFilter(c)
            select c;
        foreach (IContent current in enumerable)
        {
            Control control = this.TemplateControlLoader.Service.LoadControl(HttpContext.Current.ContextBaseOrNull(), current, parentControl.TemplateControl, tag);
            if (this.ContentValidator.ExistInControlHierarchy(parentControl, current, control))
            {
                //if (enableEditFeatures)
                //{
                //    HtmlGenericControl item = this.BuildCircularReferenceControl(current, itemTagName, itemCssClass);
                //    list.Add(item);
                //}
            }
            else
            {
                IVersionable versionable = current as IVersionable;
                if (versionable == null || versionable.Status == VersionStatus.Published)
                {
                    ContentRenderer item2 = new ContentRenderer
                    {
                        CurrentControl = control,
                        CurrentData = current,
                        CurrentContent = current,
                        Tag = tag,
                        CustomTagName = itemTagName,
                        CssClass = itemCssClass,
                        TemplateControlLoader = this.TemplateControlLoader,
                        RenderType =RenderType.Default
                    };
                    list.Add(item2);
                }
            }
        }
        return list;
    }
      
        
    public  bool CreateContent()
    {
          
        string containerTagName = (!string.IsNullOrEmpty(TagName)) ? TagName : "div";
        System.Collections.Generic.IList<Control> contentRenderers = this.GetContentRenderers2();
        Control control = CreateMainContainer(containerTagName);
        foreach (Control current in contentRenderers)
        {
            control.Controls.Add(current);
            ContentRenderer contentRenderer = current as ContentRenderer;
            if (contentRenderer != null)
            {
                contentRenderer.EnsureChildControlsCreated();
            }
        }
        if (contentRenderers.Count > 0)
            return true;
        return false;
         
    }
    protected HtmlGenericControl CreateMainContainer( string containerTagName)
    {
        HtmlGenericControl htmlGenericControl = new HtmlGenericControl(containerTagName);
        this.Controls.Add(htmlGenericControl);
           
        //if (enableEditFeatures)
        //{
        //    base.ApplyEditAttributes();
        //}
        return htmlGenericControl;
    }
        
}

EPiServer 7: Strongly typed page types in FPWC

2013-05-07T13:48:59.0000000Z

No, not really :) FindPagesWithCriteria (FPWC) is still the same beast it always was. For those of us who used PageTypeBuilder a lot, you will have worked with the page type resolver that allowed us to – at the very least – turn a strongly typed page type into a page type ID and feed it into FPWC.

EPiServer 7 provider the same feature as well. For example, let’s say we have a method to get all children of type ‘StandardPage’. We use the content type repository to ‘resolve’ the page type ID:

private IEnumerable<StandardPage> GetPosts()
{
    PropertyCriteriaCollection criterias = new PropertyCriteriaCollection();
    PropertyCriteria criteria = new PropertyCriteria();
    criteria.Condition = CompareCondition.Equal;
    criteria.Name = "PageTypeID";
    criteria.Type = PropertyDataType.PageType;
    criteria.Value = Locate.ContentTypeRepository().Load<StandardPage>().ID.ToString();
    criteria.Required = true;
    criterias.Add(criteria);
    var posts = Locate.PageCriteriaQueryService().FindPagesWithCriteria(CurrentPage.ContentLink as PageReference, criterias).Cast<StandardPage>();
    return EPiServer.Filters.FilterForVisitor.Filter(posts).Cast<StandardPage>();
}

This works, and is as performant as FPWC is, but we have a problem with inheritance. What if we had a ‘DetailPage’ that is inherited from ‘StandardPage’? Because FPWC requires a page type ID, this won’t help us. We’ll only ever get StandardPage items back, never DetailPage ones. We could do two FPWC calls of course, but now we’re getting messy.

So what’s the alternative? In old-style code the temptation would be to grab all the descendants then filter them ‘after the event’. You can do this using LINQ (bearing in mind that it’s actually still enumerating behind the scenes – this is not a highly performant way of doing things). At least the code is clean and we are dealing with real strong types so we respect inheritance – no need for page type IDs.

private IEnumerable<StandardPage> GetPosts()
{
    return EPiServer.Filters.FilterForVisitor.Filter(Locate.ContentRepository().GetDescendents(CurrentPage.ContentLink).Select(pageRef => GetPage(pageRef as PageReference)).Where(page => page is StandardPage)).Cast<StandardPage>();
}

However, there is now a better and badder way to do this. Although the Get<T> method doesn’t like you passing the incorrect page type as the generic type, the GetChildren<T> does automagical filtering for you to get the right type (including inherited types that can cast back to it). In essence, it’s doing pretty much what our code above does, but in less code and – probably – more efficiently:

private IEnumerable<StandardPage> GetPosts()
{
    return EPiServer.Filters.FilterForVisitor.Filter(GetChildren<StandardPage>(CurrentPage.ContentLink)).Cast<StandardPage>();
}

For more detail on this, you can see the related article in the SDK. Note that in all my examples I’m filtering the results for the visitor – this is an often-overlooked and crucial thing that you must do when doing things via the API! Using a PageList or similar web control, if using Web Forms, will do this filtering for you if you treat it nicely.

RSS Reader Block

2013-05-06T21:16:55.0000000Z

Based on EPiServer 7.1

EPiServer customers often want to use RSS on their sites. Some want to create RSS output from their pages, others may want to view it in a dashboard report, and others may simply want to consume a RSS source and syndicate it. Fortunately there are solutions for all of these. In this post however, I’m going to share a simple RSS Reader Block I’ve created. Once added to your site properly the usage is quite simple:

1. Create a new “RSS Reader Block”:

2. Configure the content items you desire:

RSS Feed URL (required) - URL for the RSS feed

Heading (optional) – Heading for the feed

Description Text (optional) – Descriptive text for the feed

Max Count (optional) – Maximum number of items to show in the list

Include Publish Date (optional) – Whether or not to include publish date in the list

3. Preview:

4. Publish

Additional example on Enoteca:

Get the code here…

NuGet Package

Enjoy!

I made use of some of the styling from the Alloy Templates. As a result you may wish to tweak the styling a bit for your own needs. I left some commented out HTML in the view class in case it helps.
The folder structure is based on one that mirrors the Alloy Templates thought installing on an Alloy site is not required.
This NuGet package is a developer Add-on. This means it should be installed through Visual Studio and compiled as part of your project, not through the Add-on store UI in EPiServer.
This is intended as a starting point for you to customize for your project needs. The code is provided “as is” without warranty or guarantee of operation. Use at your own risk.

Localized EPiServer model validation attributes

2013-05-05T14:16:11.0000000Z

When it comes to validation the set of model validation attributes from DataAnnotations namespace in System.ComponentModel namespace is really handy. You can decorate model properties declaratively. [DisplayName("The message")] [Required] public string Message { get; set; } However if you are dealing with multilingual site – you have possibility to specify resource name and type … Read More ...

Create an animating slider with content area

2013-05-03T11:56:00.0000000Z

The content area is a is a list of multiple content references. That should work well for creating a slider, slideshow or whatever you call it. A list of items where not all of them is visible at the same time. There are too many different JavaScript implementations for this. Depending on which you use, you might need to tweak the content area a little. Usually should be a list of items, but some also wants extra containers.

About the overlays

Before we start, let's mention the overlays. Edit mode uses overlays for the editable and visible properties on a page. The overlays are the clickable areas and the drop targets. When a page has loaded in the iframe, the editing base finds all nodes that has a data-epi-property-name attribute. These nodes are passed to a overlayfactory which will create overlay items for the nodes. The overlays are absolutely positioned to cover the corresponding node in the template page. This means that all nodes in the template that should be clickable to edit, must at least occupy some space. Floated elements in the template page can make the overlay get incorrect position and size. As the content area adds container element around each block, it's easy to get the overlay misaligned by put floating styles on the block itself, but not on the block container. A container node with no styling and floated child elements will get zero height. The overlay doesn't take overflow: hidden into the positioning either, which is a common issue when dealing with sliders. The content area uses a special overlay which has child block overlays. This is for sorting in on page edit, actions through context menu and also the message to add blocks or pages when the area is empty.

First attempt to create a slider with a content area

I'll use AnythingSlider as the example and use it in the Alloy templates. This script will create wrap the list in additional container Download it and put it in the Static folder and name it "anythingslider". The examples are for WebForms, Joel wrote about custom rendering in MVC: Custom rendering of content areas.

Add a new content area called SliderContentArea to the start page model (EPiServer.Templates.Alloy.Models.Pages.StartPage)


[Display(	
	GroupName = SystemTabNames.Content,
        Order = 330)]
	[CultureSpecific]
        public virtual ContentArea SliderContentArea { get; set; }

Add the content area to the page template (EPiServer.Templates.Alloy.Views.Pages.StartPageTemplate)

To simplify these examples I put the scripts and styles in the start page template.


<alloy:stylesheetlink runat="server" href="~/Static/anythingslider/css/anythingslider.css" />
<alloy:scriptlink runat="server" src="~/Static/anythingslider/js/jquery.anythingslider.js" />

<style>
    .slider {
    width: 400px;
    height: 240px;
    }

    .slider .mediaimg img {
        width: 100%;
    }

    .slider .border {
        width: 398px;
        height: 238px;
    }
</style>

<!-- row and spanX is for Bootstrap framework -->
<div class="row">
    <div class="span3">
        <!-- property to illustrate problem with overlay --> 
        <episerver:property id="Property3" runat="server" propertyname="TeaserText"></episerver:property>
    </div> 
    <div class="span9"> 
        <!-- render content area as a list -->
        <episerver:property id="Property1" runat="server" propertyname="SliderContentArea"> 
        <rendersettings customtagname="ul" cssclass="slider" childrencustomtag="li" /> </episerver:property>
    </div> 
</div>

<!-- AnythingSlider initialization -->
<script>
    // DOM Ready
    $(function(){
        // Create the slider
        $('.slider').anythingSlider({
            autoPlay:true,
            buildStartStop:false,
            buildNavigation:false,
            enableNavigation:false,
            enableStartStop:false
       });
    });
</script>

Add 5 blocks to content area, use the start page blocks (except the jumbotron block).

Notice that all blocks are shown in a column, no slider yet. The content area overlay is also too big. This is because the slider script is only initialized when page is loaded the first time. When the property is updated with new items, only the dom nodes inside the content area are replaced.

Publish the page and when the page reloads there will be two slider on the page and looks better, except there are two sliders and extra block overlays that appears when the mouse cursor is beside the content area overlay. The teaser text property gets a little less accessible, even though there still are some pixels left to click it. The overlay positioning the blocks overlays over where the actual node is. The double sliders are due to the custom content area in Alloy templates, with max three items per row. Read more about the templates in Ted's post: Templates for EPiServer 7 CMS.

Fix the slider script initialization

Add it full page refresh to get the script render whenever we add a block. This is essential to have the slider be recreated when we add, remove or rearrange blocks.


    public partial class StartPageTemplate : SiteTemplatePage
    {

        protected override void OnLoad(EventArgs e)
        {

            // Trigger full page reload when block is updated in edit mode
            // (requires FullRefreshPropertiesMetaData control in Root.Master)
            var page = Page as PageBase;

            if (page != null)
            {
                if (!page.EditHints.Contains("SliderContentArea"))
                {
                    page.EditHints.Add("SliderContentArea");
                }
            }
        }
    }

Fix the rendering

We can implement a custom content area that fixes the rendering as the normal content area, but it will also support extra rendering options. The RenderSettings is a dictionary and can included not known keys for a more generic content area. This implementation adds support for two extra keys innerCustomTagName and innerCssClass. The downside with custom keys are that you get no intellisense for them. So if you use a slider script that want an extra container around the list, this will do the job for you. Otherwise it'll work as the default content area implementation.

Create new class in EPiServer.Templates.Alloy.Business.WebControls.

Custom content area


using System;
using System.Web.UI.HtmlControls;
using EPiServer.Core;
using EPiServer.Web.PropertyControls;
using EPiServer.Web.WebControls;
using EPiServer.Framework.DataAnnotations;
using EPiServer.Web;

namespace EPiServer.Templates.Alloy.Business.WebControls
{
    /// 
    /// Provides custom rendering of content areas to enable one more level of markup
    /// 
    [TemplateDescriptor(TagString = "SliderContentAreaTag")]
    public class SliderContentAreaControl : PropertyContentAreaControl, IRenderTemplate    
    {

        /// 
        /// Creates block controls for the blocks in the block area. Used when the property is in view mode
        /// or in "on page edit" mode and the PropertyDataControl does not support on page editing.
        /// 
        public override void CreateDefaultControls()
        {
            CreateContentAreaControls(false);
        }

        /// 
        /// Creates the "on page edit" controls with the blocks.
        /// If no block exist, this method will do nothing.
        /// 
        public override void CreateOnPageEditControls()
        {
            CreateContentAreaControls(PropertyIsEditableForCurrentLanguage());
        }

        private void CreateContentAreaControls(bool enableEditFeatures)
        {
            // Get list of block renderers
            var controlList = GetContentRenderers(EnableEditFeaturesForChildren || enableEditFeatures);

            // get outer container tag name
            var containerTagName = !String.IsNullOrWhiteSpace(CustomTagName) ? CustomTagName : "div";

            // get inner container tag name
            var innerContainerTagName = "div";

            // use custom render settings key
            if (RenderSettings.ContainsKey("innerCustomTagName"))
            {
                var tag = (string)RenderSettings["innerCustomTagName"];
                if (!String.IsNullOrWhiteSpace(tag))
                {
                    innerContainerTagName = tag;
                }
            }

            // Create containers
            HtmlGenericControl container = CreateMainContainer(enableEditFeatures, containerTagName);
            HtmlGenericControl innerContainer = new HtmlGenericControl(innerContainerTagName);

            // add class for inner
            // use custom render settings key for classs
            if (RenderSettings.ContainsKey("innerCssClass"))
            {
                var cssClass = (string)RenderSettings["innerCssClass"];
                if (!String.IsNullOrWhiteSpace(cssClass))
                {
                    innerContainer.Attributes.Add("class", cssClass);
                }
            }

            // Add controls
            this.Controls.Add(container);
            container.Controls.Add(innerContainer);

            foreach (ContentRenderer block in controlList)
            {
                innerContainer.Controls.Add(block);
                block.EnsureChildControlsCreated();
            }
        }

        /// The default implementation simply checks the IsNull property
        protected override bool ShouldCreateDefaultControls()
        {
            return PropertyData != null && !PropertyData.IsNull;
        }
    }
}

Use the custom content area for slider property

Add Tag to render settings on Change the property name to get the correct rendering, now we don't get the extra classes used for the Alloy content areas and the blocks aren't wrapped on multiple rows. I also added support for setting an innerContainer to the inner class. Note the use of Tag to make sure we get SliderContentAreaControl and not the SitePropertyContentAreaControl (which is the default ).

Reload edit and there's only one slider, but the overlay for the content area is now even worse. If look at the page on the site the structure this for the slider:

AnythingSlider wraps the slider in two divs, the inner is a viewport with overflow hidden. Let's look at the rendered slider i edit mode. I usually hold down control/command and click on a page in the top navigation inside the preview frame. The template page will be opened in a new tab with the needed query string parameters ( .../,,4/?id=4&epieditmode=true ). Inspect the slider and we'll see that the data-epi-attributes are attached to the slider UL. This causes the overlay to be too big because it will position itself according to the UL. We want the epi attributes to be on the anythingSlider div.

Move the edit attributes

Let's add some script to fix this. The script in the template page will execute before the edit UI finds the editable nodes, so we can move the attributes without any problem.


     // DOM Ready
     $(function () {

        // Create the slider
         $('.slider').anythingSlider({
             autoPlay: true,
             buildStartStop: false,
             buildNavigation: false,
             enableNavigation: false,
             enableStartStop: false
         }).each(function (index, item) {

            // move all data-epi-attributes to the injected parent slider node
             var i;
             var epiAttributes = {};
             var attr;
             var name;

             for (i = item.attributes.length - 1; i >= 0; i--) {

                 attr = item.attributes[i];
                 name = attr.nodeName;

                // starts with "data-epi"?
                 if (name.indexOf("data-epi-") === 0) {
                     epiAttributes[name] = attr.nodeValue;
                     item.removeAttribute(name);
                     attr = null;
                }
             }

            // set attributes to parent node
             $(item).parents(".anythingSlider").attr(epiAttributes);
         });
     });

Now we'll get a better sized overlay for the content area. The overlay is now only calculated for the outer property. But there's still the block overlays that are in the way. We can use the default property overlay to remove the block overlays.

Use default overlay

Create an editor descriptor

Create a new class called SliderPropertyContentAreaEditorDescriptor.cs. In the editor descriptor we can specify a custom overlay, or use default by not specify any at all. The default overlay can't handle list items and we must remove drag and drop support.


using EPiServer.Core;
using EPiServer.Shell.ObjectEditing;
using EPiServer.Shell.ObjectEditing.EditorDescriptors;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace EPiServer.Templates.Alloy.Business.EditorDescriptors
{
    [EditorDescriptorRegistration(TargetType = typeof(ContentArea), UIHint = "SliderPropertyContentArea")]
    public class SliderPropertyContentAreaEditorDescriptor : EditorDescriptor
    {
        public SliderPropertyContentAreaEditorDescriptor()
        {
            ClientEditingClass = "epi-cms.contentediting.editors.ContentAreaEditor";
        }

        public override void ModifyMetadata(ExtendedMetadata metadata, IEnumerable attributes)
        {
            base.ModifyMetadata(metadata, attributes);

            // cancel DnD
            metadata.AdditionalValues["DropTargetType"] = new string[] { };
        }
    }
}

Use the editor descriptor for the slider property

Annotate the model with UIHint to get the custom overlay in edit mode. It's the key to be able to use this for a specific property in the model.


        [UIHint("SliderPropertyContentArea")]
        public virtual ContentArea SliderContentArea { get; set; }

The final result

Reload edit to get the final result. Items can be added, removed and reordered in the flyout editor.

Programing changes required while Upgrading Episerver Commerce R2 to R2 SP1 and R2SP2 - Part 2

2013-05-03T07:20:00.0000000Z

I will be thankful if you can add your experiences also in comments so others developers will have an idea of all issues in one basket. It will help you to estimate time required for upgrading also depending on your projects.

7: error related to loading EPiServer.Factory dll
Disable the processPaymentActivity in POSaveChangesWorkflow if you have the error related to loading EPiServer.Factory dll.

8: WOrkflow changes required if using some custom workflows
Add the SplitShipment activity to CartPrepareWorfklow. Remove any payments / shipment before calling CartPrepareWorkflow.

9: Backward compatability issue.
In Commerce R2SP1, the CalculateTotalActivity calculates the ExtendedPrice following PlacePrice.
item.ExtendedPrice = item.PlacedPrice * item.Quantity - item.LineItemDiscountAmount - item.OrderLevelDiscountAmount;
subTotal += item.PlacedPrice * item.Quantity - item.LineItemDiscountAmount;

It proved a nightmare for me as all taxes and discounts were wrong and it took long to understand this. In 1.0 SP1, the ExtendedPrice assessed by ListPrice.
item.ExtendedPrice = item.ListPrice * item.Quantity - item.LineItemDiscountAmount -item.OrderLevelDiscountAmount;
subTotal += item.ListPrice * item.Quantity - item.LineItemDiscountAmount;

if using custom cartprepare workflows then change the code in Custom CarePrepareWorkflow back to ListPrice to show the correct price. Check Front Site which field you are using using also.

10: R2SP2 setup always fails if there is some failure first time.
Issue: If the SP2 automated update fails then the Tools.zip file is removed during the rollback routine. Once this file has been removed any future attempts to run the update will fail due to this file being missing. Therefore before continuing make a backup of this file.

Fix: For R2SP2 Backup ‘<website root>\MediachaseECF\Tools.zip’

11: Commerce Manager Issue:
Issue: On Migrating to R2SP2 I got an issue in Commerce Manager. It was not loading Meta classes and was giving exception as below
[IndexOutOfRangeException: ParameterIndex] System.Data.ProviderBase.FieldNameLookup.GetOrdinal(String fieldName) +6277902 System.Data.SqlClient.SqlDataReader.GetOrdinal(String name) +249 System.Data.SqlClient.SqlDataReader.get_Item(String name) +23 Mediachase.MetaDataPlus.Configurator.MetaField.GetList(MetaClass metaClass) +404 Mediachase.Commerce.Manager.Core.MetaData.Admin.MetaClassesControl.BindItemsGrid(Int32 id) +646

Fix: Deploy Some SPs manually on DB. Find Unzip Mediachase.ECF.SDK.5.2.zip under C:\Program Files (x86)\EPiServer\CMS\6.1.379.0\Install\Modules\EPiServer Commerce 1.1.2.62\MediachaseECF and Unzip it at location e.g. E:\InstallSP2\Mediachase.ECF.SDK.5.2 and execute below scripts
C:\Program Files (x86)\EPiServer\CMS\6.1.379.0\Install\Modules\EPiServer Commerce 1.1.2.62\Setup\cms_db_upgrade.sql
E:\InstallSP2\Mediachase.ECF.SDK.5.2\Data\DeploymentPackage\SqlScripts\Update\ecf_db_ApplicationSystem_update.sql
E:\InstallSP2\Mediachase.ECF.SDK.5.2\Data\DeploymentPackage\SqlScripts\Update\ecf_db_BusinessFoundation_update.sql
E:\InstallSP2\Mediachase.ECF.SDK.5.2\Data\DeploymentPackage\SqlScripts\Update\ecf_db_CatalogSystem_update.sql
E:\InstallSP2\Mediachase.ECF.SDK.5.2\Data\DeploymentPackage\SqlScripts\Update\ecf_db_MarketingSystem_update.sql
E:\InstallSP2\Mediachase.ECF.SDK.5.2\Data\DeploymentPackage\SqlScripts\Update\ecf_db_MetaDataSystem_update.sql
E:\InstallSP2\Mediachase.ECF.SDK.5.2\Data\DeploymentPackage\SqlScripts\Update\ecf_db_OrderSystem_update.sql
E:\InstallSP2\Mediachase.ECF.SDK.5.2\Data\DeploymentPackage\SqlScripts\Update\ecf_db_Reporting_update.sql
E:\InstallSP2\Mediachase.ECF.SDK.5.2\Data\DeploymentPackage\SqlScripts\Update\ecf_db_SecuritySystem_update.sql
E:\InstallSP2\Mediachase.ECF.SDK.5.2\Data\DeploymentPackage\SqlScripts\Update\ecf_db_Users_upgrade.sql
C:\Program Files (x86)\EPiServer\CMS\6.1.379.0\Install\Modules\EPiServer Commerce 1.1.2.62\Setup\ecf_products_ProductsQuery.sql

PageType Usage Plugin with Recent Pages for each PageType

2013-05-02T10:31:00.0000000Z

To get more insight in the production environment of the client, we needed some information on the usage of PageTypes and the number of pages for each PageType. Further, in case of troubleshooting or support we needed a way to quickly retrieve the URL of a page for a given PageType. The simplest approach was to build a small admin plugin that summarizes this information in an extensive but generic way without the need to look up or manually query for certain pages. This post will show you how the plugin was set up and what the end result looks like.

The main part of the plugin is a GuiPlugin that targets the PlugInArea.AdminMenu. I’ll show you how the page layout was setup and how the code behind looks like. Further we need a few helper classes that retrieve the actual data from the EPiServer database.

End result

Let’s start with the end result. I’ve used the AlloyTech templates for this demo. Below you’ll see two screenshots. The first displays the statistics for each PageType and the second displays the page URLs for each PageType.

Figure 1: Page Type statistics

Figure 2: Recent pages for each PageType

Page Layout

Now you’ve seen the end result, we’ll get into how this plugin is created. We’ll start with the page layout first.

        1: <asp:Content ContentPlaceHolderID="FullRegion" runat="server">

       2:     

       3:     <EPiServerUI:TabStrip runat="server" id="actionTab" GeneratesPostBack="False" targetid="tabView">

       4:             <EPiServerUI:Tab Text="Page Type Usage" runat="server" ID="TabUsage" Sticky="true"/>

       5:             <EPiServerUI:Tab Text="Pages" runat="server" ID="TabPages" Sticky="true"/>

       6:     </EPiServerUI:TabStrip>

       7:     

       8:     <asp:Panel runat="server" id="tabView">

       9:         <asp:Panel runat="server" ID="Usage" CssClass="epi-contentContainer epi-padding">

  

            <h1>Page Type Usage</h1>

            <asp:GridView ID="PageTypeGridView" runat="server" 

                AutoGenerateColumns="false" AllowSorting="true" AllowPaging="false"

                Width="100%" OnSorting="PageTypeGridViewSorting">

                <Columns>

                    <asp:BoundField DataField="PageTypeId" HeaderText="PageTypeId" SortExpression="PageTypeId"  />

                    <asp:BoundField DataField="PageTypeName" HeaderText="PageTypeName" SortExpression="PageTypeName" />

                    <asp:BoundField DataField="CountPages" HeaderText="CountPages" SortExpression="CountPages"  />

                    <asp:BoundField DataField="CountWorkPages" HeaderText="CountWorkPages" SortExpression="CountWorkPages" />

                </Columns>

            </asp:GridView>

        </asp:Panel>

  

        <asp:Panel runat="server" ID="Pages" CssClass="epi-padding">

            <h1>Pages by PageType</h1>

            <asp:Literal runat="server" ID="PageUrlsLiteral" />

        </asp:Panel>

  

    </asp:Panel>

</asp:Content>

The page layout consists of a TabStrip with two Tabs. We’ll use the first tab for the statistical part and the second tab for the page URLs part. In order to get the Tabs working we’ll need two Panels. The first panel, for our statistical part, uses a GridView with four columns for PageTypeId, PageTypeName, the number of pages, and the number of work pages. Of course the amount of information of each PageType could be extended, but for now this already provides some insight in the way PageTypes are being used in the production environment.

The second part lists the most recent pages for each PageType. We’ll construct the complete listing from code behind which will be places in the PageUrlsLiteral. Building html from a code behind of course is never the best approach, but it’ll do for now. I’ll get into the page URLs in more detail later on.

Plugin code behind

The second part is setting up our code behind for the GuiPlugin.

       1: [GuiPlugIn(

       2:     DisplayName = "Page Type Usage", 

       3:     Description = "Displays statistics and actual pages for each page type", 

       4:     Area = PlugInArea.AdminMenu, 

       5:     Url = "~/Business/PageTypeStats/PageTypeStatsPlugin.aspx")]

       6: public partial class PageTypeStatsPlugin : SystemPageBase

       7: {

       8:     private readonly EPiServerSqlHelper _ePiServerSqlHelper = new EPiServerSqlHelper();

       9:  

    protected override void OnPreInit(EventArgs e)

    {

        base.OnPreInit(e);

        // Set system masterpage

        this.MasterPageFile = ResolveUrlFromUI("MasterPages/EPiServerUI.master");

    }

  

    protected override void OnInit(EventArgs e)

    {

        if (!EPiServer.Security.PrincipalInfo.HasEditAccess)

        {

            Response.Write("You do not have access rights to this page");

            Response.End();

        }

    }

  

    protected override void OnLoad(EventArgs e)

    {

        base.OnLoad(e);

        BindPageTypes();

    }

  

    protected void BindPageTypes()

    {

        List<PageTypeUsage> list = _ePiServerSqlHelper.GetPageTypeUsage();

  

        PageTypeGridView.DataSource = list;

        PageTypeGridView.AllowPaging = false;

        PageTypeGridView.DataBind();

  

        PageUrlsLiteral.Text = GetPageUrls();

    }

  

    protected string GetPageUrls()

    {

        List<PageUrlByPageType> list = _ePiServerSqlHelper.GetPageUrlByPageType();

  

        const string colgroupFormat = "<colgroup><col /><col style='width:50px;' /><col style='width:50px;' /></colgroup>";

        const string headerFormat = "<tr><th>{0}</th><th>{1}</th><th>{2}</th></tr>";

        const string pageTypeFormat = "<tr style='background-color:#DEDEDE;'><td>{0}</td><td>{1}</td><td>{2}</td></tr>";

        const string pageFormat = "<tr><td colspan='3'>{0}</td></tr>";

  

        StringBuilder sb = new StringBuilder();

        sb.Append("<table cellspacing='0' border='0' style='border-style:None;width:100%;border-collapse:collapse;' class='epi-default epi-default-legacy'>");

        sb.Append(colgroupFormat);

        sb.AppendFormat(headerFormat, "Name", "PageTypeID", "CountPages");

  

        foreach (var pageUrlByPageType in list)

        {

            sb.AppendFormat(pageTypeFormat, pageUrlByPageType.PageTypeName,

                pageUrlByPageType.PageTypeId, pageUrlByPageType.CountPages);

  

            foreach (var pageUrls in pageUrlByPageType.PageUrls)

            {

                sb.AppendFormat(pageFormat, pageUrls.PageUrl);

            }

        }

        sb.Append("</table>");

  

        return sb.ToString();

    }

}

There is probably more in depth information available on how to set up a GuiPlugin, so I won’t be covering all the basics here but I’ll try to keep this short. Limited to five steps actually.

First you add the GuiPlugin attribute on the class.
In the OnPreInit method you assign the correct masterpage.
In the OnInit method we’ll limit access to the plugin to edit rights.
The BindPageTypes method is called from the OnLoad method and retrieves the data and assigns the data to the GridView.
The GetPageUrls method retrieves the data for our second tab, the actual URLs for the pages. This retrieves a collection, iterates over the results and build the html for our list which is then assigned to our literal placeholder.

While our GuiPlugin has been set up with these five steps, we still need to cover the actual retrieval of the data required for the PageType information we want to expose.

Query the database

There are three basic queries needed to retrieve all the information needed. The three queries are mentioned below.

       1: private const string SqlPageTypeUsage = @"SELECT pt.pkID AS Id, pt.Name AS Name, 

       2:         pt.Filename AS FileName, COUNT(p.pkID) AS PageCount 

       3:         FROM tblPage AS p RIGHT OUTER JOIN tblPageType AS pt ON p.fkPageTypeID = pt.pkID 

       4:         GROUP BY pt.Name, pt.Filename, pt.SortOrder, pt.pkID 

       5:         ORDER BY pt.Name, pt.SortOrder";

       6:  

       7: private const string SqlCountWorkPages = @"SELECT COUNT(*) AS PageCount FROM tblWorkPage 

       8:         INNER JOIN tblPage ON tblWorkPage.fkPageID = tblPage.pkID 

       9:         WHERE (tblPage.fkPageTypeID = {0})";

      10:  

      11: private const string SqlTop10PagesByPageType = @"SELECT TOP 10 [pkID] AS Id 

      12:         FROM tblPage WHERE Deleted='0' AND PendingPublish='0' AND fkPageTypeID = '{0}' 

      13:         ORDER BY pkID DESC";

      14:  

      15:

The first query ‘SqlPageTypeUsage’ selects the information from tblPage and tblPageType and groups this on PageType. At this point we have most of the information on the first tab, the statistical information.

Further the information is extended with the number of workPages. The second query ‘SqlCountWorkPages’ will retrieve this information from tblWorkPage.

The third query ‘SqlTop10PagesByPageType’ retrieves the top 10 pages from tblPage on the given PageType. I’ve ordered this on the Page ID, since the most recent pages will have the newest ID. Of course you could order it on change date or publish date of the page version, but at this point ordering on ID gives us a good enough insight in the recent pages.

Domain objects

Next we defined three simple objects to hold the data which we can use in our plugin. These are PageTypeUsage which will hold the statistical tab, PageUrlByPageType and PageUrls to hold the recent pages for each PageType.

       1: public class PageTypeUsage

       2: {

       3:     public string PageTypeName { get; set; }

       4:     public int PageTypeId { get; set; }

       5:     public string FileName { get; set; }

       6:     public int CountPages { get; set; }

       7:     public int CountWorkPages { get; set; }

       8: }

       9:  

      10: public class PageUrlByPageType

      11: {

      12:     public string PageTypeName { get; set; }

      13:     public int PageTypeId { get; set; }

      14:     public int CountPages { get; set; }

      15:     public List<PageUrls> PageUrls { get; set; }

      16: }

      17:  

      18: public class PageUrls

      19: {

      20:     public int PageId { get; set; }

      21:     public string PageUrl { get; set; }

      22: }

      23:

Retrieve the data

The next part is the method GetPageTypeUsage which executes the SQL statement and parses en returns the results. We check if the PageType has a filename and exclude the sysrecylebin and sysroot. Further we call the SQL statement to count the number of WorkPages.

       1: /// <summary>

       2: /// Gets the usage of pagetypes.

       3: /// </summary>

       4: /// <returns></returns>

       5: public List<PageTypeUsage> GetPageTypeUsage()

       6: {

       7:     List<PageTypeUsage> results = new List<PageTypeUsage>();

       8:     SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings["EPiServerDB"].ConnectionString);

       9:     try

    {

        SqlCommand cmd = conn.CreateCommand();

        cmd.CommandType = CommandType.Text;

        cmd.CommandText = SqlPageTypeUsage;

        conn.Open();

  

        using (IDataReader dataReader = cmd.ExecuteReader())

        {

            while (dataReader.Read())

            {

                int id;

                if (!int.TryParse(dataReader["Id"].ToString(), out id))

                {

                    Logger.Error("Error parsing Id");

                    continue;

                }

  

                int pageCount;

                if (!int.TryParse(dataReader["PageCount"].ToString(), out pageCount))

                {

                    Logger.Error("Error parsing PageCount");

                    continue;

                }

  

                if (dataReader["FileName"] == null)

                {

                    Logger.Error("Error parsing FileName");

                    continue;

                }

  

                if (dataReader["name"].ToString().ToLower() == "sysrecyclebin"

                    || dataReader["name"].ToString().ToLower() == "sysroot")

                {

                    continue;

                }

  

                PageTypeUsage pageTypeUsage = new PageTypeUsage

                    {

                        PageTypeId = id,

                        PageTypeName = (string)dataReader["Name"],

                        FileName = (string)dataReader["FileName"],

                        CountPages = pageCount,

                        CountWorkPages = GetNumberOfPagesForPageTypeFromDatabase(id, SqlCountWorkPages)

                    };

  

                results.Add(pageTypeUsage);

            }

        }

    }

    catch (Exception ex)

    {

        const string errorMessage = "Error occured retrieving pagetype usage";

        Logger.Error(errorMessage);

        throw new Exception(errorMessage, ex);

    }

    finally

    {

        conn.Close();

    }

  

    return results;

}

  

/// <summary>

/// Gets the number of pages a for page type from database.

/// </summary>

/// <param name="pageTypeId">Page type id to count pages for</param>

/// <param name="query">Query to run against database</param>

/// <returns></returns>

private static int GetNumberOfPagesForPageTypeFromDatabase(int pageTypeId, string query)

{

    SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings["EPiServerDB"].ConnectionString);

    SqlCommand cmd = conn.CreateCommand();

    cmd.CommandType = CommandType.Text;

    cmd.CommandText = string.Format(query, pageTypeId);

    conn.Open();

    object pageCount = cmd.ExecuteScalar();

    conn.Close();

  

    return (int)pageCount;

}



Finally to retrieve the pages for each PageType we also execute the SQL statement and return the results. The first is similar to the above code when retrieving the PageTypes. For each PageType we call the GetTop10PagesByPageType method that collects the recent pages for the PageType. For each retrieved Page we also need to construct the absolute URL. In the method ‘GetUrlFromPageId’ we take in a page id and convert that to the absolute URL of the page.

       1: public List<PageUrlByPageType> GetPageUrlByPageType()

       2: {

       3:     List<PageUrlByPageType> results = new List<PageUrlByPageType>();

       4:     SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings["EPiServerDB"].ConnectionString);

       5:     try

       6:     {

       7:         SqlCommand cmd = conn.CreateCommand();

       8:         cmd.CommandType = CommandType.Text;

       9:         cmd.CommandText = SqlPageTypeUsage;

        conn.Open();

  

        using (IDataReader dataReader = cmd.ExecuteReader())

        {

            while (dataReader.Read())

            {

                int id;

                if (!int.TryParse(dataReader["Id"].ToString(), out id))

                {

                    Logger.Error("Error parsing Id");

                    continue;

                }

  

                int pageCount;

                if (!int.TryParse(dataReader["PageCount"].ToString(), out pageCount))

                {

                    Logger.Error("Error parsing PageCount");

                    continue;

                }

  

                if (dataReader["name"] == null)

                {

                    Logger.Error("Error parsing Name");

                    continue;

                }

  

                if (dataReader["name"].ToString().ToLower() == "sysrecyclebin"

                    || dataReader["name"].ToString().ToLower() == "sysroot")

                {

                    continue;

                }

  

                PageUrlByPageType pageUrlByPageType = new PageUrlByPageType

                    {

                        PageTypeId = id,

                        PageTypeName = (string)dataReader["name"],

                        CountPages = pageCount,

                        PageUrls = GetTop10PagesByPageType(id)

                    };

  

                results.Add(pageUrlByPageType);

            }

        }

    }

    catch (Exception ex)

    {

        const string errorMessage = "Error occured retrieving pagetype usage";

        Logger.Error(errorMessage);

        throw new Exception(errorMessage, ex);

    }

    finally

    {

        conn.Close();

    }

  

    return results;

}

  

/// <summary>

/// Gets the top 10 pages for a pagetype

/// </summary>

/// <returns></returns>

public List<PageUrls> GetTop10PagesByPageType(int pageTypeId)

{

    List<PageUrls> results = new List<PageUrls>();

    SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings["EPiServerDB"].ConnectionString);

    try

    {

        SqlCommand cmd = conn.CreateCommand();

        cmd.CommandType = CommandType.Text;

        cmd.CommandText = string.Format(SqlTop10PagesByPageType, pageTypeId);

        conn.Open();

  

        using (IDataReader dataReader = cmd.ExecuteReader())

        {

            while (dataReader.Read())

            {

                int id;

                if (!int.TryParse(dataReader["Id"].ToString(), out id))

                {

                    Logger.Error("Error parsing Id");

                    continue;

                }

  

                string url = GetUrlFromPageId(id);

                if (string.IsNullOrEmpty(url))

                {

                    continue;

                }

                PageUrls pageUrls = new PageUrls

                    {

                        PageId = id,

                        PageUrl = url

                    };

  

                results.Add(pageUrls);

            }

        }

    }

    catch (Exception ex)

    {

        const string errorMessage = "Error occured retrieving Top10PagesByPageType";

        Logger.Error(errorMessage);

        throw new Exception(errorMessage, ex);

    }

    finally

    {

        conn.Close();

    }

  

    return results;

}

  

protected string GetUrlFromPageId(int id)

{

    PageData page = DataFactory.Instance.GetPage(new PageReference(id));

    if (page.LinkType == PageShortcutType.External)

    {

        return null;

    }

  

    UrlBuilder ub = new UrlBuilder(page.LinkURL);

  

    EPiServer.Web.FriendlyUrlRewriteProvider urm = new EPiServer.Web.FriendlyUrlRewriteProvider();

    urm.ConvertToExternal(ub, page.PageLink, Encoding.UTF8);

  

    string siteUrl = EPiServer.Configuration.Settings.Instance.SiteUrl.AbsoluteUri;

    if (siteUrl.EndsWith("/"))

    {

        siteUrl = siteUrl.TrimEnd('/');

    }

    return string.Concat(siteUrl, ub.Uri.ToString());

}



Conclusion

That’s it. In the above post I’ve explained the use of the plugin and how you can develop it. This plugin has proven to be very useful in support for any client question on pages, and for debugging purposes as well. This plugin provides a good insight in the way your editors are using the defined PageTypes and how they use them to create pages. Hopefully this post has helped you to understand the basics and explained the use of it in everyday production environments.

Programing changes required while Upgrading Episerver Commerce R2 to R2SP1 and R2SP2 - Part 1

2013-05-02T09:03:57.0000000Z

Below is summary of issue that we have faced in upgrading different sites from R2 to R2SP1 and R2SP2.

Basic steps

http://world.episerver.com/Documentation/Items/Installation-Instructions/EPiServer-Commerce/Upgrading-EPiServer-Commerce-from-version-1-R2-to-1-R2-SP1-/
And
http://world.episerver.com/Documentation/Items/Installation-Instructions/EPiServer-Commerce/Upgrading-EPiServer-Commerce-from-version-1-R2-SP1-to-1-R2-SP2-/

Breaking changes:

1 - Issue:
If you try to import the business foundation object / meta-class but you get Access Denied exception. Please check the access to the path
%CommerceManager%\\app_data\\ImportExport\\Commerce Manager\\metadata'.

Fix:
If this folder doesn’t exist, please create it.

2 - IShippingGateway:

Issue:
Backward compatability Issue. In Commerce R2SP1, IShippingGateway required implement ShippingRate GetRate(Guid methodId, Shipment shipment, ref string message), not ShippingRate GetRate(Guid methodId, LineItem[] items, ref string message).

Fix:
Therefore you need to add the new implementation for GetRate in your custom ShippingGateway and change all the call to GetRate function. Then rebuild the solution.

3 - Browsing the site and see the error:
Issue:
The Type 'EPiServer.Business.Commerce.CommerceSettings' needs to be remapped in the Dynamic Data Store, see the Errors collection for more information.

Fix:
Remapping can be done by applying the EPiServer.Data.Dynamic.EPiServerDataStoreAttribute attribute to the type,
setting its AutomaticallyRemapStore property to true and ensuring the <episerver.dataStore><dataStore> autoRemapStores attribute in web.config is set to true (or is not defined).
Alternatively call the Upgrade-EPiRemapDDSTypes cmdlet from Powershell.

Please run these commands in PowerShell:
Add-PSSnapin EPiServer.Framework.Install.6.2.267.1
Upgrade-EPiRemapDDSTypes -ApplicationPath $applicationPath -Type "EPiServer.Business.Commerce.CommerceSettings"
$appllicationPath is the path to root folder of cms site.

4 - Changes in index data and searching for catalognode:

If we want to search for the entries/products in a catalognode, we need to use the _outline field. The code should look like this:
    if (String.IsNullOrEmpty(categoryCode))
            {
                var productRootNode = CatalogContext.Current.GetCatalogNodes(CommerceSettings.Default.MainCatalogName, CommerceSettings.Default.ProductNodeCode);
                if (productRootNode.CatalogNode.Count() <= 0)
                {
                    return new List<Entry>();
                }
                foreach (var node in productRootNode.CatalogNode)
                {
                    //criteria.CatalogNodes.Add(node.ID);

                }
            }
            else
            {
                //criteria.CatalogNodes.Add(categoryCode);
                criteria.Outlines = SearchFilterHelper.GetOutlinesForNode(categoryCode);
            }

            criteria.CatalogNames.Add(CommerceSettings.Default.MainCatalogName);
            criteria.StartingRecord = 0;
            criteria.RecordsToRetrieve = 1000;

            var entries = SearchFilterHelper.Current.SearchEntries(criteria, out count,
                                                                   entryResponseGroup, false,
                                                                   new TimeSpan(0, 0, 0));

            if (entries.TotalResults == 0)

5 - After rebuilding and building the index, you can get the exception when searching on the site, you can get exception:

Issue:
System.IndexOutOfRangeException was unhandled by user code
Message=Index was outside the bounds of the array.
Source=Lucene.Net
StackTrace:
at Lucene.Net.Index.DocumentsWriter.Abort(AbortException ae)
at Lucene.Net.Index.DocumentsWriter.UpdateDocument(Document doc, Analyzer analyzer, Term delTerm)

Fix:
The can be fixed by applying the CustomSearchProvider.

6 - Add the AuthorizedPaymentTotal by code when you see the error below:

Issue:
Cannot insert the value NULL into column 'AuthorizedPaymentTotal', table 'dbEPiServerCommerce.dbo.OrderForm'; column does not allow nulls. UPDATE fails.
The statement has been terminated.
Exception Details: System.Data.SqlClient.SqlException: Cannot insert the value NULL into column 'AuthorizedPaymentTotal', table ‘dbEPiServerCommerce.dbo.OrderForm'; column does not allow nulls. UPDATE fails.
The statement has been terminated.

Fix:
//workaround for these fields not accepting nulls
cart.Cart.OrderForms[0].AuthorizedPaymentTotal = 0;
cart.Cart.OrderForms[0].CapturedPaymentTotal = 0;

Indexing only referenced VPP-files with EPiServer Find

2013-05-02T05:00:00.0000000Z

The EPiServer Find CMS integration does not index any files stored in the VPP by default. A convention is included in the integration that index files visible in the file manager and it is enabled by setting the VisibleInFilemanagerVPPIndexingConvention on the FilieIndexer conventions...

List of XForm System Localization Keys in EPiServer 7

2013-05-01T04:27:00.0000000Z

I've recently been working on translating text that is displayed along with an XForm property. Since the localizations that are shipped with EPiServer 7 are now embedded in the assemblies, it's not as easy as searching through an XML file for the keys you need to override. So, as a reference, here are the system localization keys related to XForms that are embedded into EPiServer 7.

These are keys and values:

/xform/datatypes/date1/caption: Date (DD/MM/YYYY) 
/xform/datatypes/date1/inlineerrormessage: Not a valid date. Please enter a date in the format "DD/MM/YYYY". 
/xform/datatypes/date1/summaryerrormessage: * is not a valid date. Please enter a date in the format "DD/MM/YYYY". 
/xform/datatypes/date2/caption: Date (MM/DD/YYYY) 
/xform/datatypes/date2/inlineerrormessage: Not a valid date. Please enter a date in the format "MM/DD/YYYY". 
/xform/datatypes/date2/summaryerrormessage: * is not a valid date. Please enter a date in the format "MM/DD/YYYY". 
/xform/datatypes/defaulttype/inlineerrormessage: You have entered characters that are not permitted ("<" or ">"). 
/xform/datatypes/defaulttype/summaryerrormessage: You have entered characters that are not permitted ("<" or ">"). 
/xform/datatypes/email/caption: E-mail address 
/xform/datatypes/email/inlineerrormessage: Not a valid e-mail address. 
/xform/datatypes/email/summaryerrormessage: * is not a valid e-mail address. 
/xform/datatypes/integer/caption: Integer 
/xform/datatypes/integer/inlineerrormessage: Not a valid integer. 
/xform/datatypes/integer/summaryerrormessage: * is not a valid integer. 
/xform/datatypes/isodate/caption: Date (YYYY-MM-DD) 
/xform/datatypes/isodate/inlineerrormessage: Not a valid date. Please enter a date in the format "YYYY-MM-DD". 
/xform/datatypes/isodate/summaryerrormessage: * is not a valid date. Please enter a date in the format "YYYY-MM-DD". 
/xform/datatypes/positiveinteger/caption: Positive integer 
/xform/datatypes/positiveinteger/inlineerrormessage: Not a valid positive integer. 
/xform/datatypes/positiveinteger/summaryerrormessage: * is not a valid positive integer. 
/xform/denymultipleposts: You have already filled in this form 
/xform/errorpostingtocustomurl: The form could not be sent to a custom address 
/xform/errorpostingtodatabase: The form could not be sent to the database 
/xform/errorpostingtoemail: The form could not be sent to an e-mail address 
/xform/requiredfield/inlineerrormessage: This field is required 
/xform/requiredfield/summaryerrormessage: You haven't specified all required fields 
/xform/requiredfield/summaryerrormessageformat: You have not specified the required field "{0}". 
/xform/requirelogon: You must be logged in to answer

As you can see, the keys are primarily used to supply the error messages for the validations, and are unrelated to the localization of any other elements in the XForm.

As I mentioned in a previous post, the old 'lang' folder has disappeared with the release of EPiServer 7, and the documentation explained why:

If you want to override the system localizations that are shipped with EPiServer products, you will notice that the language files are no longer installed in the lang folder. They are now instead embedded in the assemblies but just as before you can override individual string by placing your own language XML in the lang folder. Of course you can include your localizations through any other LocalizationProvider and they will take precedence over the system localizations as long as the provider is registered before the system ones.

These translations live in the 'en' language branch, which is EPiServer's default language branch. With the proper localization fallback behavior configured, you'll see these translations for any language branch. If you want to customize the translations for the 'en' language branch, or for a completely different language branch, you would just need add them to your own language XML file and specify the language, which would look something like this:

<?xml version="1.0" encoding="utf-8" ?>
<languages>
  <language name="English (United States)" id="en-US">
    <xform>
      <requirelogon>Custom logged in alert</requirelogon>
      <datatypes>
        <email>
          <inlineerrormessage>Custom email error</inlineerrormessage>
        </email>
      </datatypes>
    </xform>
  </language>
</languages>

If you're curious about the code I used to get the list, it's actually pretty simple. You could easily customize this code to retrieve any other system localization areas that you need to override:

var resources = LocalizationService.Current.GetAllStrings().Where(t => t.Key.StartsWith("/xform")).ToList();

Installing Lucene Solr for EPiServer Commerce (EPi 6) Catalog Search

2013-04-30T12:53:13.0000000Z

By default, EPiServer Commerce uses Apache Lucene to perform its catalog search. Though within the files in Commerce Manager there exists Solr. They provide the necessary files to install Solr to your Apache search. Why Solr over Lucene? Well Solr wraps around…

The annoying “error CS1031: Type expected” after upgrade site from CMS5R2 to CMS6

2013-04-30T09:01:43.0000000Z

A few days ago a colleague upgraded a EPiServer site using Deployment Center and got this strange error. According to the dump the error was related to /Shell/Views/Shared/Site.Master. I knew the site was working correctly on my development machine, and I also knew the site was working fine in the test environment, so I ruled out any code-issues. Since there was already a lot of sites running on the production servers I also ruled out any missing dependencies. So what’s left? The Web.config of course!

The natural approach to find the error was to compare the non-working web.config in the production environment, with the working web.config from the test environment. That turned out to be an easy task since the only thing that was different was three lines, all which had to do with MVC!

For some reason Deployment Center didn’t care to replace the version of MVC on the production servers. It worked for the same site on my development machine and for the test servers. It also always worked for other sites on out production servers, but not this time.

So what I did was change the version numbers for System.Web.Mvc as below:

This is how it looked after upgrade

This is what I did change to make it work

And the error is gone!

EditPanel Manager

2013-04-29T21:00:00.0000000Z

In order to keep the Edit Panel as clean as can be, I’ve written a small extension that enhances the ability to disable and hide buttons in the EditPanel for specific PageTypes. This post explains the setup for the EditPanelManager extension, which options it currently supports and how the implementation has been done. The main objective of this post is to give insight in a possible solution to the problem and should not by default be read as the best solution. While all code is usable and tested it could well be optimized at places.

The challenge

The Edit Panel, as you probably know, is one of the areas for which you can use a GuiPlugIn with Area set to PlugInArea.EditPanel to add custom tabs. With these tabs you can add specific functionality to pages or PageTypes for instance which can improve the work for your editors in case you need to provide some functionality that otherwise would mean manual selection or at least non trivial work.

While this is a great way to extend your specific pages or PageTypes, adding a multitude of these custom GuiPlugIns can make the Edit Panel a bit overwhelming to your editors in the number of tabs they see. Most of the times however your editors won’t be using all of these tabs frequently. Some tabs probably won’t be used at all throughout the site, and perhaps some tabs are only used for a specific PageType.

The basics

This extension uses an xml configuration file to manage the tabs in the EditPanel for our PageTypes. I’ll start by explaining this configuration. Further down the post I’ll show how we can hook into EPiServer to influence the actual tabs being displayed in the EditPanel.

Let’s start with the structure of the xml configuration file. This will explain all of the options that are available in this extension and will provide the basis insights on what to do with those options.

        1: <episervereditpanelmanager>

       2:   <pagetypes>

       3:     <type name="MyPageTypeName" active="MyDefaultEditPanelTab">

       4:       <properties>

       5:         <property name="MyFirstEditPanelTabName" enable="true" />

       6:         <property name="MySecondEditPanelTabName" enable="false" ignoreroles="MyUserRole" />

       7:       </properties>

       8:     </type>

       9:   </pagetypes>

      10: </episervereditpanelmanager>

The type element

Within the ‘pagetypes’ node you set up a ‘type’ element. Each type element reflects a single PageType in your EPiServer site structure. The are two attributes on the type element. The first is the ‘name’ attribute, which is mandatory. The name attribute contains the name of the PageType that you want to manage the EditPanel tabs for. The second attribute is the ‘active’ attribute, which is optional. This attribute contains the name of the EditPanel tab that you want to set as the default tab which is displayed when an editor selects a page from the PageTree (Note: if this is the same for all your PageTypes or there is no need to customize this for each PageType you should probably use the ‘uiDefaultPanelTab’ in your EPiServer site configuration).

The property element

Within the type element there is a single ‘properties’ element that contains a number of ‘property’ elements. Each property element reflects a tab that exists in the EditPanel; like the Preview tab, the Edit tab, the Workflow tab, the Version List tab etc. The are three attributes on the property element. The first is the ‘name’ attribute, which is mandatory. The name attribute contains the name of the EditPanel tab that you want to manage. The second attribute is the ‘enable’ attribute, also mandatory. The enable attribute is a Boolean and holds the values ‘true’ or ‘false’. If set to true, the EditPanel tab should be displayed. If set to false the EditPanel tab should not be displayed. The third attribute is the ‘ignoreroles’ attribute, which is optional. This attribute can hold a comma separated list of user roles. This works as an override to the enable attribute. Users from these user roles are not taken into account on the enable attribute. In the above example this means that the ‘MySecondEditPanelTabName’ is not visible to anyone, except users from the ‘MyUserRole’ user role.

Hopefully you’re still reading ;) The summary above highlights the functional use of the EditPanelManager extension. The next part will explain some more on how this can be achieved with some code examples as well. Before we get into that just another small example xml configuration.

Pop quiz

Try and see if you understand how this would affect the EditPanel of your site editors (Note: spoiler below the example!)

       1: <episervereditpanelmanager>

       2:   <pagetypes>

       3:     <type name="TeaserPageType">

       4:       <properties>

       5:         <property name="View" enable="false" />

       6:       </properties>

       7:     </type>

       8:     <type name="NewsPageType" active="Edit">

       9:       <properties>

      10:         <property name="View" enable="true" />

      11:         <property name="Edit" enable="true" />

      12:         <property name="Version List" enable="false" />

      13:         <property name="Workflow" enable="false" />

      14:         <property name="Statistics" enable="false" />

      15:       </properties>

      16:     </type>

      17:     <type name="EventPageType">

      18:       <properties>

      19:         <property name="View" enable="true" />

      20:         <property name="Edit" enable="false" ignoreroles="WebAdmins, WebEditors" />

      21:         <property name="Version List" enable="false" ignoreroles="WebAdmins, WebEditors" />

      22:         <property name="Workflow" enable="false" ignoreroles="WebAdmins, WebEditors" />

      23:         <property name="Statistics" enable="false" ignoreroles="WebAdmins, WebEditors" />

      24:       </properties>

      25:     </type>

      26:   </pagetypes>

      27: </episervereditpanelmanager>

Ok, so how does the above configuration affect our editors?

Once logged in, I won’t see the View tab in the EditPanel for the TeaserPageType. Further I won’t see the VersionList, Workflow and Statistics tab on the NewsPageType, and the Edit tab is the default tab when selecting a page of type NewsPageType in the PageTree. If the logged in user has the ‘WebAdmins’ user role he’ll see all five tabs on the EventPageType. If the logged in user has the ‘WebSpecialAdmins’ user role, he’ll only see the ‘View’ tab in the EditPanel.

Technical Implementation

So far for the examples. As promised I’ll dive into the actual implementation.

We start by creating a GuiPlugIn. Let’s call this ‘EditPanelManager’.

       1: [GuiPlugIn(Area = PlugInArea.EditPanel)]

       2: public class EditPanelManager : ICustomPlugInLoader

       3: {

       4:     private static readonly ILog Logger = LogManager.GetLogger(typeof(EditPanelManager));

       5:  

       6:     //property that holds the current page type config element

       7:     public EPiServerEditPanelManagerPageTypeConfigElement CurrentPageTypeConfigElement

       8:     {

       9:         get; set;

    }

  

    public PlugInDescriptor[] List()

    {

        //hook LoadComplete-event on EditPanel page

        EPiServer.UI.Edit.EditPanel editPanel = HttpContext.Current.Handler as EPiServer.UI.Edit.EditPanel;

  

        if (null != editPanel)

        {

            //ADD SOME LOGIC HERE

        }

  

        //Never return a plugin - we don't want to add tabs.

        return new PlugInDescriptor[0] { };

    }

  

    protected void EditPanelLoadComplete(object sender, EventArgs e)

    {

        //ADD SOME LOGIC HERE

    }

}

The next step is to implement the ‘PlugInDescriptor[] List()’ method from the ICustomPlugInLoader interface. In short we add an EventHandler to LoadComplete of the EditPanel if the PageType of the current page exists in our xml configuration file.

       1: public PlugInDescriptor[] List()

       2: {

       3:     // hook LoadComplete-event on EditPanel page

       4:     EPiServer.UI.Edit.EditPanel editPanel = HttpContext.Current.Handler as EPiServer.UI.Edit.EditPanel;

       5:  

       6:     if (null != editPanel)

       7:     {

       8:         //get the list of all registered pagetypes from the config file

       9:         List<EPiServerEditPanelManagerPageTypeConfigElement> pageTypeList = EditPanelManagerHelper.GetPageTypeNamesFromConfig();

  

        //check if the pagetype of the current page exists in the list of pagetypes in the config file

        try

        {

            CurrentPageTypeConfigElement = pageTypeList.First(x => x.Name.ToLower().Trim() == editPanel.CurrentPage.PageTypeName.ToLower().Trim());

        }

        catch (Exception ex)

        {

            Logger.Debug("error occured while getting the CurrentPageTypeConfigElement", ex);

        }

            

        //match found, add the event handler to the LoadComplete event of the editpanel

        if (CurrentPageTypeConfigElement != null)

        {

            editPanel.LoadComplete += EditPanelLoadComplete;

        }

    }

  

    //Never return a plugin - we don't want to add tabs.

    return new PlugInDescriptor[0] { };

}

The EventHandler is added to manipulate the way the tabs in the EditPanel are rendered (Thanks to the article ‘Neat Trick: Modifying Edit Mode Tabs’ by Allan Thræn).

We also need to implement the LoadComplete event of the EditPanel for which we’ve added the new EventHandler in the ‘PlugInDescriptor[] List()’ method. There are three single line calls in the LoadComplete event. First we get the TabStrip object by looking for the ‘actionTab’ control. Secondly we retrieve all properties (the tabs) that are configured for the current page type in our xml configuration file. Finally, we call our Tab Manager that handles the processing of the individual tabs.

       1: protected void EditPanelLoadComplete(object sender, EventArgs e)

       2: {

       3:     // find the TabStrip with id = "actionTab"

       4:     TabStrip actionTabStrip = ControlHelper.FindControl<TabStrip>(sender as Control, "actionTab");

       5:  

       6:     //get all properties for this pagetype from the config file

       7:     List<EPiServerEditPanelManagerPropertyConfigElement> elements =

       8:         EditPanelManagerHelper.GetPropertyElementsFromPageTypeConfigElement(CurrentPageTypeConfigElement);

       9:  

      10:     //call our tab manager

      11:     TabStripHelper.SetTabs(actionTabStrip, elements, CurrentPageTypeConfigElement.Active);

      12: }

Within both the ‘PlugInDescriptor[] List()’ method and the LoadComplete event method there are calls to certain Helper classes. Of course you can set this up any way you like. For this demo I’ve chosen to just simply set up two classes; the EditPanelManagerHelper and the TabStripHelper.

EditPanelManagerHelper

The EditPanelManagerHelper is used to retrieve the correct PageTypes and properties from our configuration file. It has two methods. The first method is ‘GetPageTypeNamesFromConfig()’ and reads the xml configuration file for all PageTypes defined using the ConfigurationManager. The second method is ‘GetPropertyElementsFromPageTypeConfigElement()’ that reads all properties for a given PageType present in the xml configuration file.

       1: public static class EditPanelManagerHelper

       2: {

       3:     public static List<EPiServerEditPanelManagerPageTypeConfigElement> GetPageTypeNamesFromConfig()

       4:     {

       5:         List<EPiServerEditPanelManagerPageTypeConfigElement> list = new List<EPiServerEditPanelManagerPageTypeConfigElement>();

       6:         EPiServerEditPanelManagerConfigSection section = ConfigurationManager.GetSection("episervereditpanelmanager") as EPiServerEditPanelManagerConfigSection;

       7:         if (section != null)

       8:         {

       9:             list.AddRange(section.PageTypes.Cast<EPiServerEditPanelManagerPageTypeConfigElement>());

      10:         }

      11:         return list;

      12:     }

      13:  

      14:     public static List<EPiServerEditPanelManagerPropertyConfigElement> GetPropertyElementsFromPageTypeConfigElement(EPiServerEditPanelManagerPageTypeConfigElement ePiServerEditPanelManagerPageTypeConfigElement)

      15:     {

      16:         //get element information from pagetype config node

      17:         return ePiServerEditPanelManagerPageTypeConfigElement.Elements.Cast<EPiServerEditPanelManagerPropertyConfigElement>().ToList();

      18:     }

      19: }

TabStripHelper

The second helper class is the TabStripHelper. This contains the actual logic that controls which tabs are displayed and which are hidden.

       1: private static readonly ILog Logger = LogManager.GetLogger(typeof(TabStripHelper));

       2:  

       3: public static void SetTabs(TabStrip tabStrip, List<EPiServerEditPanelManagerPropertyConfigElement> elements, string activeTab)

       4: {

       5:     if (tabStrip == null)

       6:     {

       7:         return;

       8:     }

       9:  

    int firstVisibleTab = -1;

    int activeTabIndex = -1;

    for (int i = 0; i < tabStrip.Controls.Count; i++)

    {

        Tab tab = (Tab)tabStrip.Controls[i];

  

        string tabName = tab.Text.ToLower().Trim();

  

        //get element by tab name

        EPiServerEditPanelManagerPropertyConfigElement element = null;

        if (elements != null)

        {

            try

            {

                IEnumerable<EPiServerEditPanelManagerPropertyConfigElement> list = elements.ToList().Where(x => x.Name.ToLower().Trim() == tabName);

                if (list.Any())

                {

                    element = list.Single();

                }

            }

            catch (Exception ex)

            {

                Logger.Debug(string.Format("error occured while getting the element for tab '{0}'", tabName), ex);

            }

        }

        if (element != null)

        {

            if (string.IsNullOrEmpty(element.IgnoreRoles))

            {

                //set visibility

                tab.Visible = element.Enable;

            }

            else

            {

                //check current user roles

                tab.Visible = (UserHasRole(element.IgnoreRoles) ? !element.Enable : element.Enable);

            }

        }

  

        //store first visible tab index

        if (tab.Visible && firstVisibleTab == -1)

        {

            firstVisibleTab = i;

        }

  

        //store given active tab index

        if (!string.IsNullOrEmpty(activeTab) && tab.Visible && tabName == activeTab.ToLower())

        {

            activeTabIndex = i;

        }

    }

  

    if (tabStrip.SelectedTab == 0)

    {

        int set = (activeTabIndex > -1 ? activeTabIndex : firstVisibleTab);

        tabStrip.SetSelectedTab(set);

    }

}

  

public static bool UserHasRole(string roles)

{

    if(string.IsNullOrEmpty(roles))

    {

        return true;

    }

  

    //get current user roles

    List<string> currentUserRoleList;

    try

    {

        List<string> list = EPiServer.Security.PrincipalInfo.Current.RoleList.ToList();

        currentUserRoleList = list.ConvertAll(x => x.ToLower());

    }

    catch (Exception)

    {

        Logger.Error("error occured while handling the current user role list");

        return true;

    }

    

    List<string> roleList = roles.Split(',').ToList();

    return roleList.Any(role => currentUserRoleList.Contains(role.ToLower().Trim()));

}

    }

This helper class contains two methods. The ‘UserHasRole’ method has been added here for convenience, but you probably have another place for this in your codebase. It simply checks the current users role to the provided userrole list from the ‘ignoreroles’ attribute for the current PageType.

The first method ‘SetTabs()’ holds three input parameters. The current TabStrip (which holds all tabs of the EditPanel), the list of tabs that you configured in your xml configuration file for the given PageType and the name of the activeTab if present in the xml configuration file. It simply iterates over all controls in the TabStrip and compares these to the xml configuration setup.

Conclusion

And there you have it, that’s all there is to it. As you can see this example shows how to influence the way tabs are rendered within the EditPanel and can possibly simplify the way your site editors experience the Edit Mode of EPiServer. Feel free to comment!

ImageVault 4 addon update (v4.1.12)

2013-04-29T13:51:55.0000000Z

We found an issue when using ImageVault 4 with EPiServer CMS 7 and a MVC site. The issue messes up the routing for the links on the site but this has been corrected and a new ImageVault addon version has been released. It will soon be placed at the official episerver feed but for now it resides on the ImageVault nuget feed.

To update, add the following nuget feed to your site

http://nuget.imagevault.se/nuget/

and then click the Install button on the ImageVault addon v 4.1.12.

More on how to add the nuget feed to your episerver configuration can be found in the ImageVault documentation: Manual installation: EPiServer CMS7 ImageVault AddOn

Getting “Error– is not a valid user or group”, when upgrading?

2013-04-29T09:20:08.0000000Z

I’ve upgraded a lot of sites in my days, but I still run into new errors. Even when you do it the right way, by upgrading the test-environment and collect as much information you can, there is still a chance it won’t work on the production servers. This error was one of those times…

At first I tried all the obvious things, like check if account was locked, did it have all the correct permissions etc. When all of this was confirmed I really didn’t have much more ideas. But then it hit me! I checked the account in Active Directory once more, and saw that the account name was so long, the “pre-Windows 2000”-name was truncated. For some reason, EPiServer Deployment Center uses this legacy login name during upgrade, and when the name is truncated it won’t work!

So this is what I did:

1. After starting Deployment Center and executed the correct upgrade, this error occurred:

2. Check the account in Active Directory to find out the name is truncated:

3. Rename the account using a shorter name.

4. Modify the application-pool so it uses the new username

5. Run upgrade again.

Building large scale EPiServer sites

2013-04-29T07:13:03.0000000Z

It has been proven by numerous sites that EPiServer CMS can handle huge amounts of content. Doing so does bring a few challenges though. Here's a few few patterns that I've identified when it comes to building large scale EPiServer sites with great performance.

Last week I received an e-mail with the subject ”Huge number of pages (>500 000) in EPiServer?” As you can imagine the e-mail contained questions related to whether EPiServer CMS can handle sites with A LOT of content.

It has been proven on a number of occasions that it indeed can. For instance, several of the biggest newspapers in Sweden, with millions of pages, run EPiServer. There are also government sites with several hundreds of thousands of pages.

That doesn’t mean that we’re not faced with challenges when building large EPiServer sites though.

In my experience, what those challenges are differs depending on the type of site, or rather, depending on how the content is structured on the site. While an individual site may be a mix of the two, there are two categories of large scale sites in terms of how they structure their content.

Content that fit naturally in a deep hierarchy

This is common for government sites and the like. Such sites may publish a lot of content that is organized and exposed to visitors in a hierarchy based on topics, subtopic and so on.

Alternatively the content may fit naturally in a date-based hierarchy, such as an archive with publications.

Content that isn’t hierarchical or the hierarchy is shallow

This is very common on media sites such as newspapers. Those sites typically have a shallow hierarchy made up of sections. There may for instance be a first level section called "Sport" and a subsection to that called "Football".

An article about one of the Champions League semifinals 2013 is displayed in the context of Sport/Football but beyond that it has no natural place in a tree like structure. On a site with a lot of content this in turn means that an article in context of its place in the hierarchy may have thousands, or even millions, of siblings.

Finding content based on non-hierarchical criteria

Given that we’re dealing with a site that has a lot of content that fit nicely into a tree based structure EPiServer CMS works great out-of-the-box for editors. The CMS stores content in a tree, the content tree, and expose that to editors using UI components such as the Page tree and the Block gadget that also lets editors work with content in a tree.

While there is a lot of content, meaning that the content tree has a lot of branches and leafs editors can easily find the right place to publish new content. They can also find old content simply by navigating the content tree, or the site, the same way a public visitor would.

In cases where the standard navigation doesn’t suffice, such as when an editor or visitors needs to find content that, in their view, isn’t placed where it should be on the site, basic free text search functionality typically can handle that.

As for developers building navigation components is typically easy as all they have to do is utilize the page tree. EPiServer's methods for doing that, such as Get, GetChildren and GetAncestors are highly optimized and aggresively cached with clever dependencies for releasing their caches when needed and only then.

However, no matter how natural the content hierarchy is there are usually a number of requirements for components that lists content in a way that isn’t based on the hierarchy. Examples of such components could for instance be the most recently published pages of a certain type, all articles published be a certain author or department and all publications categorized with a certain keyword.

For such requirements EPiServer CMS only has the method FindPagesWithCriteria to offer. Besides obvious usability issues for developers FPWC has some serious performance issues, especially on a site with a large volume of content.

In other words, on a large scale EPiServer site with content fitting naturally into a deep hierarchy we’re faced with the challenge of finding content based on non-hierarchical criteria.

There are two common solutions to this problem. One is to somehow store the answer to such questions at a time where we know that the answer is changing. For instance, this may mean storing a list of the ten last published pages of a given type serialized into a property somewhere or in the Dynamic Data Store, updating each time a page is published. This requires quite a lot of development time and, worse, it requires us to know what questions will need answering beforehand. It’s also rather error prone.

The second, and much better, common solution to this is to use a search engine. This has been done on a number of large EPiServer sites using different search engines. Today though the obvious solution is to use EPiServer Find, the search and content retrieval product that EPiServer offers. Find was in many ways built exactly to address this problem in a way that offers great usability for developers and short development time.

Solution: Use a EPiServer Find to create navigations listings of content that are not based on the contents place in the content tree.

Non-hierarchical content

When the content can’t naturally be fitted into a deep hierarchy additional challenges arise. First, EPiServer’s API and editorial interface is designed for sites organizing content in a tree. If the content can’t be organized into a deep hierarchy performance will suffer. Here’s how I put it in my reply to the e-mail:

“The content tree can handle millions of items BUT if those items aren't stored in a deep hierarchy there will be performance problems. That is, if you have a page with ten thousand children you have a problem. If you have a page with a hundred children and each of those have a hundred children you won't have a problem.”

While I knew this from experience, after sending that reply, I decided to conduct a few experiments to prove it.

In the context of a scheduled job I wrote code that created ten thousand pages below the same parent. It also created a hundred pages below another common parent and then a hundred pages below each of those pages. Everything was done in batches of a hundred pages and the mean time for creating a page during each batch was logged.

Let’s look at the results for creating 100x100 pages in a hierarchy first.

Batch	Avg. time per published page (ms)
1-100	22
201-300	22
501-600	22
901-1000	24
1901-2000	24
4901-5000	33
9901-10000	30

There are of course some variances which would likely even themselves out with a larger sample (I ran the test only four times), but it's pretty clear that it takes almost exactly the same amount of time to create page number ten thousand as page number one when storing pages in a hiearchy where each page has ninetynine siblings.

Now, let’s compare that to creating 10000 pages below the same parent.

Batch	Avg. time per published page (ms)
1-100	22
201-300	26
501-600	34
901-1000	50
1901-2000	83
4901-5000	180
9901-10000	414

As we can see the time required to publish a page grows based on the number of existing pages below the page’s parent page. Plotted into a diagram we can see that this growth is linear.

Beyond API performance issues, expanding the tree node for a page revealing it’s ten thousand pages in edit mode takes time. Below is what FireBug reported for me when I tried to expand a none with ten thousand children.

After receiving the response from the server Firefox reported an unresponsive JavaScript on the page and it took several minutes before I actually got to see the pages in the page tree.

Of course, even if it the page tree wouldn't have any issues with displaying thousands of children for a node such a list would hardly be useful for editors.

Conclusion: EPiServer is built and optimized for sites that stores content in a hierarchy in which each node has hundreds and not thousands of child nodes.

Clearly, EPiServer's page tree doesn't work well for large scale sites with huge volumes of non-hierarchical content. Not in terms of performance and not in terms of editor usability.

Luckily there's a fairly easy solution that has proven to work very well. In fact, I've seen it done so many times that I'd call it a pattern. What is is? Faking it!

Structuring bulk content in arbitrary hierarchies

We know that EPiServer needs, or prefers, organizing pages in such a way that each node in its content tree doesn't have more than hundreds of immediate children. EPiServer does not however care about why a certain page belongs in a certain place in the tree. Therefor we can automatically place pages in a hierarchy based on some arbitrary criteria.

For articles on a media site this is commonly done by placing them in a structure based on publish date.

There are a number of ways to implement such functionality but it typically involves:

Defining a root node for a certain type of content.
Hooking up to events from EPiServer's API listening to when content is created.
When a page of a matching type is created ensure that there is a place for it in the date structure below the root, otherwise create it.
Move the newly created content to its parent in the date structure.

Of course, when content resides in a structure whose only purpose is to work well with EPiServer performance wise we can't utilize the content hierarchy when building navigations. The solution to that typically involves four things:

Defining one or several properties on the content types that will be used for "bulk content". These properties are typically of type PageReference, ContentReference or ContentArea. For instance, an article may have a property named Section of type PageReference which points to the Football section.
Utilizing the above mentioned property/properties when rendering pages to determine in what context they should be shown. For instance, an article about a Champions League game may have a Section property pointing to a page named Football which in turn is a child of a page named Sport. Based on that the article's content is displayed framed by a header, navigation elements and right column from Football or Sport.
Using a search engine to create listings. Essentially I'm talking about the same problem as we looked at before here, finding content based on non-hierarchical criteria. The only difference is that we now need to apply the same solution in more places as the majority of the content of the site's content is organized in such a way in the content tree that it can't be used to build navigations and listings.
With that said, we can still utilize EPiServer's standard API methods for components such as the main navigation as those pages aren't the "bulk content" and therefor works well with the page tree. Again while we can use pretty much any search engine that offers good performance and scalability, EPiServer Find is the best option as it was born out of these specific needs.
Rewriting URLs. By default URLs on an EPiServer site is built up using the page's name prefixed by the name of each of its ancestors in the page tree. When storing articles or other content in a structure that has nothing to do with how visitors sees the page on the site URLs won't seem very logical. For instance an URL like /2013/04/23/champions-league.. is hardly helpful and doesn't look very good. With older versions of EPiServer CMS we typically handled that using a custom URL rewriter. Nowadays with EPiServer 7 we do it using custom routing.

Solution: Automatically organize non-hierarchical content in arbitrary hierarchies based on creation date, first letter in their names or some other criteria. Use properties on the content to tie it to pages in the page tree which provide the context in which the content should be rendered. Use EPiServer Find to build listings.

Using the above approach we solve the performance issues when dealing with non-hierarchical content of the type that is often found on media sites, blogs and the like. While that works great we have one more problem to solve - how editors create and find the content for which the page tree is more or less useless.

Custom components for editorial workflows

We could tell editors "To create a new article click on the Articles node in the page tree. We have some code that will automatically move it a few levels down in a date based structure. Oh, and don't forget to set the Section property." However, odds are we wouldn't find much jobs afterwards and we'd see buch of angry comments about EPiServer on Twitter.

Clearly, if we're dealing with the type of site that the page tree doesn't work well with we can't just be content with solving performance issues. We'll also need to extend EPiServer's edit mode to provide good workflows for editors.

Exactly how such components should work and be implemented differs from site to site but it typically involves functionality to:

Create "bulk content" without having to use the page tree gadget.
Either automatically populating "infrastructure properties" such as Section or making it very easy for editors to do so.
List the most recent content. Especially on media sites it's a very common requirement to have a list that displays all articles that have either been published today, not yet been published or is scheduled to be published.
Find content based on criteria such as author, publish date and section.

I've built such functionality both in EPiServer 6 and EPiServer 7 and based on those experiences I've created the PowerSlice project. PowerSlice is one way of addressing several of the above requirements and may solve all needs for some sites. For other sites it may be used for inspiration.

Either way, it's very much possible to build the components needed by editors. With EPiServer 7 it typically involves creating custom Dojo/Dijit widgets and utilizing EPiServer Find.

Solution: Extend EPiServer's edit mode with custom components tailor made for the needs of the editors. PowerSlice may be an option and/or used for inspiration.

Are you still with me? Perhaps it's about time we looked at an example.

An example - this site

While this site doesn't exactly fit the "large scale" description as it's primarily a blog it, along with certain parts of many other "small" sites, does have non-hierarchical content. Therefor I applied the above mentioned techniques to it, meaning that we can look at it as an example of how a large scale site, such as a media site, can be built.

Organizing pages

In terms of hiearchy there are two types of pages on the site. Articles and tags are automatically organized in two separate structures. Sections and standard pages are not.

All articles resider under a node below the start page. Under that node they are grouped first by year and then by month.

Articles have a property named MainCategory edited using a drop down from which it's possible to select one of the categories (sections) on the site.

This property is used for breadcrumbs and context specific things when rendering an article.

Articles also have a content area property to which other categories can be added.

MainCategory and any categories added to AdditionalCategories are combined by a code only property on articles named AllCategories.

New articles can be created using a UI component that's created using PowerSlice.

When an article is created it's initial parent is the root node for articles. Using a modified version of my old open source project PageStructureBuilder the article as automatically moved to a year/month structure.

Listings and routing

Categories/sections list articles "belonging" to them based ordered by publication date. This is done using a fairly simple search query using EPiServer Find that filters on article's AllCategories property.

_searchClient.Search()
    .Filter(page => page.Categories.Match(currentPage.ContentLink))
    .CurrentlyPublished()   
    .FilterOnReadAccess()
    .OrderByDescending(x => x.StartPublish);

As for URLs I use a custom partial router, which I've previously described in great detail.

Dealing with traffic

So far this article has been about how to build sites with large volumes of content on EPiServer CMS. There's of course another way to interpret "large scale sites" - sites with a lot of traffic.

Again, it's already been proven by a number of existing EPiServer customers that EPiServer can handle huge volumes of traffic. With that said, it's of course also very much possible to build a site on EPiServer that crumbles once it's hit with more than a couple of concurrent requests.

A robust EPiServer site that can handle a lot of traffic and let editors work efficiently at the same time requires a good implementation. And a good implementation requires skilled and experienced developers who know what they are doing.

In general EPiServer CMS's API is highly optimized and the most significant methods for getting content based on the hierarchy are cached. As for EPiServer Find it's fast, highly scalable and also has mechanisms for caching that can be used when needed. So, as first step in hardening a site for production it's absolutely vital to use the API methods visely. Having done so the site will hold well on its own.

Sometimes though, we're dealing with a site that has so much traffic that it's not just enough use caching to prevent database calls. The actual rendered HTML output needs to be cached as well. For that EPiServer offers a fairly basic output cache that can be used.

While that may be an option, for site with really, really, really much traffic we may need even more efficient output caching. In those cases we can either construct a custom output cache to use on the webservers or, which I prefer, use a web content accelerator/caching reverse proxy such as Varnish. We may also want to look in to using a CDN instead or as a compliment.

One thing to beware of though is that any form of output caching, with the exception of partial caching, will limit editors ability to use some of the functionality built into the CMS such as personalization. If that's a problem we can often work around that by loading parts of pages using JavaScript and not caching such requests. Of course that means more requests to the site though.

In general, my philosophy is to build the site as robust and performant as possible without so that it can handle the traffic without any other form of caching. After that, if it's needed or economically motivated some sort of cache can be put in front of the site.

This approach has two benefits. First of all we can choose to use output caching for the right reasons. Second, using output caching tends to hide performance problems in the application and while those may not be a problem at first they may be whenever the cache is released or if there's an issue with the output cache. Then it's very valuable if the web applciation can hold on its own.

Summary

EPiServer CMS can handle sites with millions of pages.
For large scale sites FindPagesWithCriteria doesn't work for non-hierarchical queries. Use EPiServer Find for that.
EPiServer relies on content being split up into a hierarchy. If the content doesn't fit naturally into such a hiearchy, make one up and use a combination of properties, Find and edit mode extensions create new content and build listings.

Creating a Link to a Page in your EPiServer 7 MVC View

2013-04-29T04:00:00.0000000Z

When developing an EPiServer 7 site (or really any site, for that matter), making a link to a page is one of the most common things you'll do. So, I thought I'd do something a little more basic and explore how to handle this task in your front-end page and block templates, specifically using MVC Razor views. In this post, we'll look at what you can currently use to create a link to a page, then I'll introduce some extension methods that you can use to give yourself a little more flexibility in your MVC view.

Current Options and Limitations

First of all, resist the temptation to solely rely on the LinkURL property in the PageData object. This will return an internal link to the page that isn't very user friendly. Sure, when you click the link it takes you to the correct page, but we don't want to be showing these links to the outside world. Instead, rely on the helpers and extensions that EPiServer 7 provides.

Html.PageLink

The simplest and most common way to create a link to page is to use EPiServer's Html.PageLink helper. Using this helper, you can pass in a PageData object, a PageReference, or even a LinkItem, and it will create an HTML anchor, using the clean, friendly URL to the page. For the text of the link, if you do not supply it with a text string, it will use the PageName property for the page (or the Text property for a LinkItem object).

@Html.PageLink(Model.SomePageReference)
@Html.PageLink(Model.SomePageData)
@Html.PageLink("A link to a page", Model.SomeLinkItem)

You can also pass in route data information that can change the URL (helpful when working with language branches) or additional HTML attributes to add to the anchor tag.

@Html.PageLink("A link to a Swedish page", Model.SomePageReference, new { language = "sv-SE" }, null)
@Html.PageLink("A link with a class", Model.SomePageReference, null, new { @class = "link-class" })

Be sure to check the SDK for this helper, because there are a lot more options you could use that might be a better fit for your needs.

In most cases, this HTML helper is what you'll use to create a link to a page. There are some situations, however, where you'll need a little more flexibility. A common example is when you want to wrap an image tag with an anchor tag, or when you want to wrap more elements. To solve that situation, you could build an image link HTML helper, or you could just retrieve the actual URL to the page using Url.PageUrl.

Url.PageUrl

Another way is to use EPiServer's Url.PageUrl helper. This helper only takes one parameter: the internal URL for the page. It will then use EPiServer's PermanentLinkUtility to find the friendly URL to the page, and return only the URL as a string. You could then take that string and use it directly in an HTML anchor tag.

<a href="@Url.PageUrl(Model.SomePageData.LinkURL)">
    A link to a page
</a>

This covers a lot of the other cases when you need better flexibility when creating a link to a page. The only thing I don't like about this, though, is that you need to have the PageData of the page to use it. So if you have a PageReference property on your page or block type, you'll need to use IContentLoader or IContentRepository to get the PageData from the PageReference. Wouldn't it be easier to just pass in a PageData or a PageReference object instead?

Another Option: Extending the UrlHelper

The solution I put together, which I think provides the best of both worlds, is heavily based on the code for EPiServer's Html.PageLink helper. It only returns the friendly URL to a page like Url.PageUrl, but still gives you the flexibility to pass in a PageData or a PageReference object like Html.PageLink. Rather than extending HtmlHelper, it extends UrlHelper and works alongside of the Url.PageUrl helper.

UrlExtensions.cs

public static class UrlExtensions
{
    public static string PageUrl(this UrlHelper urlHelper, PageReference pageLink)
    {
        return UrlExtensions.PageUrl(urlHelper, pageLink, (object)null, (IContentRepository)null);
    }

    public static string PageUrl(this UrlHelper urlHelper, PageReference pageLink, object routeValues)
    {
        return UrlExtensions.PageUrl(urlHelper, pageLink, routeValues, (IContentRepository)null);
    }

    public static string PageUrl(this UrlHelper urlHelper, PageData page)
    {
        return UrlExtensions.PageUrl(urlHelper, page, (object)null);
    }

    public static string PageUrl(this UrlHelper urlHelper, PageData page, object routeValues)
    {
        if (!PageDataExtensions.HasTemplate(page))
            return string.Empty;

        switch (page.LinkType)
        {
            case PageShortcutType.Normal:
            case PageShortcutType.Shortcut:
            case PageShortcutType.FetchData:
                return UrlExtensions.PageUrl(urlHelper, page.PageLink, routeValues, (IContentLoader)null, (IPermanentLinkMapper)null, (LanguageSelectorFactory)null);

            case PageShortcutType.External:
                return page.LinkURL;

            case PageShortcutType.Inactive:
                return string.Empty;

            default:
                return string.Empty;
        }
    }

    private static string PageUrl(this UrlHelper urlHelper, PageReference pageLink, object routeValues, IContentRepository contentRepository)
    {
        if (contentRepository == null)
            contentRepository = ServiceLocator.Current.GetInstance<IContentRepository>();
        if (PageReference.IsNullOrEmpty(pageLink))
            return string.Empty;
        PageData page = contentRepository.Get<PageData>((ContentReference)pageLink);
        return UrlExtensions.PageUrl(urlHelper, page, routeValues);
    }

    private static string PageUrl(this UrlHelper urlHelper, PageReference pageLink, object routeValues, IContentLoader contentQueryable, IPermanentLinkMapper permanentLinkMapper, LanguageSelectorFactory languageSelectorFactory)
    {
        RouteValueDictionary routeValueDictionary = new RouteValueDictionary(routeValues);
        if (!routeValueDictionary.ContainsKey(RoutingConstants.LanguageKey))
            routeValueDictionary[RoutingConstants.LanguageKey] = (object)ContentLanguage.PreferredCulture.Name;
        if (!routeValueDictionary.ContainsKey(RoutingConstants.ActionKey))
            routeValueDictionary[RoutingConstants.ActionKey] = (object)"index";
        routeValueDictionary[RoutingConstants.NodeKey] = (object)pageLink;
        UrlExtensions.SetAdditionalContextValuesForContent(urlHelper, pageLink, routeValueDictionary, contentQueryable, permanentLinkMapper, languageSelectorFactory);
        return urlHelper.Action((string)null, routeValueDictionary);
    }

    private static void SetAdditionalContextValuesForContent(this UrlHelper urlHelper, PageReference pageLink, RouteValueDictionary values, IContentLoader contentQueryable, IPermanentLinkMapper permanentLinkMapper, LanguageSelectorFactory languageSelectorFactory)
    {
        bool IdKeep = HttpContext.Current.Request.QueryString["idkeep"] != null;
        contentQueryable = contentQueryable ?? ServiceLocator.Current.GetInstance<IContentLoader>();
        permanentLinkMapper = permanentLinkMapper ?? ServiceLocator.Current.GetInstance<IPermanentLinkMapper>();
        languageSelectorFactory = languageSelectorFactory ?? ServiceLocator.Current.GetInstance<LanguageSelectorFactory>();
        IContent content = contentQueryable.Get<IContent>(pageLink, languageSelectorFactory.Fallback(values[RoutingConstants.LanguageKey] as string ?? ContentLanguage.PreferredCulture.Name, true));
        if (content == null)
            return;
        if (IdKeep)
            values["id"] = (object)content.ContentLink.ToString();
        UrlExtensions.SetAdditionalContextValuesForPage(values, IdKeep, content);
    }

    private static void SetAdditionalContextValuesForPage(RouteValueDictionary values, bool IdKeep, IContent content)
    {
        PageData pageData = content as PageData;
        if (pageData == null)
            return;
        if (pageData.LinkType == PageShortcutType.Shortcut)
        {
            PropertyPageReference propertyPageReference = pageData.Property["PageShortcutLink"] as PropertyPageReference;
            if (propertyPageReference != null && !PageReference.IsNullOrEmpty(propertyPageReference.PageLink))
            {
                values[RoutingConstants.NodeKey] = (object)propertyPageReference.PageLink;
                if (IdKeep)
                    values["id"] = (object)((object)propertyPageReference).ToString();
            }
        }
    }
}

At this point, I'm just supporting passing in PageData and PageReference objects, but it could easily be extended to support the other objects that Html.PageLink supports. I also made it support additional route data information, which will help when creating links to pages in another language branch.

<a href="@Url.PageUrl(Model.SomePageReference, new { language = "sv-SE" })">
    <img src="swedish_flag.png" />
</a>

I hope you find this useful, and that it gives you the most flexibility you need when creating a link to a page in your EPiServer site!

CMS 7 Subscriptions “bug”

2013-04-26T10:56:13.0000000Z

The other day the first task was to build a subscription page. The Alloy demo templates doesn’t contain an example so I needed a quick brushing up on the topic.

The conclusion is that subscriptions work in the same way as in older versions of EPiServer. Not an extremely well documented area but that might be the topic of another post.

So our subscription template needs a property named “EPSUBSCRIBE-ROOT”.

So now the problems begins. In C# we can’t use a hyphen (-) in class or property names. We have the same issue with the property “EPSUBSCRIBE-EXCLUDE” that is optional to include on pages that should not be sent out in the subscription job.

EPiServer has created a bug for this issue.

To get around this until EPiServer has released a fix we have to create the properties through admin mode.

EpiServer CMS 6 Useful SQL Queries

2013-04-25T13:28:16.0000000Z

Here is a set of few useful queries that we have been using since CMS 5 internally for debugging and improving customer experience. I have not tested these with CMS 7.

List All Web Pages with Their Properties and Current Values

Below Query can help web editors to audit their contents.

select distinct tblPageLanguage.LinkURL 'Web Page URL', tblPageLanguage.Name 'Web Page Name',tblPageDefinition.Name
'Property Name', 'Property Value' =
case
when tblProperty.Number is null and tblProperty.FloatNumber is null and
tblProperty.PageType is null and tblProperty.PageLink is null and tblProperty.Date is null and
tblProperty.String is null and tblProperty.LongString is null
then 'Boolean: ' + cast( tblProperty.Boolean as varchar( 40 ) )
when tblProperty.Number is not null then 'Number: '+ cast( tblProperty.Number as varchar( 40 ) )
when tblProperty.FloatNumber is not null then 'FloatNumber: '+ cast( tblProperty.FloatNumber as
varchar( 40 ) )
when tblProperty.PageType is not null then 'PageType: '+ cast( tblProperty.PageType as
varchar(40))
when tblProperty.PageLink is not null then 'PageLink: '+ cast( tblProperty.PageLink as
varchar( 40 ) )
when tblProperty.Date is not null then 'Date: '+ cast( tblProperty.Date as varchar( 40 ) )
when tblProperty.String is not null then 'String: '+ cast( tblProperty.String as varchar( 40 ) )
when tblProperty.LongString is not null then 'LongString: '+ cast( tblProperty.LongString as
varchar( 40 ) )
else cast( 'Error Determining Value!' as varchar( 40 ) )
end
from tblProperty
inner join tblPage on tblProperty.fkPageID = tblPage.pkID
inner join tblPageDefinition on tblProperty.fkPageDefinitionID = tblPageDefinition.pkID
inner join tblPageLanguage on tblpage.pkID = tblPageLanguage.fkPageID
order by tblPageLanguage.LinkURL, tblPageLanguage.Name, tblPageDefinition.Name

SQL Query to List All User Tables and Their Columns In a SQL Server Database

select sysobjects.Name, syscolumns.Name
from sysobjects inner join syscolumns on sysobjects.id = syscolumns.id
where sysobjects.xtype = 'U'
order by sysobjects.Name, syscolumns.colorder

SQL Server Procedure to Display the Web Page Hierarchy

It can help us to investigate large tree structures

IF EXISTS (SELECT name FROM sysobjects
WHERE name = 'ShowHierarchy' AND type = 'P')
DROP PROCEDURE ShowHierarchy
go
CREATE PROC dbo.ShowHierarchy ( @Root int ) AS BEGIN
SET NOCOUNT ON
DECLARE @PageID int, @PageName varchar(30)
SET @PageName = (SELECT tblPageLanguage.Name FROM dbo.tblPage inner join tblPageLanguage on tblpage.pkID = tblPageLanguage.fkPageID WHERE pkID = @Root)
PRINT REPLICATE( '-', @@NESTLEVEL * 4) + @PageName
SET @PageID = (SELECT MIN( pkID ) FROM dbo.tblPage WHERE fkParentID = @Root)
WHILE @PageID IS NOT NULL
BEGIN
EXEC dbo.ShowHierarchy @PageID
SET @PageID = (SELECT MIN( pkID ) FROM dbo.tblPage
WHERE fkParentID = @Root AND pkID > @PageID)
END
END
go
ShowHierarchy 1
go

OUTPUT will be something like

--------Home
------------Browse catalogue
----------------Publications
--------------------Carousel
------------------------Publications Banner 1
------------------------Publications Banner 2
------------------------Publications Banner 3
------------------------Publications Banner 4
--------------------Featured Products
------------------------Product 3
------------------------Product 2
------------------------Product 1
--------------------Most Popular Products

List All Page Types and Their Properties

We used below query to make Properties Labels more readable for web editors.

select tblPageType.Name 'Page Type Name', tblPageType.Description 'Page Type Description',
tblPageType.FileName 'Page Template File', tblPageDefinition.Name 'Property Name',
tblPageDefinition.EditCaption 'Edit Heading', tblPageDefinition.HelpText 'Help Text'
from tblPageType inner join tblPageDefinition
on tblPageType.pkID = tblPageDefinition.fkPageTypeID
order by tblPageType.Name, tblPageDefinition.FieldOrder

List All Page Template Files, Page Types and Web Pages

select distinct tblPageType.FileName 'Page Template File', tblPageType.Name 'Page Type Name',
tblPageType.Description 'Page Type Description', tblPageLanguage.Name 'Web Page Name',
tblPageLanguage.LinkURL 'Web Page URL'
from tblPageType
inner join tblPage on tblPageType.pkID = tblPage.fkPageTypeID
inner join tblPageLanguage on tblPage.pkID = tblPageLanguage.fkPageID
order by tblPageLanguage.Name

List All Defined Page Types

select Name, Filename from tblPageType
order by Name

EPiServer.ImageMap revisited

2013-04-23T13:05:10.0000000Z

If somebody is using some legacy technologies like image maps then probably there are good news that EPiServer.ImageMap editor plugin has been revisited to make it work with EPiServer 7. Installation There are few steps that you need to take in order to make plugin available for editors: 1. Download latest source from (need … Read More ...

On-page editing and forms editing stop working in EPiServer 7

2013-04-23T11:58:42.0000000Z

Working in EpiServer 7 we discovered that some pages, without any obvious reason, were suddenly not editable anymore. Navigating in edit mode, the particular pages did not get the onpage edit borders and clicking the forms editing button would just make the ajax loader keep going forever. No errors in the logfile either. After some [...]

Set up a user friendly Edit Mode before the training

2013-04-23T11:48:52.0000000Z

EPiServer is, as you probably already know a very flexible system. There is plenty to do to adapt the tool for both visitors and editors. I am so often surprised with that so few do anything about the editor interface.

This blog post is translated with Google Translate. Read the post in Swedish here

I think one reason is that it is so easy to change so that nobody does. The developers do not see it as a problem that there are fields with strange names or tabs that can not benefit from. It does not matter that there are many folders in File Manager, for they are, after all, not be used. But from my perspective, one can not be more wrong. It is exactly this that matters.

A person who has never seen EPiServer has no idea that these things are easy to change and think it must be so. The field where an editor to write his text named Main Body does not think it is logical for that to which to write their body. This creates two problems, and the risk is that the person think that the system is not user friendly and boring. The second problem is that it makes it unnecessarily difficult for a person to learn the system.

My advice to you is that already in the requirement specifications of the website to ensure that all names and field right from the start. There is no reason to delay it. I get so often hear, that we take it later. The problem is that "later" rarely comes. It is simply not done. Even if you do not do it right so it MUST be done before the training of editors. It is often when the editors meet the system the first time and you know how they say, FIRST IMPRESSION LAST.

To simplify for you as a specifier / clients I have made a list of things that need to be examined in EPiServer before training so that editor mode is as easy as possible to learn and understand. If you do not know how things should be done, bring the list to your provider and go through it together. Most of the points concerning EPiServer 6 and earlier, but it's good to go through the list even for EPiServer 7.

Name and help texts on field

All fields in templates may have their own names and help texts. These are often quite technical names and help texts are often lacking. There should be good clear name that makes it easy to understand what each field should contain. This can be done in XML files, so that it is possible to have the editor interface in multiple languages, if desired. Making decisions about which language you should have prior training. Change preferably not on the default name from EPiServer, then this will affect the user documentation to come.

Order in the field

Put the fields in a logical order, so that it becomes easy to fill a page with content. Determine if certain fields should be mandatory or not. Also make sure that it is logical to understand why some fields located on a particular tab. Generally speaking, it may be appropriate to place fields such as page is built, top down simply.

Flaps position, name and any permissions

Determine the order in which tabs to show and which names they should have. Put any rights if not all to see all the tabs.

Settings in the editor field

As the new editor, it is perfectly possible to have different settings on different editor field in the same template. The preamble field would not normally allow the same opportunities as a body field. It would certainly not have as great a field. All this can be customized. Making decisions about size, buttons and design in each field. See attached example from another customer. Please read an old blog post about it here.

Permission to templates / templates available and name

When creating a new page, often appear all templates in a list. Which to be displayed can be controlled in various ways and by those that will be available for a certain template, but also by permission. It needs to be fixed so that editors do not think they can create all kinds of pages. Also give all templates logical names and help texts. Sort them in a logical order in the places where they are more in the same list.

Structure and permissions in the file manager

About EPiServer file manager is used, there should be a finished structure with permissions on the folders. There must be a logical way to find files and know where to invest. Failure to do this from the beginning, the file manager will be like a haystack that it is impossible to find anything in. It is important to determine the starting points to use, and structure them so that the correct starting point is displayed first.

Folder structure for block

If you use EPiServer 7, we also need a folder structure of and access rights to the block.

Folders in the form handler

It is quite common that there are lots of forms and hence a need to put them in different folders that you should find. Create these folders before training, we learn editors to find right from the start.

Permissions in tree structure

The various permissions that different groups will have, should be established before the training. It will be silly if a person has the right to do things during the course, but do not have it then. The danger is that it leads to becoming confused by too many things during the course and then when you come back you become frustrated because you can not do things that made during the course. You often think you make a mistake, though, this is actually the system that has limitations.

Clear up the tree structure

The tree should be as clean as possible, with as much "real" data as possible. Remove whatever tests and other devices and control up to any systemic side is a little hidden for editors. The tree should as far as possible reflect the structure you see on the website, it is most logical for the editor.

Multi language / Globalization

In many solutions the language support enabled, though it is not supposed to work in multiple languages. Should the site be only in one language, this function should be disabled.

Workflows

Should workflows used? If not then hide this tab.

CMS 7.1 upgrade issues

2013-04-22T14:41:55.0000000Z

Since the release of 7.1 we have had a few cases reporting problems with the update and one example is that edit/admin mode ends up being white without any errors. One possible solution for this is to empty the Temporary ASP.NET files for the site and its listed in the Known issues section for the installations

http://world.episerver.com/Documentation/Items/Installation-Instructions/EPiServer-CMS/Version-7/Installation-Instructions---EPiServer-7-CMS/Installation-Instructions---EPiServer-7-1-CMS/

We have received cases where this wasn't a solution and are investigating the causes for the issues. It has however been hard to reproduce but it got top priority within EPiServer and we will update the Known issues whenever we have more information.

If the section doesn't help for your installation then please report your problem on the link below and if you got an environment where the issue can be reproduced it’s even better:

How to choose a search solution for your EPiServer site

2013-04-21T01:50:26.0000000Z

There's a jungle of search products out there. Matching their features with your requirements is critical to making the right choice for your site.

How EPiServer's HTML helper PropertyFor works

2013-04-20T12:04:32.0000000Z

When using Web Forms the standard/default/recommended way to render an EPiServer property is to use the EPiServer:Property control. When using ASP.NET MVC its counterpart is the HTML helper PropertyFor.

That is, PropertyFor is the counterpart the Property control in MVC in terms of being the recommended way to render a property. It is however not the equivalent of the Property control in terms of functionality.

Wrapping elements

As you may know, the Property control always wraps the property value in a HTML element. The element differs depending on the property type and can be customized using the CustomTag attribute on the control. This isn't the case with PropertyFor.

To examplify, let's look at the code below where we use the PropertyFor method to render a string property.

<div>
    @Html.PropertyFor(x => x.Heading)
</div>

Given the Heading property has the value "Banana", the above will output the following when the page is rendered in view mode.

<div>
    Banana
</div>

When the page is rendered in edit mode the output will instead be:

<div>
    <div class="epi-editContainer" data-epi-property-name="Heading" data-epi-use-mvc="True">Banana</div>
</div>

As you can see, the property's value has been wrapped in a div with a CSS class and a couple of data-attributes.

Conclusion: PropertyFor never wraps the property's value in an element when rendering it in view mode. It always wraps the property's value in an element when rendering it in edit mode.

CustomTag and CssClass

As I've previously written about, it's possible to pass settings such as CustomTag and CssClass to PropertyFor. With the Property control the CustomTag setting controls the type of element that the property is wrapped in and the CssClass setting adds one or more CSS classes to the wrapping element.

Let's modify the previous example to see what PropertyFor does with them.

<div>
    @Html.PropertyFor(x => x.Heading, new { CustomTag = "h1", CssClass ="muted" })
</div>

In view mode this changes the output to:

<div>
    Banana
</div>

That's right, it doesn't change the output at all.

What about when rendered in edit mode?

<div>
    <h1 class="epi-editContainer" data-epi-property-name="Heading" data-epi-use-mvc="True" data-epi-property-rendersettings="{&quot;customTag&quot;:&quot;h1&quot;,&quot;cssClass&quot;:&quot;muted&quot;}" class="heading">Banana</h1>
</div>

Starting with CustomTag we can see that setting it to h1 changed the type of the wrapping element that PropertyFor added in edit mode.

Conclusion: CustomTag changes the type of element that wrapes the rendered property when rendered in edit mode.

As for CssClass that added a class attribute with the specified value to the element. However, there already was another class attribute on the element and our custom CSS class wasn't added to that. It was added as a separate class attribute, meaning that the browser will ignore it. Here's how FireBug sees the rendered markup:

So, it appears that while CustomTag changes the type of wrapping element that PropertyFor renderes the property in in edit mode CssClass doesn't, in practice, have any effect on the class attribute on the wrapping element.

However, there's another setting we can pass to PropertyFor, EditContainerClass. Let's see what happens if we use that instead of CssClass, like this:

<div>
    @Html.PropertyFor(x => x.Heading, new { CustomTag = "h1", EditContainerClass ="muted" })
</div>

That produces the following when rendered in edit mode:

<div>
    <h1 class="muted" data-epi-property-name="Heading" data-epi-use-mvc="True" data-epi-property-rendersettings="{&quot;customTag&quot;:&quot;h1&quot;,&quot;editContainerClass&quot;:&quot;muted&quot;}">Banana</h1>
</div>

Look at that. No second class attribute has been added and the first has changed from "epi-editContainer" to the value we specified in EditContainerClass.

Conclusion: CssClass does not change the CSS class for the wrapping element when rendered in edit mode. EditContainerClass does.

Us specifying CustomTag, CssClass and, later, EditContainerClass also brought another change to the rendered markup in edit mode - a data-epi-property-rendersettings attribute was added to the wrapping element. The attributes value looks to be the serialized version of the anonymous object we used to pass the settings to PropertyFor with.

How PropertyFor renders property values

So far we've looked at how and when PropertyFor wraps the output for a property. But, beyond rendering a wrapping element in edit mode, how does it actually render a property?

In Web Forms the Property control uses the ClassFactory

DisplayTemplates

AdditionalViewData in display templates

Null check

EPiServer 7 patch 2, MVC and session state

2013-04-20T11:22:45.0000000Z

When my colleague Niklas Melinder applied patch 2 for EPiServer 7 he ran into trouble when the site was deployed to our acceptance server. The site started to throw “System.InvalidOperationException: The SessionStateTempDataProvider class requires session state to be enabled.”. Since our acceptance environment runs with sessions state switched off it was pretty clear what caused [...]

Automatically Populating Page or Block Type Properties for a Language Branch in EPiServer 7

2013-04-19T05:02:00.0000000Z

The creation and editing of content for multiple language sites in EPiServer 7 has recently become a topic of conversation in some of our projects. We occasionally receive feedback from our clients who are looking for ways to reduce the amount of time it takes to enter content, while also being consistent with the page and block layout.

One big change with the new Edit Mode in EPiServer 7, which was available in EPiServer 6 (and technically is still available in the old Edit Mode), is that feature to compare the language branches for a page side-by-side has been removed. This was useful for editors who need to keep the content for pages consistent between each language branch, as it allowed them to easily compare the different language branches.

So to help this, we created a property attribute called [AutoPopulateLanguageBranch]. Whenever a editor translates a page or block, this copies the values from the master language branch to the new language branch for the decorated page or block type properties. This keeps the content consistent between the language branches, which, at the same time, helps speed up the process of entering content.

The Code

First of all, the ability to translate blocks for different language branches was added with the release of EPiServer 7.1. If you are not running EPiServer 7.1, I recommend upgrading your project before you start using this attribute.

We just need three things: the [AutoPopulateLanguageBranch] attribute to decorate our properties, an initialization module to monitor when we should copy our property values, and an IContent extension method to actually copy the decorated property values.

AutoPopulateLanguageBranchAttribute.cs

We start with a simple attribute to decorate our page type properties and block type properties.

[AttributeUsage(AttributeTargets.Property)]
public class AutoPopulateLanguageBranchAttribute : Attribute
{
}

AutoPopulateLanguageBranchInitializationModule.cs

The first main piece of this is the initialization module. This attaches (and detaches) the InitializeContentLanguageBranch method to the LoadedDefaultContent event of the DataFactory, which "occurs when a new content item has been created and initialized". This method is essentially just some preventative checks and content data setup. We need to make sure we have legitimate content, and that the content we are working with is not on the master language branch. Then, we grab the content data from the master language branch, so we have something to copy over to the new language branch. Once we have everything, we send it over to ContentExtensions for the copying of property values.

[InitializableModule]
[ModuleDependency(typeof(EPiServer.Web.InitializationModule))]
public class AutoPopulateLanguageBranchInitializationModule : IInitializableModule
{
    public void Initialize(EPiServer.Framework.Initialization.InitializationEngine context)
    {
        DataFactory.Instance.LoadedDefaultContent += InitializeContentLanguageBranch;
    }

    public void Preload(string[] parameters)
    {
    }

    public void Uninitialize(EPiServer.Framework.Initialization.InitializationEngine context)
    {
        DataFactory.Instance.LoadedDefaultContent -= InitializeContentLanguageBranch;
    }

    private void InitializeContentLanguageBranch(object sender, ContentEventArgs e)
    {
        if (e.Content != null && e.Content.ContentGuid != Guid.Empty)
        {
            var contentLanguage = new ContentLanguageEventArgs(e.Content);
            if (contentLanguage != null && !contentLanguage.IsMasterLanguageBranch)
            {
                var contentLoader = ServiceLocator.Current.GetInstance<IContentLoader>();
                var masterLanguageContent = contentLoader.Get<IContent>(contentLanguage.ContentLink, new LanguageSelector(contentLanguage.MasterLanguageBranch));
                if (masterLanguageContent != null)
                {
                    e.Content.InitializeDefaultPropertyData(masterLanguageContent);
                }
            }
        }
    }
}

ContentExtensions.cs

The second main piece is the extension method InitializeDefaultPropertyData for the IContent interface. Once again, we do some preventative checks, then get the page/block Type, so we can look through the properties and see which ones are decorated with the [AutoPopulateLanguageBranch] attribute. After we have on all the properties, we simply copy the Value over from the sourceContent to the targetContent. Finally, we return the targetContent back to the module.

public static class ContentExtensions
{
    public static IContent InitializeDefaultPropertyData(this IContent targetContent, IContent sourceContent)
    {
        if (sourceContent == null || 
            sourceContent.GetType() != targetContent.GetType() || 
            sourceContent.GetType().BaseType == null)
        {
            return targetContent;
        }

        var type = sourceContent.GetType().BaseType;

        foreach (var property in type.GetProperties().Where(p => p.GetCustomAttributes(typeof(AutoPopulateLanguageBranchAttribute), true).Length > 0))
        {
            if (property != null && 
                targetContent.Property[property.Name] != null && 
                targetContent.Property[property.Name].IsLanguageSpecific)
            {
                targetContent.Property[property.Name].Value = sourceContent.Property[property.Name].Value;
            }
        }

        return targetContent;
    }
}

The Usage

Using the [AutoPopulateLanguageBranch] attribute is really straightforward... Just decorate the properties that you want to copy over in your page types or block types.

So for a page type, it could look something like this:

[ContentType(GUID = "00000000-0000-0000-0000-000000000000")]
public class StandardPage : PageData
{
    [CultureSpecific]
    [AutoPopulateLanguageBranch]
    public virtual XhtmlString MainBody { get; set; }

    [CultureSpecific]
    [AutoPopulateLanguageBranch]
    public virtual ContentArea MainContentArea { get; set; }
}

Or for a block type:

[ContentType(GUID = "00000000-0000-0000-0000-000000000000")]
public class ImageBlock : BlockData
{
    [CultureSpecific]
    [AutoPopulateLanguageBranch]
    [UIHint(UIHint.Image)]
    public virtual Url Image { get; set; }
}

It's pretty obvious that the [AutoPopulateLanguageBranch] attribute is commonly seen next to the [CultureSpecific] attribute. If the property is not decorated with [CultureSpecific], then it will be skipped during the copy process.

A nice part about this attribute is that it can populate a page's ContentArea property with the blocks that are placed in it, and if the block has not yet been translated to the new language branch, it will fallback and show the content data for the block's master language branch. This is what the block will look like on a page in Edit Mode:

That gives the editor a really good visual cue that the block needs to be translated to the new language branch.

Add UIHint to an EPiServer property without affecting its editor

2013-04-18T13:49:30.0000000Z

We can use UI hints to make the PropertyFor and DisplayFor methods use a specific display template when rendering properties with ASP.NET MVC.

For instance, when rendering a property like this...

[UIHint("Banana")]
public virtual string Heading { get; set; }

...using Html.PropertyFor() it will be "sent" to a display template named Banana, given such a template exists.

There's just one problem. When adding a UI hint that no editor descriptor cares about we loose the original editing functionality for the property and it will be edited using the "legacy" editing functionality. That is, instead of a textbox for a string property editors will see a button saying "Click the button to edit".

To fix that, use an overload for the UIHint attribute and specify PresentationLayer.Website, like this:

[UIHint("Banana", PresentationLayer.Website)]
public virtual string Heading { get; set; }

One caveat, while this works great with PropertyFor it won't work with DisplayFor which won't recognize the UI hint any longer.

Specify z-index for a property's overlay in EPiServer's on page edit mode

2013-04-18T13:31:47.0000000Z

Sometimes two property values overlap when rendered in a template. It may for instance be a string property whose value should be rendered on top of an image which is also a property. Or it may be a link/URL property that should be rendered at the of a string property.

By default both properties will have an overlay, the thin blue border that is positioned on top of the element in which the property value is rendered. However, only one of them will be clickable.

To handle that we can specify the z-index for the overlay for the property that isn't clickable. To do so add a data-epi-overlay-z-index attribute to the element that contains the property. For instance, when using ASP.NET MVC and Razor:

<h1 data-epi-overlay-z-index="123" @Html.EditAttributes(x => x.Heading)>
    @Model.Heading
</h1>

ImageVault 4 is now available for EPiServer 7 CMS!

2013-04-18T12:30:24.0000000Z

The use of digital media on the web has rapidly increased during the past years and every organization today has the need to use some type of digital media (e.g. images or streaming media) to convey their message in an efficient manner. Today’s users also has a greater expectation on their CMS platform to have some kind of capability for managing digital media in a more structured way that facilitates the process of using digital assets on the web.

In the report ”Digital Asset Management Q2 2012” Forester highlight Digital Asset Management’s touch points with Content Management:

Organizations look to integrate rich media management solutions with other enterprise applications — particularly those that deliver online content. And DAM’s role in supporting persuasive content makes it an important part of the new set of CXM solutions for engaging customer experiences.

Find out more about ImageVault 4 and EPiServer 7 CMS here.

Changes to the module.config for EPiServer 7.1

2013-04-18T08:50:15.0000000Z

I’ve seen on the forum that there have been several people having issues running their custom dojo code after the EPiServer 7.1 update. So I thought I’d mention these issues, their cause and the solution.

Required Resources Key Changed for CMS

So I’ve demonstrated in previous blog posts that it’s possible to initialize a module without having a component. This was done by using a little trick to add an initializer script to the required resources for CMS by adding the following to your module.config file.

<clientResources>

  <add name="epi.cms.widgets.base" path="initialize.js" resourceType="Script" />

</clientResources>

With the upgrade to dojo 1.8.3 we changed the dojo package name for CMS to be epi-cms. This is due to the fact that dojo has made changes in their loader which means that dot or slash separated package names are no longer supported. To be consistent with our naming we also changed the key for required resources. So the following are now the required resource keys:

EPiServer 7: epi.cms.widgets.base

EPiServer 7.1: epi-cms.widgets.base

JavaScript Package Naming

As mentioned previously dojo have changed their loader to be fully AMD compliant and as such dot or slash separated names are no longer supported. For example the following is no longer supported:

<dojoModules>

  <add name="my.addon" path="scripts/addon" />

</dojoModules>

My suggestion if you are in this situation is to change the delimiter from dot or slash to be a dash instead. Meaning that in the above example the package name would instead be my-addon.

Hopefully this helps anybody who runs into similar issues!

How to Delete the Language Branch for a Page or a Block in EPiServer 7

2013-04-18T02:57:00.0000000Z

The release of EPiServer 7 has brought numerous changes to the way editors interact with Edit Mode. One such change is the process needed to remove the language branch for a page or a block. Of course, you could always use the old Edit Mode to complete this task, but let's find out how to do this in EPiServer 7's new Edit Mode.

The EPiServer 6 Way

In EPiServer 6, the process to delete the language branch for a page was pretty straightforward, primarily because the "Delete Language" link was located in the context menu (right-click) of the page.

If you prefer to use EPiServer 7's old Edit Mode, this hasn't changed at all; you'll still get the context menu and this menu still looks the same.

One issue with EPiServer 6, though, was that you couldn't delete a language branch for the Start Page. The workaround to solve this was to point the site's Start Page to a different page, remove the language branch, then point the site's Start Page back to the correct one. This might not be a big deal for development environments, but once you move to a production server, this could possibly cause some issues.

The EPiServer 7 Way

In EPiServer 7, since the context menu was removed, the link to delete the language branch for a page or a block had to be relocated. You'll now find the link in the Versions gadget.

In the navigation pane or the assets pane, click the "Settings" button (the little cog) in the upper corner next to the "Pin" button, and click the "Add Gadgets" link. In the modal that opens, scroll down and click "Versions". (Simply clicking "Versions" will add the gadget; you will not recieve any notifications that it added the gadget.) The gadget will appear by default at the bottom of the navigation/assets pane. Once the gadget has been added and is visible, you'll find the "Delete {insert your current language} Language Branch" link when you click the "More options" button.

You should note that the Versions gadget that you open in the navgiation pane is the same that you open in the assets pane. So if you are trying to delete the language branch for a block, you need to go into the block's "Edit" screen, otherwise you'll still be working with the page's version. It's probably good idea to actually read the "Delete Language Branch" confirmation window, so you don't make a mistake when deleting the language branch. Deleting the language branch for a page or a block does not put it in the Trash. It cannot be undone.

EPiServer 7 also now has the ability to delete a language branch for the Start Page. The same link in the Versions gadget will allow you to do this.

Unfortunately, you will not be able to delete the language branch if you're on the master language branch (typically the "EN" branch). The link will be grayed out, diabled, and unclickable.

Configuring TinyMCE using EPiServer custom property settings

2013-04-17T12:19:39.0000000Z

The TinyMCE rich-text editor provides great flexibility for editors to create and mark-up content within EPiServer. TinyMCE is a seemingly infinitely configurable tool and can be configured to show / hide many of its available features. One of the ways EPiServer Administrators / Developers / Integrators can help is by configuring TinyMCE to only show [...]

Hide pages in the page tree in EPiServer 7

2013-04-17T10:18:04.0000000Z

Sometimes it could be useful to manipulate how certain pages are displayed in the page tree in EPiServer 7. Because the page tree is loaded from a REST based store, all you really need to do is provide a custom implementation of the ContentQuery responsible for...

The REST stores in EPiServer are discovered at application startup. The ContentStructureStore which is used for loading content into the page tree (no shit?), will be provided with a number of ContentQuery classes at initialization. One of them is EPiServer.Cms.Shell.UI.Rest.ContentQuery.GetChildrenQuery.

Provide your custom query

First add a reference to EPiServer.Cms.Shell.UI assembly. Yes, you will now have a dependency to an EPiServer module, so think about that for a moment.

Then add your own GetChildrenQuery class. You get alot of goodies through the ContentQueryParameters object passed to GetContent, such as CurrentPrincipal, CurrentLanguage etc.

So, short example. I’ll hide all content that have a name containing “Alloy”.

using System;

using System.Collections.Generic;

using System.Diagnostics;

using System.Linq;

using System.Web;

using EPiServer.Cms.Shell.UI.Rest.ContentQuery;

using EPiServer.Core;

using EPiServer.ServiceLocation;

namespace EPiServer.Templates.Alloy.Business

{

    [ServiceConfiguration(typeof(IContentQuery))]

    public class MyGetChildrenQuery : GetChildrenQuery

    {

        public MyGetChildrenQuery(IContentQueryHelper queryHelper, IContentRepository contentRepository, LanguageSelectorFactory languageSelectorFactory) : base(queryHelper, contentRepository, languageSelectorFactory)

        {

        }

        protected override IEnumerable<IContent> GetContent(ContentQueryParameters parameters)

        {

            return base.GetContent(parameters).Where(x => !x.Name.Contains("Alloy"));

        }

    }

}

EPiServer Find 101

2013-04-16T20:36:20.0000000Z

New to EPIServer Find and want a jump start? Here's what you need to know.

If you're new to EPiServer Find and going to use it in a project, or just want to try it out, there's plenty of documentation on Find's site. There's also training offered by EPiServer. Not to mention the forum on EPiServer World.

Sometimes you need a little quick start though. Here's the most essential things to know about Find's .NET API and CMS integration.

Setting up

You can grab yourself a free test index at find.episerver.com. Once you have created your index you can copy and paste the necessary configuration into your app.config or web.config.

Finally you need to download and reference Find's .NET API. That's easily done through NuGet given that you have EPiServer's NuGet feed added as a package source. There's three packages to choose from. For an EPiServer CMS site install EPiServer Find CMS Integration. For any other type of .NET application install EPiServer Find Client API.

Communicating with the REST API

You can use the .NET API from any .NET application. When doing so, all communication with Find's REST API goes through an instance of the IClient interface. To obtain such an instance when not using the CMS integration you can use the Client.CreateFromConfig() method to create it based on settings in app.config/web.config.

If you're using the CMS integration or any other integration for other EPiServer products always use the singleton SearchClient.Instance. This is important. The singleton is preconfigured with conventions set up for CMS content.

"If you're using the CMS integration always use the singleton SearchClient.Instance"

Finding things

Once you have a client search for indexed objects (CMS objects are automatically indexed upon save) using the Search<T>() method where T is the type of objects you want to search for. The method supports inheritance and searching for objects that implement an interface.

The Search method returns an object which you can add queries and filters to. Use the For method for free text search. Use the Filter method to apply criterias.

The Filter method is very similar to LINQ's Where method but has a slightly different syntax. You can filter on any property of a "simple" type, such as int, string, DateTime, double, GUID etc. Check out the documentation for more information or use Intellisense.

You can use methods with familiar names from LINQ to apply sorting, projections and paging - OrderBy, Select, Skip, Take etc.

Once you're done building your search request execute it against the REST API and get the result using the GetResult() method. The returned object will be an object the implements IEnumerable<T> so you can start iterating over the results straight away.

Note that if you're searching for CMS objects such as PageData and want to fetch the full objects you shouldn't use GetResult but instead use the GetContentResult() method. When using the integration for CMS 6, that's called GetPagesResult.

"if you're searching for CMS objects such as PageData and want to fetch the full objects ... use the GetContentResult() method"

Unified Search

One of the things that makes Find powerful and easy to use at the same time is the fact that it let's us index our own .NET object and search for them in a strongly typed way. Sometimes though, such as building a search page, we want to search over many different types. Find makes that easy to using a concept called Unified Search.

In general - use the regular Search method for building listings, navigations and specialized search page with ease and use Unified Search when building free text search pages where users should search in *everything*.

Where to go from here

That's it. A few key concepts to get you started and a few important things to remember to avoid being faced by a YSOD.

Once you've familiarized yourself with Find's .NET API you can move on to indexing custom objects or why not check out some of the more specialized and interesting methods such as MoreLike and BoostMatching. Also, don't miss out of the many types of facets which you can use to build many interesting things.

Want to build a search page for an EPiServer site quickly? Here's one complete with annotated source code for you.

Happy Finding!

Unwanted Lucene Search Results in EpiServer Commerce R2

2013-04-16T08:33:00.0000000Z

Issue: User was getting unexpected search results for products, e.g. with a search key word ‘Sate’ he was getting same result as for ‘Site’. Although for most of the clients they will happy with these results but this particular client was unhappy with this result due to their business requirements. We do not have any word like ‘Sate’ in our Database or in Index file for Lucene. Clearly it was Fuzzy search that was causing this although in code we have set FuzzySearch = false;

Reason:

// Perform Lucene search

SearchResults results = searchFilterHelper.SearchEntries(criteria) as SearchResults;

In the Mediachase.Commerce.Website, Version=5.2.243.2, SearchFilterHelper's SearchEntries() method, below:

public virtual ISearchResults SearchEntries(CatalogEntrySearchCriteria criteria) { try {

_Results = Manager.Search(criteria);

}

catch (SystemException)

{

if (HttpContext.Current.IsDebuggingEnabled)

throw;

}

// Perform fuzzy search if nothing has been found

if (_Results.TotalCount == 0) {

criteria.IsFuzzySearch = true;

criteria.FuzzyMinSimilarity = 0.7f;

_Results = Manager.Search(criteria);

}

return _Results;

}

As you can see there is an initial call to Manager.Search().

Before returning, the TotalCount property on the ISearchResults object returned is checked to see if there were no results.

If there are no results a fuzzy search is done.

That was causing the issue although iSFuzzySearch was false at the time of request.

Fix: A fix is present in Episerver Commerce R2 Sp2. There is an extra Function is available that can be used to stop FuzzySearch if no result is found with actual keyword.

public virtual ISearchResults SearchEntries(CatalogEntrySearchCriteria criteria, bool isFuzzySearch, float minSimilarity)

// Perform Lucene search

SearchResults results = searchFilterHelper.SearchEntries(criteria,false,0) as SearchResults;

Special thanks to Jeff from EpiServer’s Developer Support team to find out the reason and fix.

Example Code:

internal CatalogIndexSearchDataSource CreateDataSource(SearchFilterHelper filter, int pageNo, int pageSize, ref int totalRows, bool cacheResults, int cacheTime, string nodeString, string keywords, List<string> metaClasses)

{

var currentCulture = Thread.CurrentThread.CurrentUICulture;

Thread.CurrentThread.CurrentUICulture = new CultureInfo(SiteContext.Current.LanguageName);

var recordsToRetrieve = pageSize;

//cache timeout

TimeSpan cacheTimeout = new TimeSpan(0, (int)cacheTime, 0);

// Perform search

SearchSort sortObject = null;

// Put default sort order if none is set

if (sortObject == null)

sortObject = CatalogEntrySearchCriteria.DefaultSortOrder;

var criteria = filter.CreateSearchCriteria(keywords, sortObject);

//If meta classes are given to search.

if (metaClasses != null)

foreach (string metaClass in metaClasses)

criteria.SearchIndex.Add(metaClass);

//Add catalogs

foreach (var row in CatalogContext.Current.GetCatalogDto(SiteContext.Current.SiteId).Catalog)

{

if (row.IsActive && row.StartDate <= FrameworkContext.Current.CurrentDateTime && row.EndDate >= FrameworkContext.Current.CurrentDateTime)

criteria.CatalogNames.Add(row.Name);

}

//add catalog nodes

if (!string.IsNullOrEmpty(nodeString))

{

foreach (string outline in SearchFilterHelper.GetOutlinesForNode(nodeString))

{

criteria.Outlines.Add(outline);

}

CatalogIndexSearchDataSource dataSource = null;

// No need to perform search if no catalogs specified

if (criteria.CatalogNames.Count != 0)

{

Entries entries = new Entries();

// Perform Lucene search

SearchResults results = searchFilterHelper.SearchEntries(criteria,false,0) as SearchResults;

// Get IDs we need

int[] resultIndexes = results.GetIntResults(pageNumber , maxRows+5); // we add padding here to accomodate entries that might have been deleted since last indexing

if (resultIndexes.Length > 0)

{

int[] productResultIndexes = RefinementHelper.GetParentProducts(pageSize, pageNumber, resultIndexes, ref totalRows);

// Retrieve actual entry objects, with no caching

entries = CatalogContext.Current.GetCatalogEntries(productResultIndexes, false, new TimeSpan(), responseGroup);

// Add in attribute information

AddAttributes(entries, results);

// Insert to the cache collection

entries.TotalResults = totalRows;

CatalogCache.Insert(cacheKey, entries, cacheTimeout); dataSource = new CatalogIndexSearchDataSource { TotalResults = totalRows, CatalogEntries = entries };

}

Thread.CurrentThread.CurrentUICulture = currentCulture;

return dataSource;

}

Sending settings from the server to your editor

2013-04-16T07:20:10.0000000Z

I got a question how you can send settings that are defined on the server to an editor. It’s really quite simple so lets have a look on a simple example. We start by defining an editor descriptor and adding an entry in the EditorConfiguration dictionary:

[EditorDescriptorRegistration(TargetType = typeof(string), UIHint = "author")]

public class AuthorEditorDescriptor : EditorDescriptor

    public AuthorEditorDescriptor()

        ClientEditingClass = "alloy.editors.AuthorSelector";

        EditorConfiguration["foo"] = "bar";

The settings in the EditorConfiguration dictionary is mixed on to the editor instance when started so you can access these settings as they were regular properties of your editor. This sample checks the value of foo in the postCreate-method:

postCreate: function () {

    if (this.foo === "bar") {

        alert("Happy happy joy");

},

And when the editor starts we get:

How to Add Valid Elements (like iframes) to TinyMCE in EPiServer 7

2013-04-16T03:23:00.0000000Z

In a recent EPiServer 7 project, our client needed support for iframes and some other HTML tags in the TinyMCE WYSIWYG editor. Luckily, the way you add valid elements to TinyMCE hasn't changed much between EPiServer 6 and EPiServer 7, though some small issues have made the update a little more involved. In this post, I'll show you how to add valid elements to TinyMCE and how to fix the issues you'll potentially encounter along the way.

What Hasn't Changed

Like EPiServer 6, you need to add a simple class to your project to register the extended valid elements. The name and location of the class does not matter, as long as it is compiled into your project. The most important part of this that we are focusing on is the TinyMCEPluginNonVisual attribute

[TinyMCEPluginNonVisual(AlwaysEnabled = true, EditorInitConfigurationOptions = "{ extended_valid_elements: 'iframe[src|frameborder=0|alt|title|width|height|align|name]' }")]
public class TinyMceExtendedValidElements
{
}

As you can see in above code, our example is pretty simple. We are just telling TinyMCE to allow the iframe tag and some attributes.

Next, you need to update episerver.config...

<episerver>
    ... some configuration ... 
    <tinyMCE mergedConfigurationProperties="valid_elements, extended_valid_elements, invalid_elements, valid_child_elements" />
</episerver>

Where Issues Arise

After you add the class to your project and update the configuration file, you may notice that the TinyMCE editor doesn't load. If you open up Fiddler or your browser's developer tool utility, you can see a 404 error is thrown for a particular JavaScript file.

The browser is looking for a file in the path /util/Editor/tinymce/plugins//editor_plugin.js. The // hints that something is missing, and that something is the plug-in name. So from here, we can update our class to include the PlugInName...

[TinyMCEPluginNonVisual(PlugInName = "TinyMceExtendedValidElements", AlwaysEnabled = true, EditorInitConfigurationOptions = "{ extended_valid_elements: 'iframe[src|frameborder=0|alt|title|width|height|align|name]' }")]
public class TinyMceExtendedValidElements
{
}

And when we build the project and refresh the browser, we can see the exact path that TinyMCE needs:

But now the issue is that we don't have a file at that location, and in fact, we don't need one. Ted Nyberg used to a good workaround to solve this... Simply use an empty file handler to serve up a blank file. Here is the code for our empty file handler:

public class EmptyFileHandler : IHttpHandler
{
    public bool IsReusable
    {
        get { return true; }
    }

    public void ProcessRequest(HttpContext context)
    {
    }
}

Then to hook this up, just add this configuration to web.config that only targets the path that TinyMCE is looking for:

<configuration>
    ... some configuration ... 
    <location path="util/editor/tinymce/plugins">
        <system.webServer>
            <handlers>
                <add name="TinyMceExtendedValidElements" path="/util/editor/tinymce/plugins/TinyMceExtendedValidElements/editor_plugin.js" verb="GET" type="MyEPiServerProject.Business.Handlers.EmptyFileHandler, MyEPiServerProject" />
            </handlers>
        </system.webServer>
    </location>
</configuration>

And there we have it! Now TinyMCE will stop removing iframe tags from the saved content.

From here, you can simply update the parameter in the TinyMCEPluginNonVisual attribute on the class to allow any other tags and attributes that you need to support in your content.

Resources:

Clone a purchase order and convert into cart

2013-04-15T09:38:00.0000000Z

We have a requirement for our client that he can masquerade user and can create a new cart based on some existing Purchase Order(e.g. for damaged/lost orders).

Option 1: Get The OrderForm and other objects from PurchaseOrder and assign it to new Cart.
It did not work as result was a nasty output. On saving Purchase Order for new cart, OrderForm from Parent was assigned to new cart and parent Purchase order lost its associated OrderForms.

Option 2:

Clone the Purchase Order and create a cart based on that but it will not work because. (I tested this with EpiServer Commerce R2SP2)

Type 'Mediachase.Commerce.Orders.PurchaseOrder' in Assembly 'Mediachase.Commerce, Version=5.2.628.0, Culture=neutral, PublicKeyToken=6e58b501b34abce3' is not marked as serializable.

Solution:

We can clone OrderForms and OrderAddresses. Therefore I created a clone copy of OrderForm and order addresses and added that into the Cart.

Below piece of code helped me to achieve this. Note I have not tested/run workflows.

Cart mycart = OrderContext.Current.GetCart("replacementcart", SecurityContext.Current.CurrentUserId);

CopyCart(mycart, Order);

//Delete and added a new Payment(Zero Charged)
//Convert into Purchase Order

/// <summary>

/// Copy cart

/// </summary>

/// <param name="_cart"></param>

/// <param name="orderGroup"></param>

public static void CopyCart(Cart _cart, PurchaseOrder orderGroup)

{

// Initial validation

if (_cart == null) throw new ArgumentNullException("_cart");

if (orderGroup == null) throw new ArgumentNullException("orderGroup");

// need to set meta data context before cloning

MetaDataContext.DefaultCurrent = OrderContext.MetaDataContext;

OrderForm of = orderGroup.OrderForms[0].Clone() as OrderForm;

// Remove existing Order Forms

for (int i = _cart.OrderForms.Count-1 ; i>=0;i--)

{

_cart.OrderForms[i].Delete();

}

//Add order Forms to basket from PurchasOrder.

_cart.OrderForms.Add(of);

// Remove existing Order Addresses

for (int i = _cart.OrderAddresses.Count-1 ; i>=0;i--)

{

_cart.OrderAddresses[i].Delete();

}

foreach (OrderAddress address in orderGroup.OrderAddresses)

{

MetaDataContext.DefaultCurrent = OrderContext.MetaDataContext;

OrderAddress oa = address.Clone() as OrderAddress;

_cart.OrderAddresses.Add(oa);

}

_cart.SetParent(_cart);

_cart.AddressId = orderGroup.AddressId;

_cart.AffiliateId = orderGroup.AffiliateId;

_cart.ApplicationId = orderGroup.ApplicationId;

_cart.BillingCurrency = orderGroup.BillingCurrency;

_cart.CustomerId = orderGroup.CustomerId;

_cart.CustomerName = orderGroup.CustomerName;

_cart.ProviderId = orderGroup.ProviderId;

_cart.Status = orderGroup.Status;

_cart.Owner = orderGroup.Owner;

_cart.OwnerOrg = orderGroup.OwnerOrg;

_cart.ShippingTotal = orderGroup.ShippingTotal;

_cart.SiteId = orderGroup.SiteId;

_cart.SubTotal = orderGroup.SubTotal;

_cart.TaxTotal = orderGroup.TaxTotal;

_cart.Total = orderGroup.Total;

_cart.AcceptChanges();

}

Pattern for EPiServer block preview MVC controller

2013-04-15T08:26:49.0000000Z

using System.Web.Mvc;
using EPiServer.Core;
using EPiServer.Framework.DataAnnotations;
using EPiServer.Framework.Web;
using EPiServer.Web;

namespace MySite
{
    [TemplateDescriptor(
        Inherited = true,
        TemplateTypeCategory = TemplateTypeCategories.MvcController,
        Tags = new [] { RenderingTags.Preview },
        AvailableWithoutTag = false)]
    public class PreviewController : Controller, IRenderTemplate<BlockData>
    {
        public ActionResult Index(IContent currentContent)
        {
            //TODO: Create model suitable for the view and return ViewResult
            return View();
        }
    }
}

Explained:

using System.Web.Mvc;
using EPiServer.Core;
using EPiServer.Framework.DataAnnotations;
using EPiServer.Framework.Web;
using EPiServer.Web;

namespace MySite
{
    [TemplateDescriptor(
        //Support everything inheriting from BlockData.
        Inherited = true,
        //By default controllers implementing IRenderTemplate<T> where T is BlockData
        //are registered as partial renderers. As this will be a "full page" renderer
        //we need to change that.
        TemplateTypeCategory = TemplateTypeCategories.MvcController,
        //Should only be used for preview
        Tags = new [] { RenderingTags.Preview },
        AvailableWithoutTag = false)]
    public class PreviewController : Controller,
        //Register as template for BlockData. To only support a specific type
        //change the type parameter from BlockData to that type and optionally
        //set Inherited = false in the the TemplateDescriptor attribute above.
        IRenderTemplate<BlockData>
    {
        public ActionResult Index(
            //While we implement IRenderTemplate for BlockData model binding
            //can only deal with IContent, ie shared blocks in this case.
            IContent currentContent
            )
        {
            //TODO: Create model suitable for the view and return ViewResult
            return View();
        }
    }
}

Hiding EPiServer properties from editors

2013-04-14T14:10:08.0000000Z

When managing a property in EPiServer's admin mode there is a setting named "Display in Edit Mode". To control this setting from code in EPiServer 7 use the ScaffoldColumn attribute.

When set to false it will hide the property from editors, meaning that while they may seem the rendered value in preview mode they won't see a blue box around it and they won't be able to click on the property to edit it. The property won't be visible in forms editing mode either.

There is also the Editable attribute. When this is set to false the property will still be visible to editors in both preview mode, with a blue box around it, and in forms editing mode. The editor for it will however be disabled, meaning that while editors can inspect the property's value they can't modify it.

Working with Localization and Language Branches in EPiServer 7 MVC

2013-04-12T02:40:00.0000000Z

One powerful feature that EPiServer 7 provides is the localization of page content and the creation of language branches for your site, which allows you to create a multi-language, international site without the need for a huge amount of work. In this post, we'll look at how to configure, utilize, and develop for localization in EPiServer 7.

Languages Branches in Edit Mode

When comparing to previous versions of EPiServer, the latest release of EPiServer 7 has dramatically changed the way you work with language branches in Edit Mode. While some may think this new approach is taking a step backwards, it definitely takes a bit more steps to add a language branch to a page. But at the same time, it provides better organization when working with multi-site EPiServer applications.

Adding Languages

Let's first start with adding languages. This part has not changed between EPiServer 6 CMS and EPiServer 7. In Admin Mode, under the Config tab, you'll find the "Manage Website Languages" page. On this page, you can add a new language, enable/disable languages, and set access rights for a language branch. One thing to note that the access rights in the area only control which languages editors/administrators can work with in Edit Mode. It does not affect access rights on the visitor's side.

Also, the list of languages that you can add is generated from the .NET Framework's CultureInfo class in the System.Globalization namespace, and only contains the language codes that adhere to the RFC 1766 standard. If you want to add a custom language code, you'll need to add a custom culture, and this culture will need to be added on any server the site lives on.

Making Languages Available

After all the languages you want to support are added and enabled, you need to make them available in Edit Mode. Click on the Root Page of your EPiServer site, go into Forms Editing mode, click the "Tools" dropdown, and select "Language Settings". Click the "Change" button in the "Available Languages" section, check all of the languages you want to make available for editing, then click "Save". If you already have a Start Page set up and configured, you may need to do the same steps on the Start Page.

Changing the Master Language

If you want to change the master language for the site, you don't necessarily need to worry about this in EPiServer 7, primarily because you no longer need the Root Page to be in the same language branch as your master language. After you add, enable, and make available the language branches you want to use, just assign the "master" language to the host name, and switch to that language branch. If you have previously created pages in the old "master" language, you can just remove them then disable that language branch.

Adding a Page to a Language Branch

The biggest change between EPiServer 6 CMS and EPiServer 7 is the steps needed to switch from one language branch to another in order to add a new page:

Open the navigation pane
Click the "Sites" tab
Click the "Settings" button (the little cog) in the bottom right of the navigation pane and choose "Show All Languages" (you might be able to skip this step if you are using EPiServer 7.1)
Expand the current site and select the language you want (Edit Mode will reload)
Open the navigation pane again
Click the "Settings" button (the little cog) in the bottom right and select "Show All Languages"
Click the page in the other language and click the button "Translate"
Edit the page

I find it useful to pin the navigation pane open when working on sites with multiple languages.

Note: If you are using EPiServer 7.1, the "Show All Languages" text has been switched to say "Show Content Not in {insert your current language}". Also, the flow of language handling has been improved (see below).

Translating Blocks and Their Folders (added in EPiServer 7.1)

Much like translating pages, with the release of EPiServer 7.1, you can now translate blocks and the folders they live in. From the release notes:

Now you can translate blocks and their folders in the same way as for pages with the option Show All Languages for the shared blocks gadget. This option will show blocks and folders for all languages. Not translated blocks have a language code representing the fallback language, when this is turned off only blocks and folders that are available for the current language will be shown.

Edit Mode "View As" Settings (added in EPiServer 7.1)

Also added in EPiServer 7.1 is the improved flow of language handling, which added a new option to the view settings. When you click the "Toggle view settings" button (the little eye) in Edit Mode, you'll see a new option with your current language branch.

Clicking that will open the "View in this language" dropdown with all enabled languages for the site. When you select one of those languages, it will display the currently viewed page in the selected language, though it will not switch completely to that language branch. If the page does not exist in the selected language, it will give you direct link to translate it, which will switch Edit Mode to that language branch.

Language Provider Configuration

In EPiServerFramework.config, you can configure the location of your language files, the fallback behavior, and the fallback culture:

<localization fallbackBehavior="Echo, MissingMessage, FallbackCulture" fallbackCulture="en-US"></p>

<pre><code><providers>
    <add virtualPath="~/Resources/LanguageFiles" name="languageFiles" type="EPiServer.Framework.Localization.XmlResources.FileXmlLocalizationProvider, EPiServer.Framework" />
</providers>
</code></pre>

<p></localization>

Notice in the configuration the values in the fallbackBehavior attribute. There are four possible values available:

Echo - If no match for the key is found, and if the key does not start with a '#' or a '/', it will return back the key unmodified.
MissingMessage - If no match for the key is found, it will return a message stating that the resource could not be found.
FallbackCulture - If no match for the key is found, it will attempt to return the resource from the culture specified in the fallbackCulture attribute.
None - If no match for the key is found, nothing will be returned.

If you would like to use a custom localization provider, check out this page in the EPiServer documentation.

Linking to Another Language Branch

Getting your visitors to a different language branch has became much easier with EPiServer 7 MVC. You just need to provide the language code to the route data.

For example, in your front-end views (using Razor):

@Html.PageLink("Link Text", pageData.PageLink, new { language = "sv-SE" }, null)

Or your back-end code:

return RedirectToAction("Index", new { language = "sv-SE" });

Back-End Localization

To access localization data from the back-end code, use an instance of the LocalizationService, which is part of the EPiServer.Framework.Localization namespace.

var translatedValue = LocalizationService.Current.GetString("/sometemplate/somevalue");

Other methods in this class allow you to return all localization keys available, or to return localization data for a specified culture. I recommend checking out the LocalizationService class in the EPiServer 7 SDK when it comes to finding the right method for your needs.

From the back-end, you can also override the fallbackBehavior language provider configuration attribute directly in the method from the LocalizationService instance. For example, if you do not want to show any fallback text, you can pass in FallbackBehaviors.None as a parameter:

var translatedValue = LocalizationService.Current.GetString("/sometemplate/somevalue", FallbackBehaviors.None);

Alternatively, if you want to directly specify the fallback text, you can just pass in a string:

var translatedValue = LocalizationService.Current.GetString("/sometemplate/somevalue", "Fallback String");

Front-End Localization

To access localization data from the front-end view (in our case, using Razor), use the Translate helper, which is a provided EPiServer MVC HTML helper:

@Html.Translate("/sometemplate/somevalue")

You could also use the TranslateFallback helper, which will return a supplied fallback string if no match is found:

@Html.TranslateFallback("sometemplate/somemissingvalue", "Missing a translation")

EPiServer has also created some HTML helpers that can generate HTML for forms, such as the TranslatedButton, TranslatedLabel, and TranslatedTextBox helpers.

Language Files

More than likely, you'll create custom language files for your application, either to store translated text used in Edit Mode for editors in different cultures, or in the view for visitors in different parts of the world.

The Old 'lang' Folder

With the release of EPiServer 7, the system localization normally stored in the 'lang' folder have disappeared. The documentation explains what happened to them:

Though strictly not needed, the lang folder under the web directory will continue to work as before and any language XML files placed here will be read by a default localization provider that is added automatically. If you do not wish for this to happen, you can just remove the folder or set the value of the addDefaultProvider attribute of the resources element to false.

If you want to override the system localizations that are shipped with EPiServer products, you will notice that the language files are no longer installed in the lang folder. They are now instead embedded in the assemblies but just as before you can override individual string by placing your own language XML in the lang folder. Of course you can include your localizations through any other LocalizationProvider and they will take precedence over the system localizations as long as the provider is registered before the system ones.

Our Custom Language Files

In the above configuration file, we specified our location of the language file. At this location, you just need to add (one or many) XML files to hold the values. Any XML files you add here needs to have the XML declaration, followed by the parent <languages> node which contains (one or many) <language> nodes for each language code (that matches the language branch):

<?xml version="1.0" encoding="utf-8" ?>
<languages>
  <language name="English (United States)" id="en-US"></p>

<pre><code><sometemplate>
    <somevalue>Translated Value</somevalue>
</sometemplate>
</code></pre>

<p>  </language>
</languages>

Aside from the <languages> and <language> nodes, there are no naming standard you need to follow when naming the custom keys or the XML files. So as you can imagine, you could either put all translated values for all languages in one XML file, or you could split it up into many XML files so it's better organized.

The one exception to this is when you are trying to localize the text in Edit Mode. Unfortunately, it is not thoroughly documented what the names of the keys should be, though there has been a couple blog posts that has helped shed some light on these values. For more information on this, I've found these resources:

If you still cannot find the necessary names for the keys, the best solution is just look at the source code using a decompiler/reflector tool. I had to do this when I was trying to figure out how to localize error messages generated from an XForm property.

A Closer Look at the AvailablePageTypes Attribute in EPiServer 7

2013-04-12T02:35:00.0000000Z

I was recently looking into how to fully use the [AvailablePageTypes] attribute in my page models, and after a bit of research and reading the sometimes confusing documentation, and the less confusing class documentation, I found it has some interesting and helpful features. Let's take a closer look at this attribute.

Using the Attribute

As you could guess, this attribute is used to specify which page types can or cannot be created under an instance of a specific page type. This is an optional attribute, but it can drastically help organize the 'Create New Page' screen, while also preventing editors from creating pages in the wrong area. This attribute is not supported on block models.

Availability

The first parameter in the attribute is Availability. This parameter takes one value from the Availability enum found in the EPiServer.DataAbstraction.PageTypeAvailability namespace. There are four possible options:

All - This specifies that all page types will be available to be created under a page instance. This is the default value.
None - This specifies that no page types will be available to be created under a page instance. If this value is set, all other settings on the attribute are ignored.
Specific - This specifies that only the selected page types will be created under a page instance. This value makes more sense when configuring available page types in Admin Mode. (My guess is that when any of the other settings on the attribute is set, this value gets auto-selected.)
Undefined - You shouldn't use this, as it's not even an option in Admin Mode.

Include and Exclude

The two most common parameters for this attribute are Include and Exclude, both of which require an array of Types. One common example would be on a Start Page model:

[ContentType(GUID = "49754310-E0ED-4C95-AA69-C155323E0AA9")]
[AvailablePageTypes(</p>

<pre><code>Include = new Type[]{ typeof(StandardPage), typeof(ListPage) },
Exclude = new Type[]{ typeof(StartPage), typeof(SettingsPage) }
</code></pre>

<p>)]
public class StartPage : PageData
{
}

In this page model, we are saying that we will allow any pages of type StandardPage and ListPage to be created, and we will not allow any pages of type StartPage or SettingsPage to be created.

Pretty simple and straightforward in my opinion.

IncludeOn and ExcludeOn

These parameters were a bit tricky to understand at first, primarily because the explanation in the documentation is a little confusing.

The documentation states:

IncludedOn differs from Include in the way that it is not excluding. That is. for types in IncludedOn that has all page types available no page types will be excluded. Include on the other hand will exclude all typed pages except the ones given in Include.

Excluded works so that if no types are set on Included then the result will be that all registered page types except the Excluded ones are available. If there are types registered in Included then all types in Included except the ones in Excluded are available. Below is an image that shows how Excluded and ExcludedOn are mapped to settings in admin mode.

This is how I see it:

You would use IncludeOn to specify that the current page type can be created under the specified page type(s). So for our example, we could use the IncludeOn parameter in the StandardPage to specify that it can be created under any page instance the StartPage page type:

[ContentType(GUID = "49754310-E0ED-4C95-AA69-C155323E0AA9")]
[AvailablePageTypes(</p>

<pre><code>IncludeOn = new Type[]{ typeof(StartPage) }
</code></pre>

<p>)]
public class StandardPage : PageData
{
}

Similarly, you would use ExcludeOn to specify that the current page type can not be created under the specified page type(s). So for our example, we could the the ExcludeOn parameter in the SettingsPage to specify that is can not be created under any page instance of the StartPage page type:

[ContentType(GUID = "49754310-E0ED-4C95-AA69-C155323E0AA9")]
[AvailablePageTypes(</p>

<pre><code>ExcludeOn = new Type[]{ typeof(SettingsPage) }
</code></pre>

<p>)]
public class SettingsPage : PageData
{
}

So think of these parameters as a vice-versa of Include and Exclude. By using these parameters, you can keep the array of Types short and concise, while also reducing the need to go back and revise the Include or Exclude Type arrays of the other page model.

How the Attributes are Applied

With this attribute potentially spread across all of your page models, you might start finding yourself either conflicting or being redundant with your Include, IncludeOn, Exclude, and ExcludeOn parameters.

If that's the case, keep in mind how the attributes are applied:

Include implicitly excludes all page types not in the list
Exclude implicitly includes all page types not in the list
IncludeOn and ExcludeOn combine with the settings on the target page type
If there is a conflict, Exclude and ExcludeOn have priority over Include and IncludeOn.

Turn Your EPiServer 7 MVC Page/Block Model into a View Model using the Ignore Attribute

2013-04-12T02:28:00.0000000Z

If you've ever built a large MVC application, you'll know that your project can sometimes contain a large amount of files, some of which act as a layer of code between two aspects of the application. One such file is the view model, which is used to transfer data from the controller to the view.

When developing with EPiServer 7 MVC, in most situations you can use the page or block model directly in your view. There are some cases, however, where you'll find yourself using a separate view model to satisfy the needs of the view.

An Example

For example, say you have a page model with a LinkItemCollection property, but the view needs a List of a particular page type. You could easily create two files for this, the page model and the view model:

Page Model

[ContentType(GUID = "49754310-E0ED-4C95-AA69-C155323E0AA9")]
public class ListPage : PageData
{</p>

<pre><code>public virtual LinkItemCollection PageCollection { get; set; }
</code></pre>

<p>}

View Model

public class ListPageViewModel
{</p>

<pre><code>public List<SimplePage> PageList{ get; set; }
</code></pre>

<p>}

However, you can simplify this into one file by using the [Ignore] attribute on the property. The [Ignore] attribute prevents EPiServer from registering the property as an editable page/block type property.

[ContentType(GUID = "49754310-E0ED-4C95-AA69-C155323E0AA9")]
public class ListPage : PageData
{</p>

<pre><code>public virtual LinkItemCollection PageCollection { get; set; }

[Ignore]
public virtual List<SimplePage> PageList{ get; set; }
</code></pre>

<p>}

Why Use This?

While I completely understand that some people may disagree with this idea (primarily because of the many benefits that the view model provides), I've found this useful particularly for a couple reasons:

Fewer lines of code by eliminating edit hints - By turning the page/block model into a view model, you don't need to add on-page editing hints in the ViewData in your controller:

var editHints = this.ViewData.GetEditHints<ListPageViewModel, ListPage>();
editHints.AddConnection(vm => vm.PageList, pm => pm.PageCollection);

Instead, you can use EPiServer's EditAttributes HTML helper, and use on the properties in the page/block model to provide the proper on-page editing:

@model ListPage</p>

<div @Html.EditAttributes(m => m.PageCollection)>
    @foreach (var page in Model.PageList)
    {
        ... some code ...
    }
</div>


<p>

Fewer files to maintain by eliminating a layer of code - By using the [Ignore] attribute, you can look at the page/block model and see exactly what the view needs, whether the property is for editing purposes or for displaying purposes. This also makes it easier to update or maintain the code in future changes.

Creating a XForm Block in EPiServer 7 MVC with Working Validation (Updated)

2013-04-12T02:11:00.0000000Z

I initially posted this solution on the Nansen blog, but since then the code has been updated for both bug fixes and to reduce unnecessary layers (at least, unnecessary for my situation).

With the flexibility that block types offer in EPiServer 7, it would make sense that one common feature that people would want is an XForm in a block, so editors can freely add, move, and reuse blocks with forms around their website. In a recent project, this was one of my requirements.

Although a solution for making XForms to work inside a block type has been partially solved, it doesn't fully support validation, which is a common requirement. Also, the documentation is still lacking when it comes to explaining how to integrate XForms in EPiServer 7 MVC, both within a page type and a block type.

This solution was developed using the initial release of EPiServer 7. The EPiServer support team has stated that they may implement a solution for fully working XForms in a block on a future release.

The Solution

The solution to this revolved heavily around making sure the action URL on the form was correct (so we stay on the page the the block is located) and sharing the controller's ViewData with all controllers that needed it (both page controllers and block controllers).

/Models/Blocks/XFormBlock.cs

This is the block class with the XForm block. By decorating the ActionUri property with the [Ignore] attribute, we can treat this class also as the view model for the view. The [Ignore] attribute prevents EPiServer from registering the property as an editable block type property.

[ContentType(GUID = "49754310-E0ED-4C95-AA69-C155323E0AA9")]
public class XFormBlock : BlockData
{</p>

<pre><code>[Display(GroupName = SystemTabNames.Content)]
public virtual XForm Form { get; set; }

[Ignore]
public virtual string ActionUri { get; set; }
</code></pre>

<p>}

/Controllers/BasePageController.cs

This is the most important piece of the solution, since it handles all the XForm actions, as well as sets the ViewData that's used in the block controller.

The first main method that we override is the OnResultExecuting() method, which sets the ViewData in the TempData collection after a page controller sets it. Without this, the block controller will have a different ViewData, which makes all the validation information go away.

The second main method we override is OnActionExecuting(), which handles the transfer of the ViewData between the XForm methods Success() and Failed() to the page controllers they are redirecting to through the RedirectToAction("Index") call.

When the ViewData is set, we use a unique key for the form in the TempData collection. The unique key uses the ContentLink ID of the block, which is built into the ActionUri and passed in as a parameter to the XFormPost method. This unique key allows us to use multiple XForm blocks on the same page without the ViewData of one block interfering with the ViewData of another block. The only exception to this is when a page has two instances of the same XForm block (which really doesn't happen very often). One side benefit of this is that we only transfer the ViewData when we have the _contentId, which prevents unnecessary saving and fetching of the ViewData.

public class BasePageController<T> : PageController<T> where T : PageData
{</p>

<pre><code>private readonly XFormPageUnknownActionHandler _xformHandler;

private string _contentId;

private readonly string _viewDataKeyFormat = "ViewData_{0}";
private string ViewDataKey
{
    get
    {
        return string.Format(_viewDataKeyFormat, _contentId);
    }
}

public BasePageController()
{
    _xformHandler = new XFormPageUnknownActionHandler();
    _contentId = string.Empty;
}

protected override void OnActionExecuting(ActionExecutingContext filterContext)
{
    if (!string.IsNullOrEmpty(_contentId))
    {
        if (TempData[ViewDataKey] != null)
        {
            ViewData = (ViewDataDictionary)TempData[ViewDataKey];
        }
    }

    base.OnActionExecuting(filterContext);
}

protected override void OnResultExecuting(ResultExecutingContext filterContext)
{
    if (!string.IsNullOrEmpty(_contentId))
    {
        TempData[ViewDataKey] = ViewData;
    }

    base.OnResultExecuting(filterContext);
}

[AcceptVerbs(HttpVerbs.Post)]
public virtual ActionResult Success(XFormPostedData xFormPostedData)
{
    return RedirectToAction("Index");
}

[AcceptVerbs(HttpVerbs.Post)]
public virtual ActionResult Failed(XFormPostedData xFormPostedData)
{
    return RedirectToAction("Index");
}

[AcceptVerbs(HttpVerbs.Post)]
public virtual ActionResult XFormPost(XFormPostedData xFormpostedData, string contentId)
{
    _contentId = contentId;

    return _xformHandler.HandleAction(this);
}
</code></pre>

<p>}

/Controllers/XFormBlockController.cs

In the block's controller, we grab the ViewData that we saved in the BasePageController using the same unique key. This allows us to maintain the validation data for the XForm.

The important part of this is how we build out the ActionUrl. We can get the currentPage data from the PageRouteHelper, then find the virtual path to the page we are viewing using a UrlResolver, so we always POST to the page that the block is on. We also put the block's ContentLink ID in the ActionUri so the BasePageController knows how to save the ViewData. The rest of the values in the query string are to set the actions that the XForm handler uses if the submission was successful or unsuccessful.

One things to note is that if we are using on-page editing for the block, we won't have a currentPage. In this situation, we just borrow the Start Page. This won't matter anyway, because if you try to click the "Submit" button, rather than the form being submitted, the form selection modal will pop up instead.

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

{</p>   {         {      }              {       }       {               }   }   

>1 class="">public class XFormBlockController : BlockController<XFormBlock> <pre><code>public override ActionResult Index(XFormBlock currentBlock) var currentBlockID = (currentBlock as IContent).ContentLink.ID; var viewDataKey = string.Format("ViewData_{0}", currentBlockID); if (TempData[viewDataKey] != null) ViewData = (ViewDataDictionary)TempData[viewDataKey]; var pageRouteHelper = ServiceLocator.Current.GetInstance<PageRouteHelper>(); PageData currentPage = pageRouteHelper.Page; // For block preview mode, we need to have a current page, // but since preview isn't really a page, we'll use the start page // This won't matter anyway. If you try to submit the form, // the form selection window will pop up. if (currentPage == null) var contentLoader = ServiceLocator.Current.GetInstance<IContentLoader>(); currentPage = contentLoader.Get<StartPage>(ContentReference.StartPage); if (currentBlock.Form != null && currentPage != null) var urlResolver = ServiceLocator.Current.GetInstance<UrlResolver>(); var pageUrl = urlResolver.GetVirtualPath(currentPage.ContentLink); var actionUri = string.Format("{0}XFormPost/", pageUrl); actionUri = UriSupport.AddQueryString(actionUri, "XFormId", currentBlock.Form.Id.ToString()); actionUri = UriSupport.AddQueryString(actionUri, "failedAction", "Failed"); actionUri = UriSupport.AddQueryString(actionUri, "successAction", "Success"); actionUri = UriSupport.AddQueryString(actionUri, "contentId", currentBlockID.ToString()); currentBlock.ActionUri = actionUri; return PartialView(currentBlock); </code></pre> <p>}



/Views/XFormBlock/Index.cshtml

This is just a simple view for the block. The primary thing that is different compared to how we normally output page properties is that we need to set the action on the form.

1
2
3
4
5
6
7
8
9
10
11
12
@model XFormBlock</p>

<div @Html.EditAttributes(m => m.Form)>
    @Html.ValidationSummary()
    @using (Html.BeginXForm(Model.Form, new { Action = Model.ActionUri }))
    {
        Html.RenderXForm(Model.Form);
    }
</div>


<p>


And that's it. With this solution, you don't need to worry handling the XForm in any specific page controllers that the block lives in, although you could easily just override the XFormPost() method in the BasePageController if needed. This also supports the built-in 'Save to database' and/or 'Send e-mail' submit options.



Get the PageData of some Catalog Node
2013-04-11T08:46:15.0000000Z
Below function can help you to retrieve PageData object of some CatalogNode without effecting performance.

        private PageData FindPageByCatalogNode(CatalogNode catalogNode)     
        {     
            string text = (catalogNode.ParentNode != null) ? catalogNode.ParentNode.ID : 
            CatalogContext.Current.GetCatalogNode(catalogNode.ParentNodeId).ID;     
            if (text == null)     
            {     
                CatalogDto catalogDto = CatalogContext.Current.GetCatalogDto(catalogNode.CatalogId);     
                text = ((catalogDto == null || catalogDto.Catalog == null || catalogDto.Catalog.Count == 0) 
                ? string.Empty : catalogDto.Catalog[0].Name);     
            }     
            string key = MappedPPDB.BuildKey(new object[]     
            {     
                catalogNode.CatalogNodeId,     
                string.Empty,     
                catalogNode.ParentNodeId,     
                catalogNode.CatalogId,     
                NodeType.CatalogNode,     
                catalogNode.ID,     
                text     
            });     
            int id = MappedPPDB.Instance.LoadMapping("CatalogPageProvider", key).Id;     
            return DataFactory.Instance.GetPage(new PageReference(id, "CatalogPageProvider"));     
        }


Integrating EPiServer 7 with MVC – Next Steps
2013-04-09T16:40:42.0000000Z
My previous blog post, Integrating EPiServer 7 with an existing MVC site, outlined the initial steps to get EPiServer 7 running. However there are a number of additional steps you may need to take before your site is fully integrated. Convert any Controllers not in Areas If your site only contains controllers within Areas then [...]


Custom routing for EPiServer content
2013-04-09T04:30:00.0000000Z
Two real-world examples of how to customize the routing for EPiServer pages to take control of the site's URLs and links.
EPiServer 7 CMS uses the built in routing functionality in ASP.NET for URL handling. The default routing when using EPiServer 7 mimics the friendly URL functionality in older versions of the CMS in which the URL for a page is built up of it's URLSegment property prefixed by it's ancestors URL segments.

There are many nice aspects of the default behavior.  For instance, URL's for pages match their places in the page tree and in navigation elements making them seem logical and predictable. However, it also has the drawback of tying the URL for a page to it's location in the page tree making it risky to move content.
Also, in some situations, such as when you have a site with a lot of content, it may not be appropriate to place content in a specific place in the content tree even though it belongs there.
It may also be that a page is only used as a data bearer without a template and links to it should lead to some other page, optionally with some parameters in the URL.
In such cases we need to extend or modify EPiServer's default routing. In this article I'll show two real-world examples of doing just that.
Custom routing using partial routing
The first example is drawn from how articles are routed on this site. The article you're currently reading is tied to the EPiServer CMS category (a page) on the site which is reflected in navigation elements.

It does not however reside under the CMS category's page. Instead it's placed in a hierarchical structure based on the date it was created.

Why articles is stored this way is beyond the scope of this article but, as you can probably imagine, storing them this way brings a few problems.
Making the article belong to the CMS category is straight forward. All that's needed is a property of type ContentReference or PageReference on the page type used for articles. That can then be used when building menus and breadcrumbs.
Listing content based on categories is a bit trickier to achieve performance wise with the CMS' API but in my case I have Find to help me with that.
Finally, the URL for an article will be /<year>/<month>/<URLSegment>/. While that's not terrible it's not what I want. Instead I wanted the URL's for articles to be simply the host name followed by their URL segments.
Partial routing
EPiServer 7 features a concept called partial routing. In the developer guide it's described as
Partial routing makes it possible to extend routing beyond pages. You can use partial routing either to route to data outside EPiServer CMS or to route to other content types than pages.
We can however also use it to route ordinary pages, like articles in this case.
To utilize partial routing we create a class implementing IPartialRouter<TContent, TRoutedData> found in the EPiServer.Web.Routing namespace. The first type parameter specifies the type of content we're interested in routing children for. The second the type of content, or other type of object that we'll be routing.
Did I lose you there? Perhaps a fruity example can clarify things.
A class that implements IPartialRouter<Banana, Apple> will be able to route outgoing URLs whenever the object to route is an apple. Whenever a part of the URL for an incoming request has been routed to a content object of type Banana and there are still parts of the URL left to route it will be handed the banana and information about the remaining URL and asked to return an apple.
Crystal clear, right? Perhaps not. Let's look at how we can use it to route articles.
Implementing IPartialRouter
Given that we want articles to have relative URLs that are simply their URL segments the first type parameter when implementing IPartialRouter is the page type class that is used for the start page. The second type parameter is the page type used for articles.
Let's create a class that implements IPartialRouter with those type parameters and have Visual Studio generate the required methods for us.
using System.Web.Routing;
using EPiServer.Web.Routing;
using EPiServer.Web.Routing.Segments;
using MySite.Models.Pages;

namespace MySite.Routing
{
  public class ArticleRouter : IPartialRouter<StartPage, ArticlePage>
  {
    public object RoutePartial(StartPage content, SegmentContext segmentContext)
    {
      throw new System.NotImplementedException();
    }

    public PartialRouteData GetPartialVirtualPath(
      ArticlePage content, 
      string language, 
      RouteValueDictionary routeValues,
      RequestContext requestContext)
    {
      throw new System.NotImplementedException();
    }
  }
}
As you can see, there are two methods that we'll need to implement. RoutePartial is for incoming requests while GetPartialVirtualPath is for outgoing.
We'll start by implementing the RoutePartial method.
RoutePartial
The RoutePartial method will be invoked whenever a the first parts of the URL points to a page of the TContent type parameter and there are remaining parts of the URL left to route. In this example, as we're implementing the IPartialRouter interface with the start page's type as the TContent parameter that will pretty much always be the case.
The method is invoked with two arguments. The first is the content of type TContent that the first parts of the URL route to, the start page in our case. The second is an object of type SegmentContext which contains information about the next segment in the URL to route.
Using the two arguments it's our job to figure out what article, if any, the request should be routed to.
public object RoutePartial(StartPage content, SegmentContext segmentContext)
{
  if (!content.ContentLink.CompareToIgnoreWorkID(ContentReference.StartPage))
  {
    return null;
  }

  var nextSegment = segmentContext.GetNextValue(segmentContext.RemainingPath);
  var urlSegment = nextSegment.Next;
  if (string.IsNullOrEmpty(urlSegment))
  {
    return null;
  }
            
  ArticlePage article = null;

  //TODO: Figure out which article it is we're routing based on the urlSegment variable, if any, and populate the article variable with that.

  if (article != null)
  {
    segmentContext.RemainingPath = nextSegment.Remaining;
    segmentContext.RoutedContentLink = article.ContentLink;
  }
  
  return article;
}
There's quite a few things going on in the above code.
First of all it verifies that the root content is indeed an object for which we want to route remaning parts of the URL. In other words, if we for some reason are dealing with a page of the StartPage type that is not the start page. Not likely when dealing with start pages perhaps, but stranger things have happened and this check may be vital in other scenarios.
Next we proceed to retrieve the next part of the URL which we assign to the urlSegment variable. For an URL such as /hello-world/ the urlSegment variable's value will be "hello-world". For an URL such as /hello/world/ the urlSegment variable's value will be "hello".
Given that there is indeed at least one more segment in the URL we proceed to locate an article whose URL segment matches that. As that's code specific to the site I've omitted my implementation.
How one would do this can vary greatly from site to site. On a small site we may simply retrieve all articles and use LINQ's Where method to find an article with a matching URLSegment property. On a larger site we may use EPiServer Find or we may make the page's ID a part of the URL when implementing outgoing routing which we'll get to shortly.
However we choose to locate articles, or whatever it it we're routing, we need to make sure to do it in a good way performance wise. This code will be called a lot!
Given that we've found an article that we wish to route to we remove the URL segment that we've taken care of from the SegmentContext by assigning the remaning part of the URL to its RemainingPath property. That is, given an article with a URL such as /hello-world/ where we have extracted "hello-world" from the segment context we update it to set its remaining path to nothing.
Also, given that we've found an article, we modify the segment context so that it knows that we've found content that we want to route to.
Finally we return the article, or null, if we didn't find one. If we return null nothing in particular will happen. The routing will proceed as usual routing to a page of some other type or resulting in a 404.
GetPartialVirtualPath
The GetPartialVirtualPath method will be invoked when an article is being outgoing routed. That is, when we for instance create a link to an article with the PageLink HTML helper method.
It's invoked with four arguments which we can use to determine the context in which the article is being routed. Based on those we need to return an object of type PartialRouteData.
The PartialRouteData class has two properties - BasePathRoot and PartialVirtualPath. The generated relative URL will be a combination of the relative URL of the content referenced by BasePathRoot and whatever we set PartialVirtualPath to.
public PartialRouteData GetPartialVirtualPath(
  ArticlePage content, 
  string language, 
  RouteValueDictionary routeValues,
  RequestContext requestContext)
{
  var contentLink = ContentRoute.GetValue("node", requestContext, routeValues) 
                      as ContentReference;

  if (!content.ContentLink.CompareToIgnoreWorkID(contentLink))
  {
    return null;
  }

  return new PartialRouteData
  {
    BasePathRoot = ContentReference.StartPage,
    PartialVirtualPath = content.URLSegment
  };
}
In the implementation above we begin by extracting a reference to the content that is being routed using the ContentRoute.GetValue method. Typically this will be a reference to the same article that is being passed to the method as the "content" parameter. However, I've found at least one situation when that wasn't the case.
If the method is invoked in context of routing something else than the article passed in as the "content" variable we're not interested in modifying the routing so we simply return null.
If however we are dealing with an article that we want to modify the routing for we create a new PartialRouteData object, populate its properties and return it.
Since in this example we want articles to simply have their own URL segments as URLs we set the BasePathRoot to a reference to the start page and the PartialVirtualPath to the article's URLSegment property.
Using the partial router
Our partial router class is done. In order for it to be used we need to add it to the site's route table during start-up though. That's easily done using an initialization module and the RegisterPartialRouter extension method that EPiServer provides (in the EPiServer.Web.Routing namespace).
using System.Web.Routing;
using EPiServer.Framework;
using EPiServer.Framework.Initialization;
using EPiServer.Web.Routing;

namespace MySite.Routing
{
  [ModuleDependency(typeof(EPiServer.Web.InitializationModule))]
  public class RouteInitialization : IInitializableModule
  {
    public void Initialize(InitializationEngine context)
    {
      var articleRouter = new ArticleRouter();
      RouteTable.Routes.RegisterPartialRouter(articleRouter);
    }

    public void Uninitialize(InitializationEngine context)
    {
    }

    public void Preload(string[] parameters)
    {
    }
  }
}
Restoring tree-like URLs
In the above example we modify EPiServer's default routing to make pages of a specific type, articles, have URLs that are simply their URL segments. That's what I wanted for this site as it decouples article's URLs from both their place in the tree and their categories.

However, we're not limited to that specific use case. For instance we may instead want articles in the example scenario we've looked at here to have a URL based on their categories instead. As if they were actually placed under their categories in the page tree.

To accomplish that we would need to make a few modifications to our partial router class.
Since the "URL homes", the base path, for articles won't be the start page but instead a categories the first step is to modify the TContent type parameter when implementing IPartialRouter. Instead of the start page's type we set it to the type under which articles will reside URL-wise. In the case of this site that would be the class CategoryPage.
public class ArticleRouter : IPartialRouter<CategoryPage, ArticlePage>
Changing the type parameter of the implemented interface we need to change the type of the RoutePartial method's first parameter or the compiler will complain.
public object RoutePartial(CategoryPage content, SegmentContext segmentContext)
Now the compiler is happy but we'll need to make some changes to the code as well. Let's start with the GetPartialVirtualPath method as that's easiest.
All we need to do there is change what we set the BasePathRoot property on the object we return to. Instead of setting it to a reference to the start page we set it to a reference to some other page that will provide the first part of the article's URL. For our example scenario that would be the property that points to the article's main category.
return new PartialRouteData
{
  BasePathRoot = content.MainCategory,
  PartialVirtualPath = content.URLSegment
};
The RoutePartial method will need to undergo larger changes.
We can skip the initial check that the root content which is passed in in as the "content" variable is indeed the root page we care about as we now have multiple possible roots.
Instead we'll need to verify that the root, the category, should be used as the routing parent for the article that we're routing.
ArticlePage article = null;

//TODO: Figure out which article it is we're routing based on the urlSegment variable, if any, and populate the article variable with that.

if (article == null 
    || content.ContentLink.CompareToIgnoreWorkID(article.MainCategory))
{
  return null;
}

segmentContext.RemainingPath = nextSegment.Remaining;
segmentContext.RoutedContentLink = article.ContentLink;
      
return article;
Custom routing using a custom segment
We've now seen an example of how we can use the partial routing concept in EPiServer 7 to implement custom routing. In the next example we'll look at another way of customizing routing - by using a custom implementation of the ISegment interface.
On this site I use pages to define tags. That is, each tag is a page somewhere in the page tree and articles have a content area to which I can add one or more tag pages. This allows me to change the name of a tag without having to update all pages tagged with it. It also gives me the possibility to add unique content to a tag beyond its name.
When I tag a page with one or more existing tags I simply drag them to the content area. When I render a list of tags I simply output a link to each tag using the PageLink HTML helper.
As I have a separate template for tag pages this works great. However, when the site first went live I didn't have that template. Instead I wanted a tag-link to point to a search for the tag using the site's search page.

One way to solve that would of course have been to find all places where links to tags were rendered and modify the code there to link to the search page. That wouldn't have been a very flexible solution though. By instead modifying the outgoing URLs for tag pages by modifying routing for them I didn't have to touch any other code.
At first glance it may seem like we could use partial routing for this scenario as well but a case like this, where we want to route to a specific page with one or more query string parameters isn't really what partial routing is for.
Instead we can handle cases like this by creating a custom implementation of the ISegment interface and register a  route that uses the segment.
Creating a segment
In order to create a custom segment we create a class that implements ISegment (in the EPiServer.Web.Routing.Segments namespace). Alternatively we can let our class inherit SegmentBase which I'll do in this example.
using System;
using System.Web.Routing;
using EPiServer.Web.Routing.Segments;

namespace MySite.Routing
{
  public class TagSearchSegment : SegmentBase
  {
    public TagSearchSegment(string name) : base(name)
    {
    }

    public override bool RouteDataMatch(SegmentContext context)
    {
      throw new NotImplementedException();
    }

    public override string GetVirtualPathSegment(
      RequestContext requestContext, 
      RouteValueDictionary values)
    {
      throw new NotImplementedException();
    }
  }
}
As you can see from the code above, where I've had Visual Studio autogenerate required methods for me, SegmentBase has two abstract methods that we must implement - RouteDataMatch and GetVirtualPathSegment.
RouteDataMatch is invoked during in-bound routing. We get passed information about the current context and can use that to determine if we want to modify the routing. If we do we modify the context in some way and return true. However, as we only care about out-bound routing in this example we can simply implement it to return false.
public override bool RouteDataMatch(SegmentContext context)
{
  return false;
}
GetVirtualPathSegment
The GetVirtualPathSegment method is invoked during outgoing routing and in order to modify the URL we'll need to return a string with the URL, or part of the URL, that we want to route to. We'll also need to remove values that we feel we've taken care of from the RouteValueDictionary that is passed to the method.
public override string GetVirtualPathSegment(
  RequestContext requestContext, 
  RouteValueDictionary values)
{
  if (GetContextMode(requestContext.HttpContext, requestContext.RouteData) 
      != ContextMode.Default)
  {
    return null;
  }

  var contentLink = ContentRoute.GetValue("node", requestContext, values) 
                      as ContentReference;

  if (ContentReference.IsNullOrEmpty(contentLink))
  {
    return null;
  }

  var contentLoader = ServiceLocator.Current.GetInstance<IContentLoader>();
  var tagToRoute = contentLoader.Get<IContent>(contentLink) as TagPage;
  if (tagToRoute == null)
  {
    return null;
  }

  string tagSearchUrl = null;

  //TODO: Figure out the url we want to route to, if any, and set the tagSearchUrl variable to that

  if (tagSearchUrl == null)
  {
    return null;
  }

  values.Remove("node");
  values.Remove("controller");
  values.Remove("action");
  values.Remove("routedData");

  return tagSearchUrl;
}
That's quite a mouthful! Let's go through it step by step.
First we check that we're not in edit mode using a helper method. This is necessary as we will otherwise get a 404,  or worse, when viewing tag pages in edit mode as our code will route to the search page while EPiServer will add the tag's ID to the URL, meaning that we'll end up viewing invoking the search page's template with the tag page as the current page.
The GetContextMode method looks like this:
private static ContextMode GetContextMode(
  HttpContextBase httpContext, 
  RouteData routeData)
{
  var contextModeKey = "contextmode";
  if (routeData.DataTokens.ContainsKey(contextModeKey))
  {
    return (ContextMode)routeData.DataTokens[contextModeKey];
  }
  if ((httpContext == null) || (httpContext.Request == null))
  {
    return ContextMode.Default;
  }
  if (!PageEditing.GetPageIsInEditMode(httpContext))
  {
    return ContextMode.Default;
  }
  return ContextMode.Edit;
}
Next we proceed to extract a reference to the content that is being  routed. If we can't find such a reference we're probably routing a file  or something else that we don't care about so we return null.
Given that we have a content reference we proceed to fetch the content that we're routing. If it isn't a tag we don't care about it so we return null.
If however the content that we're routing is a tag we build up the URL we want to route to. I've omitted that code as it may be specific to each site and use case.
Given that we have a URL that we want to route to we return it, but before doing so we remove route values that we don't want anyone else who cares about routing to see as we've already taken care of them.
Using the segment
With the custom segment done we need to register a route that uses it for it to matter. As this should be done during start-up of the site we add an initialization module.
using System.Collections.Generic;
using System.Web.Routing;
using EPiServer.Framework;
using EPiServer.Framework.Initialization;
using EPiServer.Web.Routing;
using EPiServer.Web.Routing.Segments;

namespace MySite.Routing
{
  [ModuleDependency(typeof(EPiServer.Web.InitializationModule))]
  public class RouteInitialization : IInitializableModule
  {
    public void Initialize(InitializationEngine context)
    {
      var segment = new TagSegment("tag");
      var routingParameters = new MapContentRouteParameters()
      {
        SegmentMappings = new Dictionary<string, ISegment>()
      };
      routingParameters.SegmentMappings.Add("tag", segment);

      RouteTable.Routes.MapContentRoute(
        name: "tags",
        url: "{language}/{tag}",
        defaults: new { action = "index" },
        parameters: routingParameters);
    }

    public void Uninitialize(InitializationEngine context)
    {
    }

    public void Preload(string[] parameters)
    {
    }
  }
}
Using the code in the Initialize method above we register a route for "{language}/{tag}". We map the {tag} part to our custom segment meaning that it will be replaced with whatever we return from the segment's GetVirtualPathSegment method.
Basic routing
We've just seen two fairly advanced examples of how the routing for content can be customized when using EPiServer 7. In both cases we're more or less in complete control and can execute custom logic on a per-request basis.
That's nice, but there may be cases where we want to do something simpler. Were we don't need all that power and flexibility. For instance, let's say we for some reason wanted to support outputting only the first n characters of the name of a page given that the request is for a page followed by /name/<n>/.
Not the most realistic scenario perhaps, but it does make for a simple example. Anyhow, To handle such a case we wouldn't have to create a partial router or a custom segment. All we need to do is register a route using the MapContentRoute method during start-up.
RouteTable.Routes.MapContentRoute(
  "myRoute", "{language}/{node}/{action}/{charcount}", 
  new {action = "name"});
Now, given that we're using MVC, we can add an action to controllers for pages named Name which will be used for matching requests.
public ActionResult Name(CategoryPage currentPage, int charCount)
{
  if (currentPage.PageName.Length < charCount)
  {
    charCount = currentPage.PageName.Length;
  }
  return new ContentResult()
  {
    Content = currentPage.PageName.Substring(0, charCount)
  };
}

For another example of this type of custom routing check the routing section in EPiServer's developers guide.
Conclusion
We've seen a couple of examples of how we can take charge of the routing for specific types of content. With this in our toolbox we can free the URLs for pages from the content tree, change where pages links to as well as other interesting stuff.
A couple of words of warning is in place though.
First of all, when modifying both the outbound and inbound routing as in the first example, the one with articles, we're bypassing EPiServer's functionality for ensuring that no two pages can have the same URL. That is, in the example with the articles we'll need to ensure that no two articles have the same URL segment.
Second, do think about that the methods for routing, such as the ones we've looked at in this article may be invoked a lot, so be sure to test the performance with realistic data before deploying to production.
With that said, I must say that it's nice that we can control the routing in just about any way we'd like. That brings many interesting possibilities.
Happy routing!


Deploying an EPiServer website in a load balanced environment using master slave licenses without downtime for visitors
2013-04-08T20:31:45.0000000Z
When working with large EPiServer websites having hundreds of tousands of visitors each month, you will want to make sure that you get as little downtime as possible while deploying your new releases; especially if the website’s content is of … Continue reading →


Resolve PageType & ContentType from Class
2013-04-07T23:05:30.0000000Z
In PageTypeBuilder for EPiServer CMS 6 we had a lovely feature called PageTypeResolver which could be used to find the Id of a PageType based on your implementation of TypedPageData. All you needed to do is run PageTypeResolver.Instance.GetPageTypeID(typeof(MyPageType)) and you would get a Nullable Int which represents the Id of your PageType, or null if no PageType [...]


EPiServer architecture and cross cutting concerns
2013-04-05T14:57:58.0000000Z
Introduction
  Let's spend a few moments to talk about a few different ways how to implement cross cutting concerns type of functionality like logging, caching, auditing etc while keeping a high code quality. Each has it's own pros and cons which makes different solutions good for different project sizes. I'll use logging as an example of a cross cutting funtionality to be added and a repository for news as an example of the "real" functionality to extend.
  Architecture lvl 0: Basic cross cutting concerns code mixed with actual function
  Also known as…no architecture…
  Let's start with the simplest version; code for performance logging is mixed with code for the actual functionality you want to log. Dirty but fast to implement for a single class. This will give us something to discuss pros and cons for. 
     
     
  An example class called NewsRepository with only one function, GetAllNews() was created. This function returns a list of NewsItems and will serve as the example service/repository class. Support was then added for log4net, which is a nice logging framework which is installed by default with EPiServer. Below is the simple example class with some basic logging. It uses a PerformanceTimer class to get a really accurate time of execution (custom made class so it's not part of any framework if you are wondering). Feel free to use the .NET DateTime.Now instead if you don't need extreme precision. Thread.Sleep is used to simulate that this method takes a while to run. The advantage with this simple version of architecture, or lack of it, for handling cross cutting concerns is that it's easy to find all code that is being run, and as long as the amount of code is pretty small, it will be a good solution. The value of simplicity is a value in itself.
  public class NewsRepository:INewsRepository
    {
        private readonly ILog _logger;
        public NewsRepository()
        {
            _logger = LogManager.GetLogger(typeof(NewsRepository));
        }
        public List<NewsItem> GetAllNews()
        {
            var timer = new PerformanceTimer();
            timer.Start();
            Thread.Sleep(200);
            var duration = timer.Stop();
            if (_logger.IsDebugEnabled)
            {
                _logger.Debug("Result of GetAllNews() in " + string.Format("{0:f4}", duration) + " seconds");
            }
            return new List<NewsItem>(){new NewsItem(){Headline = "Item 1"},new NewsItem(){Headline = "Item 2"}};
          
        }
    }

 

Architecture lvl 1: Implementing logging as a decorator to the original class


  Ok, so that covered the basic case of logging. Not much to see yet. What can possibly go wrong with this beautiful code? Well, the main issue is that this function will contain both code for GetAllNews() and the code needed to provide logging within the same method. This is what you in computer science would refer to as low cohesion. The class does a bit of everything. Right now that is no big problem but what if some caching, security and auditing was thrown in as well while the customer comes up with 10 new improvements to the original functionality. Pretty soon this will become a method that is 500+ lines of code where only a small part actually is about the main functionality. Developers will then start to groan about code quality. Customers will start to groan about high maintainance bills. People are not happy and projects starts to fall apart. Not a happy place to be in…  
Let's back the tape and say this above was the first simplest implementation but now the customer also wants these cross cutting concerns above implemented plus some extra improvements to GetAllNews(). According to the nice, “you may fool me once” philosophy, it's now time to refactor to a bigger costume according to the single responsibility principle (S) where we split this mixed functionality into separate classes.



  What if we extend the NewsRepository with a decorator pattern instead? This means that we create another class that implements the same interface but routes all calls to the original class (which only contains GetAllNews() functionality and no logging). This new decorator class can then add functionality to the original class without modifying the original class by placing itself "above" it. This is a much more SOLID approach…


    




  Example of the new decorator class responsible for logging:


  public class LoggingNewsDecorator:INewsRepository
{
        private readonly INewsRepository _newsRepository;
        private readonly ILog _logger;
        public LoggingNewsDecorator(INewsRepository newsRepository)
        {
            _newsRepository = newsRepository;
            _logger = LogManager.GetLogger(typeof(LoggingNewsDecorator));
        }
        public List<NewsItem> GetAllNews()
        {
            var timer = new PerformanceTimer();
            timer.Start();
            var result = _newsRepository.GetAllNews();
            var duration = timer.Stop();
            if (_logger.IsDebugEnabled)
            {
                _logger.Debug("Result of GetAllNews() in " + string.Format("{0:f4}", duration) + " seconds");
            }
            return result;
        }
}




  As you can see, this class above implements the same interface but takes the original class as a parameter in the constructor to be able to route all method calls. The code for the logging can now be in this class (LoggingNewsDecorator) and the code for the actual functionality can be in the original class (NewsRepository). This is what computer science would refer to as high cohesion which is a good thing. That will definitely help keeping a nice separation and structure when the code is growing. It is also possible to hook up this logging decorator automatically with an IoC container like structuremap like this: 


  container.For<INewsRepository>()
         .Singleton()
         .Use<LoggingNewsDecorator>()
         .Ctor<INewsRepository>().Is<NewsRepository>();



  This basically says that for the interface INewsRepository, use a singleton class of type LoggingNewsDecorator EXCEPT in the constructor when you try to make an instance of LoggingNewsDecorator; use the original NewsRepository there as parameter to the constructor instead. Otherwise you'll get a very funny circular reference thingy  If you don't like IoC, feel free to create your classes manually. The decorator pattern doesn't need IoC but it sure is helpful to avoid typing as much.



  Nice! Now with the decorator pattern in place you can actually chain classes for caching, auditing, logging etc on top of the actual functionality if you want.


  TIP: If you are a fan of decorator pattern and interfaces, use a custom class to pass in parameters to methods and also return the response as a custom response class. This will minimize the number of times you need to update the interface when you add new filtering options etc. Visual Studio also has plenty of shortcuts to update classes and interfaces that helps keeping the additional work down to a minimum. 
      



  This is normally where you stop, even if you have a big project. Creating the decorators will involve a lot of copy / paste if you have many classes you want to apply them on. It's SOLID but not very DRY. Implementing cross cutting concerns with the decorator pattern when you have a large project is a nice way of solving the problem and keeping a nice structure. But let's try another step just for fun and do some magic.

Architecture lvl 2: Implementing cross cutting concerns with AOP (Aspect Oriented Programming)
"O day and night, but this is wondrous strange!” – Horatio
Decorators involve a lot of copy / paste code to act as a wrapper around the original class. Is it possible to autogenerate these decorators so you only need to create them once for each type of decorator?


As it turns out, you can, since this is exactly what Castles dynamic proxy component does. It lets you autogenerate a class to a specific interface. Let's see some magic in action if you combine castles dynamic proxy with structuremap! Download the nuget package for castle.core and start with register a structuremap interceptor like this: 
container.RegisterInterceptor(new StructureMapInterceptor());

public class StructureMapInterceptor : TypeInterceptor
        {
            private readonly ProxyGenerator _proxy = new ProxyGenerator();
            public object Process(object target, IContext context)
            {
                var targetInterfaces = target.GetType().GetInterfaces();
                return _proxy.CreateInterfaceProxyWithTargetInterface(
                    targetInterfaces.First(), //What interface should we create proxy for
                    targetInterfaces,         //Any addition interfaces we need to support?
                    target,                   //Target class
                    new LoggingInterceptor());//What interceptors to generate 
                                              //and use in front of this target 
                 
            }
            public bool MatchesType(Type type)
            {
                if (type.IsSealed)
                    return false;
                if (type.Name.Contains("NewsRepository"))
                {
                    return true;
                }
               
                return false;
            }
        }



This StructureMapInterceptor will basically tell what decorators to generate and use for which classes, this is refered to as the pointcut in AOP. It’s nothing more than a mapping of classes vs decorators. This pointcut is done by first specifying in the MatchesType() method if any custom decorators should be generated for the calling type. Returning true will trigger the Process() method which will return what decorators to use and in which order and trigger the ProxyGenerator from Castle to generate them. If you have a security decorator / interceptor you'd probably want to run that first for instance. In this version we only generate a decorator for logging and this is implemented by the LoggingInterceptor class.  

Below, in the bonus material section, it is also shown how to match classes by attributes instead if you want to do that. This method, MatchesType(), is where you add logic for it anyway.
So, how do you create the logging interceptor class that implements the actual logging? So far we have only handled the mapping of what decorators to use for which classes...Let's check out the implementation of the actual interceptor for logging below:
public class LoggingInterceptor : IInterceptor
    {
        public void Intercept(IInvocation invocation)
        {
            var logger = LogManager.GetLogger(invocation.TargetType);
            try
            { 
                StringBuilder sb = null;
                if (logger.IsDebugEnabled)
                {
                    sb = new StringBuilder(invocation.TargetType.FullName)
                        .Append(".")
                        .Append(invocation.Method)
                        .Append("(");
                    for (int i = 0; i < invocation.Arguments.Length; i++)
                    {
                        if (i > 0)
                            sb.Append(", ");
                        sb.Append(invocation.Arguments[i]);
                    }
                    sb.Append(")");
                    logger.Debug(sb);
                }
                var timer = new PerformanceTimer();
                timer.Start();
                invocation.Proceed();
                var duration = timer.Stop();
                if (logger.IsDebugEnabled)
                {
                    logger.Debug("Result of " + sb + " is: " + invocation.ReturnValue + 
                        " in " + string.Format("{0:f4}", duration) + " seconds");
                }
            }
            catch (Exception e)
            {
                logger.Error(e);
                throw;
            }
        }
    }



This class will now work as our general logging decorator which can be put in front of any class that implements an interface! How cool is that? This class needs to implement an interface of type IInterceptor which only has a single method: Intercept. Information about the calling method etc is passed into the interceptor with the input parameter (IInvocation). To pass the method call along to the original class you can use invocation.Proceed(). This will call the actual GetNewsMethod() and return our little list of NewsItems. 
  
Congratulations! With this single class, you can now enable logging and measure execution time on all classes you want in your solution without touching the actual functionality with a lot of copy / paste code. It's a bit of magic alright so I would personally only use this for logging and auditing. Implementing caching this way would probably leave me sleepless at night or at least with nightmares. This AOP way will probably only be worth the effort for really big projects where you have a lot of service layer classes etc. You will have to weigh the amount of duplicated code vs the increased complexity when choosing to go down this path.
 
Performance considerations with autogenerating classes with AOP
Since autogenerating the decorators is actually only done once and then stored, the performance hit will be small. The same as for a decorator class basically but with a few extra reflection calls within the interceptor. Not a huge drawback in my eyes. The question mark above a junior developers head will be the biggest drawback according to me. Documentation can help somewhat there.
Summary
So now you have 3 options above how to implement cross cutting concerns. My general suggestion is to stick to the first option with inline code for small trivial solutions, switch to the second option with using decorators when you notice that the small project will probably grow into a big one and use the third magic one with aspect oriented programming only if you feel lucky and in special cases like logging. If you don't document the AOP variant well, it will probably take around a year for a junior programmer to figure out how it works though so keep that in mind as a likely side effect of the "magic" version...
So, within 1 hour you can now implement performance logging on every class you want in a big project without actually touching an existing class and risk breaking it. How cool is that? Feel free to make your own interceptors for auditing and caching as an exercise 
Happy coding fellas!
Bonus material 1; Adding support for attributes to enable logging on a class
1. Create custom attribute / annotation to be able to mark a class you want to log 

  [System.AttributeUsage(System.AttributeTargets.Class)]  
public class LogAttribute : System.Attribute
{
}
  
2. Set attribute on class to enable log

  [Log]
public class NewsRepository:INewsRepository
{
}
  
3. Update the method that checks what classes should use what interceptors (MatchesType() method in the StructureMapInterceptor class above)

  public bool MatchesType(Type type)
{
      if (type.IsSealed)
           return false;
      var attributes = System.Attribute.GetCustomAttributes(type); 
      if (attributes.Any(a => a is LogAttribute))
      {
           return true;
      }              
      return false;
}
  
4. Lean back and enjoy the little log messages ticking in...
Bonus material 2; Manual creation of proxy classes without an IoC container
Of course it’s also possible to use the ProxyGenerator class from Castle to “manually” generate a matching decorator class. 
var newsRepository = new NewsRepository();
var proxyGenerator = new ProxyGenerator();
var newsRepositoryWithLogging = 
           (INewsRepository)proxyGenerator.CreateInterfaceProxyWithTargetInterface(
            newsRepository.GetType().GetInterfaces().First(),
            newsRepository.GetType().GetInterfaces(), newsRepository,
            new LoggingInterceptor());
var items = newsRepositoryWithLogging.GetAllNews();

Performance will definitely need some careful consideration when doing this manually though. Wrapping the above in a factory for class creation will help of course, combined with the singleton pattern to avoid doing it too often. But to be honest, using an IoC container makes much more sense to handle object creation when using AOP so regard the last example as a more theoretical exploration. 
Happy coding again!


How to create a nice looking admin plugin
2013-04-05T03:57:00.0000000Z
Creating an admin plugin is easy. But making it look good and  blend in  with the core components isn’t documented at all.
  In this blog post I will try to shed some light on how to achieve the EPiServer built in look and feel. 
  Initial setup
  After creating your plugin make the following 3 changes. Credit to Dan Mathews who blogged about it first.
     
1. Inherit the EPiServer.UI.SystemPageBase (You need to add a reference to the EPiServer.UI assembly.
  2. Use the EPiServer UI masterpage. 
  protected override void OnPreInit(EventArgs e)
{
  base.OnPreInit(e);
  this.MasterPageFile = ResolveUrlFromUI("MasterPages/EPiServerUI.master");
}

3. Register the following in system.web-pages-controls in web.config
<add tagPrefix="EPiServerUI" namespace="EPiServer.UI.WebControls" assembly="EPiServer.UI" /> 
<add tagPrefix="EPiServerScript" namespace="EPiServer.ClientScript.WebControls" assembly="EPiServer" />
<add tagPrefix="EPiServerScript" namespace="EPiServer.UI.ClientScript.WebControls" assembly="EPiServer.UI" /> 

Heading and description
To add a header and intro text to your plugin you can set it via the following in OnPreInit.
this.SystemMessageContainer.Heading = "Example heading"; 
this.SystemMessageContainer.Description = "Introduction text";










 

Contentplaceholder
When creating your plugin you need to add the front-end code to the MainRegion contentplaceholder.
<asp:content contentplaceholderid="MainRegion" runat="server">
<div class="epi-formArea epi-paddingHorizontal">
</div>
</div>



You need the “epi-formArea” on the div containing the code or else everything will go bananas.
The “epi-paddingHorizontal” does exactly what is says so removing it will start everything at the left side.
Grouping
If you would like to create a nice group of content with a heading just create a fieldset.

  <fieldset>
      <legend>Group heading</legend>
      <dl>
          <dt>Plugins</dt>
          <dd>Are fun to build</dd>
          <dt>GUI</dt>
          <dd>Now with nice looks</dd>
      </dl>
      <div class="floatright">
          <episerverui:toolbutton id="SettingsButton" 
  
    runat="server" 
    text="<%$ Resources: EPiServer, button.settings %>" 
    tooltip="<%$ Resources: EPiServer, button.settings %>" 
    skinid="File" />
  
      </div>
  </fieldset>


 
Example with and without “floatright” and “epi-paddingHorizontal”..

 

Tabs
If you want to create tabs you first need to create a tabstrip. The target id need to be set and point to a asp panel. The “epi-padding” class on the panel creates a horizontal padding below the tabs and the content.
Tabstrip
<EPiServerUI:TabStrip  runat="server" id="actionTab" EnableViewState="true" GeneratesPostBack="False" targetid="tabView" supportedpluginarea="SystemSettings">
    <EPiServerUI:Tab Text="Tab1" runat="server" ID="Tab1" />
    <EPiServerUI:Tab Text="Tab2"  runat="server" ID="Tab2" />
</EPiServerUI:TabStrip>
<asp:Panel runat="server" ID="tabView" CssClass="epi-padding">
</asp:Panel>


To add content to each tab you add a runat=”server” controls in the panel. The first equals tab1 and so forth.

 
Tab 1 – general content

         <div class="epi-formArea" ID="GeneralTable" runat="server">
              <div class="epi-size25">
                  <div>
                      <asp:Label runat="server" AssociatedControlID="EPsSiteName" Text="Label" />
                      <asp:TextBox Columns="50" ID="EPsSiteName" runat="server"></asp:TextBox>
                  </div>
                 
                  <div class="epi-indent">
                      <asp:CheckBox ID="EPfEncryptSensitiveInformation" runat="server"></asp:CheckBox>
                      <asp:Label ID="Label3" AssociatedControlID="EPfEncryptSensitiveInformation" 
                          Text="Label" runat="server" />
                  </div>
              </div>
          </div>    


 
Class “epi-size25” creates the spacing between the first label and the textbox.
To push the content to right you use the “epi-indent” class.
 

Tab 2 – tables
You can create nice tables manually or using for example a gridview. If creating a table manually you need to have the class “epi-default” on the table.
<table class="epi-default">
 <tr>
<thead>
 <th>Header 1</th>
 <th>Header 2</th>
</thead>
 </tr>
 <tr>
 <td>row 1, cell 1</td>
 <td>row 1, cell 2</td>
 </tr>
 <tr>
 <td>row 2, cell 1</td>
 <td>row 2, cell 2</td>
 </tr>
 </table>

 

Buttons
The tab solution won’t be complete without at least one button to let the user commit some changes ore something like that. Adding the code below with give you a horizontal line and a right floating button.
<div class="epi-buttonContainer">
   <EPiServerUI:ToolButton  DisablePageLeaveCheck="true"   runat="server" SkinID="Save" text="Save" ToolTip="Tip" />
</div>


 
Notice the SkinID attribute. There exist a lot of toolbutton skins. You can check out which exist in the Toolbutton.skin file in folder (64 bit os) : C:\Program Files (x86)\EPiServer\CMS\7.0.586.1\Application\App_Themes\Default
 

Jquery
Jquery is automatically included and ready  to use in your plugin.
 
I’ve added the example code to the code section to make it easier to get started..


Scheduled Jobs not running after site upgrade
2013-04-04T14:24:00.0000000Z
After an upgrade of a customer site from EPiServer 5 to EPiServer 6 all scheduled jobs stopped working in all  environments. When debugging the scheduling service (in a command prompt run "EPiServer.SchedulerSvc.exe DEBUG" in the service directory) we noticed that when the service tried to connect to the site it failed with the following error message,


#INF# [_LM_W3SVC_1_ROOT] Failed calling site (Attempting to deserialize an empty stream.)

We tried to clear the "EPiServer.SchedulerService.Sites.xml" file to force a re-registration of the site but it never registered. After some thinking and contact with EPiServer support we found the fault, a missing module in Web.config. When we added the "FirstBeginRequestModule" module to the modules section everything started working again. 

<configuration>
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true">
      <add name="FirstBeginRequestModule" precondition="managedHandler" type="EPiServer.Web.InitializationModule, EPiServer">
    </modules>
  </system.webServer>
</configuration>



EPiServer CMS 7 logical architecture diagram
2013-04-04T10:30:12.0000000Z
I often have to describe the logical components of EPiServer CMS to clients and customers. It always feel like I end up recreating a logical architecture diagram on each occasion. The best place to keep something so that you never lose it, is in a place where it’s easy to find. Anything on the web [...]


Hiding seen ChangeInfo in an EPiServer CMS 6 R2 Solution
2013-04-04T06:38:44.0000000Z
This post is mostly a reminder to myself about how to achieve this. The task In addition to marking a page as changed, the customer wanted the editors to be able to show the users a description of what is new/updated. The customer also wanted users to be able to mark the message as seen. [...]


How to disable CMS edit/admin mode on "public facing" servers in a load balanced environment
2013-04-03T20:54:00.0000000Z
Hi Folks!

I realize that there have been several other blog posts regarding this topic, but after lots or trial and error I believe I have found a solid approach for disabling CMS edit/admin mode on public facing IIS servers in a load balanced environment.

There are other techniques that can be used to secure CMS edit/admin modes in a single server environment.  Check out this blog post by David Knipe for additional information.  It essentially uses IP white lists at the IIS level.  Maintaining IP whitelists can be problematic, so I prefer having a dedicated CMS server that's only accessible within the internal network.

In my last blog post we covered how to setup EPiServer load balancing using net.tcp.  We also detailed the three basic models that can be used when implementing EPiServer load balancing.  Today we'll be focusing on the Security model.

To recap, the security model provides a dedicated server for CMS editors to connect to and make changes to CMS content.  This server is normally only accessible from within the company's internal network.  The one or more "public facing" servers are what the general public connects to.  These "public facing" servers have the CMS edit/admin mode completely disabled.



For example:

Let's say we have our CMS server available onon http://cms.mysite.com (internal network only), and our "public facing" server available on http://www.mysite.com, then...

http://cms.mysite.com/episerver would prompt for login, and if the credentials are correct, allow the individual to navigate to CMS edit/admin mode.
http://www.mysite.com/episerver would be completely disabled, even if the user managed to steal a CMS editor's credentials.
Some of my Swedish colleagues have told me that this sort of setup is not very common in Sweden.  But I've personally noticed that many of our clients here in the States prefer having a dedicated CMS editor server.  I can't say I blame them.

So how do we harden the "public facing" servers.  It's remarkably easy.  All you have to do is make some tweaks to the Web.config file on the public facing server(s).

Disclaimer: these instructions work for EPiServer CMS 6 R2, I'm not sure about EPiServer CMS 7, but I believe the premise is essentially the same thing.

Web.config changes

The idea here is to modify any <location> element in the Web.config which currently requires WebEditors, WebAdmins or Administrators role membership to access.

For example, the <location> element for "/episerver" access by default looks like:

<location path="episerver">
  <system.web>
    <httpRuntime maxRequestLength="1000000" />
    <pages enableEventValidation="true">
      <controls>
        <add tagPrefix="EPiServerUI" namespace="EPiServer.UI.WebControls" assembly="EPiServer.UI" />
        <add tagPrefix="EPiServerScript" namespace="EPiServer.ClientScript.WebControls" assembly="EPiServer" />
        <add tagPrefix="EPiServerScript" namespace="EPiServer.UI.ClientScript.WebControls" assembly="EPiServer.UI" />
      </controls>
    </pages>
    <globalization requestEncoding="utf-8" responseEncoding="utf-8" />
    <authorization>
      <allow roles="WebEditors, WebAdmins, Administrators" />
      <deny users="*" />
    </authorization>
  </system.web>
  <system.webServer>
    <handlers>
      <clear />
      <add name="webresources" path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" />
      <add name="PageHandlerFactory-Integrated" path="*.aspx" verb="GET,HEAD,POST,DEBUG" type="System.Web.UI.PageHandlerFactory" modules="ManagedPipelineHandler" scriptProcessor="" resourceType="Unspecified" requireAccess="Script" allowPathInfo="false" preCondition="integratedMode" responseBufferLimit="4194304" />
      <add name="SimpleHandlerFactory-Integrated" path="*.ashx" verb="GET,HEAD,POST,DEBUG" type="System.Web.UI.SimpleHandlerFactory" modules="ManagedPipelineHandler" scriptProcessor="" resourceType="Unspecified" requireAccess="Script" allowPathInfo="false" preCondition="integratedMode" responseBufferLimit="4194304" />
      <add name="WebServiceHandlerFactory-Integrated" path="*.asmx" verb="GET,HEAD,POST,DEBUG" type="System.Web.Services.Protocols.WebServiceHandlerFactory, System.Web.Services, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" modules="ManagedPipelineHandler" scriptProcessor="" resourceType="Unspecified" requireAccess="Script" allowPathInfo="false" preCondition="integratedMode" responseBufferLimit="4194304" />
      <add name="wildcard" path="*" verb="*" type="EPiServer.Web.StaticFileHandler, EPiServer" />
    </handlers>
  </system.webServer>
</location>

Notice that the <allow> element currently specifies that WebEditors, WebAdmins, and Administrators can access this location.  The <deny> elements tells IIS to deny everyone else.

All we essentially have to do is remove the <allow> element (comment it out) on the public facing servers and this location will be denied to everyone - including CMS editors/admins.  This means even if someone managed to steal the username and password of a CMS editor, they wouldn't be able to login to CMS edit mode unless they were somehow connected to the internal network and knew the URL to the CMS web application instance.

Please note: you can easily use Visual Studio transforms to create a Solution Configuration which automatically removes the <allow> element when publishing to the "public facing" servers.  We'll take a closer look at transforms in my next blog post.

Here we've commented out the <allow> element for the <location path="episerver"> element.

<location path="episerver">
  <system.web>
    <httpRuntime maxRequestLength="1000000" />
    <pages enableEventValidation="true">
      <controls>
        <add tagPrefix="EPiServerUI" namespace="EPiServer.UI.WebControls" assembly="EPiServer.UI" />
        <add tagPrefix="EPiServerScript" namespace="EPiServer.ClientScript.WebControls" assembly="EPiServer" />
        <add tagPrefix="EPiServerScript" namespace="EPiServer.UI.ClientScript.WebControls" assembly="EPiServer.UI" />
      </controls>
    </pages>
    <globalization requestEncoding="utf-8" responseEncoding="utf-8" />
    <authorization>
      <!--<allow roles="WebEditors, WebAdmins, Administrators" />-->
      <deny users="*" />
    </authorization>
  </system.web>
  <system.webServer>
    <handlers>
      <clear />
      <add name="webresources" path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" />
      <add name="PageHandlerFactory-Integrated" path="*.aspx" verb="GET,HEAD,POST,DEBUG" type="System.Web.UI.PageHandlerFactory" modules="ManagedPipelineHandler" scriptProcessor="" resourceType="Unspecified" requireAccess="Script" allowPathInfo="false" preCondition="integratedMode" responseBufferLimit="4194304" />
      <add name="SimpleHandlerFactory-Integrated" path="*.ashx" verb="GET,HEAD,POST,DEBUG" type="System.Web.UI.SimpleHandlerFactory" modules="ManagedPipelineHandler" scriptProcessor="" resourceType="Unspecified" requireAccess="Script" allowPathInfo="false" preCondition="integratedMode" responseBufferLimit="4194304" />
      <add name="WebServiceHandlerFactory-Integrated" path="*.asmx" verb="GET,HEAD,POST,DEBUG" type="System.Web.Services.Protocols.WebServiceHandlerFactory, System.Web.Services, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" modules="ManagedPipelineHandler" scriptProcessor="" resourceType="Unspecified" requireAccess="Script" allowPathInfo="false" preCondition="integratedMode" responseBufferLimit="4194304" />
      <add name="wildcard" path="*" verb="*" type="EPiServer.Web.StaticFileHandler, EPiServer" />
    </handlers>
  </system.webServer>
</location>

You should repeat this step for all <location> objects that currently require WebEditors, WebAdmins, or Adminstrators role membership.

Depending on whether or not your using Commerce and/or Composer you might have to make the changes to the <location> elements with the following paths:

<location path="episerver">
<location path="episerver/CMS/admin" >
<location path="WebServices">
<location path="Admin/SettingsPlugin">
<location path="Admin/SitePlugin">
<location path="Edit">
<location path="EPiServerCommon">
<location path="dropit/plugin/extension/ui/edit">
<location path="dropit/plugin/extension/ui/admin">
After doing this, you'll notice one serious and annoying problem...




Assuming someone is able to login using CMS editor credentials, they can still access the EPiServer context menu (for on page editing), even if they cannot get to CMS edit/admin mode.

This is because the <location> elements don't affect access to the context menu.  The context menu is driven by EPiServer ACLs.

I stumbled across the solution on this blog post by Paul Houghton.  It requires building some code which will disable the EPiServer context menus for all page templates and then using appSettings to control whether or not this code should execute.  You could then configure the appSettings in Web.config for the servers where you want to disable the context menu appropriately.

Well appSettings was fine and dandy several years ago, but these days we use project level application settings.  See this post on Stackoverflow for addition information on the differences between appSettings and application settings.

So let's build a boolean application setting for our project in Visual Studio.



Now we can add some code in PageBase.cs (which all of our EPiServer templates inherit from) to override the onInit() page life cycle method.  This code checks the application settings value and determines if it should enable or disable the EPiServer context menu.

namespace MySite.Core
{
    public abstract class PageBase<T> : TemplatePage<T> where T : PageTypeBase
    {
        protected override void OnInit(System.EventArgs e)
        {
            if (ContextMenu != null && !Settings.Default.EnableEPiContextMenu)
            {
                ContextMenu.IsMenuEnabled = false;
            }

            base.OnInit(e);
        }
    }
}

The great part about application settings is that the values are compiled into the DLL, but can be overriden via the Web.config.  If you don't supply a value in Web.config, the compiled in value is used.  Pretty cool huh?

So now all we have to do is override the "True" value for our EnableEPiContextMenu in the Web.config on our public facing servers.

<applicationSettings>
  <MySite.Core.Properties.Settings>
    <setting name="EnableEPiContextMenu" serializeAs="String">
      <value>False</value>
    </setting>
  </MySite.Core.Properties.Settings>
</applicationSettings>

Extra steps for sites that don't require login functionality

If your site literally does not require any sort of login functionality for the general public you can further secure your "public facing" severs by disabling the login page completely.  You would keep the login page for the CMS server so that your CMS editors can login.

If you go this route, a person from the general public going to http://www.mysite.com/episerver would get a 404.  This is because:

IIS determines the user is going to a location path that requires login.
IIS tries to respond with the login page defined in the <forms> element in Web.config.
IIS can't find the login page and therefore returns a 404.
If you are using the standard EPiServer login page, you can comment out this line in episerver.config.  This disables the virtual path to "~/Util" where the EPiServer login page is stored.

<virtualPath customFileSummary="~/FileSummary.config">
    <providers>
        ... more ...    
        
          
        <add name="App_Themes_Default" virtualPath="~/App_Themes/Default/"
physicalPath="C:\Program Files (x86)\EPiServer\CMS\6.1.379.0\application\App_Themes\Default"
type="EPiServer.Web.Hosting.VirtualPathNonUnifiedProvider,EPiServer" />
            
        <add name="UI" virtualPath="~/episerver/CMS/"
physicalPath="C:\Program Files (x86)\EPiServer\CMS\6.1.379.0\application\UI\CMS"
type="EPiServer.Web.Hosting.VirtualPathNonUnifiedProvider,EPiServer" />
            
        <!--<add name="UtilFiles" virtualPath="~/Util/"
physicalPath="C:\Program Files (x86)\EPiServer\CMS\6.1.379.0\application\util"
type="EPiServer.Web.Hosting.VirtualPathNonUnifiedProvider,EPiServer" />-->

        ... more ...

    </providers>
</virtualPath>

If you are using a custom login page, just remove it from the build you publish to your "public" facing servers.

That about does it folks.  Tune in next time for how to use Visual Studio transforms to easily customize Visual Studio publish configurations.  This allows you to make configuration changes automatically when publishing builds of your web application to different servers: DEV, TEST, CMS, and PROD.

Thanks!

Rob


Add custom fields to the EPiServer Search index with EPiServer 7
2013-04-02T14:28:01.0000000Z
If you have an EPiServer 7 site with basic search requirements not warranting the full blown EPiServer Find search engine, you can come a long way with EPiServer Search and some customized indexing.


EPiServer 7 example properties
2013-04-02T12:49:07.0000000Z
Welcome EPiServer This is my first post about EPiServer 7. For those who are not familiar, its a CMS and we are using it at Making Waves. If you are not using it at work, this and other posts about … Czytaj dalej →


How to Configure EPiServer Load Balancing with net.tcp
2013-04-01T21:50:00.0000000Z
EPiServer load balancing configuration is critical for large scale enterprise deployments. It allows you to have multiple IIS servers that all connect to same database.

There three main models that can be used when using EPiServer load balancing.

1. Performance – When most people here the term "load balancing" they think of the performance benefits that can be obtained. Using the performance model you will be splitting the incoming connections up between two or more IIS servers – each one running a copy of the web application. Using this model requires a minimum of two IIS servers. A hardware load balancer is normally also involved.



2. Security – Most people don’t think of using EPiServer load balancing to help with security, but I’ve found this is actually one of the primary benefits of load balancing. The idea here is to have one dedicated CMS IIS server, and one our more public facing IIS servers. The CMS IIS Server is normally only accessible via the company’s internal network. The public facing server(s) have the CMS edit/admin mode completely disabled. This model requires a minimum of two IIS servers.



3. Performance and Security – A hybrid of the two above models, requires a minimum of three IIS servers.



Note that technically you can also performance load balance the CMS IIS severs, but this is overkill in most cases. Unless of course you have an army of CMS editors maintaining the site.

There are already other blog posts on how to setup EPiServer load balancing using the preferred method, UDP Multicasting. I would be happy to create another blog post of this if there is demand, but the focus of this blog post is how to setup EPiServer load balancing when UPD Multicasting is not an option. In this case you need to use net.tcp.

I've had the privilege of setting up all three of the above models with both UDP multicast load balancing and net.tcp load balancing. You should always try UDP multicasting first, because the configuration is far easier. If you discover (to your horror) that UPD MC is not an option, you’ll have to bite the bullet, have a strong drink, and go the net.tcp route. Here’s a picture of me after I discovered that UDP multicasting wasn’t an option in our latest project.



Disclaimer: this individual isn't actually me, many of my fellow colleagues would never speak to me again if I started doing .NET development on an iMac. No second mouse button, give me a break!

EPiServer load balancing revolves around the broadcast of events to each of the servers. The idea is that if someone publishes a change to any of the pages on one server, the other servers must be told of this change and flush their cache (for the page that has changed). If you don’t have load balancing setup correctly, the other servers will continue to use the old, cached version of the page.

The key difference between UDP MC and using net.tcp is that UPD MC broadcasts events to all the servers listing a single multicast IP address and port. Because it’s a multicast IP address, all servers can receive the broadcast message.

Typically what prevents you from using UDP MC event handling are stricter security rules. Some IT departments don’t like the idea of UDP MC broadcasts being sent out to many servers and prefer to keep things more locked down.

So without further delay, let’s get started.

EPiServer.config Configuration

The first thing you need to do is update your episerver.config file so that each site has event handling turned on. There are two attributes that are required in the <siteSettings> element. These attributes are enableEvents and enableRemoteEvents. Both of these should be set to "true". If you have an EPiServer enterprise environment, you must do this for each <siteSettings> element for each <site>.

<sites>
  <site siteId="MySite" description="My Test Site">
    <siteSettings ... more stuff ... enableEvents="true" enableRemoteEvents="true" />
  </site>
  <site siteId="MySite2" description="My Test Site 2">
    <siteSettings ... more stuff ... enableEvents="true" enableRemoteEvents="true" />
  </site>
        
  ... more ...
 
</sites>

Now comes the fun part. You need to determine which servers will be event "broadcasters" and which servers will be event "listeners". Please note that servers can be both a "broadcaster" and a "listener".
Servers that are "broadcasters" will be broadcasting events to other servers. These are typically the CMS server(s). If you have more than one server that CMS editors will be connecting to in order to publish changes you will have multiple "broadcasters".

Servers that are "listeners" will be receiving events from other servers. These are typically the public facing servers. Please note that if a server is not configured to be a "listener" it will never be alerted if changes to content are made on other servers.

Net.tcp General Configuration

First you want to make sure that you have the appropriate configuration in Web.config to support net.tcp binding. Make sure that you have the <netTcpBinding> element in the <system.serviceModel><bindings> element in your Web.config.

<system.serviceModel>

    <client>
      ... more stuff ...
    </client>

    <bindings>

        <customBinding>
          <binding name="RemoteEventsBinding">
            <binaryMessageEncoding />
            <udpTransport multicast="True" />
          </binding>
        </customBinding>
        
        <netTcpBinding>
          <binding name="RemoteEventsBinding">
            <security mode="None" />
          </binding>
        </netTcpBinding>
 
    </bindings>
    
    ... more stuff ...

</system.serviceModel>


Please note that the <customBinding> element would be used for UDP MC events. It’s safe to leave this in place as a reference.

Configuring "Broadcasters"

The hardest part about configuring "broadcasters" is understanding that "broadcasters" actually act as clients to the listeners. This means that the "broadcasters" call the remote event service on each "listener" server.

To property configure the "broadcasters", update the <client> element in the <system.serviceModel> element in Web.config. You need to create a separate client endpoint for each enterprise site for each listener server you want to broadcast to. Each client endpoint must have a specific syntax for the name attribute: name="{siteId}-{IP address of server}". Please note that the siteId needs to match the siteId attribute in episerver.config. Also within each collection of client endpoints for a specific target "listener", the endpoints must have unique ports.

So if you have a single "broadcaster" acting as the client to two "listeners" on an EPiServer enterprise environment with two sites you will have four client endpoints.

Broadcaster #1 to Listener #1 (Site #1) port 13000
Broadcaster #1 to Listener #1 (Site #2) port 13001
Broadcaster #1 to Listener #2 (Site #1) port 13000
Broadcaster #1 to Listener #2 (Site #2) port 13001

Remember that each client endpoint (within a collection of client endpoints for a specific target "listener" server) will have its own port number. Typically you start at 13000 and work your way up.

The example below should help illustrate.

<system.serviceModel>
  <client>
<!--robstr: no longer using UDP multicast event handling, switched to net.tcp-->
<!--this was previously used for UDP MC event handing
<endpoint
name="RemoteEventServiceClientEndPoint" 
address="soap.udp://224.0.0.1:5000/RemoteEventService" 
binding="customBinding" bindingConfiguration="RemoteEventsBinding" 
contract="EPiServer.Events.ServiceModel.IEventReplication"/>
-->
    <endpoint
        name="MySite-192.168.7.130"
        address="net.tcp://192.168.7.130:13000/RemoteEventService"
        bindingConfiguration="RemoteEventsBinding"
        contract="EPiServer.Events.ServiceModel.IEventReplication"
        binding="netTcpBinding" />
    <endpoint
        name="MySite2-192.168.7.130"
        address="net.tcp://192.168.7.130:13001/RemoteEventService"
        bindingConfiguration="RemoteEventsBinding"
        contract="EPiServer.Events.ServiceModel.IEventReplication"
        binding="netTcpBinding" />
    <endpoint
        name="MySite-192.168.7.131"
        address="net.tcp://192.168.7.131:13000/RemoteEventService"
        bindingConfiguration="RemoteEventsBinding"
        contract="EPiServer.Events.ServiceModel.IEventReplication"
        binding="netTcpBinding" />
    <endpoint
        name="MySite2-192.168.7.131"
        address="net.tcp://192.168.7.131:13001/RemoteEventService"
        bindingConfiguration="RemoteEventsBinding"
        contract="EPiServer.Events.ServiceModel.IEventReplication"
        binding="netTcpBinding" />
  </client>
</system.serviceModel>


Configuring "Listeners"

"Listeners" listen for incoming event broadcasts from the "broadcasters". A listener simply has to have a service endpoint available for the "broadcasters" to connect to. This is done by configuring the appropriate <service> elements in the <system.webService><services> element in Web.config.

In this case you need to make sure to have a separate service available for each EPiServer site (when using EPiServer enterprise). Each service endpoint must have its own port number and the <service> element should have the following pattern syntax for the name attribute: name="{siteId}/EPiServer.Events.Remote.EventReplication".

In the example below, we have two service endpoints (one for each of the two sites). Each "listener" server would have this same configuration (with the exception of the IP addresses).

<system.serviceModel>

... more stuff ...

<!--robstr: we are using net.tcp for load balancing, not UPD mulicast.  The public server configuration must listen, so it has services.-->
  <services>
 
<!-- left over from UDP MC event handling <service name="EPiServer.Events.Remote.EventReplication" xdt:Locator="Match(name)">
<endpoint name="RemoteEventServiceEndPoint" contract="EPiServer.Events.ServiceModel.IEventReplication" binding="customBinding"
bindingConfiguration="RemoteEventsBinding" address="soap.udp://224.89.89.89:5000/RemoteEventService" xdt:Transform="Insert" />
</service>
-->
 
    <service name="MySite/EPiServer.Events.Remote.EventReplication">
      <endpoint
      name="RemoteEventServiceEndPoint"
      contract="EPiServer.Events.ServiceModel.IEventReplication"
      bindingConfiguration="RemoteEventsBinding"
      address="net.tcp://192.168.7.130:13000/RemoteEventService"
      binding="netTcpBinding" />
    </service>
            
    <service name="MySite2/EPiServer.Events.Remote.EventReplication" >
      <endpoint
      name="RemoteEventServiceEndPoint"
      contract="EPiServer.Events.ServiceModel.IEventReplication"
      bindingConfiguration="RemoteEventsBinding"
      address="net.tcp://192.168.7.130:13001/RemoteEventService"
      binding="netTcpBinding" />
    </service>
  </services>
</system.serviceModel>

That about does it. To test your configuration log onto a "broadcaster" server and do a page change/publish. You should see this change reflected in all the "listener" servers.

Stay tuned for my next blog post of disabling CMS edit/admin mode from the public facing IIS servers.
Thanks!

Robert


Custom settings for link properties in EPiServer CMS
2013-04-01T14:16:00.0000000Z
Even though a solution for this is already out there, albeit somewhat incoherent, way too many EPiServer websites lack the ability to limit the selection of pages editors may choose from when selecting a link in Edit mode. Editors cost money, and we need to keep them efficient and happy; that is in fact one [...]


EPiServer custom property: Multiple Category checkbox list from specific sub category
2013-04-01T13:29:59.0000000Z
Sometimes editors have to select multiple categories from a long list, including other category nodes which might not be relevant for that page. This is a custom property which you can configure to only list categories from a certain category parent. The editors can then select multiple categories directly from a list of checkboxes. Configure [...]

Blogs

DropDownList Category Picker in EPiServer 7

Unsupported languages: Arabic, Tigrinya or Chinese characters in SiteSeeker search result using EPiServer

Texts missing inTinyMCE?

Using the REST API of ImageVault

Javascript

Client

Authentication

API calls to Core

Demo

5 years of EPiServer World awesomeness

Adding Cross Site Scripting protection in EPiServer CMS with .NET 4.0

Render ContentArea with temporarily content

EPiServer 7: Strongly typed page types in FPWC

RSS Reader Block

Related content with EPiServer Find

Find similar pages using MoreLike

Add business logic using BoostMatching

An example

Localized EPiServer model validation attributes

Create an animating slider with content area

About the overlays

First attempt to create a slider with a content area

Fix the slider script initialization

Fix the rendering

Custom content area

Use the custom content area for slider property

Move the edit attributes

Use default overlay

Create an editor descriptor

Use the editor descriptor for the slider property

The final result

Programing changes required while Upgrading Episerver Commerce R2 to R2 SP1 and R2SP2 - Part 2

PageType Usage Plugin with Recent Pages for each PageType

Programing changes required while Upgrading Episerver Commerce R2 to R2SP1 and R2SP2 - Part 1

Basic steps

Breaking changes:

Indexing only referenced VPP-files with EPiServer Find

List of XForm System Localization Keys in EPiServer 7

Installing Lucene Solr for EPiServer Commerce (EPi 6) Catalog Search

The annoying “error CS1031: Type expected” after upgrade site from CMS5R2 to CMS6

EditPanel Manager

ImageVault 4 addon update (v4.1.12)

Getting “Error– is not a valid user or group”, when upgrading?

Building large scale EPiServer sites

Content that fit naturally in a deep hierarchy

Content that isn’t hierarchical or the hierarchy is shallow

Finding content based on non-hierarchical criteria

Non-hierarchical content

Structuring bulk content in arbitrary hierarchies

Custom components for editorial workflows

An example - this site

Organizing pages

Listings and routing

Dealing with traffic

Summary

Creating a Link to a Page in your EPiServer 7 MVC View

Current Options and Limitations

Html.PageLink

Url.PageUrl

Another Option: Extending the UrlHelper

UrlExtensions.cs

CMS 7 Subscriptions “bug”

EpiServer CMS 6 Useful SQL Queries

EPiServer.ImageMap revisited

On-page editing and forms editing stop working in EPiServer 7

Set up a user friendly Edit Mode before the training

Name and help texts on field

Order in the field

Flaps position, name and any permissions

Settings in the editor field

Permission to templates / templates available and name

Structure and permissions in the file manager

Folder structure for block

Folders in the form handler

Permissions in tree structure

Clear up the tree structure

Multi language / Globalization

Workflows

CMS 7.1 upgrade issues