7 thoughts on “No Faking? Publish from a Parent Publication without Faking a Publication Target”

1. 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);
   }
   }
   }

2. 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.

3. 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).

4. How does this “hack” work when your SDL Tridion license limits the number of Publishable publications (number of publications from where you are entitled to publish)?

5. I understand the publishing publication restriction is just on which publications represent “real” sites. The parent publication doesn’t have a site, so it should technically be okay. When in doubt check with Support and maybe your sales contact.

6. I tried out Barts resolver from SDL Tridion World, and it worked. I was not quite satisfied however as you still get an item in the publishing queue for the parent publication which could be confusing for Editors. This got me thinking that maybe a better approach is simply to use the event system to delete any publish transactions that are created for the parent publication. This is quite simple and works well. You can find a code example at: https://gist.github.com/willprice76/9639405

7. After some testing, there is always a Warning in the event log with the Event System only approach. If this is not acceptable in your environment, you will need a resolver + event system solution to have a ‘clean queue’ result. You can use the resolver here: https://gist.github.com/willprice76/9664092 and the above linked event system, but you will need to add a check that the transaction status is success before deleting (otherwise the publisher will still be busy with it and give the warning).