Blog posts by tomstenius

Changing Master Language in EPiServer CMS 6

Wed, 09 Feb 2011 05:49:00 GMT

Yesterday I faced a problem that I had met before; I needed to change the master language of an EPiServer CMS site. I have done successfully using the awesome tool called Advanced Language Manipulation Tool for EPiServer by Adam Najmanowicz, but that time I used it on a EPiServer CMS 5 site.

When doing a little bit of searching I found that Mari Jørgensen had made some updates to the tool and uploaded it to Coderesort. So I grabbed it from there instead of from its original source.

It turns out it works like a charm in EPiServer CMS 6 as well, although the look and feel was a bit off:

However one thing that I forgot after I had updated the master language from English (en) to Australian English (en-au) was to enable the new language. The result was that I could not create any new pages, the option for creating new pages was disabled.

It took me a little while before I thought of enabling the language, but once that was done everything worked great! Just go to Language Settings for the Start page in Edit Mode and enable the language of your choice.

Updated WAVE Checker Plug-In

Mon, 13 Dec 2010 05:43:00 GMT

All of you accessibility fans out there are probably aware of a web site called WAVE. Wave is a free web based accessibility tool provided by WebAIM. If you know about this tool and EPiServer, you have probably come across Allan’s nice WAVE plug-in for EPiServer CMS.

A couple a weeks ago I came across a scenario where I wanted to use Allan’s plug-in a demo scenario. “Too easy” I thought to myself, just drop the DLL in the bin folder an let’s rock. However on this demo site I was using PageTypeBuilder, and it turns out that the way Allan’s plug-in added the context menu item was a bit too late in the page life cycle. Therefore I took the freedom to copy Allan’s code and modify it a bit to work with PageTypeBuilder – I hope Allan doesn’t mind ;)

In the process I also added language support and created a small icon that is shown in the context menu. Feel free to download the source code here.

Disclaimer: Please note that the code comes as-is and I will not be held responsible.

Search CMS Pages in Relate+ 2.0

Thu, 18 Nov 2010 04:52:00 GMT

The new search function in Relate+ 2.0 is really powerful. Relate+ will populate the search index with community content, CMS pages and files out-of-the-box. However the search page that is included in the templates will only search community content.

Eric Pettersson has blogged about adding CMS page search to the search page of Relate+ 2.0 – this is great! However he left out a few steps that you have to take to make the search work completely. In this blog post I will highlight these steps. I will assume that you have read Eric’s post and implemented that part already.

If you have followed Eric’s steps and then played around with your site, the chances are good that your index is a bit off – especially if you have deleted pages. Because of this, the first thing that we want to do is re-build the index. This is done using this code snippet:

EPiServer.Search.SearchHandler.Instance.ResetIndex("default");
EPiServer.Community.Search.SearchHandler.Instance.AddCommunityEntitiesToIndex(true);            
EPiServer.Templates.RelatePlus.CmsModules.CmsSearchHandler.Instance.IndexPublishedCmsPages();

The “default” is the name of your index, change it if you have changed the name of the index. You can find that code in the attached ReIndexRelatePlus2.aspx – this is a modified version of the re-index page found here. Simply place the file in your web root and run it.
Now locate the file CmsIntegrationModule.cs in /Templates/RelatePlus/InitializationModules/and have a look at the method called Instance_MovedPage. We need to modify this version so that the search index is always updated. In the code that you get out-of-the-box the search index will only be updated if the Club association has been effected. Change the code to something like this:

private static void Instance_MovedPage(object sender, PageEventArgs e)
{
    // Guard
    if (e == null || PageReference.IsNullOrEmpty(e.PageLink)) return;

    // Remove the page from cache due to Bug #24524 where IsDeleted gets its value from cache.
    DataFactoryCache.RemovePage(e.PageLink);
    PageData currentPage = EPiServer.DataFactory.Instance.GetPage(e.PageLink);

    // Update this page in search index
    // Since we don't want pages from the recycle bin in search result, we remove them from index
    if (currentPage.IsDeleted)
    {
        CmsSearchHandler.Instance.UpdateIndex(currentPage, IndexAction.Remove);
    }
    else
    {
        CmsSearchHandler.Instance.UpdateIndex(currentPage, IndexAction.Update);
    }

    // Get the club id
    int clubId = GetClubId(e.PageLink);

    if (clubId != -1)
    {
        // Get the club
        Club associatedClub = ClubHandler.Instance.GetClub(clubId);
        if (associatedClub != null)
        {
            Club clubClone = associatedClub.Clone() as Club;

            if (currentPage.IsDeleted)
            {
                clubClone.RemoveAssociatedPage(currentPage);
                ClubHandler.Instance.UpdateClub(clubClone);
            }
        }
    }
}

In this code I have also changed it so that when a page is deleted, i.e. moved to the recycle bin, the page is removed from the search index. This is done since we do not want to include deleted pages in the search result.

You can find the entire source code here. Enjoy!

Disclaimer: Please note that the code comes as-is and I will not be held responsible.

Resetting the EPiServer Dashboard

Mon, 15 Nov 2010 03:40:00 GMT

Here is a quick little tip; Sometimes when you are playing around with new gadgets on the Dashboard of EPiServer CMS 6 things doesn’t go as you planned. In these cases it could be good to know that there is a way of resetting your Dashboard. Simply navigate to http://[yoursite]/[secureui]/shell/debug/dashboard, there you will displayed with the options of deleting gadgets, entire tabs or resetting the Dashboard.

FW: Security Vulnerability in ASP.NET

Fri, 24 Sep 2010 06:32:00 GMT

This is a very short post for all my readers in Australia and New Zealand. I just wanted to make sure that you have not missed the blog post from EPiServer's CTO Per Ivansson about how EPiServer dealt with the Security Vulnerability discovered in ASP.Net a couple a weeks ago.

