16

I am using Tridion UI 2012 on our website (which is built using DD4T). The problem we're facing is that the session preview web service does successfully commit the edited content to the session-preview database, but it loses its UTF-8 encoding. So everything is stored with symbols like "Â" etc. The encoding is however maintained in the broker database. It's just the session preview database which contains non-UTF8 text.

I have updated the web.config for the session preview web service with the following but this doesn't have an effect:

<globalization culture="auto" fileEncoding="utf-8" uiCulture="auto" requestEncoding="utf-8" responseEncoding="utf-8" responseHeaderEncoding="utf-8" />

Any ideas?

NOTE: This problem only started appearing after we included the following new entry in the same web.config (i.e. session preview web service): 

<httpRuntime maxRequestLength="2097151" />

Thanks.

Improve this question

2 Answers 2

Reset to default
20

Session preview bypasses the standard publishing mechanism. I found it the hard way too, that after "previewing" content my characters were wrong.

Easily fixed if you know what to search for.

The problem is that you need to tell the Java process on the delivery side to use UTF-8 encoding, which is usually handled nicely by the Deployer... but with Session preview you don't have a deployer.

Add the following to the registry of the machine where the WebService is running:

  • Create a registry key called HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Tridion\Content Delivery\General (create all keys you need to get this far)
  • Add a string value with name jvmarg1 and value -Dfile.encoding=UTF-8

Restart the webservice, try again.

EDIT I don't know for sure if this is required on the webservice machine or the Staging website machine... now that I think of it, it should be on the staging machine. I always had both running on the same server, so I don't know which one needed it.

Improve this answer
8
  • I'm having the exact same problem, but on a JAVA implementation. Session Preview however is on a .NET IIS Web App. Is this still the right answer for this?
    – MDa
    Mar 12, 2013 at 20:48
  • 2
    This is the right answer as long as you set it to where the staging application with session preview enabled is running. It does not matter for the preview web service (at least I don't think it does). For a Java staging app, you need to set the encoding at the application server level (JVM startup parameter). This worked for me in Java. I assume you could also use page directives in the page template as well. But UTF-8 usually takes care of any special characters, so probably no harm in setting this at the app server level.
    – Amit Mehta
    Mar 12, 2013 at 20:57
  • 3
    If you're running a Java web app you can probably set this -Dfile.encoding=UTF-8 as part of your JVM parameters. It will also work with the registry entry (if you're on windows obviously) and for .NET there's no other way to specify it.
    – Nuno Linhares ♦
    Mar 12, 2013 at 21:22
  • 1
    +1 for Nuno's answer. This (also) worked for me: stackoverflow.com/a/623036/1221887
    – Albert Romkes
    Mar 13, 2013 at 7:05
  • 1
    I've just followed this post - for some reason setting the registry key did not work for me (I set it on the Staging machine and the Session Preview web service machine) However I followed Albert's link in the comment above and that seemed to fix it. Thought i'd leave a comment incase anyone else is struggling with the same thing!
    – Dave Houlker
    Apr 2, 2013 at 20:06
7

It is tricky to diagnose, but I noticed that I don't have the 'culture' and 'uiCulture' attributes in my Session Preview web service's web.config:

<globalization fileEncoding="UTF-8" requestEncoding="UTF-8" responseEncoding="UTF-8"/>

I suspect that this may be forcing the webservice to use the culture that the Session Preview Extension uses.

Also, I assume that your Content Delivery web service is running on IIS v7.5? If so, then the 'maxAllowedContentLength' attribute is now used to specify the maximum file upload size (rather than the 'maxRequestLength'). Please see the ASP.NET blog for more details.

Hope it helps.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.