About Dylan (the Reverend)

Mark Saunders is the EU Technical Director for SDL Tridion Consultancy company Content Bloom. Mark has led a number of successful SDL implementations for brands such as Dunlop, Lexus, TD Bank and CIPD and worked on a multitude of projects from requirements definition to build implementation.

Improve the Publishing “Experience”

booksSo, you’ve got a release going on and some 20 people are publishing. A few of the editors only have a page or two to publish but some of them then select to publish the whole site and a few have published only whole Structure Groups!

How many of these publish by Structure Group! And, I ask, Why?

Why do it in the first place?

The first answer I hear a lot is

I don’t know exactly what to publish


Continue reading

Translation Manager – would it ever unlocalize something in my translation publication?

Oddly enough, yes it can – in a very specific scenario – of course, this can be avoided with clear processes (or even better automation) with the right hotfix (TT88491: Translation Manager revert retrieved translation for target item in “Reserved state”) but it’s good to know as tracking this down was a real bugger!

Continue reading

Who’s got that bugger checked out?

So that latest update of Chrome has broken some of the Tridion GUI :( … one consequence of this has been that a number of users have been checking out Components and not quite realizing.

Whilst checking who had a some of the items check-out I realised that one of my colleagues was giving out the wrong person – in disbelief, astonishment and sheer anger I had them show me just how they were retrieving the information… and it turned out to be a perfectly easy mistak.

So, this colleague… he was using a method that I suspect a lot of people do and thus thought I’d write this wee observation. On checking the History of the Component you’re presented with a list of … well a list of stuff.

list of stuff about Component history

As you can see Item [2] would appear to be showing me just who has this bugger checked out… but does it?

On closer observation I see that the last two versions [1] are the same – meaning a minor version hasn’t been added (i.e. the person with this checked out has just checked it out … that’s it… checked out and gone home / on holiday / another place of employment – how rude).

Now note item [3] … this shows me the person that really has this checked-out. And you can see that the user ID x43 is not the same as Damian’s x77 as [2] lead us to rashly believe! It seems that the ‘user’ is actually ‘last user to save this item’ whilst the comment is the important one!

Is there an easier way…

You betchya… open the offending Component and look at the ‘Info’ tab. Here we can see the item is locked as it’s checked out and Tridion is telling us which user this is [1].

Straight-up Component info

There’s no confusion here and I was probably in the Component anyway – additionally I can copy the username form here to enter directly into the email system…

Regards the user IDs … Tridion isn’t obfuscating the user for some crazy-ass security reason but this is the info it gets from the client systems – I can live with this and more importantly I can easily hunt down and get the person to check the item back in (or undo-checkout).


Oh no, my Flickr ECL just stopped working!

Just a quick blog note on the ‘recent’ update by Flickr. Essentially they’ve removed support for http:// and only support https:// requests to the Flickr API – see the note from Flickr Code.

We utilised the excellent ECL Flickr Provider posted by Bart Koopman on SDL Tridion World and after making a tiny tweak all was at peace in the ECL Flickr world!

Simply update the http:// reference to https:// in the api\flickr.cs class, rebuild, deploy and view until your heart is content!

Special thanks to Harald Hoffelinck for working through this!

Issues with the TridionRsaContainer registration!


We’d copied a CM instance (VirtualMachine) from the PRD environment and placed this into the UAT environment, all configurations done as we’d tested and expected.

To avoid getting the error stating that the [clientUATdomain]\MTSUser does not have access to the tridion.security configuration setting we executed the TridionRsaContainer command

aspnet_regiis -pa "TridionRsaKeyContainer" "[clientUATdomain]\MTSUser"

This failed with the MTSUser. On confirming we had the correct [domain]/username/password and further investigation we found that no-one knew the actual account that had been used to install SDL Tridion 2011 CM. We needed this account so we could log into the UAT CM machine in order to give the MTSUser access to the tridion.security configuration setting. This is because this config setting is protected using this windows functionality : http://msdn.microsoft.com/en-us/library/yxw286t2(v=vs.100).aspx

We could see that file in question is actually a file in c:\programdata\microsoft\crypto\rsa

This file is accessible only to a small number of users (the production domain mtsuser had access to it). So we tried this:

  • log in on the PRD machine as the production domain mtsuser
  • export the rsa key via this command
aspnet_regiis -px "TridionRsaKeyContainer" keys.xml -pri

We then placed this keys.xml file onto the UAT CM box and then executed the import command

aspnet_regiis -pi "TridionRsaKeyContainer" c:\temp\keys.xml

and finally, the following command

aspnet_regiis -pa "TridionRsaKeyContainer" "[clientUATdomain]\MTSUser"

So, on booting up the CM Browser… boom… We got an error in the GUI after a quick dig into the respective ‘Tridion Configuration’ error in the Event system … we then executed

aspnet_regiis -pa "TridionRsaKeyContainer" "nt authority\network service"

Quick restart of the services and all is well again.

The motto of the story – DO NOT ‘LET SLIP‘ WHICH USER INSTALLED THE CM – especially if you want to clone the machine during a setup!

If you’ve had a similar experience we’d be very interested to hear if there are other ways around this – other than simply re-installing the CM with a noted user :)

