FAQs for CMS v13.0.0

CMS 13 is the next major version of Optimizely's content management system, designed to help marketing and digital teams create, manage, and optimize content using AI-driven workflows and a modern content architecture.

Key capabilities include: Opal AI agents for content creation, optimization, and governance; Optimizely Graph for unified content retrieval and semantic search; Visual Builder for page creation and preview; Embedded DAM for asset management; and External Content to connect third-party systems.

CMS 13 helps teams move faster with AI-assisted workflows and built-in content creation tools while maintaining quality and governance. It enables organizations to build on any frontend architecture, produce content faster with AI agents, create and personalize pages without developer dependency, connect content and data across systems, and improve discoverability across search and AI-driven channels.

CMS 13 is the PaaS version of Optimizely's CMS. PaaS allows full control of the application, custom code in the process, and deployment flexibility. With SaaS, Optimizely manages all of that. The SaaS model does not allow custom code running in the process. Optimizely refers to its SaaS offering as "CMS SaaS."

CMS 13 is scheduled for general availability on March 31, 2026.

CMS 13 is best suited for organizations that manage large volumes of content, need faster publishing workflows, want to adopt AI-driven content creation, operate across multiple systems and channels, and require scalable infrastructure for global experiences.

CMS 13 focuses on modernizing the CMS platform. It does not replace external analytics or experimentation platforms, specialized third-party search platforms, or dedicated SEO/GEO platforms. These can still be integrated through APIs and connectors.

CMS 13 is an opinionated move toward a Graph-first, headless-capable platform. Graph is now mandatory and included in the license, and many headline features such as Content Manager, Content Variations, the new C# SDK, that depend on it.

That said, the upgrade still delivers meaningful improvements. Visual Builder replaces on-page edit as a modern, unified editing experience that works with server-side MVC rendering without requiring Graph. The move to .NET 10 ensures long-term Microsoft support. Editors benefit from auto-translation with structure preservation, content templates and blueprints. Developers get a full REST API included by default and a cleaner multi-site management model through the new Applications concept. There are also security hardening improvements around file uploads and user management.

For clients not planning to adopt Graph, the upgrade is more about future-proofing and editorial quality-of-life than unlocking transformative new capabilities. The biggest features remain on the table until Graph is embraced.

CMS 13 requires .NET 10.

CMS 13 is built on .NET 10 (LTS). While CMS 12 supports .NET 8, moving to CMS 13 is the required upgrade path for teams looking to utilize .NET 10 and ensure their platform remains on a supported framework after .NET 8 reaches end-of-support in November 2026. CMS 12 will not officially support .NET 10.

.NET 11 is expected to be released in November 2026 and is a Standard Term Support (STS) release. No specific announcement has been made regarding CMS 13 and .NET 11 support.

Existing Dojo property editors continue to work in CMS 13. CMS 13 also introduces ES6 module-based custom property editors — a plain JavaScript function with no Dojo mixins or Dojo dependencies required. React, TypeScript, Vite, and Storybook are all supported for building custom editors. See: https://world.optimizely.com/blogs/grzegorz-wiechec/dates/2026/3/custom-property-editors-in-optimizely-cms-13/

Razor pages are already supported in CMS 12 and continue to be supported. Razor components do not yet have first-class support. Blazor is not officially supported but is not discouraged either.

There are no current plans to provide direct TagHelper equivalents for Razor components (.razor) within the traditional MVC framework. While Optimizely remains fully committed to supporting MVC and Razor for existing implementations, our engineering focus for CMS 13 is on enabling a more flexible, decoupled architecture.

Yes. MVC remains fully supported in CMS 13. There are no plans to drop MVC or Razor support. Tag helpers and HTML helpers are available for rendering Experiences and DAM integrations.

Graph is strongly recommended and positioned as required from a sales perspective. The CMS can run without Graph, but key capabilities are unavailable, and functionality is significantly limited.

Yes. Search & Navigation is not supported in CMS 13; switch to Optimizely Graph is mandatory.

No formal end-of-life has been announced. Customers migrating to CMS 13 will typically have a 6-month overlap period, with extensions available on request.

No. CMS 13 supports .NET MVC, headless, hybrid, and mixed architectures. Graph replaces Search & Navigation for content retrieval while frontend flexibility is preserved.

