SDL Tridion Troubles
This post is a Response to “Rants on Tridion Implementations” which I ran into on my Sunday evening round of blog reading. In this post Nuno L rants about the burden of fixing broken Tridion implementations. We seem to be in the same business and I would like to share my perspective on this subject. I strongly diasgree with “my job is not always an easy or necessarily happy one”. In addition when I (please read the rant of Nuno first) walk into a project it means your Tridion Troubles are over. I love to fix things that are broken or find a solution to problems other people have given up on. To see despair turn to optimism and see smiles on the customers face always makes me feel happy with my job. Though I have to admit I find that the best part of fixing the impossible is the bragging rights afterwards.
In the language debate I would like to make a stand for reduction in the number of languages/technologies needed to implement Tridion. The cost of maintaining different development environments alone should be enough reason to want to limit the number of languages and technologies.
That said I would also like to vent about the most unintelligible Tridion troubles I have come across: Read more
SDL Tridion (5.3) deleting large publications
Recently I had the possibility of fixing one of my customers blueprinting structures which was of questionable quality. The change involved phasing out twelve large publications filled with all types of content imaginable. Of course I used the tips&tricks from a previous post on this topic which handled the ‘unpublishing‘ of content. However I quickly ran into problems which were the result of the time needed by the application to delete the publication.
The publications had been in use for over 4 years and a lot of content had been accumulated in them. In order to be able to delete these publications I had to set a number of timeouts to > 600 seconds. The following might prove useful if anybody attempts a similar clean-up:
- Tridion configuration -> timeout settings ->Seconds before a time out is generated when executing a long query
- MSDTC Admin Tools –> Component Services. Then Right click Computer –> Properties.
- IIS “script time out” error in Active Server Pages.
After these changes I was able to delete most publications and in addition serve a lot of coffee to my colleagues. Unfortunately some publications had not yet reconciled with their fate and refused to be deleted throwing all kinds of incomprehensible errors. I found the following solution to this problem:
<content disapproved by Tridion support>
- Please back-up your DB before attempting the following.
- Run the Stored procedure: EDA_PUBLICATIONS_DELETE using the publication id as parameter.
</content disapproved by Tridion support>
XSLT templating Tcm Script Assistant
I have to admit I am an XSLT junky. It seems to be useful for almost anything. From transforming Enterprise Architect models to full blown reports or simply adding sequential numbering to data dictionaries. My XSLT skills have proven to be a huge time saver on many occasions. The only flaw in XSLT is its readability.
In a rare bout of regression to my very first project role. I got down and dirty with some of the finer points of the SDL WCMS XSLT Component Templating. Specifically the part of using the Tcm Script Assistant in XSLT. From this experience I would like to share my most valuable lesson learned: Do not forget to cast the xslt node text to a string. Hopefully the code below will prove beneficial for someone running into a similar challenge:
<xsl:template match=”Content:photo”><xsl:element name=”=”{local-name()}”><xsl:value-of select=”tcmse:PublishBinary(string(@xlink:href))”/></xsl:element></xsl:template>
The error I received was: “Error occurred during a call to property or method ‘PublishBinary’”
PS do not forget to declare the tcmse namespace: xmlns:tcmse=”http://www.tridion.com/ContentManager/5.1/TcmScriptAssistant”