Read Per's blog post here.

AGLS Metadata Support in EPiServer CMS

Wed, 25 Aug 2010 05:00:00 GMT

In almost every tender, RFQ, RFI, or whatever you want to call it, that goes out in Australia there is a mandatory request to support the AGLS Metadata Standard. In governmental type of tenders there are no exception to this rule. To best describe what AGLS Metadata is I’m going to quote the AGLS Metadata web site;

“The AGLS Metadata Standard is a set of descriptive properties to improve visibility and availability of online resources.”

It is a standard used to add metadata to almost any type of resource, but in my case – since I’m working with EPiServer CMS – I’m going to apply it to web pages and also talk about it from this perspective. There are a number of ways to add custom metadata tags to EPiServer pages, and this is also what I tend to say to partners responsible for replying to the already mentioned tenders, RFQs, RFIs… But since the AGLS Metadata support is so common I decided to create an out-of-the-box solution that will add the AGLS Metadata Standard support to EPiServer.

In my work I have used the AGLS Metadata Standard Part 2, Usage Guide (PDF) as reference on how to implement AGLS on web sites. This document is recently updated (mid August 2010) and if you have a look around at random governmental web sites in Australia you will find that most of them still use the legacy implementation mentioned in the document. However since I’m doing a fresh implementation I will go for the new way of adding the metadata tags.

From the Usage Guide you will find that AGLS Metadata is an application profile of Dublin Core metadata standard. This is almost the same as saying that AGLS is a superset of Dublin Core. With this said I decided to make a component that supports both Dublin Core and AGLS, you can simply choose which of these two metadata standards you want to use on your web site.

Dublin Core support for EPiServer CMS has been built before. I think Ben’s implementation is pretty cool, however I decided to take a slightly different approach since I wanted to give the editors an easy way of overriding the default values. To solve this I decided to make use of PageTypeBuilder and create two page base classes; one for Dublin Core and one for AGLS. These base classes will add properties to your PageType corresponding to the elements in Dublin Core and AGLS. All the properties will show up on a Metadata tab on the page with a few exceptions, since some of the properties are always automatically added. The automatic properties are;

DCTERMS.created – The creation date of the page
DCTERMS.modified – The modified date of the page
DCTERMS.format – Will be “text/html”
DCTERMS.identifier – Url to the page
DCTERMS.language – Language branch of the page
AGLSTERMS.availability – Url to the page

To add support for either of the metadata standards you simply inherit from either EPiXternal.Metadata.PageTypes.DublinCore or EPiXternal.Metadata.PageTypes.AGLS – as you have understood by now you have to be using PageTypeBuilder in your project. Then you just have to add the MetadataIncluder web control to the head tag of your MasterPage. This control will look at the current page type and include metadata elements if the page is of type DublinCore or AGLS.

<EPiXternal:MetaData ID="MetaData" runat="server" />

This is how it would like if you view the source of a page implementing AGLS.

<link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" /> 
<link rel="schema.AGLSTERMS" href="http://www.agls.gov.au/agls/terms/" /> 
<meta name="DCTERMS.title" content="Sample Article" /> 
<meta name="DCTERMS.description" content="This is a sample article using the AGLS plugin" /> 
<meta name="DCTERMS.created" scheme="DCTERMS.ISO8601" content="2010-08-19T21:24+10:00" /> 
<meta name="DCTERMS.modified" scheme="DCTERMS.ISO8601" content="2010-08-19T21:24+10:00" /> 
<meta name="DCTERMS.format" scheme="DCTERMS.IMT" content="text/html" /> 
<meta name="DCTERMS.language" scheme="DCTERMS.RFC4646" content="en" /> 
<meta name="DCTERMS.publisher" content="EPiServer Australia Pty Ltd" /> 
<meta name="DCTERMS.creator" content="tom" /> 
<meta name="DCTERMS.coverage" content="World" /> 
<meta name="DCTERMS.rights" scheme="DCTERMS.URI" content="http://pagetypebuilder.local/Copyright/" /> 
<meta name="DCTERMS.identifier" scheme="DCTERMS.URI" content="http://pagetypebuilder.local/Sample-Article/" /> 
<meta name="DCTERMS.type" scheme="DCMIType" content="episerver sample code" /> 
<meta name="DCTERMS.subject" content="episerver sample code" /> 
<meta name="AGLSTERMS.availability" scheme="DCTERMS.URI" content="http://pagetypebuilder.local/Sample-Article/" /> 
<meta name="AGLSTERMS.function" content="education" /> 
<meta name="AGLSTERMS.aggregationLevel" content="collection" /> 
<meta name="AGLSTERMS.category" content="service" /> 
<meta name="AGLSTERMS.documentType" content="guidelines" /> 
<meta name="AGLSTERMS.serviceType" content="training" />

Almost all of the properties will have default values if the properties are not set on the specific page. The default value of each of the properties in edit mode is stated in the help text. The editor also have the possibility to override the defaults by specifying a fallback value on the corresponding properties on the start page. If for some reason you have a fallback value on the start page, but you don’t want it to be displayed for a specific property on a specific page you can just insert a “-“ which will cause the MetadataIncluder to omit that property on the page.

I hope this will make all of our partners in Australia, and maybe some in UK as well since Dublin Core is big over there. The source code can be downloaded here – enjoy!

Disclaimer: Please not that the code comes as-is and I will not be held responsible.

Multilevel Drop Down Menu in EPiServer CMS

Fri, 20 Aug 2010 04:01:00 GMT

Today I want to share a simple and small code sample that I put together for a partner. In this sample I going to show how you could implement a Drop Down Menu in EPiServer CMS.