A new .NET SDK aligned with the Find API simplifies migration. A full content sync can be triggered during deployment. A migration guide will be available at the launch. See the early access preview docs: https://docs.developers.optimizely.com/content-management-system/v13-Pre-Release/docs/migrate-from-search-navigation-early-access-preview

Waiting until CMS 13 is recommended. The Graph schema format is quite different between CMS 12 and CMS 13, so the benefits of migrating to Graph in CMS 12 are likely not worth the additional effort.

On the query side, it mainly involves adjusting queries — built-in metadata is now clearly separated from partner-defined data. On the server side, the new implementation is not based on Content Delivery API, so server-side extensions are not directly portable. The effort depends on the types of customizations in place.

In CMS 13, the Graph schema aligns more closely with SaaS. Built-in metadata is clearly separated from partner-defined properties, allowing both Optimizely and partners to evolve schemas over time without breaking each other. The REST API format and payload is consistent between SaaS and CMS 13.

The Graph Search UI will be in beta at the time of the CMS 13 launch, including synonym management, best bet setup, and most analytics. Additional features are planned for Q2. Note: tracking, did-you-mean, spellcheck, and GDPR-related functionality are current gaps — check migration documentation for workarounds.

Yes. Optimizely Graph is designed to be a unified reflection of your content model and fully supports core platform capabilities such as localization and translation. Because Graph mirrors the CMS structure, localized content is indexed and remains retrievable based on the language settings defined within the system.

FilterForVisitor is still available and works as expected in CMS 13, no changes were made to its API or behavior.

However, the underlying FilterAccess.QueryDistinctAccessEdit() methods that support content access checking were marked as obsolete in CMS 13. If you're using FilterAccess directly in your code, you may see deprecation warnings. The recommended replacement is IContentAccessEvaluator.HasAccess(), which provides the same access-checking functionality through a more modern, dependency-injection-friendly interface. The obsolete FilterAccess methods are scheduled for removal in a future major version.

In CMS 12, ContentArea.FilteredItems automatically filtered content area items by publish status, user permissions, and visitor group personalization. In CMS 13, this property is obsolete and will be removed in CMS 14. The reason is that ContentArea was hiding a ServiceLocator dependency rather than being a data class.

The migration approach depends on how you use it:

If you render content areas using HTML helpers or tag helpers, then no action is needed. The ContentAreaRenderer pipeline already applies filtering automatically during rendering, just as it did in CMS 12.

If you called FilteredItems directly in code, for example to count visible items or check whether a content area appears empty for a visitor, you should inject IEnumerable<IContentAreaItemsRenderingFilter> and apply the filters to contentArea.Items yourself. The built-in implementations ContentAreaItemAccessFilter (permissions) and VisitorGroupContentAreaItemsFilter (personalization) cover the same logic that FilteredItems handled. You can also register custom implementations of IContentAreaItemsRenderingFilter for additional filtering.

If you just need all items without filtering, use contentArea.Items directly.

The strategy focuses on providing a more modern and flexible developer experience. While the older Optimizely.Graph.Client has been deprecated, it is replaced by the newer Optimizely.Graph.Cms and Optimizely.Graph.Query packages. These new packages are designed to allow for querying and indexing in a more flexible way. Specifically, they are intended to support integrations beyond just the core CMS, including external data sources and .NET APIs hosted separately within the DXP environment. Additionally, a new .NET SDK—designed to align more closely with the Search & Navigation (Find) API to simplify migrations—is currently in progress.

External data can be indexed using the new .NET packages, such as Optimizely.Graph.Cms and Optimizely.Graph.Core, which are designed to allow querying and indexing of external data sources and separate .NET APIs in a flexible way. Regarding licensing, Optimizely Graph is included as a core capability of the CMS 13 offering for DXP customers. While it is designed to act as a unified reflection of your content model, you should consult your specific license agreement or account manager to confirm the volume and usage limits for third-party external data indexing under your standard package.

The initial release of CMS 13 does not include any extension capabilities. In an upcoming minor release, we will include the capability to provide data for content type base types. These base types are usually used by add-on implementers and should not be used to extend existing types in the schema. We will also release indexing conventions, similar to the conventions in CMS 12. These conventions will let you exclude types and include computed properties on existing types. Instead of providing conventions to include .NET base types, we rely on contracts. Contracts, also known as abstract content types; are indexed automatically. We will also provide an abstraction to do conversions for custom property data types. @JohanP

