Yet Another Tridion Blog

This week's TBB is about resolving Component links statically - i.e. at publish time. This is considered terribly bad practice , but sometimes, in the field, it is just what the custmer needs. It really goes against every Tridion principle and it will make the website completely inconsistent (e.g. dead links cannot be prevented). However, if you need to do it, this it how. The code below reads the 'Where Used' Pages for a Component. It takes the Page publish location URL and constructs a 'static' link to the Page. It will not even check if the page is published. public string ResolveLinkStatic( Engine engine, Package package, Component component) {     if (component.BinaryContent == null ) { // is Content Component         XmlElement node = component.GetListUsingItems(             new UsingItemsFilter (engine.GetSession()) {       ...

This topic touches on hot Tridion practices, both of them debatable: Publishing from Template code; Impersonating a user in Template code; I won't go into the debate (maybe I'll write about it at a later stage). I will just say that I don't find it bad practice to impersonate in templates, hence the code and topic below. The use case for "publishing from template code" comes mainly when dealing with Multimedia Components that need to be published also as Dynamic Component Presentations (DCPs). If they weren't publish from template code, you would either have to publish them manually or from some event system. I think both alternatives are clumsy and less suitable than the publish from template code. So, my requirement is to issue a Publish on a given Tridion item from template code. The publish should have the same properties as the original item (the one currently being rendered by templates). So, the same target, user, and priority. First,...

We should all know by now that passing an empty (aka Null TcmUri) as PageUri when resolving a Component Link is very bad practice. The reason -- this kind of link resolving is not cached. So, in case you are using a Content Delivery DB, you will make a trip to the DB for every single Component Link resolving. I have written an older article available here on SDLTridionWorld , about solving these issues, but that's about old school templating. This post presents the mechanism to use when writing Compound Templates. So, I have a DWT TBB that generates some output for an RTF field. Something like @@Component.Fields.Paragraph@@ . I have some ComponentLinks in the RTF field. The templates runs on a DCP and it generates a TCDL link like this: <tcdl:Link type="Component" origin="tcm:0-0-0" destination="tcm:37-968" templateURI="tcm:0-0-0" linkAttributes="" textOnFail="true" addAnchor="false" variantId...

Let me start by saying that I am a strong believer that handling, uploading or publishing CSS or JS files as Multimedia Components is bad practice . At the same time I was recently surprised that opinions are actually quite different on the topic. There are people who don't always agree with me, shocker!!! So I guess the point of this post is just to present the advantages/disadvantages of the two methods and see which you like best. Make that one best practice :) Multimedia Components In this approach, CSS or JS files are uploaded into Tridion as MMComponents based on a MMSchema. This is the default way the Dreamweaver mediator handles references to CSS or JS from an HTML (.dwt) document. Advantages: speed - easy to upload into Tridion, without having to create additional items like Schemas, Components, CTs, PTs, Pages; easy to understand - developers with little Tridion experience understand this approach easier; out-of-the-box - this is the default way the Dreamwe...