Special thanks to Harald Hoffelinck on this solution!

DWT strings, integers and repeatable fields

I was reviewing a solution I’ve been working on and noticed that at one point I was pushing out a ‘QuantityOfListItems’ from C# into the package – and couldn’t recall why.

On further investigation I saw that I was using this in the DWT to detect when I was on the last list item so I could compare this with the TemplateRepeatIndex value. Although it all worked fine it felt like overkill to rely on C# for something so trivial and didn’t add any value so I had a scoot around.

I found a CollectionLength built-in function that looked like it might be just what the Dr. ordered…

So… the reason for the post… It took quite some phaffing to tweak the syntax for this – just due to the fact I’ve had my head in C# code more than I have DWT lately so I thought I’d share it!

All I need to do is check

  • if the current index of the item in the repeatable field is the first then print the opening tags
  • write out the repeated syntax/value for each instance of the repeatable field
  • if the current index of the item in the repeatable field is the last then print the closing tags
First attempt:
<!-- TemplateBeginRepeat name="Component.Fields.repeatField" -->
 <!-- TemplateBeginIf cond = "TemplateRepeatIndex == 0 " -->
 <!-- TemplateEndIf -->
 <!-- TemplateBeginIf cond = "TemplateRepeatIndex == @@CollectionLength("repeatField")@@" -->
 <!-- TemplateEndIf -->
<!-- TemplateEndRepeat -->

OK, so the obvious error – TemplateRepeatIndex is 0 based whilst the CollectionLength returns a 1 based  result! The other syntax is pretty standard so we’ll concentrate on the test for the last index item.

<!-- TemplateBeginIf cond = "TemplateRepeatIndex == @@CollectionLength("repeatField")-1@@" -->

No Joy. So I have another scoot around and find an interesting StackOverflow post reminding me the value returned is a string. As we need to perform an integer calculation and comparison we need to parse the value to an integer.

<!-- TemplateBeginIf cond = "TemplateRepeatIndex == @@parseInt(${CollectionLength("repeatField")})@@-1" -->

Now I’m using the debug method Frank van Puffelen describes in his StackOverflow posting and all appears well – I can see the CollectionLength and the TemplateRepeatIndex are both 1 and the end tag still isn’t written out.

See the deliberate error (well it wasn’t deliberate and it was one of those annoyingly simple things that I’m sure others will trip up on!).  Although our first comparison with TemplateRepeatIndex and == 0 above is with an integer and it works as we want (even if the comparison is against a non-zero integer) I figured I’d try to parseInt the TemplateRepeatIndex…

<!-- TemplateBeginRepeat name="Component.Fields.repeatField" -->
 <!-- TemplateBeginIf cond = "TemplateRepeatIndex == 0 " -->
 <!-- TemplateEndIf -->
 <!-- TemplateBeginIf cond = "@@parseInt(TemplateRepeatIndex)@@ == @@parseInt(${CollectionLength("repeatField")})@@-1" -->
 <!-- TemplateEndIf -->
<!-- TemplateEndRepeat -->


Hopefully this simple pattern can assist you in not having to resort to C# as I’d figured I had to originally.

“The” Navigation Debate

Please see below slides for the discussion we hope to have initiated in the Community Webinar held on the 14th March 2012.

Essentially, as a wise man once noted, there are as many ways of rendering navigation as there are Tridion Consultants… The purpose of this discussion is for us, as a community, to share and discuss our experiences.

Please feel free to post links to blogs with specific examples but ideally here we would have more of a discussion of why we would choose one method over another (implementation timescales, environment, editor requirements etc.) and whether, on reflection, previous decisions would be the same…

Let’s talk….