Let's Play What Published That (aka SDL Tridion Link Propagation)?

"Link propagation" or the SDL Tridion feature that causes items that use your item to be republished comes up frequently.

• Some ask about how to not publish pages when publishing content
• Or the status of linked components when unpublishing
• It gets interesting when unpublishing pages when mixing DCPs with static CPs
• Someone eventually notices that related items also get published
• But occasionally someone gets it (congrats!)
• Most recently the newer questions seem to get it so this post might be redundant until we forget how it all works.

I didn't really understand what published what even after a few years of Tridion experience. See my embarrasing comment to KnewKnow's post where I get it backwards. Most recently I explored the differences between (dynamic) components on a page and template's publishing component presentations with Bart Koopman on TRex.

The main take-away is when an author publishes a page, most of the content will update, even if it's dynamic. Publishing a component is tricky, because SDL Tridion will assume you want to update it everywhere it's used.

Here are the basic rules. Understand this and you might pass the SDL Tridion Business Analyst exam.

• By default publishing an item will republish the items that use it.
• Pages publish the dynamic presentations embedded on them.
• Dynamic components publish all presentations when published directly as well as items that use them.

But why would we want this?

Because items that use your item might display parts of your item. It's a good default, one that you can change with custom resolvers if needed. But before you do, understand this magically handles all of these scenarios:

• Update and publish an image to automatically queue publishing for the actual content or pages that display that image as well as any metadata you use from the multimedia component (e.g. "alt text")
• Publish a component and all dynamic versions are published, including full and summary versions, along with pages or components that might use parts of its text (assuming these link to or embed the component)
• Update a title and places it appears will also gets published (see below)
• Pages that aren't already published don't update with your component (see below)

It's tempting to assume this works the other way, that SDL Tridion published items your item uses or links to. It doesn't, you (probably) did. Specifically your template publishes items by using one of two API calls:

• AddBinary()
• RenderComponentPresentation()

See the third component presentation (blue component and gray template) below.

But since we use AddBinary() regularly (and sometimes RenderComponentPresentation()), it's easy to assume that publishing a page or component that links to images always publish the images, right? No, not always.

Frank van Puffelen explains the case for Multimedia and ways to address user expectations with the Binary Event Tracker, Will Price shows how this works with DCPs, and Bart Koopman answers a related question on StackOverflow. If you understand these posts, forget the BA exam, go for Architect, you SDL Tridion SME, you.

As a good practice for authors with pages that include lots of images, unless they're completely dynamic, publish the pages, not the images. Also don't assume you always need dynamic component presentations in the first place.

Why/when DCPs then?

Is an API call to publish content or images a Good Thing?

I would say so, because by default you'll publish images (using the Default Finish Actions Template Building Block), but you still have ultimate control over what your templates "publish."

• Place multimedia that your items or pages us. Or not.
• Publish changes to a page by publishing the page.
• Publish items used in several places in one request.

Maybe you want to publish DCPs and/or images that aren't even on your page or referenced. Create a "publish some DCPs" functionality from whatever indirect relationship (metadata, folder, naming convention, etc) that you can imagine but still makes sense for authors.  Don't get carried away here, but some scenarios to consider include:

• Publishing a set of images
• Reference "global" elements dynamically, but publish them at will, independently

After you understand what publishes what, if you still want to control what SDL Tridion will automatically add to the publishing queue, look at making custom resolver, if you know what you're doing. I would also add, if you know what SDL Tridion does by default.

Let's keep this simple.

1. Read this (login required) as many times as you need.
2. To remove content from static embedded scenarios, remove embedded or linked content and publish. Unpublishing will likely remove more than you wanted.
3. If your dynamic content is used by static content, be wary of unpublishing the content directly. This is akin to asking your friend to remove all the embarrassing Facebook pictures from last Friday night, but then wonder where all the pictures went.
4. If you don't want to publish images, don't.
5. Be very careful with mixing approaches for the same schema.
6. When talking about link propagation and the default resolving behavior, be clear on what's using what. It's not enough to mention "related items" or even "Where Used." There are three significant parts here:
1. Already published items that use the item you want to publish
2. Template logic that publishes component presentations or adds binaries
3. The removal of binaries no longer in use in delivery (this not the same as unpublishing them)

Okay, so maybe that's not simple. Let's try memes.

Link Propagation and Default Resolver Memes

Unpublish, especially for components is an "Oh sh*t" button. Think (or quietly scream to yourself), "remove this from the site everywhere! Abort! Abort!"

Publishing a component is a request to "update this everywhere it's used for the site." If it's used statically on 500 pages, then well, eventually you have to update 500 pages. Ever make a typo on a flyer and caught if after you printed? Are you surprised to learn you have to print the batch over? Just because something's digital doesn't automatically make it dynamic.

Publishing a page is a request to "update the page and the content on it." Items embedded statically get re-rendered into the (already-published) pages. Dynamic content also gets published (for that specific look-and-feel (DCP), but not with other templates--credit to Will Price for the explanation).

Instructions for authors:

• If you want to update something in some places, make the update then publish those places.
• If you want to remove content from a page, remove it and republish the page.
• If you want to change something everywhere, double check what's impacted (see items to publish), then proceed to publish the component.

I haven't explored (or confirmed) all the edge cases (types of links, differences between the API calls, if the type of template matters), but most of it is in the documentation. The important thing is to know when SDL Tridion is resolving items to also publish versus when you're adding items to the package. Then it's not Tridion, that's all you.

Propagate wisely. Publish pages. Share More.