How can I best use the Tridion Broker as the single source of content for multiple web sites?

Question

I am working on this Tridion implementation that has a bunch of very different websites, but some content (like news) is shared via the basic Tridion principle of blueprinting. Sites are all in the same language, so we are only dealing with branding differences.

Current situation: There is a publication called Global content in which this global content is created. In the schema there are some checkboxes where a child publication this content should appear can be selected. When the component is saved the event system kicks in and creates pages with the components on it, publishes it, etc... deletion of the components doesn't happen, only a resave with all checkboxes unchecked will eventually via a batch process remove pages.

Broker situation: I would like to start using the broker. More so, because in the future situation the website(s) will also start sharing more content to external websites, which I was going to do via RSS feeds or a basic API, which works best with content from the Broker.

The scenarios:

1. Allow this global content publication to publish dynamic content, and on the other sites pull that content straight from the Broker (with the Global Content Publication ID?)
2. Make a fake empty target in Global content so they can say "publish/unpublish to all child publications?" (You can still use the checkboxes to allow it to publish in certain publications)
3. Use a Global Content website for publishing dynamic content and create the API/RSS feeds for internal and external websites to use?
4. Something else?

My initial thought goes out to the first scenario, but I can see the main drawback that it would become more difficult to mix local(ized) news items and global news items.

The second scenario seems to be the second best chance. Anyone has experience with an implementation like that?

Answer 1

On the implementation I'm currently working on we are using something like the second solution. I added the website master publication (in which we create all pages) to the publication target we use for all the websites so we can use publish to all child publications from there. If it fits in your model I would prefer this option as it continues to give you the control over the items by localization in child publications.

Since we didn't feel like having the content rendered on the website master publication (as this isn't going anywhere and will just be a waste of my publisher processor time and then also a waste of broker storage when it gets deployed), we created a ChildOnlyPublicationResolver (SDL Tridion 2011). In this resolver we loop through all resolved items, and if the item comes from the website master publication, we remove it from the list.

The outcome is that you will see the website master publication appear in the publish queue, but it will be set to success almost instantaneously since there is nothing to render in it. So it doesn't take up any performance from the publisher nor is it deployed, but you keep the benefit of your child publications and have an easy way to publish them in one go.

If interested, here is an example for the resolver code:

using System.Collections.Generic;
using Tridion.ContentManager;
using Tridion.ContentManager.Publishing;
using Tridion.ContentManager.Publishing.Resolving;

namespace SDL.Example.Resolvers
{
    public class ChildOnlyPublicationResolver : IResolver
    {
        /// <summary>
        /// Master Publication TCMURI
        /// </summary>
        private const string MasterPublicationTcmUri = "tcm:0-2-1";

        /// <summary>
        /// For publish and unpublish, remove all items from the master publication from the list.
        /// </summary>
        /// <param name="item">Item to be resolved (e.g. a page, structure group, template)</param>
        /// <param name="instruction">Resolve instruction</param>
        /// <param name="context">Publish context</param>
        /// <param name="resolvedItems">List of items that are currently to be rendered and published (added by previous resolvers in the chain)</param>
        public void Resolve(IdentifiableObject item, ResolveInstruction instruction, PublishContext context, Tridion.Collections.ISet<ResolvedItem> resolvedItems)
        {
            List<ResolvedItem> itemsToRemove = new List<ResolvedItem>();
            TcmUri masterPublicationUri = new TcmUri(MasterPublicationTcmUri);

            // check for items from master publication (these do not need to be published or unpublished)
            foreach (ResolvedItem resolvedItem in resolvedItems)
            {
                // mark all items from website structure publication for removal
                if (resolvedItem.Item.Id.PublicationId == masterPublicationUri.ItemId)
                {
                    itemsToRemove.Add(resolvedItem);
                }
            }

            // remove all items that we need to discard
            foreach (ResolvedItem itemToRemove in itemsToRemove)
            {
                resolvedItems.Remove(itemToRemove);
            }
        }
    }
}

Answer 2

In a traditional Tridion architecture, your best bet might have been to inherit through the BluePrint. This would mean having the content available in all the broker in all publications, and determining which items to show from the metadata.

As Bart has suggested, there are some wasteful aspects to this design, so you might rather think in terms of the global content being "federated" from a single web site. This is what the Content Delivery web service is intended for. If you are on Tridion 2011, you can effectively choose your option 3, but with more out-of-the-box support than used to be present, so you wouldn't have to build the API, just consume it.