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 – The data is not stored in the local CMS website database; the data source is integrated with CMS.
• 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 displays as CMS content only.
• DefaultContentProvider technology – CMS uses the content provider concept internally; that is, the local pages and content served by the CMS database are also delivered through a content provider: DefaultContentProvider.
• Enable/Disable Content Provider Functionality – To move content between content providers, special permissions must be switched on 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 content provider that is registered with CMS 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 setsContentReference 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.