I did some research online to see what others had done. I found two great posts by Joel Abrahamsson and one from Fabio Fabrizio, who based his solution on Joels experiments.

Joels first attempt was to create a base class from which all Controllers inherited. However, this made the controller do more than it should and made it very hard to test. His second attempt was to create a custom model binder and make every action receive currentPage as a parameter. This approach makes it much easier to create unit tests for the code, since it is now possible to moc the currentPage parameter.

Fabio took a different approach and decided to implement a custom MVC handler and a controller factory. This approach fits very well with MVC and felt like the right way to go, so I decided to create a prototype based on Fabios code. Fabios code was based on EPiServer CMS 5 and ASP.NET MVC 1.0, but I wanted to use EPiServer 6 and ASP.NET MVC 2.0, so I started porting the solution.

Porting the solution to EPiServer 6 and ASP.NET MVC 2.0 required some changes to both code and configuration, which not all of them was trivial. At the moment I have a prototype up running, and it works remarkably well! I will continue my experiments and post my results.

Prev 1, 2 , 3, …, 99 Next

A fairly normal approach to this would have been to use a query parameter for handling the paging. Like this:

By using this approach each page would have a unique entry point, using query strings is however not optimal for SEO, but even worse is using asp:LinkButtons. Whoever created the site had decided to use asp:LinkButtons. LinkButtons are very convenient to work with in ASP.NET, but the HTML code they generate is not very SEO friendly. This is the HTML that was generated:

We can see that:

• LinkButtons generates a javascript that is run when the link is clicked, instead of using a normal link
• Paging is handled using a postback, the pages will no longer have unique entry points.

This is disastrous from a SEO perspective.

So lets fix it. First step is to replace the LinkButtons with normal links (asp:Hyperlink) – and then we are going to do some URL rewrite magic to create SEO-friendly URLs. The code behind was changed to assign links like /products/?page=4.

Now, to get URLs like /products/page/4, we can create a custom url rewrite module in EPiServer. First we create a new class, Rewrite, that inherits from EPiServer.Web.FriendlyUrlRewriteProvider. In this class we override three methods (don’t ask we why they have such confusing names, someone at EPiServer must have been under the influsene of something when nameing them):

• ConvertToInternalInternal - Used to convert from /product/page/4/ to an internal EPiServer page with the page id as a query parameter
• ConvertToExternalInternal - Used to convert from an internal EPiServer URL (/PageType.aspx?lotsofqueryparameters=values) to an external (/products/page/4/)
• ConvertToInternal - Needed to work around URL rewrite caching behaviour in EPiServer, will get into more detail on this later.

This is the class:

The first method we implement is the ConvertToInternalInternal which will convert the URL to an internal EPiServer URL.

While not nessesary, we should override the ConvertToExternalInternal as well. This will let EPiServer automatically convert internal urls containing the dqcPagingId querystring to a external url ending with /page/{Id}/.

Now one can think we would be done, but there is one more method we need to implement. EPiServer uses a cache to cache URL rewrites from external URLs to internal URLs, but it will only cache the querystrings used by EPiServer, not the dqcPagingId we added. This gives a rather unexpected result. The first time the page is loaded everything loads fine, from code behind we can access the dqcPagingId and show the requested page. If you wait 10 senconds (default cache time) or more and reloads the page, it works fine. But if you reload the page sooner, the dqcPagingId will not be set when the page loads. This is because the querystring dqcPagingId is not cached by EPiServer. This took me quite some time to figure out.

The solution to the problem is to override ConvertToInternal to bypass the default caching:

The last step is to add our Rewrite module to the web.config:

Now we should be all done! Enjoy!

Rename a Folder

There is no Rename method on the EPiServer.Web.Hosting.UnifiedDirectory class. To rename a folder you need to call the MoveTo method as follows:

1.  
2. protected void RenameFolder(string path, string oldName, string name)
3. {
4.     if (IsFolder(path))
5.     {
6.         UnifiedDirectory directory =
7.         System.Web.Hosting.HostingEnvironment.VirtualPathProvider.GetDirectory(path) as UnifiedDirectory;
8.  
9.         int e = -1;
10.         while (path.IndexOf(oldName, ++e) > -1) ;
11.  
12.         StringBuilder sb = new StringBuilder();
13.         sb.Append(path.Substring(0, e – 1));
14.         sb.Append(name);
15.         sb.Append("/");
16.  
17.         directory.MoveTo(sb.ToString());
18.     }
19. }
20.  

What a convenient way of renaming a folder Good thing that you don’t have to do it too often.