Oskar Zetterberg
Apr 13, 2011
  8137
(2 votes)

EPiServer CMS6 R2 and broken FriendlyUrlRewriteProvider

Ran into alot of problems yesterday while upgrading our website to the latest EPiServer version, CMS6 R2. The problem: I have made a custom FriendlyUrlRewriteProvider that inherits from EPiServer.Web.FriendlyUrlRewriteProvider that partly stopped working. My custom querystrings was discarded and the link click rendered into a 404 visit.

After alot of head scratching and dll and config checking I digged in to the EPiServer.dll of both the new and old version (CMS 6 and R2) and compared the two classes, method by method. Finally I realized that I needed to add an override for the method TryConvertToInternal with the same functionality as in ConvertToInternal (should have been obvious but I intend to always check the easiest solutions last).

Now the pager and all the other rewrites works as expected. This might not be the correct way to handle this but from what I can tell it works as it should.

Anyone with better solutions are more then welcome to comment on this.

Apr 13, 2011

Comments

Apr 14, 2011 07:25 AM

Hi

Unfortunately we had to make this "semantic breaking change" to the implemenation in Url rewriting to correct a bug regarding language handling.

The suggested way if you have written a custom provider that override ConvertToInternal is to override TryConvertToInternal and move the logic there (just like you did).

Sorry for the inconvenience this have caused...

Ted
Ted Apr 14, 2011 08:18 AM

More people are having this problem, but I think the workaround is acceptable. If you'd talk to Deane Barker (@gadgetopia) you'd see he's had some frustration with FURL rewriters too. :)

smithsson68@gmail.com
smithsson68@gmail.com Apr 14, 2011 10:02 AM

Thanks for sharing Oskar.

Kai de Leeuw
Kai de Leeuw Sep 11, 2012 04:58 PM

I did like this:

public override bool TryConvertToInternal(UrlBuilder url, out CultureInfo preferredCulture, out object internalObject) {
return (bool)typeof(EPiServer.Web.FriendlyUrlRewriteProvider).GetMethod("TryConvertToInternal", BindingFlags.NonPublic | BindingFlags.Instance).Invoke(
this,
new[] { url, 0, preferredCulture = null, internalObject = null });
}

The alternative to doing this was to copy several hundred rows of code just to be able to send LanguageApiMode.Destructive which is required for the code in ConvertToInternalInternal to get called.

Please login to comment.
Latest blogs
Optimizely Opal: How to Build Effective Workflow Agents

If you're building workflow agents in Optimizely Opal, this post covers how specialized agents pass context to each other, why keeping agents small...

Andre | May 20, 2026

ReviewPR: An Azure Function That Reviews Your Azure DevOps Pull Requests With Claude

A while back I wrote about an  Azure Function App for PDF creation that we use to offload PDF rendering from our Optimizely DXP site. That same...

KennyG | May 19, 2026

Accelerating Optimizely CMS and Commerce upgrades with agentic AI (Part 2 of 2)

The Real Transformation in Optimizely CMS 13: Why the Upgrade Itself Is the Easy Part. A field-tested playbook for enterprise teams moving from...

Hung Le Hoang | May 18, 2026

Is the most powerful AI model really the best value?

Artificial Intelligence is already becoming part of everyday software development. Developers now use AI tools to generate code, write documentatio...

K Khan | May 16, 2026

Optimizely London Dev Meetup 2026

Well, everyone, it's that time of the year again, and we have another London Developer meet up coming for this summer. The date is set for the 2nd ...

Scott Reed | May 15, 2026

Semantic Search - Deep Dive

Deep dive into semantic search with Optimizely Graph

Michał Mitas | May 14, 2026 |