Property Editor UI

Presenting the Editing Experience of a Property Editor

The Property Editor UI is the client-side component that renders the editing interface in the Umbraco backoffice. It provides the visual interface for content editors to interact with their data. The Property Editor Schema validates and stores data on the server. The Property Editor UI focuses on providing an intuitive editing experience through the browser.

Creating a Property Editor UI

A Property Editor UI is a purely frontend extension in the shape of a web component. In this example, we will create a Property Editor UI using an Umbraco Lit element step by step. At the end of the article, the full example is provided.

To create a Property Editor UI, the following needs to be done:

  • Implement the Umbraco Lit component - the actual visible part.

  • Register the Property Editor UI using a manifest.

Implement the interface

What makes a standard Umbraco Lit component a Property Editor UI is the implementation of the UmbPropertyEditorUiElement interface. The UmbPropertyEditorUiElement interface ensures that your element has the necessary properties and methods to be used as a Property Editor UI element. See the UI API documentation for the full interface definition.

import { UmbLitElement } from '@umbraco-cms/backoffice/lit-element';
import type { UmbPropertyEditorUiElement } from '@umbraco-cms/backoffice/property-editor';

// Implement the UmbPropertyEditorUiElement
export default class UmbPropertyEditorUITextBoxElement extends UmbLitElement implements UmbPropertyEditorUiElement {
	...
}

This interface gives access to important information about the data and configuration through a collection of properties. None of them are technically required to implement, but in practice, you need value and probably also config.

  • value: Contains the actual value that will be processed and stored when the content is saved and retrieved. The value is automatically populated when the component loads. When saved, the value is sent to processing and saved to the database.

  • config: The configuration as set on the Data Type.

  • readonly: If you support read-only mode, this will indicate whether the component should be read-only.

For the full interface properties of the UmbPropertyEditorUiElement, see the UI API documentation for more information.

A minimal implementation where the value is read and placed in a textbox looks like this:

Handle value changes

In the previous example, the value is read and placed in a text box. However, it will not react to changes in the value. When the value needs to be changed, it is required to dispatch an UmbChangeEvent.

Handle configuration

As discussed before, both the Property Editor UI and the Property Editor Schema can have settings that are set when creating a Data Type. You can access these settings like this:

Handle mandatory and validation

When an editor is creating a Document Type in the backoffice and adds properties, properties can be marked as mandatory. There is also an option to add a custom validation message for that property.

When a property is marked as mandatory, it will automatically perform validation when the content node with that property is saved. This validates whether the value property has a value or not. If not, the custom validation message is displayed.

The validation is handled automatically by the CMS. However, if it makes sense in the context of your Property Editor UI, you can access both the mandatory flag and the custom error message.

The validation above is only performed on the value of the property editor as a whole. When you have complex Property Editor UIs with multiple inputs and advanced validation, you need more advanced validation techniques. See the UI Library Form Validation documentation on how to implement advanced validation.

Handle readonly

The readonly property indicates whether the Property Editor should be in read-only mode. This happens automatically based on:

  • User permissions - The current user does not have update permissions for this content.

  • Content locks - Another user is currently editing the content.

  • Workflow states - Content is in a state that prevents editing (for example, awaiting approval).

  • Variant restrictions - Editing a culture/segment variant without proper permissions.

By default, Umbraco places an overlay on the Property Editor if it needs to be read-only. In most cases, this is sufficient. However, you can also handle read-only mode in the Property Editor more gracefully.

To properly support read-only mode, the manifest should set the supportsReadOnly property to true, and you need to handle read-only yourself. This means you need to ensure the editor cannot change any content in read-only mode.

Full example

The following code is a complete example that includes all the previous examples in this article. This example Property Editor UI:

  • Reads and updates the value.

  • Handles configuration.

  • Handles mandatory and the mandatory message.

  • Handles read-only mode.

Register the Property Editor UI

To make your Property Editor UI available in Umbraco, you need to register it using a manifest. The manifest defines the alias, element location, and metadata such as the label, icon, and which schema it works with.

For details on the manifest structure and all available options, see the Property Editor UI Extension Type documentation.

Basic example

Last updated

Was this helpful?