There are heaps of Drop Down Menus available on the Internet. I did quick Google search and found this one, which I kind of liked. It is a simple drop down menu with multilevel support built with CSS. You also have the option of adding some JQuery to make it look even prettier. Kudos to Kriesi for building the menu! What I have done is implementing the menu in EPiServer CMS. To learn more about the specific of the CSS and the JavaScript code please visit the original blog post.

To illustrate how you could implement the menu in EPiServer I created a plain PageType. I decided to use the EPiServer PageTree class to build my menu, the code looks like this:

<EPiServer:PageTree runat="server" ID="DropDownMenu" EvaluateHasChildren="true" ExpandAll="true" NumberOfLevels="3">
    <ItemTemplate>
        <li>
            <EPiServer:Property ID="Property1" PropertyName="PageLink" runat="server" /><%# GetItemSeparator(Container.HasChildren) %>
    </ItemTemplate>
    <IndentTemplate>
        <%# GetIndentTemplate(Container.Indent) %>
    </IndentTemplate>
    <UnindentTemplate>
        </ul> 
        </li>
    </UnindentTemplate>
</EPiServer:PageTree>

There are two tricks used in this implementation. Since the menu relies on nested lists, we have to have a dynamic approach to which IndentTemplate and which ItemTemplate to use. For this I created two methods; GetIndentTemplate(int) will add an id tag to the <ul> element if it is the most outer, i.e. the first, list. GetItemSeparator(bool) will make sure we get a nested list if the current item has children. This is how the code looks like:

protected string GetIndentTemplate(int indent)
{
    if (indent == 1)
    {
        return "<ul id=\"nav\">";
    }

    return "<ul>";
}

protected string GetItemSeparator(bool hasChildren)
{
    if (!hasChildren)
    {
        return "</li>";
    }

    return String.Empty;        
}

Using the default CSS that comes with the menu will make your EPiServer CMS page look something like this:

If you want the complete sample code, you can download it here.

Update!

As Johan mentioned in one of the comments you can make use of the ItemHeaderTemplate and the ItemFooterTemplate to make an alternate implementation of the menu without logic in the code behind. Inspired by the comment by Johan I made some changes to show you how it could look like. Thanks Johan!

<EPiServer:PageTree runat="server" ID="DropDownMenu" EvaluateHasChildren="true" ExpandAll="true" NumberOfLevels="3">        
    <IndentTemplate>
        <%# Container.Indent == 1 ? "<ul id=\"nav\">" : "<ul>" %>
    </IndentTemplate>        
    <ItemHeaderTemplate>
        <li>
    </ItemHeaderTemplate>
    <ItemTemplate>
        <EPiServer:Property ID="epiPageLink" PropertyName="PageLink" runat="server" />
    </ItemTemplate>
    <ItemFooterTemplate>
        </li>
    </ItemFooterTemplate>
    <UnindentTemplate>
        </ul>
    </UnindentTemplate>
</EPiServer:PageTree>

And this version of the code can be downloaded here.

Disclaimer: Please not that the code comes as-is and I will not be held responsible.

Active Directory Membership and Role Providers in Relate+

Fri, 06 Aug 2010 11:22:00 GMT

I don’t get a huge of amount of traffic to my blog, but my most popular posts are the ones about Membership and Role Providers and their configuration in Relate+ found here and here. Today I decided to follow up these post with one covering Relate+ in combination with the Active Directory Membership- and Role Providers. This post is based on information sent to me by my colleague Håkan and is published with his consent. Thanks Hawk!

The solution to make Active Directory play nice with Relate+ (and vice versa) is in the form of some custom code overriding some things in the Active Directory Providers. The AD Membership and Role Providers are known to cause some issues, something that Johan Olofsson fortunately has blogged about earlier. Start out with the code provided at:

http://labs.episerver.com/en/Blogs/Johano/Dates/2008/9/Some-ActiveDirectoryRoleProvider-issues/

Use that as a base (the code overrides some things in the Active Directory Providers to strip domain names from usernames as well as fixing some issues with escaping of characters in role names), and then, in the WinActiveDirectoryMembershipProvider.cs found there replace the GetUser method with something along these lines:

public override MembershipUser GetUser(string username, bool userIsOnline) {   string domain = "";   int bsIndex = username.IndexOf('\\');    if(bsIndex > 0)   {     domain = username.Substring(0, bsIndex + 1);     username = username.Substring(bsIndex + 1);   }    MembershipUser user = base.GetUser(username, userIsOnline);    return new MembershipUser(user.ProviderName, domain + user.UserName, user.ProviderUserKey, user.Email, user.PasswordQuestion, user.Comment, user.IsApproved, user.IsLockedOut, user.CreationDate, DateTime.MinValue, DateTime.MinValue, DateTime.MinValue, DateTime.MinValue); }

Now set up your site to use this modified WinActiveDirectoryMembershipProvider as your default Membership Provider, the special version of the ActiveDirectoryRoleProvider (from the blog post) as the default Role Provider, and make sure that the “EPiServer.Common.Web.Authorization.IntegrationHttpModule, EPiServer.Common.Web.Authorization” http module is active. And voila – it should work!

What it does different is that it strips the domain from the username in the call to the AD Membership Provider, but then puts the domain back in the MembershipUser it returns to the system. This way the usernames in Membership.GetUser().UserName and HttpContext.Current.User.Identity.Name will match, which is currently required for the Integration http module to work.

The solution is, unfortunately, not well tested, but it does work in my test environment. Happy coding!

Note! This post is primarily written for Relate+ version 1.x

CodePlex: CMS Properties for Relate+

Tue, 08 Jun 2010 08:26:00 GMT

A few days back I wrote about a little project that I’ve been working on; CMS Properties for Relate+. After that I started an Open Source Project for Add-ons for Relate+ on CodePlex. Now I’ve taking the time to move my code and even done the first releases of these CMS properties on CodePlex.

