Hi, we had similiar issue when we applied the Episerver update 197. We switched xhtmlstring rendering from @Model.ViewModel.SomeXhtmlStringProperty to be rendered like this: @Html.DisplayFor(m => m.ViewModel.SomeXhtmlStringProperty) to fix the issue (we use DisplayFor as these were used in places that editor cannot edit those directly which I believe is the same for you as you are not using the @Html.PropertyFor( xxx )

You can also use the HTML helper.  HTML.Xhtmlstring(model.xhtml)

Thanks for your help. We were just struck by such a surprise as I could not find anything in patchnotes/breaking changes and well we have a lot of view to verify!

I agree.  We ran into this issue as well awhile back.  The one thing i wish would change is the patchs/notes on how items were fix etc..  We ran into this on forms as we override the renderers of form fields and there was a line of code in the view that fixed a latency problem but no where was this documentented.  Makes it hard to upgrade/fix when you have no idea what has changed.

TGIF and weekend started so there is time to investigate things on ones own time :D

Anyways, in our case using the @ on the XhtmlString property has been wrong all the time as another developer in the project had added customisation to the XhtmlString renderings to DisplayTemplate so the other developers XhtmlString property usage has never worked correctly. So in out case we must always call the DisplayFor or PropertyFor if editor editing is desired.

I poked around the Episerver XhtmlString implementation in different versions and there is a change. Do remember that Episerver 11 pre-release was the update 186 and there were big changes to prepare Episerver moving to .net core world. New assemblies and packages were introduced. And finally the update 189 included Episerver 11.

So, looking at the XhtmlString before Episerver 11, we can see that it implements the System.Web.IHtmlString interface. In Episerver 11 it doesn't implement the interface anymore.

So that is the reason why suddenly in Episerver 11 the XhtmlString output using @ is actually html encoded. Do remember that the IHtmlString dates back in Asp.Net MVC history. Even it returns string and not MvcHtmlString it is a marker that the string is already HTML encoded and shouldn't be encoded anymore. So I would say this was a breakinbg change in Episerver 11. The Episerver 11 breaking changes page https://world.episerver.com/documentation/upgrading/Episerver-CMS/cms-11/breaking-changes-cms-11/ doesn't mention this change.

Have a nice weekend all :)

Hi, I have had the same issue in a large project with a lot of views. Not fun to correct all views. Had a discussion with episerver and they did not actually follow why I thought this was a breaking change..and I did not argue anymore after 10 emails. Anyhow this is a breaking change as far as I can tell. It is not that easy to notice since you have to implent the views withouth displayfor or propertyfor. At least it is brarking for views :) 

And @Anti have made the same discovery as I did so I support that this is breaking, but I also can say that you should always use displayfor or property for when rendering xhtmlstring since it can contain blocks and dynamic content (legacy) that need this to be rendered correct in the views. 

You are perfectly right, one should really use displayfor, propertyfor or similiar. Nevertheless, I do agree that since the "api" has changed it is a breaking change! Especially since someone might juggle the properties in models before actually writing them in views/emails or similiar.