Albert te Boekhorst

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) :
Read the rest of this entry »

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). Read the rest of this entry »

Most websites use some form of sitemap xml for rendering the navigation blocks. In Tridion implementations this sitemap is usually rendered from the folder structure created by the content editors. The established way of doing this is by creating a component template which calls the Tridion API repeatedly and traverses the folder tree. Unfortunately opening a lot of folders and components through the Tridion API is a time and resource consuming activity.

A traffic jam might occur in the Tridion publishing queue if you use the API for rendering the sitemap.

The method of traversing the tree will work fine if you have just one website in Tridion and not too many folders and components which need processing. Unfortunately most companies purchasing Tridion host more then one small website. Typical Tridion clients will manage the content of up to 50 websites in Tridion with thousands of components and folders per website. Most of these implementations suffer from a performance penalty in publishing content as a result of slow sitemap rendering.

In one implementation we needed to generate 13 sitemaps with a rendering time of 10-12 minutes each. With both a staging and live website (a typical tridion production setup) needing a new sitemap at least once an hour this meant the rendering of 26 sitemaps per hour. Needless to say that this would put a huge strain on rendering resources.

The solution to this problem is in NOT using the Tridion API for rendering the sitemap. In the case mentioned above I created a program which queried the filesystem of the presentation server. The program is capable of rendering the sitemap in well under 5 seconds. Which is roughly 100 times faster then the alternative. On the staging server the program runs every minute to give the content editors a near realtime experience. On the live server it is scheduled to run every 5 minutes.

The drawback of taking resources from the presentation server can be remedied by running the program on the lowest possible priority. When running in low priority the program will only use the idle time of the presentation server for rendering the sitemaps.

Other options:

• Querying the Tridion broker DB. To do this you need to make sure that every component knows its parent. This option can be used for websites using a dynamic publishing strategy.
• Maintaining the sitemap via the Tridion event system (not recommended, I will go into detail on the event system some other time).