Just when you think you really know the ins and outs of SDL Tridion, surprise, here’s a neat trick from Kelly Thompson, 10 year+ Tridionaut and now Global Education Manager with SDL Web Content Management solutions.
Update (15-May 2012): This technique will push parent items through your child publication’s publication target. See Bart’s comment on how to prevent the extra items from being sent through (thanks, Bart!).
From a child publication’s publication target, set the parent publication as an allowed publication.
Now you can publish from a parent item even if its publication doesn’t have its own dedicated publication target.
Select the advanced publishing option to also publish in child publications. Selecting “Show Items to Publish” will show what’s queued for corresponding child publications.
Use target types, groups, and group scope to fine tune this to your needs. Thank Kelly for the insight.
Very good insight Alvin, the only thing I never liked about this is that the items for the parent publication are still rendered and send through to the Content Delivery side (where they are not needed, as we only need the child’s items).
Luckily there is a solution to that using ta custom Resolver, which you can use to strip out the parent items form the publish transaction so that they will never be rendered or deployed (or even appear as published for that matter).
Here is some example code for such a resolver (SDL Tridion 2011):
///
/// Resolver to strip out items from parent publication
///
public class OnlyChildPublicationsResolver : IResolver
{
///
/// For publish and unpublish, remove all items from the parent publication from the list.
///
/// Item to be resolved (e.g. a page, structure group, template)
/// Resolve instruction
/// Publish context
/// List of items that are currently to be rendered and published (added by previous resolvers in the chain)
public void Resolve(IdentifiableObject item, ResolveInstruction instruction, PublishContext context, Tridion.Collections.ISet resolvedItems)
{
List itemsToRemove = new List();
StringBuilder infoMessage = new StringBuilder();
infoMessage.AppendLine(string.Format(“Removed the following items from a {0} transaction to {1}:”, instruction.Purpose, context.PublicationTarget.Title));
Publication currentPublication;
switch (item.Id.ItemType)
{
case ItemType.Publication:
currentPublication = (Publication)item;
break;
default:
RepositoryLocalObject repositoryLocalObject = (RepositoryLocalObject)item;
currentPublication = (Publication)repositoryLocalObject.ContextRepository;
break;
}
// parent publication id (should come from a configuration)
TcmUri parentPublicationUri = new TcmUri(“tcm:0-2-1″);
// check for items from parent publication (these do not need to be published or unpublished)
foreach (ResolvedItem resolvedItem in resolvedItems)
{
// mark all items from parent publication for removal
if (resolvedItem.Item.Id.PublicationId == parentPublicationUri.ItemId)
{
itemsToRemove.Add(resolvedItem);
}
}
// remove all items that we need to discard
foreach (ResolvedItem itemToRemove in itemsToRemove)
{
infoMessage.AppendLine(string.Format(“{0}: {1} ({2})”, itemToRemove.Item.Id.ItemType, itemToRemove.Item.Title, itemToRemove.Item.Id));
resolvedItems.Remove(itemToRemove);
}
// log info mesage about which items have been removed
if (itemsToRemove.Count > 0)
{
Logger.Write(infoMessage.ToString(), “OnlyChildPublicationsResolver”, LoggingCategory.General, TraceEventType.Information);
}
}
}
Thanks for the catch, Bart. I updated the post with the caveat and mentioned the resolver.
This setup can still be useful in scenarios where you have control over the CMS settings and code, but not infrastructure. Setting up a publication target involves configuring servers, which you may not always have access to.
I totally agree Alvin, this is a very useful approach and I would actually recommend it over others. Even without the resolver it is still a good solution (I just think it becomes an even better one with the resolver ;o).