Tag: route

EPiServer 301-handling

Got some room to breath today, so decided to split a simple 301-handling I did some weeks ago into it’s own project and “put it in the git”. Also made a nuget for it if anyone wants to try it out.

https://github.com/studsboll/EPiServer301Handler

I like nugets, if done correctly they make it very easy and clean to try code if you want to, and I’m trying to make it a natural part of when i package stuff for safekeeping.

So what does this thing do then?

Basic 301-handling for EPiServer 7.5+. Support for Domain-redirects. Based on XML-files to be as simple as possible doing nothing more and nothing less.

If domain-redirects exists, that request will be routed first with persistent relative path.

Routes will catch what EPiServer does not want and send it to controller for checking if it’s a 301, if it is, a permanent redirect will trigger to new place. If not, a 404-exception will be thrown falling back on website configured error-handling.

Installation
Drop bin-file in your bin-directory. All is IInitializable modules and will hook onto EPiServer.

Optional configuration, add to appsettings

These are also the default paths if no appsettings exist.
XML should look as follows

I trim surrounding /, as well as ignore lower/uppercase on compare. So not that important.

So what about errorhandling?

To accompany this module I usually redirect to a page in EPiServer. Webconfig as

Then I set a page in EPiServer to answer on /error address. The page someone tried to access can be found in TempData[“originalUrl”].

EPiServer 7.5 handling extra Routedata using Partial Routing

Querystrings are evil and does not make pretty links. We can agree to this yes? So what you normally do is put up routes that can handle all those quirky bastards and put em where they belong.

As an example I’m going to use a newslistpage with pagination. (I’m lazy so i’ll only write relative urls) /newslist. If i want to target a specific page in the pagination, i would normally set up a route to handle it so i could write /newslist/2 instead of the ugly /newslist/?page=2.

But if you are working with a Cms like EPiServer, the paths are not really known all the time and routing changes. This can be a tricky thing and I’ve seen a lot of people just ignoring it and carry on with querystrings since it’s the easy thing to do.

There is a very easy way to deal with this in EPiServer 7+ and it’s called Partial Routing. I was reading some posts about it on http://joelabrahamsson.com/ and thought, hey i can use that for simpler things aswell. So here is the implementation to use it for your own “extra” route data.

So what it does it add this extra routing to all pages of type NewsListPage. When resolving it, the routing checks if there are any parts of the routing left unhandled. In my case I’m expecting a possible paginationreference, so i try parse it to an int to see if its data i should bother with.

If it fits, I then add that extra data to the RouteData collection. This will make it easily accessible in the Controller.

So to recap, if there are parts left in the routing after hitting the NewsListPage, we handle it in the Partial Router, add it to the routedata collection and then we can fetch it like it was a querystring/normal route in the controller.

To initialize and attach this Partial Routing to EPiServer, we need to load it. I like to keep it pretty clean so I have a class handling it.

And that should be it. No excuse to use querystrings for simple tasks like this ^^