As announced by SDL earlier this week – it’s here!
Just in case you’re week’s still too busy to read the full-monty here’s a few snippet to highlight the main ‘changes introduced’ in this new framework:
I promised myself I’d put something together after my first MVP Retreat but it’s taken me a while to ‘get over it’ (this is, of course, a reference to the amount of food that was eaten).
YES!
Why was it different this year (TDS2017)? And why should I go next year?
This year, as ever, was a festival of information packed presentations with lots of opportunities to network with developers and some customers too. Not only that – Content Bloom were the Diamond Sponsors so it was great to have a strong contingent from our various offices across the globe (including Nova Scotia, New Orleans, Belgium, UK, India, Czech Republic, Ukraine).
I know time’s precious so let me give you the summary – read on for the rationalisation!
An RTF field is exactly that – a Rich Text Field – it was never intended to facilitate how the combination of text and images are presented across multiple views in different devices; that is what we use CSS, HTML, JS and-the-like for.
Control’s important and should be in the hands of the people with the tool for the job. Tridion is an excellent content management system and affords editors with a multitude of tools to manage content across hundreds (if not thousands) of publications.
So, 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?
The first answer I hear a lot is
I don’t know exactly what to publish
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!
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.
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].
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).
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!
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
This file is accessible only to a small number of users (the production domain mtsuser had access to it). So we tried this:
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!
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
<!-- TemplateBeginRepeat name="Component.Fields.repeatField" -->
<!-- TemplateBeginIf cond = "TemplateRepeatIndex == 0 " -->
<ul>
<!-- TemplateEndIf -->
<li>@@Field@@</li>
<!-- TemplateBeginIf cond = "TemplateRepeatIndex == @@CollectionLength("repeatField")@@" -->
</ul>
<!-- 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 " -->
<ul>
<!-- TemplateEndIf -->
<li>@@Field@@</li>
<!-- TemplateBeginIf cond = "@@parseInt(TemplateRepeatIndex)@@ == @@parseInt(${CollectionLength("repeatField")})@@-1" -->
</ul>
<!-- TemplateEndIf -->
<!-- TemplateEndRepeat -->
Success!
Hopefully this simple pattern can assist you in not having to resort to C# as I’d figured I had to originally.