Content providers

A content provider connects an Optimizely Content Management System (CMS) site to an external data source so that the data appears to be part of the CMS website, even though the data resides at the data source. You can build multiple custom content providers, consolidating the data into one CMS and giving users an integrated user experience. A content provider operates in the following ways.

• Data resides in original store – Integrates the data source with CMS; does not store the data in the local CMS website database.
• Requires coding and configuration – Registered content providers must inherit from ContentProvider configuration or registration of a content provider. Add a registered provider to ContentOptions.Providers, or through IContentProviderManager.
• IContent only – The information or data from a content provider appears as CMS content only.
• DefaultContentProvider technology – CMS uses the content provider concept internally; that is, DefaultContentProvider delivers the local pages and content served by the CMS database.
• Enable/Disable Content Provider Functionality – To move content between content providers, turn on special permissions in Admin view > Access Rights > Permissions for functions > Move between page providers. A warning dialog box displays when you attempt to move pages between providers.

📘

Note

You can display the data handled by the content provider only as EPiServer.Core.IContent instances.

You register and configure a content provider through EPiServer.Core.IContentProviderManager or through ContentOptions.Providers. See also Configure content providers.

Custom content providers and the ContentProvider class

Each registered content provider must inherit from the ContentProvider class that resides in the EPiServer.dll assembly. When you create a custom content provider, you must implement only one abstract method:

• LoadContent – Pulls out one specific content instance from the data store and returns it–an instance of an object that is implementing the IContent interface (such as PageData).
  You can override and implement many ContentProvider methods to offer more functionality to the content provider. The following methods are several examples.
• LoadChildrenReferences – Returns the content references for the children to one specific node. You should implement LoadChildrenReferences if the provider is registered with an entry point and displayed in the page tree.
• ContentResolveResult ResolveContent(ContentReference) – Supports permanent links from a ContentReference to a GUID and a Uri. Suppose the passed-in identifier corresponds to an identifier for content served by the content provider instance. In that case, this method returns the internal ("classic") link to the content and the Guid-based identifier for the content. You can construct the URI by the ConstructContentUri(contentTypeId, contentLink, contentGuid) helper method, which maps to PageLink, PageGUID, and LinkUrl properties for a PageData instance.
• ContentResolveResult ResolveContent(Guid) – Supports permanent links from a GUID to a ContentReference or Uri. If the passed-in identifier corresponds to an identifier for content served by the content provider, then the implementation returns the internal ("classic") link to the content and set ContentReference identifier. You can construct the URI by the ConstructContentUri(contentTypeId, contentLink, contentGuid) helper method, which maps to PageLink, PageGuid and LinkUrl properties for a PageData instance.