Author Archives: admin

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: Continue reading →

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:

  1. Tridion configuration -> timeout settings ->Seconds before a time out is generated when executing a long query
  2. MSDTC Admin Tools –> Component Services. Then Right click Computer –> Properties.
  3. 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>

  1. Please back-up your DB before attempting the following.
  2. 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”

SDL Tridion dynamic website performance

During one of my recent Tridion consulting assignments the client asked me about the performance difference between a website using a dynamic publishing approach vs a static approach. For he had concerns about the performance of dynamic websites. In the graph below you can see the difference the Google crawler noticed after a website, which consists mainly of article type content, changed from a static to a dynamic publishing approach. The left side of the graph shows the average time it took the Google crawler to download a page from the website (created by a well known Tridion implementation partner – not Deloitte) based on the static publishing model. The right side shows the average time it took to download pages from the exact same front-end, but with the back-end rebuilt based on the dynamic publishing model.

As you can see the average download times went down significantly. We have regularly seen the cached (home)page load within 100ms and uncached pages in double that time. The peaks that show up from the middle of December marked the go live of an application which was not fed with Tridion data and showed some mediocre performance until the first week of January.

The project of replacing the Tridion back-end for this particular website felt like killing my white whale. The website performance increase was an added bonus on top of the other improvements we realized during this project.

Why page load times matter:

SDL Tridion 2009 installation on windows 2008 64-bit

In a standard situation I would strongly advice against installing Tridion software yourself. It is far more efficient to hire a friendly Tridion application engineer to do the installation for you. The reason behind this is simple: They install Tridion on a weekly basis where I struggle to get one installation a year under my belt. Add to that the vast knowledge about known issues that Tridion has available in their knowledge-base and you will arrive to my conclusion.

That said it is useful to install Tridion yourself at least once. Installing Tridion will teach you a lot about the intricacies of the system which will prove useful when facing disturbances. Continue reading →

Outbound Google Analytics tracking on a WordPress RSS widget

Today I ran into the fact that outbound links from the standard WordPress RSS widget are not tracked by Google Analytics for WordPress. Unfortunately I have been unable to find a WordPress plugin for an RSS widget that does track the outbound links. However before embarking on a journey to create a widget with this feature myself, and finally add something to the community that gave me so much, I tried out the KB advanced RSS widget.

Fortunately this widet gives you control over the output it generates. This made it fairly easy to add the GA tracking code to the widget by replacing the code in the last text area of the widget with:

<li><a class=’kbrsswidget’ href=’^link$’ onClick=”javascript:pageTracker._trackPageview(‘/outbound/rss/^link$’);” title=’^description$’ >^title$</a></li>

Hope this will be of use to someone.

How to delete a publication from Tridion

Recently I came across a post (and a fellow Tridion blogger, keep up the good work!) which answered the question “Why won’t this publication delete?“.  It describes a tool (source code included) which helps you find the pages which you need to unpublish before you can delete the publication. It mentions two prerequisites which need to be met before you can delete a publication:

  • No pages in the publication are published
  • There are dependencies on the publication, child publications etc.

I would like to add a third prerequisite:

  • Check the publishing queue for publish transactions which belong to the publication to be deleted which have the status “in progress”.  In some instances publication transactions never leave this state and they will prevent you from deleting the publication.

In addition I would like to propose another way of ‘unpublishing’ all items in a publication (pages, components, MM components etc) by running the following query on the CM database (back-up the DB first) :
Continue reading →

Howto publish folders from SDL Tridion

In the Tridion cms content is being stored in folders. The folders are similar to folders in file systems, they contain both subfolders and components. However if you wish to publish the content of an entire folder you will have to traverse all subfolders yourself in order to select and publish the components manually. Not exactly a job for volunteers.

Fortunately there is something called the Tridion API which allows you to write a (power)tool which takes care of traversing a folder hierarchy and republishing all the content in it. This will reduce the effort of republishing an entire folder to an acceptable level and give any script kid a huge sense of accomplishment.

Alas a tool like this is not very friendly to the users of the Tridion cms. They will ask why it is impossible to publish a folder in the same manner they can publish a structure group. The answer to this question is unknown to me at this point in time. Perhaps one of the Tridion employees reading this blog can enlighten me on this subject (and approve my comments on ideas.sdltridion.com). Continue reading →

Publish XML or HTML from Tridion?

I created a small evaluation in order to make a substantiated choice between publishing XML or HTML from Tridion. I already assume that you made the choice between static and dynamic publishing Perhaps it will be of interest to someone:

XML HTML
Separating content and presentation / Re-usability of data.
Since the web application completely determines how or which parts of the XML content is presented, the same content can easily be displayed in different ways.		 + –
Tridion publishing Performance.
When publishing XML content, Tridion only needs to render one Component Presentation which will take less time then rendering multiple Component Presentations.		 + –
Maintenance and extension of Component Templates.
Your templates in Tridion will be simpler and thus easier to maintain. The complexity is transferred to the web application which is much easier to main then Tridion templates (try debugging or refactoring your code in Tridion).		 + –
Minimizing CMS development dependencies
Changes in the HTML templates will not result into changes of the CMS template code.		 + –
Presentation performance.
Rendering the XML into HTML on the presentation server will use more resources then displaying plain HTML.		 – +
Complexity of the web application
The web application will be partially responsible for rendering the content.		 – +
Grand total + –

SDL Tridion Dynamic component templates vs static Rendering

Tridion has two main methods for publishing information to websites:

  1. Publishing chunks of content to the Tridion broker
  2. Publishing whole pages to the file system.

Both publishing strategies have already been explained in previous posts. However the fundamental differences between both strategies deserves some additional attention.

Publishing chunks of content (dynamic)

In tridion chunks of content are called component presentations. For this publishing strategy the Tridion rendering tree is traversed until step 4. The result of the rendering is a chunk of XHTML/XML/plain text/ etc. which is subsequently published to the broker DB on the presentation server.

On the presentation server the broker DB will be queried by a website based on ASP, ASP .NET or Java which will use the pre rendered content to create a fully rendered page for the visitors.

Publishing whole pages (static)

In this publishing strategy the full Tridion rendering tree is executed. The result of which can be a file of any type, but usually has one of the following extensions: ASP, JSP, HTML, CSS, XML etc. To get the required results you will need to implement both Component Templates and Page Templates.

Which one to choose?

I recommend the dynamic approach. The static model is quickly becoming obsolete in an era of monthly  website updates and personalization at the top of everybody’s wish list.

A good illustration of why the static model is useless is an update we recently made to the navigation and layout of a website based on the static model (and NO it was not created by me or one of my colleagues). When you make changes to the templating in the static model in Tridion you will need to re-render all of the pages which make use of these templates. In this particular case there were over 2500 pages in the top publication which was blueprinted over 10 times and each blueprint contained an average of 500 local pages.

I needed to explain to the client on several occasions that the go-live was a ‘process’ which would take the better part of 3 days and three nights. The re-rendering of 30K pages would take approximately 60 hours. During this period the website would slowly go from the old look and feel to the new.

Feel free to share your views on this subject in the comments …