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.
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:
Setting the maxlength attribute is used only for client-side validation and to help editors adhere to data validation rules. This does not automatically trigger server-side validation on save. If you need server-side validation, the Property Editor Schema needs to implement this explicitly.
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?