OK. Well we tried to install the hotfix, but this failed with error “The detection failed, this can be due to a corrupt installation database.". The server guys were unable to solve this within their SLA and gave up.
However, I have discovered the reason for the odd characters and the cure. It’s a tale of woe.
Management Summary; The variation System didn’t match up with the correct content type, but this was only an issue when we had more than one publishing content field on a page…. Confused? Read on….
The client created their Source site some months ago, and created several target variations with several locales and languages. All seems to work, and published content didn’t have any problems.
One large portion of the site had its own custom content type which amongst other things contained a page content field of type Publishing HTML. This had always worked fine and no issues were suspected.
We recently amended the custom content type to have three extra Publishing HTML fields, and the content from the old field was migrated by hand into the three new fields. When this was published we started getting those odd characters in the Target Variations, but the Source Variation text looked fine.
I looked at the available content types on the Publishing Page Lists in our Target Variations. (Not easy – you have to go to ‘Manage Content and Structure’, then go to the pages list and click Edit Properties.) It turns out that the custom content type on the pages had never gone out to the variations. (Content type was based in the root site and should have been inherited but wasn’t). All the Target Variation Pages were based on Content Type ‘Page’. It staggers me that publish had worked at all.
Even a brand new Turkish variation we created recently was based on Page, whereas the Source Variation was ‘customContentType’ (sic). I have heard about this issue with Content Types needing to be added manually before, but considering how variations need the Source and Target Content Types to be the same I had thought it not an issue in this case.
So, I wrote some code to go through all the offending Publishing Page Lists and add the customContentType to them (not wanting to do several hundred lists by hand). They all have the right content type available to them now. ‘Page’ content type is still the default, but the correct one is being referenced.
Now when we select ‘Update Variation’ or re-publish a page the content is coming through correctly.
I’m going to state again – I can’t believe the initial publish worked. Why did it work just because there was a single Publishing Content field rather than several? The Page content type in Target was significantly different to the content type in use on the Source Variation. But by working it stopped us seeing the obvious problem when we changed things in Source. Wow. Glad to have that one sorted.
Why oh why doesn’t the correct content type go out to Variations? Even when a new variation is created from scratch!!
Now I just have to figure out why one of our servers doesn’t like hotfixes…