Extending your online reach by targeting local audiences in their own language without compromising global brand consistency. This is what Tridion blueprinting is all about:
- Effectively managing your global message and allow local content editors to adapt and extend that message to incorporate cultural differences and local messages. This will maximize your impact on local markets and still keep the costs manageable.
- It enables reuse of web applications, cms templating and web design, for each sub site you create. This shortens the time to market for a new website considerably. A good example is the Equens Merger where 6 websites were created in record time.
- Content can be reused over different websites and channels. There are however some limitations to reusing content in Tridion which need to be considered when creating a Tridion blueprint (todo write about limitations).
In my previous article I showed an elementary blueprint which contained only one language and one website. The picture below shows what the blueprint will look like when an additional language is added.
Tridion uses a transactional publishing architecture which enables it to publish content to different websites or channels. To publish your content to a website or channel you specify a publish transaction which includes the publishing target and a date (and some advanced options). The publish transaction will then be placed in the publishing queue where the editors cant track the progress.
The interface enables users to publish their content to one or more predefined publishing targets. A publishing target can be a specific website or any other specific channel. If the user chooses more then one target to publish to, then the system will define a different publish transaction for each of these targets.
During the publish transaction the following happens:
- The content is retrieved from the content manager data store.
- The content is rendered using the appropriate component templates and page templates.
- The rendered content is sent to the Tridion deployer on the presentation server.
- If the first three steps succeed the CMS registers that the content is published to the specified target.
If the transaction fails for any reason this will show up in the publishing queue. A nice new feature in 5.3 is that double clicking on the “failed” tag will show you the actual error message that was written to the error log.
Unfortunately 5.3 also has a “bug” fix. As you might have noticed in my Tridion blueprinting article the content is not published from the publication where it was created. Usually it is published in one of the child publications. In previous versions (5.1) it was possible to publish the content directly from the parent publication. Now we have to add the parent publication to the publication target where the child is supposed to publish to. Not very logical and it adds a transaction to the publishing queue and subsequently slows down the publishing queue.
One common problem in Tridion implementations are “slow” publishing queues. The queue becomes “slow” when the publishing process is unable to handle all the publish transactions. This will frustrate the editors as they will need to wait longer for their content to show up on the website. I have identified the following reasons for that contribute to this problem:
- Rendering full pages can easily take up to 5 seconds. Which I think is an extraordinary long time for executing a few templates (simple programs). This becomes a problem when you have a lot of editors publishing content at the same time. Or when you need to republish your entire site (I have seen one example where it took 2 multi-core publishing servers 3 days).
- Rendering the sitemap through the Tridion API takes up a lot of resources. Consider using the rendering strategy from my article about fast sitemap generation in Tridion.
- Using SiteEdit in combination with automatic publishing. A lot of implementations use the Tridion event system to auto publish content to the staging environment on a component save action. SiteEdit saves a component regardless whether there are changes to the component or not. In doing so it will trigger a publish transaction every time an editor visits a page and has SiteEdit enabled on a staging website.
The solution to speed up the publishing process is by adding dedicated publishing servers to your Tridion setup. The real solution, in my opinion, can be found in speeding up the rendering process. I think Tridion should look into this.