A critical vulnerability was discovered in React Server Components (Next.js). Our systems remain protected but we advise to update packages to newest version. Learn More


Feb 11, 2010
  6959
(0 votes)

Configuring page provider capabilities

Page providers requires some configuration. In addition to the obvious ones like name, type and entryPoint you should also define what capabilities your page provider supports, such as Create, Edit, Delete and Search. If you, for example, specify that your provider does not support delete, all delete related ui in edit mode will be disabled for your providers pages. More details on capabilities can be found in the Configuration section of the Page Provider Tech Note.

In almost all examples I have seen for page provider configuration, capabilities are specified in web.config. In my opinion, capabilities should not be defined in configuration. This could lead to, by accident, specifying more capabilities than what is actually implemented in code. I think the best place for this kind of configuration is code. Fortunately, the Capabilities property in PageProviderBase is virtual, which means you can override it and configure it there.

public override PageProviderCapabilities Capabilities
{
    get
    {
        return PageProviderCapabilities.Create | 
            PageProviderCapabilities.Edit | 
            PageProviderCapabilities.Search;
    }
}
Feb 11, 2010

Comments

Sep 21, 2010 10:33 AM

Good one Martin! I totally agree with you.
/ Tom Stenius

Sep 21, 2010 10:33 AM

This is not as good if you want to provide some reusable provider. When you override Capabilities property web.config settings have no effect at all. So someone else won't be able to suppress for example Delete or Create later. I think implementation should be like this:

Math.Min( base.Capabilities & (int)PageProviderCapabilities.Create,
(int)PageProviderCapabilities.Create ) |
Math.Min( base.Capabilities & (int)PageProviderCapabilities.Edit,
(int)PageProviderCapabilities.Edit ) ...
/ Vlad

Please login to comment.
Latest blogs
Looking back at Optimizely in 2025

Explore Optimizely's architectural shift in 2025, which removed coordination cost through a unified execution loop. Learn how agentic Opal AI and...

Andy Blyth | Dec 17, 2025 |

Cleaning Up Content Graph Webhooks in PaaS CMS: Scheduled Job

The Problem Bit of a niche issue, but we are building a headless solution where the presentation layer is hosted on Netlify, when in a regular...

Minesh Shah (Netcel) | Dec 17, 2025

A day in the life of an Optimizely OMVP - OptiGraphExtensions v2.0: Enhanced Search Control with Language Support and Synonym Slots

Supercharge your Optimizely Graph search experience with powerful new features for multilingual sites and fine-grained search tuning. As search...

Graham Carr | Dec 16, 2025

A day in the life of an Optimizely OMVP - Optimizely Opal: Specialized Agents, Workflows, and Tools Explained

The AI landscape in digital experience platforms has shifted dramatically. At Opticon 2025, Optimizely unveiled the next evolution of Optimizely Op...

Graham Carr | Dec 16, 2025