12

What level/Types of scalability we achieve by creating the empty root publication in Tridion blueprinting? Though question may be very basic but each one can give a certainly different view of scalability so i am asking it over here.

1
  • Lots of great answers, but as a practical recommendation, new branches, implementations, or sites don't always mean a new complete branch of publications. Share what needs to be shared, split as needed, and don't hesitate to use authorization to help with what authors see in lower publications. Given a new website requirement for example, my first thought isn't a new schema or content publication (though it may fit the circumstances). Commented Jul 2, 2013 at 3:47

4 Answers 4

11

Keeping in mind that you cannot add a publication on top of a "root" publication, but you can always add publications between 2 existing ones, this layer is there really just to make sure you have the flexibility to add additional layers between "Root" and "Schemas" if you ever need to.

A common scenario nowadays is to have a separate set of schemas for mobile channels. You can do one of the following 3 options:

  • Create your mobile schemas in the same publication as your normal content schemas
  • Create a child publication of "Schemas" where you create your mobile schemas
  • Create a child publication or "Root" where you create your common schemas, move "Schemas" to be under this one, and create a "Mobile-specific Schemas" publication under this one too.

Even if the example is not perfect (I should add diagrams and such), the 3rd option would not be possible if you had created all your schemas on the top publication.

I guess the best way to describe that publication is "one day you may wish you had it".

1
  • +1 to the "wish you had it" point. I'd say mobile works as an example for 2013. I'm sure future versions of Tridion may look at the mobile=publication(s) equation differently. ;-) Commented Jul 2, 2013 at 3:32
9

If you put content or schemas into the root publication, then all of that is inherited down, whether you need it or want it or not.

I always saw "Empty parent" as a fail safe. If you suddenly needed to manage a new group of sites with a different content model (say from a company acquisition), you could do so nicely by splitting off from the empty publication without impacting anything already existing.

2
  • +1 for the company acquisition point. This may also happen when the same company creates then wants to merge separate Tridion instances. Commented Jul 2, 2013 at 3:34
  • But of course, you might equally just create an entirely new master chain under such circumstances. If you really have an entirely different model, this would be better. Commented May 10, 2014 at 9:06
8

The empty parent or empty root Publication by itself doesn't add any features, but when you make sure that any new Publication you create is a child of that, then you have made sure that all your Publications are part of a single BluePrint, which allows you to move the Publication anywhere inside that BluePrint.

It basically comes down to the features of BluePrinting, you can only create a Publication as a child of another at first creation time, if you don't do it at first save, then you can never add it to a BluePrint anymore. So to allow you to do that, you will need an empty parent (which because it remains "empty" has no influence other than being your BluePrint parent).

2
  • Empty Parent, as the first publication does have minor control over the set of "default" items. Commented Jul 2, 2013 at 3:30
  • true, but if you truly consider them as default items, then every Publication will need them anyways, or gets them anyways Commented Jul 2, 2013 at 8:37
3

To generalize, you can visualize your Blueprint hierarchy as a Tree with Empty Parent being the Root of this Tree. This Empty Root will allow you to stretch another branch which may or may not have any dependency on the Existing tree.

To be specific: Consider below scenario where you already have an existing blueprint hierarchy with multiple websites for a brand/company/service, and later on in the future you come across any of the below scenario:

  1. A need to create a completely isolated Mobile Site
  2. There is an acquisition/take over of organization which may have entirely different verticals and you want to put the site for it in the same architecture
  3. One architecture for a big organization with a diversification of product range and for each product you may need to put up a site

Most basic error that I have seen people misusing the Empty Root is when they become a part of such a big implementation where the Blueprinting, Architecture etc are done and few site have already been rolled out and they are required to implement a new site without affecting the already rolled out site - Instead of understanding the existing system, they on the safer side stretch a new isolated BP hierarchy and go ahead with their implementation - do not do it

2
  • You can say it's a basic error to create a separate blueprinting chain, but that's only true in situations when creating a new chain is a worse choice than using the existing one. Commented Jul 1, 2013 at 19:26
  • Absolutely Dominic! There could be different scenario when you are not left with a choice but to create a new chain, but in many cases this might not be the case Commented Jul 2, 2013 at 2:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.