- 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.
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:
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.
- Publishing a set of images
- Reference "global" elements dynamically, but publish them at will, independently
Let's keep this simple.
- Read this (login required) as many times as you need.
- To remove content from static embedded scenarios, remove embedded or linked content and publish. Unpublishing will likely remove more than you wanted.
- 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.
- If you don't want to publish images, don't.
- Be very careful with mixing approaches for the same schema.
- 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:
- Already published items that use the item you want to publish
- Template logic that publishes component presentations or adds binaries
- The removal of binaries no longer in use in delivery (this not the same as unpublishing them)
Link Propagation and Default Resolver MemesUnpublish, 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.
Propagate wisely. Publish pages. Share More.