So please check out the Relate+ project on CodePlex. You can find it here.

Relate+ on CodePlex

Fri, 04 Jun 2010 08:00:00 GMT

Lately I have been putting together some random extensions/modules/what ever you like to call it for Relate+, such as the Friendly URLs for Relate+ and the Contest Picker property. I thought it was about time to create a home for these modules and other things that are created for Relate+.

I had some considerations about where to put the modules – CodePlex, github, CodeResort, Google Code – but I ended up choosing CodePlex since it seems to be the one that is mostly adopted and easiest to use. After a quick chat with Joel Abrahamssson on the matter I was convinced it was the right choice.

So let me present to you the new home of Open Source extensions to Relate+; http://relateplus.codeplex.com. I will move my modules there as soon as possible, and I hope that YOU will contribute as well. If you have any opinions on the setup and so on, I’m all ears.

CMS Properties for Relate+

Tue, 01 Jun 2010 11:30:00 GMT

In EPiServer Relate+ there are two EPiServer CMS Custom Properties built-in that enables the editor to do nice cross references between editorial content and user generated content on Article pages and News items. The two properties are:

Club Association – a dropdown list showing the available clubs and lets the editor associate an article with a club. The article is also shown on the specific Club’s page.
Forum Association – a dropdown list showing all the forum rooms on the web site. By selecting a room, the latest topic from that room will be displayed on a news item.

This all good, even though I think the design choice to go with dropdown lists are not optimal (have myself to blame, but at the time it was the only option). The biggest problem however is the way theses properties are designed, they are not generic. So when I got asked by one of our partners Down Under about this I got an idea.

The partner wanted to integrate the Contest module on a Relate+ site. As you all probably know, the Contest module is a part of EPiServer Community, but not implemented i Relate+ – confused? Have look here. They wanted to give the editor the possibility to add a link to a Contest from a CMS page. So this was my starting point.

I wanted to create a “framework” (it’s over the top to call it a framework, but it was the best word that came to my mind) that enables the editor to easily link to any kind of Community object from CMS pages. Obviously I had to create a Custom Property! I started to have a look around and I found this Google Maps Property built by Joel Abrahamsson (this guy seems to be everywhere!). This property follow the same architecture as the built-in properties in EPiServer CMS, so I decided to use almost the same layout for my community property.

I tried to be as generic as possible and not lock the property down to just work with Contest, because I want to use it for Clubs, Forums, Users, etc. Basically an object that inherit from FrameworkEntityBase – the base class for all Community objects. Therefore I split my Custom Property into two different projects:

EPiXternal.RelatePlus.WebControls
EPiXternal.RelatePlus.Properties

In the WebControls project I have created a generic web control that consists of a TextBox and a picker button. The picker button will open a pop-up window with a specified address where you do your selection.

In the Properties project you will find the actual implementation of the Custom Property. It uses the InputRelatePlusEntityPicker class in the WebControls project, so you have to have that installed for it to work. In the Properties project I didn’t have the luxury to be as generic as I wanted to due to the implementation of some of the things i Community, however this will be solved in the Community 4 release and will update my project accordingly. However the CSS and the JavaScript functions that are used are generic so you could easily add a new object picker that picks Clubs for instance.

In the Contest Picker pop-up you will be able to search for Contest and pick the one you like. The “picking” part is all done in JavaScript and when you’re done you click “Select” which will close the pop-up and send the value back to the CMS page.

You have obviously heaps of choices when it comes to deciding how you should implement a listing of objects and add associated paging. I chose to use the DataGrid web control, since that is the way it is done in a lot of places in the CMS. I know that it may not be the most beautiful approach, but it’s simple and straight forward. I was thinking of using the GridView instead, but the lack of the VirtualItemCount property made me change my mind. However I will probably change the implementation to use ListView in combination with a DataPager as suggested by Frederik Vig.

I’m not a front end developer, so if you have comments on the HTML, CSS or JavaScript please let me know how I can approve the solution.

Getting the source code

Update! The source code is now available on CodePlex.

You can download the source code below:

Get it on CodePlex

If have set up the projects so that after build an install directory will be created. If you want an installable EPiServer CMS Module, just make a Zip file of the contents in the install directory. Included in the install directory is a web.config update file, which will limit the access to the Contest Browser so that only the roles “WebEditors”, “WebAdmins” and “Administrators” will have access to it.

If you prefer to just get the installation modules and you don’t care about the source code, have a look at the releases at CodePlex.

Disclaimer: Please not that the code comes as-is and I will not be held responsible.

Friendly URLs in Relate+ (Part 2)

Tue, 16 Mar 2010 06:15:00 GMT

In the first part of the “Friendly URLs in Relate+” series I introduced a prototype I’ve been working on to give you friendly URLs in Relate+. In this part two I will go through installation of the provider and also guide you through some details of the code.

Installation

The provider that I have built inherits from the EPiServer.Web.FriendlyUrlRewriteProvider (which is the default URL provider in CMS). My provider will call the base class if it doesn’t find any matches. Therefore you are safe to comment out the use of the default provider in the web.config and to use mine instead. Find the urlRewrite element in your web.config and make it look something like this:

urlRewrite Element
 <urlRewrite defaultProvider="RelatePlusFriendlyUrlRewriteProvider">  
    <providers>  
        <add name="RelatePlusFriendlyUrlRewriteProvider"  
             description="Friendly URL rewriter for Relate"  
             type="EPiXternal.RelatePlus.FriendlyUrl.UrlRewriteProvider,EPiXternal.RelatePlus.FriendlyUrl"/>  
        <add name="EPiServerIdentityUrlRewriteProvider"  
             description="EPiServer identity URL rewriter"  
             type="EPiServer.Web.IdentityUrlRewriteProvider,EPiServer"/>  
        <add name="EPiServerNullUrlRewriteProvider"  
             description="EPiServer bypass URL rewriter"  
             type="EPiServer.Web.NullUrlRewriteProvider,EPiServer"/>  
    </providers>  
