Configuring Block Types

By Optimizely Education
Published: Feb 11, 2026
Rating 1 star 2 stars 3 stars 4 stars 5 stars

Average rating: 0 No reviews

Outline

At a glance

Registration core: ContentTypeAttribute handles GUIDs and UI categorization for system-wide consistency across environments.
Field control: Display and validation attributes govern editor experience, localization, and search indexing behavior.
Architectural guardrails: AllowedTypes restricts content areas to specific blocks, preventing layout drift and content bloating.
Rendering choice: Decoupled architecture supports lightweight Partial Views or logic-heavy asynchronous ViewComponents.

Configuring block types in Optimizely CMS 12 involves defining metadata, property behavior, and rendering templates to ensure a performant and governed editorial experience. The configuration is primarily handled through .NET attributes, which are processed during the system initialization to synchronize the code-defined model with the CMS database.

1. The ContentType Attribute

The ContentTypeAttribute is the primary mechanism for registering a Block Type. It defines how the block appears in the CMS assets pane and how instances are categorized.

Mandatory and Critical Metadata

GUID: A unique identifier for the content type. It is essential to explicitly define GUIDs to ensure consistency across different environment deployments (Integration, Pre-production, Production).
DisplayName & Description: These provide labels and help text for editors in the "New Block" creation dialog.
GroupName: Categorizes block types in the creation UI, facilitating easier discovery in large enterprise systems.
AvailableInEditMode: A critical governance setting. Setting this to false prevents editors from creating standalone shared instances of the block, effectively restricting it to be used only as a property on a page.

[ContentType(
    DisplayName = "High-Impact Teaser",
    GUID = "f7a2b3c1-4d5e-6f7a-8b9c-0d1e2f3a4b5c",
    Description = "Used for homepage banners and cross-site promos.",
    GroupName = "Editorial Components",
    AvailableInEditMode = true)]
public class HighImpactTeaserBlock : BlockData
{
    // Property definitions
}

2. Property-Level Configuration

Individual properties within a block are configured to control data entry, localization, and technical metadata.

The Display Attribute

This attribute controls the presentation of the property in the "All Properties" edit view.

Name: The label shown to the editor.
Description: Contextual help/tooltips for the editor.
GroupName: Places the property within a specific tab or heading in the UI.
Order: Determines the vertical placement of the field.

Localization and Validation

CultureSpecific: Marks a property as translatable. When enabled, editors can provide different values for each enabled language.
Required: Enforces data entry at the database level.
Searchable(false): Prevents property data from being indexed in Optimizely Search & Navigation if the data is purely technical or structural.

[CultureSpecific]
[Display(
    Name = "Top Heading",
    Description = "Capitalized title for the teaser component.",
    GroupName = SystemTabNames.Content,
    Order = 10)]
[Required]
public virtual string Heading { get; set; }

3. Editorial Governance through AllowedTypes

To maintain architectural integrity, it is necessary to restrict which blocks can be utilized within specific areas of a page. The AllowedTypesAttribute is used on ContentArea properties to enforce these rules.

Performance and Architecture Governance

By restricting a ContentArea to only allow specific block types, the system prevents "content bloating" and ensures that the layout remains consistent with the designed components.

public class LandingPage : PageData
{
    [Display(Name = "Lead Components")]
    [AllowedTypes(typeof(HighImpactTeaserBlock), typeof(HeroBannerBlock))]
    public virtual ContentArea LeadArea { get; set; }
}

4. Technical Rendering Configurations

In CMS 12, block rendering is decoupled from the data model. There are two primary patterns for configuring how a block type is displayed to the end-user.

Partial Views (Lightweight)

For blocks that only require basic HTML rendering with no complex logic, a conventional PartialView is the most performant choice. The system automatically searches for a view naming convention matching the block type (e.g., _HighImpactTeaserBlock.cshtml).

ViewComponents (Logic-Driven)

For blocks requiring dependency injection, database lookups, or external API calls, a ViewComponent is required. This allows for asynchronous execution, which is vital for maintaining high performance in a PaaS environment.

public class HighImpactTeaserBlockViewComponent : BlockComponent<HighImpactTeaserBlock>
{
    protected override IViewComponentResult InvokeComponent(HighImpactTeaserBlock currentContent)
    {
        var viewModel = new TeaserViewModel(currentContent)
        {
            // Logic to calculate dynamic data
        };
        return View(viewModel);
    }
}

5. Metadata and Grouping Best Practices

For enterprise-scale CMS implementations, grouping configurations into logical hierarchies improves both the developer and editor experience.

Tab Names: Use constants or SystemTabNames to ensure properties are grouped into logical UI sections like "Content," "SEO," or "Advanced Settings."
Initialization Modules: For global configurations that apply to multiple block types, use IInitializableModule to programmatically adjust metadata or register custom validation rules during startup.

Conclusion

Effective block configuration in Optimizely CMS 12 requires a synthesis of metadata definition, strict editorial governance through attributes, and optimized rendering selections. By explicitly defining GUIDs, implementing AllowedTypes restrictions, and utilizing asynchronous ViewComponents for logic-heavy blocks, technical teams can ensure a scalable architecture that remains maintainable as the content model grows.