Sharing Dynamic Content-Type Definitions Across Portals and Apps with Ghost Content-Types (400)

Dynamic Content-Types are extremely flexible. In advanced scenarios you want to share ONE type definition across multiple portals or apps - for example when many sub-portals have a similar setup. 2sxc has supported this since version 5 and in 8.1 there is finally a web-UI to do this.

Common Use Cases For Sharing Content-Type Definitions

1. When you have have many portals which are very similar - like in a franchise - then each sub-portal may need a lot of freedom in managing the content, but you want to keep a central definition of content types
2. When you create a News-App which exists in many portals and want to collect all news from all portals to show on the home-portal. In such cases you want to be really sure the content-type is always the same.
3. When you have a complex, often-changing content-type - like Catalog-Item - and want to use it across multiple portals

In summary, sharing a content-type is when you have different data-items = entities across various systems, but they should all adhere to the same schema = content-type. 

Basics of Shared (Ghost) Content-Types

To share a content-type across any kind of system borders - so across Apps or even across Portals (aka Zones) you need:

1. The original (master) content-type which you can create anywhere, but usually will create in a portal/app which you regard as the Master-System. 
2. One or more Ghost-Content-Types inheriting the main definition - in other Apps and Portals

If you want to know more about Ghost Content-Types, check out this blog.

Setting it up

Creating the Master Content-Type

Basically you can do this wherever you want - and it doesn't require any extra steps. So create a content-type and you're ready. 

Note that Master-Types have implications on many aspects like export/import, because as soon as you share content-type definitions across system-part-borders, the system that uses the master will not work without it. So the master becomes very important (for example: you shouldn't delete it) and changing it will always have further consequences. Because of this I recommend treating master-types with reverence. For example, I recommend that the master-definition has no content-items. 

Recommended Setup (Best Practices)

1. In most cases I recommend that you create a portal which contains only master-data, in this case master Content-Types. Give this portal a name like "Master Schema" or "Master Content-Types" just so people working on this will not make the mistake of changing things quickly. 
2. I also recommend that the master definition does not contain content-items. So I would not create a master News App and put data in it, but create a Master News App with the content-type, but without data. This again will ensure that a future editor will realize that this is a special use case and not just fiddle around it with.

How to find the internal Static-Name of the Master

1. Go to the master content-type, click on the edit-definition button
2. In the definition, hit Ctrl+Click to see the Static-Name in the Advanced Mode
3. The static name is usually a GUID - copy it into your clipboard, you'll need it.

This all will look a bit like this:

Creating the Slave (Ghost) Content-Type

Starting with 2sxc 8 this is easy to do in the UI. Here are the steps to do it.

1. Go to the data-management of the target (where you need to inherit the original content-type)
2. With Ctrl+Click anywhere, change into the Advanced Mode
3. Now, click on the new Ghost button to create a ghost, paste the original static-name and click ok - like this:

Errors you may get

Sharing Content-Types is a very advanced functionality so 2sxc checks various things before it creates the ghost. Common errors are:

1. If the master doesn't exist yet, it won't work.
2. You have multiple master types with the same GUID. This can happen if your master is an App you installed in many portals - then the GUID of that content-type would be the same in many Apps. 2sxc protects you from this as it could cause trouble later on. So if this is your issue, then go to your one-and-only master and give it a new guid - you could generate one in the online GUID generator.
3. If your current App contains the master-type, then 2sxc will not allow you to create the shadow/ghost in the same App. This is a "don't shoot yourself in the foot" kind of thing

To find out which error is the most likely, best look in the JavaScript console. 

Understanding Export / Import

Export-import of the master-app will behave just like always. 

Export/Import of a Slave-App which inherits the master content-definition works as follows:

1. The exported App-package will contain a reference to the original Master-Type. It will referr to the Static-Name (usually the GUID) of the master.
2. Because of this, you can create a "slave" App - for example a Franchise-News App - which shares definitions. The export will again contain a reference to the master, so re-importing it in another portal will work, and will also reference the master-type.

If an import would ever find multiple possible master-types (this shouldn't happen, but you could shoot yourself in the foot if you want to) then the import will reference the first = oldest undeleted content-type in the DB with this static name. So everything would work, but you could run into strange aspects in the future. 

Updating the Master Content-Type

This is very easy and works like any content-type definition change. There is one thing you'll have to know though: The slave Portals/Apps have cached the original definition and won't know about the change till the cache is re-loaded. This happens whenever data changes (in the slave App) or the entire DNN refreshes the cache. So in general we advise that you quickly refresh the entire DNN cache when you make changes to your master content-type.

Love from Switzerland,
Daniel