</urlRewrite> 

You also have to add the EPiXternal.RelatePlus.FriendlyUrl.dll to your bin directory.

Modifying The Relate+ Templates

To make the friendly URL rewriter work with all the supported scenarios you have to make modifications to two methods in the Relate+ templates. This has to do with how the URLs are created in these two methods. In the following code snippets you will see the new implementation of these methods. The first method to change is the GetEntryUri(…) on line 856 in ExtentionMethods.cs.

Line 856 ExtensionMethods.cs
 public static Uri GetEntryUri(this Entry entry)  
{  
    UrlBuilder url = new UrlBuilder(Pages.Base.PageBase.MyBlogPage.LinkURL);  
    url.QueryCollection.Add("userId", ((UserAuthor)entry.Blog.Author).User.ID.ToString());  
    url.QueryCollection.Add("entryId", entry.ID.ToString());  
  
    if (UrlRewriteProvider.IsFurlEnabled)  
    {  
        Global.UrlRewriteProvider.ConvertToExternal(url, Pages.Base.PageBase.MyBlogPage.PageLink, Encoding.UTF8);  
    }  
  
    return url.Uri;  
} 

The second method to change is GetBlogListingUrl(…) in MyBlog.aspx.cs.

Line 504 MyBlog.aspx.cs
 protected string GetBlogListingUrl(int year, int month)  
{  
    string date = year.ToString();  
  
    if (month != -1)  
    {  
        date += month.ToString("00");  
    }  
  
    UrlBuilder url = new UrlBuilder(Pages.Base.PageBase.MyBlogPage.LinkURL);  
    url.QueryCollection.Add("userId", ((UserAuthor)CurrentBlog.Author).User.ID.ToString());  
    url.QueryCollection.Add("date", date);  
  
    if (UrlRewriteProvider.IsFurlEnabled)  
    {  
        Global.UrlRewriteProvider.ConvertToExternal(url, Pages.Base.PageBase.MyBlogPage.PageLink, Encoding.UTF8);  
    }  
  
    return (string)url;  
} 

The Details

In this section I will go through some details of the implementation. I will assume that you have some knowledge about how friendly URLs work in EPiServer CMS and have seen Relate+ in action.
In the Relate+ Templates we find the id of the object to show in the query string. Sometimes even multiple ids are used in the query string. When creating friendly URLs for Relate+ my first thought was to cheat and still have the ids present in the URLs. That would look something like this:

http://localhost/My-Blog/johndoe/2010/03/My-first-entry-13/
http://localhost/My-Blog/johndoe/2010/03/My-first-entry/13

In these cases 13 would be the id of the blog entry. However I opted for something that I would like to call true friendly URLs, that is when no ids are included in the URL whatsoever. The examples above will therefore be rendered like this:

http://localhost/My-Blog/johndoe/2010/03/My-first-entry/

Since no ids are included in the URLs I have to have another way of getting a specific object, whether it be a blog entry or an image. Here comes the Query System to the rescue! But let me back up a bit and take it from the top.

When creating a URL rewriter for the EPiServer CMS the two most important methods are ConvertToExternalInternal(…) and ConvertToInternalInternal(…). The first one of these takes a non-friendly, raw URL and creates its friendly counterpart. This part is easy, the only thing that is a bit tricky is to find out which of the cases we are dealing with. But by looking at the Path of the incoming UrlBuilder parameter you can figure out which page type is used and therefore also which case you are dealing with. The only thing you have to do is decide how your friendly URLs should look like. If you scroll down and take a look under “The Cases” you can see my choices.

The second method is a bit more complex. What you want to do here is to do the opposite, that is go from a friendly URL to its raw counterpart, which the system can understand. This also means that you have to add the query string parameters that the system will assume are there.

Back to the queries… Since I don’t have the ids of the objects in the friendly URLs I’m using the Query System from the Community platform to create custom queries to find my objects. Basically I’m searching for objects based on names and titles with some extra criterion for security checks. However this means that I take some things for granted. For example I assume that there is only one blog entry that is called “X” created by user “Y”. Therefore if you going to use this prototype in a real life scenario you will have to insert some validation into your Relate+ Templates. See next section for list of validation requirements.

The Validation Requirements

Module	Requirement
General	Username must be unique
Blog	Each entry must have a unique title per user
Forum	Each room must have a unique name
Forum	Each topic must have a unique title
ImageGallery	Each image gallery must have a unique name per user
ImageGallery	Each image must have a unique name in an image gallery

The cases

These are the cases that the code handle and how the URLs are being transformed.

Old URL	Friendly URL
/My-Page/?userId=1	/My-Page/johndoe/
/My-Page/My-Settings	/My-Settings/johndoe/
/My-Blog/?userId=1	/My-Blog/johndoe/
/My-Blog/?userId=1&entryId=1	/My-Blog/johndoe/2010/03/My-first-entry/
/My-Blog/?userId=1&date=2010	/My-Blog/johndoe/2010/
/My-Blog/?userId=1&date=201003	/My-Blog/johndoe/2010/03/
/Tags/?tag=car	/Tags/car/
/Forum/Room?roomId=1	/Forum/Hotels-in-London/
/Forum/Room/Topic?topicId=4	/Forum/Hotels-in-London/Recomendation-for-hotels/
/Images/My-Image-Galleries?userId=1	/My-Image-Galleries/johndoe/
/Images/My-Image-Galleries/Images?userId=1&imageGalleryId=142	/My-Image-Galleries/johndoe/My-First-Gallery/
/Images/My-Image-Galleries/Images/View-Image/?imageGalleryId=144&imageId= 106&index=0	/My-Image-Galleries/johndoe/My-First-Gallery/Butterfly/?index=0