The CMS handles Graph schema generation from Content Types automatically. Extension points exist (e.g., custom properties), but the schema is more restricted than in CMS 12 — built-in schemas cannot be changed, only extended. The conventions API (for computed properties) will be released in a minor release shortly after the initial launch.

Yes. Developer indexes will be available. Documentation will be provided. A self-service portal for short-lived developer indexes is under consideration; no confirmed timeline.

This is currently being investigated as part of the longer-term developer experience roadmap. While a cloud-connected index is presently required for Optimizely Graph, the product team is exploring the possibility of a Graph-compatible service that could run in a Docker container to support local development workflows and provide a solution for on-premise hosted environments.

Text is extracted from most document types and made searchable.

Virtual roles marked as "Available as permission role" are included in Graph. Note that the evaluation of virtual roles is dependent on the context. For example, some criteria only work when they're evaluated in the same process as the CMS and do not work when the frontend is hosted outside the process.

Visual Builder is available in both SaaS and PaaS (CMS 13).

Yes. Visual Builder supports existing pages and blocks from CMS 12. Shared blocks cannot be used as elements within sections (though support for this is planned). Reviewing content modeling for CMS 13 is recommended to get the most out of Visual Builder.

VB basically does not support Forms and Language Manager.

Yes. A mix of traditional Pages/Blocks and new Experiences/Sections is supported. Static properties can also be added to Experiences.

Except for Forms and LanguageManager.

Rows and columns are a logical grouping within Visual Builder (Sections/Rows/Columns/Elements). They do not need to be rendered as rows and columns in the actual frontend — that is up to the implementation. Shared blocks can also be used at the section or element level.

Elements inside Columns do not support ContentArea; ContentReference should be used. This matches the same content modeling rules in CMS SaaS.

Yes, as a configurable option. Documentation will be available at launch.

In CMS 13, On-Page Editing for decoupled or headless implementations is primarily powered by the new Visual Builder. It features a split-view interface where the left side serves as the editing pane and the right side provides a live preview of the content.

Key technical aspects include:

• Granular Componentization: Visual Builder allows for a cleaner content model by letting developers componentize content at a more granular level than traditional blocks.
• Preview Breakpoints: Just like in CMS 12, editors can view their changes across different device breakpoints within the live preview.
• Support for Existing Structures: Visual Builder supports pages and blocks from CMS 12, meaning no immediate changes are required for existing content structures during migration.
• Content Modeling Agent: An AI-driven agent is available to recommend and create content models optimized specifically for Visual Builder based on design files, URLs, or prompts.
• Graph Integration: The editing experience is increasingly dependent on Optimizely Graph, which serves as the delivery and integration layer for features like the embedded DAM and external content.

The IContentLoader and IContentRepository fully support working with experiences.

Visitor Groups and Audiences work in MVC-based implementations. They are not indexed to Graph, so for Graph-based delivery, the recommendation is to use the new Variations support for content and Experimentation for personalization. Deeper CMS/Experimentation integration is on the roadmap.

Yes. In CMS 13, AI-driven capabilities through Opal are more deeply embedded into the core experience than in previous versions. This integration allows for out-of-the-box tools and agents that assist with the creation, management, and optimization of content.

A critical component of this strategy is Optimizely Graph, which is now a required technology for CMS 13. Graph enables advanced personalization and semantic search by allowing the system to query content dynamically based on specific user contexts. This architecture ensures that personalized and optimized experiences can be delivered across any channel while maintaining high performance.

We have no plans to announce for CMS 13 on this topic.

Opti ID is required to unlock AI capabilities (Opal) and certain platform features such as the Embedded DAM. It is only available in SaaS and DXP environments.

Opti ID is required for accessing CMS-level features like Opal and DAM. For a more detailed breakdown of which editor flows require Opti ID vs. traditional login, please refer to the launch documentation.

Opti ID is intended for business users (editors and admins) who access the CMS. For end users and site visitors, any authentication scheme can be used. Opti ID is only available in DXP (not on-prem or self-hosted Azure).

I'd like the Opti ID team to verify, but my layman's answer is that this should be handled by configuring Okta as an Identity Provider for Opti ID (Option 3): Get started with Opti ID – Support Help Center

