Oskar Zetterberg
Apr 13, 2011
  8039
(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
Lessons from Building Production-Ready Opal Tools

AI tools are becoming a normal part of modern digital platforms. With  Optimizely Opal , teams can build tools that automate real tasks across the...

Praful Jangid | Mar 7, 2026

My Takeaway from Optimizely Opal Agents in Action 2026 - What Agentic AI Means for the Future of Digital Marketing

I would like to share with you what stayed in my head after this amazing virtual event organized by Optimizely. Agents in Action 2026 , a live...

Augusto Davalos | Mar 6, 2026

From Vision to Velocity: Introducing the Optimizely MVP Technical Roundtable

Digital transformation is a two-sided coin. On one side, you have the high-level strategy, the business cases, the customer journeys, and the...

Patrick Lam | Mar 6, 2026

Commerce 14.45.0 is incompatible with CMS 12.34.2 (but that's an easy fix!)

Incompatible is a strong word, but that is to get your attention. This is one of the small thing that can be overlooked, but if you run into it, it...

Quan Mai | Mar 5, 2026

Announcing Stott Security Version 5.0

March 2026 marks the release of Stott Security v5, a significant update to the popular web security add-on for Optimizely CMS 12+, with more than...

Mark Stott | Mar 5, 2026

Is Opal the Enterprise-Ready Evolution of OpenClaw?

From OpenClaw experiments to enterprise AI agents: exploring the journey from my personal automation to governed execution at scale with Optimizely...

Hristo Bakalov | Mar 5, 2026 |