What’s to come

Maybe I will add the source code to CodePlex or CodeResort if anyone wants me to. I’m also thinking about implementing the stuff that is missing in this alpha release:

Friendly URLs for Video section
Friendly URLs for Club section
URL Caching
Do a real implementation of ConvertToInternal(…)
Making Query objects publicly available

Getting the code

Download the source code here.
Disclaimer: Please not that the code comes as-is and I will not be held responsible.

Friendly URLs in Relate+ (Part 1)

Mon, 15 Mar 2010 05:29:00 GMT

One thing I from time to time get questions about is whether Relate+ comes with friendly URLs – you know those URLs that look really nice and are easy to read for a human. Unfortunately this is something that didn’t make it to the version 1 series of Relate+. I think this is a shame since friendly URLs is a built in feature of CMS. I understand that from a user’s point of view it would seem obvious that we would have it in the templates where EPiServer CMS and EPiServer Community come together. Given that, my answer to our partners has always been; “Since the Friendly URL system is provider based, you could build your own”. Now, that is not the answer you would like to hear…

However building a friendly URL rewriter for Relate+, even though it’s feasible, it’s quite of a hassle. The reason being that the number of different cases of navigation are so many. Stop to think about it for a minute. You are not only dealing with pages, instead you are dealing with objects that resides on the same page. On top of that the objects are not structured in the same way. Look at a blog post for instance compared to a forum post. In the blog case you like the date of the post in the URL, but in the forum case you want the room and thread in the URL.

So to make a few of our partners happy (or maybe I should say happier!) I decided to put some effort in to building a prototype for friendly URLs in Relate+. I want to stress that currently this is just a prototype, it’s something that I put together pretty quickly and the code is in need of some refactoring. Also there is need for adding caching if you are going to use it in a live scenario. But anyways, I’m putting the code out there for you to download and play with.

I want to acknowledge the work of Ted Nyberg, his friendly URLs for EPiServer CMS blog post served as a base for my implementation. Thanks Ted!

Download the source code here.

I’m thinking about maybe doing some refactoring and then putting the code on CodeResort or CodePlex as Open Source – if there is someone who wants me to. Please drop me a comment on the matter.

In part two – which will be posted soon I hope – I will go in to the details of the implementation. I will also give an instruction how to install it.

Update! Here is the link to the second part.

Disclaimer: Please not that the code comes as-is and I will not be held responsible.

Relate+ in CMS 6

Wed, 13 Jan 2010 05:55:00 GMT

I hate when people write on their blogs that it has been a while since the last post and that they intended to blog a lot more than they have done so far. But now I’m going to do it as well. The reason for sporadic blogging the last couple of months is that – as some of you already know – I have moved to Sydney to help out starting up the EPiServer ANZ office – that is Australia and New Zealand. Sine the end of October I live with my wife in Sydney, and the EPiServer office in CBD in Sydney is the place to find me.

Ok, enough said about that and over to the juice parts of my first blog post on Australian soil.

By now most of you have probably tried either the CTP or the RC1 of the upcoming EPiServer CMS 6 – the next big release of EPiServer’s content management system – or seen a couple of screenshots of how it may look like. However the screenshots I’m going to show you comes with a twist – it’s Relate+ (1.0.1.0) running on CMS 6!

I have not tested all the features yet, but what I’ve seen so far almost everything works great. I have only found two flaws;

The CSS for the Mail admin gets effected and looks a bit off
By default you have to append the language code to the URL to reach the start page

As you can see, these are minor issues and pretty easy to fix. So how did I accomplish this? It’s really easy. I just installed a standard Relate+ site and then upgraded it to a CMS 6 using the excellent EPiServer Deployment Center. If you want to see more details on upgrading CMS 5 sites to CMS 6, read this blog post by Per Bjurström.

So if your about to start a Relate+ project, but you are curious on the new CMS 6 maybe this is the way to go! No guarantees that everything will work though…

Windows Authentication in EPiServer Community and EPiServer Mail

Wed, 09 Sep 2009 14:27:00 GMT

Lately I have seen more and more of our partners using Windows Authentication in their EPiServer Community and EPiServer Mail solutions. I guess the reason is the products are being more and more used within an intranet environment, which is really cool.

However I have noticed that a lot of developers are having difficulties configuring this type of environment. I’m sad to say that the documentation about this type of setup is sparse at best – so I can’t blame the developers who comes asking for help. I decided to write this blog post instead of sending the same mail to everyone who needs help.

In an environment where you use Forms Authentication you are fine using the instructions in my previous post, EPiServer Community role and membership providers. But if you are using Windows Authentication the EPiServerCommonIntegrationProvider will not be able to do the syncing of the users and roles. The reason is because the ValidateUser(username, password) method in EPiServerCommonIntegrationProvider is not called, since the WindowsAuthentication ticket stores everything needed to validate the user. This causes the user to be authenticated, but not synchronized (Identity of the request is set, but the Name of the Identity is not present in the EPiServerCommon database).

The rescue is a HTTP Module that is part of the EPiServer Common. Simply add the following module to your list of HTTP Modules in the web.config:

     <add name="EPiServerCommonWindowsAuthenticationIntegration" type="EPiServer.Common.Web.Authorization.IntegrationHttpModule, EPiServer.Common.Web.Authorization" preCondition="managedHandler" />

