Now i am old enough to remember when a property editor could be defined with a few lines in a package.manifest file and a .html pages. but they where much simpler times, and even in 'Traditional' Umbraco 13 land, it takes a lot more now to create a custom property editor.
v14 property editors have a few quirks in the current release (preview005) but once you have gotten over them, you can create your own property editors.
Creating your own editor can be broken down into three parts.
- Config
- User Interface
- Backend (c#) code
Schema.
The first step to defining your own property editor is to define the schema for the editor.
The schema does many things, but it defines what your property editor alias is. and what configuration properties you will have on your editor.
export const styledTextSchema : ManifestPropertyEditorSchema = {
type: 'propertyEditorSchema',
name: 'Styled textbox',
alias: 'styled.textbox',
meta: {
defaultPropertyEditorUiAlias: 'styled.textbox.ui',
settings: {
properties: [
{
alias: 'styleValue',
label: 'Styles',
description: 'Styles to apply to the box',
propertyEditorUiAlias: 'Umb.PropertyEditorUi.TextArea'
}
],
defaultData: [
{
alias: 'styleValue',
value: 'font-size: 20px;\r\nborder:none; border-bottom: 1px solid #444;'
}
]
}
}
};
Our schema defines our styled.textbox
property editor, with a styledValue
property that the editor can set via a textbox.
UI Manifest.
The schema defines what appears in the 'datatypes' section of Umbraco. the UI Manifest determains what appears in the content section when an editor is using your property type.
const styledTextUi : ManifestPropertyEditorUi = {
type: 'propertyEditorUi',
alias: 'styled.textbox.ui',
name: 'styled textbox',
js: () => import('./styledtext.ui.element.js'),
elementName: 'styled-text',
meta: {
label: 'Styled textbox',
icon: 'icon-brush',
group: 'common',
propertyEditorSchemaAlias: 'styled.textbox',
}
}
I have seen this section defined with the properties, (so a duplicate of schema) in some code and the docs, but it appears to work fine without !
Update:
Jacob Overgaard from Umbraco tells me:
You mention here that you have seen configuration defined both on the schema and the UI manifests.
This is because you can define configuration on either, say, if you just want a UI configuration that the server doesn't need to know about, it's perfect to put on the UI side.
A good example would be a rich text editor, which can have configurable buttons on the UI that doesn't matter as to how the data is processed, so you would create a UI property editor for a specific implementation such as TinyMCE, ckeditor, or others, which saves the data down to a simple Umbraco.RichText property editor.
In doing so, you can have multiple UI implementations using the same schema.
Top comments (3)
@kevinjump Would you like to contribute this article to the TinyMCE DevTo Community?
Hi, yeah sure, if you think it will be of use to people
@kevinjump Email me at mrina.sugosh@tiny.cloud