They should first decide if they want to implement SSO with or without SCIM, then follow the relevant instructions for configuring with Okta as their IdP.

https://support.optimizely.com/hc/en-us/articles/44424935212941-Configure-Opti-ID-for-CMS-13

Opti ID is only for business users accessing the CMS. B2C authentication for public-facing site visitors is independent and fully supported alongside Opti ID for editors.

Plans exist for a self-service portal where redirect URIs can be managed by teams. No confirmed timeline has been announced.

This depends on what specific functionality is missing. If there is a specific integration gap, submitting that feedback through official channels is recommended.

Opti ID configuration can be adjusted to control session behavior, including idle timeouts. Default settings are configured and changing them is not recommended without specific need.

Yes. The Embedded DAM is available for all CMS 13 DXP customers and requires Opti ID.

DAM is included with CMS SaaS and CMS 13.

DAM is a cloud service that requires Opti ID. Since Opti ID is not available on-prem, DAM is not available for on-prem customers.

The Content Manager picker will eventually replace the old modal popup. In the initial CMS 13 release, the DAM library picker remains available as an option.

Plans exist to fully disable the old media library, but this is not yet possible in CMS 13.0. CMS assets and DAM assets can coexist in the meantime.

No official Optimizely migration tooling is planned at this stage. Migration is possible but non-trivial — all asset references must be updated. Third-party tools such as the Proxima DAM Migration Tool (from Epinova) are available. CMS assets and DAM assets can coexist, so a migration is not required upfront.

The DAM product follows its own roadmap, and this is an area the team is actively exploring.

Content types related to external content (including DAM and OCP) are public and visible to everyone in the initial CMS 13 release. Role-based restriction for DAM assets is not supported at launch.

In CMS 12, the DAM integration pulled asset metadata from CMP and stored it in a persistent cache within CMS. This reduced repeated lookups to CMP and improved performance.

In CMS 13, the DAM integration is built on Optimizely Graph, which serves as both the indexing and delivery layer for DAM assets. Asset metadata, including tags, labels, and custom fields defined in DAM, are indexed into Optimizely Graph and can be queried and used directly in content delivery.

Yes. Opal will be available in CMS 13 PaaS with a range of out-of-the-box agents as well as the tools, equivalent to what's already available in SaaS CMS.

No. Opal requires Opti ID, which is not supported on-prem.

Yes. An Opal Tool can connect through the CMS API to create and edit content, enabling publishing directly from Opal.

Opal carries additional cost via Opal credits. Opal credit packages are available, and these should be discussed with your Customer Success Manager (CSM). Opal is not installed automatically; it must be provisioned by Optimizely, and the supporting Nuget package must be installed for Opal Chat. Opal Chat will be released for CMS13 soon.

For use within Optimizely CMS (user interface): Yes, OpalChat is already available for CMS12, CMS13 and SaaS CMS:

https://nuget.optimizely.com/packages/Optimizely.Cms.OpalChat/

For use as a website chatbot for end customers to search for products/content (i.e. frontend chatbot):

No, Opal does not currently support this use case.

Opal agents are configurable to users' needs and a combination of prompt engineering alongside Opal instructions can be used to provide brand governance in agent workflows.

Opal is optional, it must be provisioned and installed for access within PaaS CMS.

The Opal application data residency is currently US-based but will also offer EU soon.

Opal is opt-in rather than opt-out. Opal will not appear if not provisioned. When installed, customers can disable Opal at any time via a simple toggle, and can designate access per individual user.

Any data you put into Opal stays private to your organization. Google Cloud (our underlying Opal LLM provider) does not utilize customer inputs or the LLM output for its LLM training purposes. Your data, including your Opal input and the Opal output, are not used by Optimizely to train, develop, or improve any GenAI features. All processing happens within Google Cloud, using secure, enterprise infrastructure. Customer data is protected with robust controls that minimize exposure only to provide services as contracted to you, our customer.

Refer to the latest Services Descriptions for the Optimizely Software Service for more details: https://world.optimizely.com/services/descriptions/

Yes. An MCP server can be used by any LLM and client. A CMS MCP server has been confirmed.

The general steps are: (1) Configure Opti ID, (2) Enable Graph, (3) Update content models if using Visual Builder, (4) Migrate media assets if using Embedded DAM. Detailed documentation will be published at launch. Upgrade timing depends on implementation complexity — estimates range from 2 to 6 months on average.

