PageProvider capabilities

There has been some questions regarding why capabilities for a page provider are set through configuration rather than that the provider itself declares its capabilities through code.

First, it is possible to “ignore” the configured capabilities in your provider implementation. That is possible since you can override the virtual property Capabilities in PageProviderBase.

There is however a reason why capabilities are set through configuration rather than code. The reason is that there are some occasions where it is desirable to have the provider configured with less capabilities than it “technically” supports. One such scenario is when you have a setup with an dedicated editor site and other “read-only” public sites (just delivering content). In those cases it is practical to configure the page provider with no capability (same as read-only) on the read-only sites. Then the UI will automatically prohibit edit on those sites. And also if some code (e.g. through some web or wcf service) would try to edit content on that site it would throw NotSupportedException.

You can use this “feature” even if you are not using any custom page provider by declaring following in the config files for the “read-only” sites:

<pageprovider>
   <providers>
     <add name="default" type="EPiServer.LocalPageProvider,EPiServer" /> 
</providers>
 </pageprovider>

In that case the “read-only” site will run with the normal built in EPiServer page provider serving pages from the episerver database but the pages will not be editable through that site.