What this module will do, is to first make sure that there’s a MembershipUser for the current request. This object would originate from the configured MembershipProvider. If it is set, but there’s no user in EPiServer.Common, it will synchronize the user using EPiServer.Common.Web.Authorization.Integrator.SynchronizeUser(MembershipUser, Password, createNew).

(Remember to remove the preCondition="managedHandler" attribute if you're not using IIS7 – thanks Erik)

Hanselman’s Tool List Revisited

Wed, 09 Sep 2009 13:19:00 GMT

I’m constantly in the hunt for new tools and programs that can make life easier, not only as a programmer but for my everyday personal life as well. Since I’m a programmer on the .Net platform I follow Scott Hanselman’s blog (if you are .Net programmer you don’t follow his blog; head over to this address straight away). Every year Scott produces the “Ultimate Developer and Power Users Tool List for Windows”, this list is my golf mine for finding new tools and util programs to use.

If you haven’t read Scott’s post before, I suggest you to start out by doing that - Scott Hanselman's 2009 Ultimate Developer and Power Users Tool List for Windows – because this blog post is my reflection on that list.

First of all, kudos to Scott for compiling this awesome list! I have not tested out all the programs that he mentions, but some of them I would like to comment and I have a few additions.

The best text editor for the Windows platform is in my opinion Notepad++. I used UltraEdit before, but Notepad++ is just as good and at the same time for free! It’s an obvious choice for me.
Never heard of Evernote before I read Scott’s list. Now I’ve downloaded it and started to use it. Since I both use Mac and Windows I really love applications that work on both, and especially apps that sync with over the web as well. I really hope that this app can replace Onenote.
Dropbox is the app/service I use to store stuff in the cloud. It has a nice web interface, but also applications for both Mac and Windows – which I love. You get 2 GB for free and it’s really easy to use, just drop your files in the Dropbox folder on your machine and it’s synced to the cloud. Fantastic!
Since I’m a Mac user I also have to mention WMware Fusion, which is the best virtualization software for the Mac.
Again, since I’m a Mac user – Bootcamp, could it be better?!
Writing comments in code is boring, but it’s more fun with GhostDoc. GhostDoc is a plug-in to Visual Studio that generates comments for you. Use it as stubs for your comments. GhostDoc recently got acquired by SubMain – let’s hope that this only brings good to the application.
Lately I have switched to Google Chrome as my preferred browser just because is so lightning fast and because I just love the “One box for everything” idea.

SharePoint Connector on IIS 7

Fri, 03 Jul 2009 11:24:00 GMT

Came across an issue yesterday where a customer wanted to install EPiServer CMS on an IIS 7 together with EPiServer Connect for SharePoint for integration with SharePoint. As you probably already know, EPiServer CMS supports IIS 7 since the R2 release. However configuring the SharePoint connector is done somewhat different than for previous IIS versions.

If you are going to configure the SharePoint connector I suggest you to start of by reading this tech note, since this blog post will not cover all the details included. But when comes to configuring the IIS 7 for Basic Authentication you should look here instead, since it is here things are a bit different. In IIS 7 you can only turn on Basic Authentication on for the entire site (or turn it off), and you cannot run it in combination with for instance Forms Authentication for obvious reasons. So just make sure that Basic Authentication is enabled in the Windows features, in Windows 7 it will look like this:

Also make sure that Basic Authentication is disabled for your site in IIS 7.

Now you might think, what the h***? If I turn off Basic Authentication how could SharePoint connector use it?! Well actually the tag you inserted in the web.config (see below) is an EPiServer hack to enable Basic Authentication on the requests made to a particular location.

     <EPiServer.basicAuthentication sendBasicChallenge="true" basicRealm="" />

Hopefully now you will shout out something like; Hallelujah it works!

Turn off logging for EPiServer Community

Fri, 12 Jun 2009 16:13:00 GMT

The EPiServer Community does not have the same extensive logging capabilities as EPiServer CMS, which utilizes the log4net component. But there are some basic logging done to the standard Windows Event Log under the Application group. The problem is that there is no configuration for turning off the logging if you don’t want it.

But, as in many cases, there is a workaround. The installer for EPiServer Community will set up an entry in the registry to allow the application to write to the Event Log. To turn off the logging simply start up Regedit and navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\EPiServer Common

Either remove the entry or rename it. Now the application will not be allowed to write to the Event Log, and therefore no entries are written there!

EPiServer Community role and membership providers

Thu, 09 Apr 2009 12:00:00 GMT

From various sources I have found out that a lot of people are having trouble with the configuration of role providers and membership providers for EPiServer Community and EPiServer Mail. In this blog post I will try to describe the different setups that are available.

The basic facts

The first thing you need to know is that both Community and Mail has to have the users and groups in the database, independent of which membership provider and role provider you are using. The reason is the the user is such a central concept in the Community case, and Mail is using the same user management as Community. Ok, now we got this settled – let’s move on!

The most basic configuration

In the default installation for Community and Mail, the system will be configured to use the role provider named EPiServerCommonRoleProvider and the membership provider EPiServerCommonMembershipProvider. This means that the system will authenticate against the EPiServer Common tables, which is used by both Mail and Community. The system will also get the user roles, or groups, from the EPiServer Common tables. I.e. the user/group management and access rights is entirely managed by EPiServer Common.

     <roleManager enabled="true" defaultProvider="EPiServerCommonRoleProvider" cacheRolesInCookie="true">

        <providers>

            <clear/>

            <add name="EPiServerCommonRoleProvider" applicationName="EPiServerCommonApplication" type="EPiServer.Common.Web.Authorization.RoleProvider, EPiServer.Common.Web.Authorization"/>

        </providers>

    </roleManager>

    <membership defaultProvider="EPiServerCommonMembershipProvider" userIsOnlineTimeWindow="10">

        <providers>

            <clear/>

            <add name="EPiServerCommonMembershipProvider" applicationName="EPiServerCommonApplication" type="EPiServer.Common.Web.Authorization.MembershipProvider, EPiServer.Common.Web.Authorization"/>

        </providers>

    </membership>

A little bit more advanced configuration

In this case we want to use external membership provider and role provider. In my example I’m going to use Windows providers, but these could easily be substituted with SQL providers or something else.

We start off by setting the WindowsRoleProvider as default role provider, nothing tricky here. However when specifying the membership provider we will not set the WindowsMembershipProvider as default. Remember that every user/group needs to exist in the EPiServer Common tables. To solve this we use the EPiServerCommonIntegrationMembershipProvider and set it as default membership provider. This provider has an attribute called “provider”, here you specify your underlying provider – in this case the WindowsMembershipProvider.

You will also specify the attributes “roleToSynchronizeX” where X is a number (has to be in sequence and start with 1). If a user logs in and gets authenticated the system will look at the user’s groups – if the user is member of any of the groups specified in the “roleToSynchronize” attributes, then the user and all of its groups will be copied to the EPiServer Common tables. Note that only the user’s groups will be copied, not the other users in these groups.

If you use the notation roleToSynchronize1=”*”, the user will be copied independent of the group memberships it has. Note that you have to have EPiServer Common 2.3 Hotfix 1 for this to work.

    <roleManager enabled="true" defaultProvider="WindowsRoleProvider" cacheRolesInCookie="true">

        <providers>

            <clear/>

            <add name="WindowsRoleProvider" applicationName="EPiServerSample" type="EPiServer.Security.WindowsRoleProvider, EPiServer"/>

        </providers>

    </roleManager>

    <membership defaultProvider="EPiServerCommonIntegrationMembershipProvider" userIsOnlineTimeWindow="10">

        <providers>

            <clear/>                

            <add name="WindowsMembershipProvider" type="EPiServer.Security.WindowsMembershipProvider, EPiServer" deletePrefix="BUILTIN\" searchByEmail="true"/>                

            <add name="EPiServerCommonIntegrationMembershipProvider" applicationName="EPiServerCommonApplication" type="EPiServer.Common.Web.Authorization.IntegrationMembershipProvider, EPiServer.Common.Web.Authorization" provider="WindowsMembershipProvider" roleToSynchronize1="Group1" roleToSynchronize2="Group2" />

        </providers>

    </membership>

Advanced configuration

The last type of configuration is where you want to use a series of providers, something we at EPiServer would call a multiplexing scenario. In this case will make us of the IntegrationMultiplexingMembershipProvider which can be found in EPiServer Common 2.3 Hotfix 1. This is actually a combination of the multiplexing provider found in EPiServer CMS and the integration provider mentioned above. This will be used in combination with the MultiplexingRoleProvider in EPiServer CMS.

When using this provider you will be able to specify several underlying providers. The system will try the providers one after another until either the user is authenticated or the the list of providers runs out.

In my example below I’m using the Windows provider as primary provider and SQL provider as secondary.

    <roleManager enabled="true" defaultProvider="MultiplexingRoleProvider" cacheRolesInCookie="true">

        <providers>

            <clear/>

            <add name="MultiplexingRoleProvider" type="EPiServer.Security.MultiplexingRoleProvider, EPiServer" provider1="WindowsServerRoleProvider" provider2="SqlRoleProvider" providerMap1="WindowsServermembershipProvider" providerMap2="SqlMembershipProvider"/>

            <add name="WindowsRoleProvider" applicationName="EPiServerSample" type="EPiServer.Security.WindowsRoleProvider, EPiServer"/>

            <add name="SqlServerRoleProvider" connectionStringName="EPiServerDB" applicationName="EPiServerSample" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

        </providers>

    </roleManager>

    <membership defaultProvider="MultiplexingMembershipProvider" userIsOnlineTimeWindow="10">

        <providers>

            <clear/>

            <add name="MultiplexingMembershipProvider" type="EPiServer.Common.Web.Authorization.Multiplexing.IntegrationMultiplexingMembershipProvider, EPiServer.Common.Web.Authorization.Multiplexing" provider1="WindowsServerMembershipProvider" provider2="SqlMembershipProvider" roleToSynchronize1="*" />

            <add name="WindowsMembershipProvider" type="EPiServer.Security.WindowsMembershipProvider, EPiServer" deletePrefix="BUILTIN\" searchByEmail="true"/>

            <add name="SqlServerMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="EPiServerDB" requiresQuestionAndAnswer="false" applicationName="EPiServerSample" requiresUniqueEmail="true" passwordFormat="Hashed" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="7" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" passwordStrengthRegularExpression=""/>

        </providers>

    </membership>

Confusion about what Relate+ is

Mon, 06 Apr 2009 16:18:00 GMT

Ever since the Relate+ package was released I have experienced that partners, customers and sometimes even EPiServer employees are a bit confused about what Relate+ really is from a technical point of view. Or maybe I should say that probably they are not confused, but they are using the Relate+ name in a confusing way. My idea here is to sort out once and for all what Relate+ is, and what Relate+ is not.

First thing first; Relate+ is not equal to EPiServer Community. This is the most common misinterpretation. With that said, it’s best to also say Relate+ is not equal to EPiServer CMS.

What is Relate+ then? From a technical point of view Relate+ is set of templates, pretty much like the public templates for EPiServer CMS, built on top of EPiServer Community and EPiServer CMS. The templates are then bundled together with EPiServer Community and EPiServer Mail and sold as an add-on package to EPiServer CMS. The idea is to show off the greater part – not all – of the functions in EPiServer Community. This means that you can run a community site without Relate+. It also means that there are more functions in EPiServer Community besides those implemented in Relate+.

To summarize, Relate+ is a template package and not a separate product.