Dev GuideAPI ReferenceUser Guide
HomeDev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunityDoc feedbackLog In
GitHubNuGetDev CommunityDoc feedback

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 more than one custom content provider, 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/data from a content provider appears 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 also are 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 appears 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 [Configuring 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 thereby displayed in page tree.

  • `ContentResolveResult ResolveContent(ContentReference)` – Supports permanent links from a `ContentReference` to a GUID and a Uri. If the passed-in identifier corresponds to an identifier for a content served by the content provider instance, then 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 a 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.