CMS 13 is a recent release, and it remains to be seen which breaking changes will cause the most friction in practice. For the full list of breaking changes and detailed migration guidance, refer to our breaking changes documentation.

Opti ID is required to enable AI capabilities and DAM. Search & Navigation must be replaced by Optimizely Graph. Other specific components will be documented in the migration guide at launch.

Migration tooling is being explored. AI-assisted migration tools are also under investigation. No specific tool has been announced for the initial launch.

A direct upgrade from CMS 11 to CMS 13 is technically supported. The level of effort is similar to upgrading 11 to 12, as the majority of work involves upgrading the .NET framework. For highly customized solutions, breaking the upgrade into smaller steps may still be advisable.

Documentation for migration via the PaaS Portal — including project migration steps — will be published alongside the CMS 13 release.

Yes, refer to Project migration for CMS 12 with Optimizely Graph

Switching from Search & Find to GraphQL is a recommended preparatory step. Adopting Opti ID while still on CMS 12 is also beneficial. Full guidance will be published at launch.

We are actively monitoring early upgrades to CMS 13 and will continue to update our documentation as we learn which areas require additional guidance. The full list of breaking changes is documented and being made publicly available.

Optimizely fully supports the current major version and backports select fixes, primarily security-related, to the previous version. We provide a documented upgrade path to help customers migrate between major versions. We do not formally end-of-life CMS versions, but we encourage customers to stay current to benefit from the latest features, fixes, and security updates.

