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).
Unfortunately changing the Tridion content manager explorer is not for the faint hearted. Which made this exercise an ideal initiation rite for any intern lounging about hoping to be accepted as an employee of ‘the firm’. In the zip-file you can find his Odyssey including the patched files for Tridion 5.3 (Dutch). The files come from the \tridion\web\ folder on the CM server. They are not fit for any purpose use at your own peril (create a backup etc) and nobody, except perhaps the person installing these files, will be liable for any damages.
Kudo’s should be addressed to Oskar uit de Bos. If you think this is a useful addition to the Tridion content explorer please vote for the idea posted by Wouter van Vegchel and maybe sdl Tridion will implement it someday.
PS if you use a language other then Dutch you will need to add the following lines to your language file(\Tridion\web\Resource\####\ContextMenu.xml):
<resource id=”18000″ ref=”actFolderPublish”>Publish Folder</resource>
<resource id=”18001″ ref=”actFolderPublish”>UnPublish Folder</resource>
SDL Tridion sitemap/navigation rendering < 5s
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).
SDL Tridion Blueprinting elementary
Blueprinting is the name Tridion uses for creating a hierarchy of publications. Every publication in the hierarchy contains a specific website building block (XML schemas,content, templates, layout, applications). Each child publication inherits the building blocks of its parent(s). The publications lowest in the hierarchy are the publications where content, layout and applications come together and form a website. The building blocks inherited from a parent publication are read-only unless you “localize” (i.e create a local copy) them.
Choosing the right blueprint for your organization is critical to the success of a Tridion implementation. If you fail to get the blueprint right then future changes to it will prove to be very hard and the usability of the system very low. Even the initial implementation of a simple, one language and one channel, website will be a daunting undertaking and will remain a challenge during the entire product life cycle. Read more
-
About Albert te Boekhorst
This is the professional blog of Albert te Boekhorst. Albert is a Senior Consultant Webstrategy at Deloitte Consulting.
Powered by FireStats