No Faking? Publish from a Parent Publication without Faking a Publication Target

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.

Add the parent publication as an allowed publication in the child publication's publication target.

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.

Select "Show Items to Publish" to see your items queued to the child publication.

Use target types, groups, and group scope to fine tune this to your needs. Thank Kelly for the insight.

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;
    RepositoryLocalObject repositoryLocalObject = (RepositoryLocalObject)item;
    currentPublication = (Publication)repositoryLocalObject.ContextRepository;
    // 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)

    // 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));

    // 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:

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

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>