Foundation (https://github.com/episerver/Foundation) is a reference implementation that demonstrates what a CMS solution can look like. It will be updated to CMS 13 by Optimizely Solution Architects in the near future.

The documentation will contain references to dependencies like Opti ID and Optimizely Graph.

We are planning for an annual release cadence for PaaS, which means the lifecycle of CMS 13 will be shorter than what customers have been accustomed to with previous major versions.

No. Commerce 14 is not compatible with CMS 13. Commerce 15 is required.

Commerce 15 is targeted for late April 2026. A preview version is currently available: https://docs.developers.optimizely.com/commerce-connect/v15-pre-release/docs/overview-of-commerce-15-pre-release#/versions

The recommendation is to upgrade Commerce to Commerce 15 before or alongside the CMS 13 upgrade.

Yes. A Commerce 15-compatible version of the Commerce Service API will be released in Q2 2026.

There are some improvements to catalog language handling which can be significant in multi-language catalogs, but Commerce 15 is primarily a Compatibility release for CMS 13.

At present, there are no plans to implement changes related to Experimentation or Personalization in Commerce 15. Personalization and experimentation are primarily used in CMS in conjunction with commerce content pulled from Commerce 15.

A full list is available internally. Partner packages are being updated — contact Product or Partnerships for details. Forms (traditional/classic) are supported quickly after the CMS 13 is released.

Traditional Forms will be supported quickly post launch. For Find, the move to Graph is required — no CMS 13 support for the Find package is planned. For Language Manager (EPiServer.Labs), it would come to public at the end of quarter 2.

Within Q2, it would be released. And the current name is preserved.

No, the packages will not be upgraded to support CMS 13. Search & Navigation will continue to work from CMS 12, but not from CMS 13.

Yes, existing Dojo property editors continue to work. CMS 13 also introduces a modern ES6-based approach for custom property editors with no Dojo dependency.

Yes. CMS 13 will move to TinyMCE 8.

Third-party add-on owners are responsible for updating their packages for CMS 13 compatibility. For Geta packages, submitting issues in their GitHub repository is recommended. The Geta Advanced Reviews author has confirmed CMS 13 support is coming soon.

For Optimizely provided packages, the answer here is the same as for "When will CMS 12 reach end of life (EOL)?". The addons we provide follow the same patch policy as the CMS major version they are for. NotFoundHandler is a 3rd party package though.

Product Recommendations are expected to be supported. Content Recommendations are lightweight and may not require changes. Confirm with the relevant product team.

There are currently no additional feature announcements on this topic planned for CMS 13.

Developer indexes will be available. A self-service portal for short-lived developer indexes is available, see https://docs.developers.optimizely.com/content-management-system/v13.0.0-CMS/docs/cms-13-overview?isFramePreview=true#request-a-developer-instance

For developer demo instances, there will be a page by end of Q2 where people can request instances directly and it will be automated via a form and conductor. In the meantime, we'll handle the process manually via support and Kevin Shea and I will do the provisioning. @anna

Documentation is not published yet but will be available at launch.

Coming slightly after the 13.0.0 release, we will release a version of the JS SDK that supports CMS 13. That will contain some samples and templates, https://github.com/episerver/content-js-sdk/. Note that inline editing is not supported for headless setups. Headless is fully supported in Visual Builder and On-Page-Edit only support floating property editors.

Yes. The CMS 13 launch includes a new template called Stride, in addition to Alloy. It is updated with the content model supported by Visual Builder.

Follow the JS SDK guides and documentation. Changing the architecture requires a complete rewrite of the frontend.

CMS handles Graph schema generation from Content Types automatically. Local schema generation before deployment is not currently supported. The indexing conventions API (for computed properties/schema extensions) will be released in a minor post-launch release.

No. Opti ID is only available in DXP (SaaS or PaaS) environments.

Yes, on-prem customers can upgrade to CMS 13. However, features that require Opti ID — including Opal AI, Embedded DAM, and Optimizely Connect Platform — are not available on-prem. Graph is required and runs in the cloud but can be accessed from on-prem.

Optimizely Graph is a cloud-hosted service and is not available for self-hosted or on-premises deployments. However, any CMS instance that can connect to the Graph service can use it, regardless of where the CMS itself is hosted.

Yes. PaaS projects can be set up and run locally. Note that some cloud-dependent features (like Opti ID and Graph) require connectivity to cloud services.

No, but CMS 14 will likely see changes in this area driven by the development of webhooks.

Yes, IApplicationResolver and IApplicationRepository replace the old services.

If you want a reference where the user can only select pages, model it as a ContentReference and set the AllowedTypes to only allow PageData.

No, it works the same way as in CMS 12.

The scheduled jobs API have not changed in CMS 13. There are plans to fully support async scheduled jobs in a future release.

Yes. The REST API available in SaaS will be available in CMS 13 with the same format and payload.

Content Delivery API is supported for backward compatibility but is not available at the CMS 13 launch — it is expected to be in a follow-up release. Graph is the recommended long-term delivery approach.

Not all packages around tradition headless would be released. We preferably release the most important ones like Content Delivery API and perhaps EPiServer.OpenIDConnect. And The API would only support traditional content types like pages, blocks. No experience / sections support.

A new version of the JS SDK will be released supporting both SaaS and CMS 13. It is the recommended approach for frontend model management. For PaaS + headless, managing types where they're primarily used is the recommendation. Full PaaS headless support is an area of ongoing development.

The recommendation is to manage types where they're primarily used. For PaaS + headless this is typically the .NET code, with the JS SDK used for syncing types to the frontend.

Custom properties default to their base types in ContentGraph. For PropertyList<T>, the schema type is JSON. PropertyList<T> has effectively been superseded by IList<TBlock>, which has a better interface.

To include base types in Graph we recommend modeling them as contracts, also known as abstract content types. Contracts are indexed automatically in Graph.

The same way you could do it in CMS 12 is still supported for CMS 13. But we also added a new way to create custom property editors without the need to write any Dojo, https://world.optimizely.com/blogs/grzegorz-wiechec/dates/2026/3/custom-property-editors-in-optimizely-cms-13/.

The initial release does not support extending the schema or adding computed properties. The indexing conventions API, which enables this capability, will be released in a minor post-launch release.

Documentation on enabling live preview is available at: https://docs.developers.optimizely.com/content-management-system/v13.0.0-CMS/docs/enable-live-preview

Yes. The Content JS SDK (https://github.com/episerver/content-js-sdk) provides improved integration for Next.js and other JS-based frontends.

Manage types where they're primarily used. For a primarily .NET PaaS implementation, content types are still managed in C# code, with the JS SDK used for type sync via Graph.

No official SDK or first-class support exists yet. Blazor is not discouraged, and content retrieval via Graph or the .NET API is still possible.

Coming slightly after the 13.0.0 release, we will release a version of the JS SDK that supports CMS 13. That will contain some samples and templates, https://github.com/episerver/content-js-sdk/. Note that inline editing is not supported for headless setups. Headless is fully supported in Visual Builder and On-Page-Edit only supports floating property editors.