Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Alias: Umbraco.MultiNodeTreePicker
Returns: IEnumerable<IPublishedContent>
The Content Picker enables choosing the type of content tree to display and which specific part to render. It also allows you to set a dynamic root node for the content based on the current document using the Content Picker.
The Content Picker was formerly known as the Multinode Treepicker in version 13 and below.
The renaming is purely a client-side UI change, meaning the property editor still uses the Umbraco.MultiNodeTreePicker
schema alias.
The change was made as the word Content in the backoffice acts as an umbrella term covering Documents, Media, and Members.
Are you looking for the original Content Picker?
The Content Picker from version 13 and below has been renamed Document Picker.
Define a limit on the number of items allowed to be selected.
Checking this field allows users to choose nodes they normally cannot access.
This option allows for configuring what type of content is available when using the Data Type. The available types of content are Content, Members, or Media items.
When selecting Content from the dropdown, the option to specify a root node, also called the origin, becomes available.
When picking the origin there are several different options available:
The following options are available when picking the origin:
Root: The root is the first level item of the sub-tree of the current node.
Parent: The parent is the nearest ancestor of the current node.
Current: The current node.
A picker that uses the current node, cannot pick anything when the current node is created, as it will not have any children.
Site: The nearest ancestor of the current node with a domain assigned.
Specific node: A specific node selected from the existing content.
When an origin has been specified, it becomes possible to continue to build a Dynamic Root by adding additional query steps.
Navigate the content tree relative to the specified origin to execute multiple query steps and find the root node needed.
The following options are available:
Nearest Ancestor or Self: Find the nearest ancestor or current item that fits with one of the configured Document Types.
Furthest Ancestor or Self: Find the furthest ancestor or current item that fits with one of the configured Document Types.
Nearest Descendant or Self: Find the nearest descendant or current item that fits with one of the configured Document Types.
Furthest Descendant or Self: Find the furthest descendant or current item that fits with one of the configured Document Types.
The options above are all based on navigating the document hierarchy by locating ancestors and descendants. It is possible to execute custom steps to build even more complex queries. Once a custom query is available it will be added to the bottom of the Append steps to query dialog. Learn more about adding custom query steps in the section below.
Each query step takes the output from the origin or the previous step as input. It is only ever the result of the last query step that is passed to the next step.
Custom query steps can be used to solve specific use cases, such as traversing sibling documents or matching property values. Before the custom query steps can be selected in the Data Type settings, they must be defined via code.
When implementing a query step it requires a collection of origins and information about the query step. The collection is taken from where the name specified in the UI can be found.
Specifying the origin is required for the custom query step to become available.
Read the Node Type section above to learn more about this.
You can inject dependencies into the constructor. These dependencies could be custom repositories or the IVariationContextAccessor
, if you want to use the current culture.
The ExecuteAsync
method receives a set of content keys from the last executed query step or the origin. It has to return a new set of content keys.
To register the custom query step, append it to the existing query steps, DynamicRootSteps()
. This is done from a composer as shown below.
Choose which types of content should be available to pick using the Content Picker.
This is done by selecting one or more Document Types.
Consider the following tree structure where the Document Type alias is presented in square brackets.
Codegarden
2023 [year
]
Talks [talks
]
...
Umbraco anno MMXXIII [talk
]
Stages [stages
]
Social Space [stage
]
No 10 [stage
]
No 16 [stage
]
The Theatre [stage
]
2022 [year
]
Talks [talks
]
...
Stages [stages
]
Main Stage [stage
]
The Barn [stage
]
The Theatre [stage
]
Consider configuring a Content Picker on the talk
Document Type to select a stage
for the talk
. Here, you want to display only the stages for the actual year. To do this, you need to set the parent as the origin.
For instance, if you are on the Umbraco anno MMXXIII
node, the collection of content keys passed into the first query step will only contain the Talks
content node.
First, query for the nearest ancestors of the type year
. This will return 2023
.
Second, query for the nearest descendants of the type stages
.
When opening the picker on the Umbraco anno MMXXIII
node, it will now show the children of the node on the path Codegarden > 2023 > Stages
.
See the example below to see how a value can be added or changed programmatically. To update the value of a property editor you need the Content Service.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.CheckBoxList
Returns: IEnumerable<string>
Displays a list of preset values as a list of checkbox controls. The text saved is an IEnumerable collection of the text values.
Unlike other property editors, the Option IDs are not directly accessible in Razor.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.ListView
Returns: IEnumerable<IPublishedContent>
Collection displays a collection of categories when it is enabled on a Document Type with children.
If enabled, editors will be able to see multiple children from a collection on a content node that has children. When not enabled, no collection will be shown and all children will be shown in the Content Tree.
Defines how many child content nodes you want to see per page. This will limit how many content items you will see in your collection. If you set it to 5, then only 5 content items will be shown in the collection.
Will sort your collection by the selection you choose in the dropdown. By default it selects "Last edited" and you get the following three columns:
Last edited - When the content node was last edited and saved.
Name - Name of the content node(s).
Created by - This is the user who the content node was created by.
You can add more sorting to this collection by adding more datatypes to the columns in the "Columns Displayed" section.
You can select order of the content nodes displayed, "Acsending" or "Descending". The order is affected by the "Order By" selection.
It is possible to add more columns to the collection, via adding the properties through the dropdown. These properties are based on the Data Types which are used by the Document Type. It will show up in the dropdown by its alias and not the name on the property.
Once you have selected a column you want to display, define what its name should be and what kind of value it should display. You can also move the headers around, re-ordering how they should look. This is done by the move icon on the left side of the alias.
The template section is where you define what kind of value you want to display. The value of the column is in the value
variable.
Collection comes with two layouts by default. A list and a grid view. These views can be disabled if you are not interested in any of them.
A minimum of one layout needs to be enabled for Collection to work.
You can also make your own layout and add it to the settings. For example, if you wanted to change the width or length of the grid, you will be able to do so.
Select what kind of action is available on the collection.
Allow bulk publish - content only
Allow bulk unpublish - content only
Allow bulk copy - content only
Allow bulk move
Allow bulk delete
Changes the icon in the backoffice of the collection. By default it will look like the image below.
You can change the name of the collection itself. Default if empty: 'Child Items'.
Enable this to show the Content Workspace View by default instead of the collection's.
The {{ value }}
will take the value of the Email property and display it in the collection, as shown on the image below.
First, a Member Picker property needs to be present on the content item. In this example, the child item
has gotten a Member Picker Data Type with the alias of isAuthor
.
The child item has a member and the value that should be displayed is the name of the picked value. The next step is to reconfigure the template value in the collection setting.
Alias: Umbraco.ContentPicker
Returns: IPublishedContent
The Document Picker opens a panel to pick a specific page from the content structure. The value saved is the selected nodes .
The Document Picker was formerly known as the Content Picker in version 13 and below.
The renaming is purely a client-side UI change, meaning the property editor still uses the Umbraco.ContentPicker
schema alias.
The change was made as the word Content in the backoffice acts as an umbrella term covering the terms Document, Media, and Member.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.DateTime
Returns: DateTime
Displays a calendar UI for selecting dates which are saved as a DateTime value.
There are two settings available for manipulating the DateTime property.
The second setting is "Offset time". When enabling this setting the displayed time will be offset with the servers timezone. This can be useful in cases where an editor is in a different timezone than the hosted server.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.ColorPicker
Returns: String (Hexadecimal)
Returns: Umbraco.Cms.Core.PropertyEditors.ValueConverters.ColorPickerValueConverter.PickedColor (When using labels)
The Color picker allows you to set some predetermined colors that the editor can choose between.
It is possible to add a label to use with the color.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
You can use dictionary items to translate the options in a Checkbox List property editor in a multilingual setup. For more details, see the article.
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the .
This example uses a generic field on a child item and displays it in the collection.
This will take the value picked up by the member picker.
And display it in the collection. Shown in the example below:
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the .
One is to set a format. By default the format of the date in the Umbraco backoffice will be YYYY-MM-DD HH:mm:ss
, but you can change this to something else. See for the supported formats.
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the .
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the .
The only setting that is available for manipulating the Date property is to set a format. By default the format of the date in the Umbraco backoffice will be YYYY-MM-DD
, but you can change this to something else. See for the supported formats.
See for more information about why the dynamic approach is obsolete.
In this article you can learn how to use the build in email property editor
Alias: Umbraco.EmailAddress
Returns: String
Displays an email address.
The Email Address Property Editor does not come with any further configuration. The property can be configured once it has been added to a Document Type.
See the example below to learn how a value can be added or changed programmatically to an Email-address property. To update a value of a property editor you need the Content Service.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
The value sent to an EmailAddress property needs to be a correct email address, For example: name@domain.com.
It is recommended that you set up validation on this property, in order to verify whether the value added is in the correct format.
Alias: Umbraco.UploadField
Returns: string
Adds an upload field, which allows documents or images to be uploaded to Umbraco.
You can define which file types should be accepted through the upload field.
For uploading and adding files and images to your Umbraco project, we recommend using the Media Picker.
Find the full documentation for the property in the Media Picker article.
In code, the property is a string, which references the location of the file.
Example: "/media/o01axaqu/guidelines-on-remote-working.pdf"
The samples in this section have not been verified against the latest version of Umbraco.
Instead, we recommend using the Media Picker for uploading files to your Umbraco website.
See the example below to see how a value can be added or changed programmatically. To update a value of this property editor you need the Content Service and the Media Service.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.Decimal
Returns: decimal
In the example above the possible values for the input field would be [8, 8.5, 9, 9.5, 10]
All other values will be removed in the content editor when saving or publishing.
If the value of Step Size is not set then all decimal values between 8 and 10 is possible to input in the content editor.
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the Content Service.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.ColorPicker.EyeDropper
Returns: string
The Eye Dropper Color picker allows you to choose a color from the full color spectrum using HEX and RGBA.
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the Content Service.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Returns: MediaWithCrops
Returns a path to an image, along with information about focal point and available crops.
When the Image Cropper is used on a Media Type the crops are shared between all usages of a Media Item. This is called global crops.
If the Image Cropper is used on a Document Type, the file and crops will be local to the Document.
Notice that it is possible make local crops on shared Media Items via the Media Picker Property Editor.
You can add, edit & delete crop presets the cropper UI can use.
The Image Cropper provides a UI to upload an image, set a focal point on the image, and use predefined crops.
By default, images in the Image Cropper will be shown based on a set focal point and only use specific crops if they are available.
The Image Cropper comes with 3 modes:
Uploading an image
Setting a focal point
Cropping the image to predefined crops
The editor exposes a drop area for files. Select it to upload an image.
By default, the Image Cropper allows the editor to set a focal point on the uploaded image.
All the preset crops are shown to give the editor a preview of what the image will look like on the frontend.
The editor can fit the crop to the image to ensure that the image is presented as intended.
ImageSharp.Web is image processing middleware for ASP.NET.
We bundle this package with Umbraco and you can therefore take full advantage of all its features for resizing and format changing. Learn more about the built in processing commands in the official ImageSharp documentation.
The Image Cropper comes with an API to generate crop URLs. You can also access the raw data directly as a dynamic object.
For rendering a cropped media item, the .GetCropUrl
is used:
The third parameter is HtmlEncode
and is by default set to true. This means you only need to define the parameter if you want to disable HTML encoding.
Or, alternatively using the MediaWithCrops
extension method:
Set the htmlEncode
to false so that the URL is not HTML encoded
To update a content property value you need the Content Service.
The following sample demonstrates how to add or change the value of an Image Cropper property programmatically. The sample creates an API controller with an action, which must be invoked via a POST request to the URL written above the action.
If you use Models Builder to generate source code (modes SourceCodeAuto
or SourceCodeManual
), you can use nameof([generated property name])
to access the desired property without using a magic string:
Crop URLs are not limited to usage within a view. IPublishedContent
has a GetCropUrl
extension method, which can be used to access crop URLs anywhere.
The following sample demonstrates how to use GetCropUrl
to retrieve URLs for all crops defined on a specific image:
Below the example to output a PNG using ImageSharp.Web format command.
Alias: Umbraco.MemberPicker
Returns: IPublishedContent
The member picker opens a panel to pick a specific member from the member section. The value saved is of type IPublishedContent.
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the Content Service.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.MultiUrlPicker
Returns: IEnumerable<Link> or Link
Multi Url Picker allows an editor to pick and sort multiple urls. This property editor returns a single item if the "Maximum number of items" Data Type setting is set to 1 or a collection if it is 0. These can either be internal, external or media.
If Max number of items
is configured to 1
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the Content Service.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.Integer
Returns: Integer
Numeric is an HTML input control for entering numbers. Since it's a standard HTML element the options and behaviour are all controlled by the browser and therefore is beyond the control of Umbraco.
This allows you to set up a minimum value. If you will always need a minimum value of 10 this is where you set it up and whenever you use the datatype the value will always start at 10. It's not possible to change the value to anything lower than 10. Only higher values will be accepted.
This allows you to control by how much value should be allowed to increase/decrease when clicking the up/down arrows. If you try to enter a value that does not match with the step setting then it will not be accepted.
This allows you to set up a maximum value. If you will always need a maximum value of 100 this is where you set it up. It's not possible to change the value to anything higher than 100. Only lower values will be accepted.
By casting the output as an int it's possible for you to do mathematical operations with the value.
You can also render the output by casting it to a string, which means you will not be able to do mathematical operations
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the Content Service.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.MemberGroupPicker
Returns: string
The Member Group Picker opens a panel to pick one or more member groups from the Member section. The value saved is of type string (comma separated IDs).
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
You can also add multiple groups by creating a comma separated string with the desired member group IDs.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.Label
Returns: String
Label is a non-editable control and can only be used to display a pre-set value.
If you want to set a value other than a String, you can define the data using one of the other available Data Types. These include Decimal, Date/time, Time, Integer, and Big integer.
There is also a Value Type: Long string if you need to set a long string value for your Label.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.MediaPicker3
Returns: IEnumerable<MediaWithCrops>
or MediaWithCrops
This property editors returns a single MediaWithCrops
item if the "Pick multiple items" Data Type setting is disabled or a collection if it is enabled.
Use setting to limit the picker to only select Media Items of these types.
Use this setting to enable the property to contain multiple items. When this is enabled the property editor returns an IEnumerable<MediaWithCrops>
.
You can still set the maximum amount to 1. Do so when you want to retrieve a collection but only allow the Content Editors to select one Media Item.
Use this setting to enforce a minimum and/or maximum amount of selected Media Items.
It is not possible to set a maximum amount when the "Pick multiple items" feature is disabled.
This setting is used to limit the Media Picker to certain parts of the Media Tree.
Use this setting to overrule user permissions, to enable any user of this property to pick any Media Item of the chosen Start node.
When this setting is enabled, a user who doesn't normally have access to the media selected as "Start Node" (/Design in this case), can access the media when using this particular Media Picker. If no Start node has been defined for this property any content can be viewed and selected of this property.
Enable the focal point setter, do only enable this if the focal point is used or if you have Image crops defined.
Define local image crops. Local image crop data is stored on the document in this property. This means it can differentiate between documents.
This is different from Global crops as they are defined on the Media Item, making the crops shared between all usage of that Media Item.
Global crops are configured on the Image Cropper property of the Image Media Type
Both local and global crops are retrieved using the method GetCropUrl
. If crops with identical aliases are defined both locally and globally, the locally defined crops are always prioritized by GetCropUrl
.
The following is an example of how to retrieve a crop from a MediaWithCrops
entry:
You can retrieve globally defined crops explicitly by using GetCropUrl
on the UrlHelper
:
The following sample will update a single image in a Media Picker.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.RadioButtonList
Returns: string
Pretty much like the name indicates this Data type enables editors to choose from list of radio buttons and returns the value of the selected item as string.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.MarkdownEditor
Returns: System.Web.HtmlString
This built-in editor allow the user to use the markdown formatting options, from within a tinyMCE-like interface.
There are three settings available for manipulating the Markdown editor property.
Preview toggles if a preview of the markdown should be displayed beneath the editor in the content view.
Default value is inserted if no content has been saved to the Document Type using this property editor.
Overlay Size is used to select the width of the link picker overlay in the content view.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.TextArea
Returns: String
Textarea is an HTML textarea control for multiple lines of text. It can be configured to have a fixed character limit, as well as define how big the space for writing can be. By default, there is no character limit unless it's specifically set to a specific value like 200 for instance. If you don't specify the number of rows, 10 will be the amount of rows the textarea will be occupying, unless changed to a custom value.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
How to use the TextBox property editors in Umbraco CMS.
Alias: Umbraco.Textbox
Returns: String
Textbox is an HTML input control for text. It can be configured to have a fixed character limit. The default maximum amount of characters is 512 unless it's specifically changed to a lower amount.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.Tags
Returns: IEnumerable<string>
The Tags property editor allows you to add multiple tags to a node.
The Tag group setting provides a way to categorize your tags in groups. So for each category you will create a new instance of the Tags property editor and setup the unique category name for each instance. Whenever a tag is added to an instance of the tags property editor it's added to the tag group, which means it will appear in the Typeahead list when you start to add another tag. Only tags that belong to the specified group will be listed. If you have a "Frontend" group and a "Backend" group the tags from the "Frontend" group will only be listed if you're adding a tag to the Tags property editor configured with the "Frontend" group name and vice versa.
Data can be saved in either Comma-Separated Values (CSV) format or in JSON format. By default data is saved in JSON format. The difference between using CSV and JSON is that with JSON you can save a tag, which includes comma separated values.
Whenever a tag has been added it will be visible in the typeahead when you start typing on other pages.
You can use the ContentService to create and update Umbraco content from c# code, when setting tags there is an extension method (SetTagsValue) on IContentBase that helps you set the value for a Tags property. Remember to add the using statement for Umbraco.Core.Models
to take advantage of it.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled, you can get the alias of the desired property without using a magic string:
Alias: Umbraco.Slider
Returns: decimal
or Umbraco.Core.Models.Range<decimal>
Pretty much like the name indicates this Data type enables editors to choose a value with a range using a slider.
There are two flavors of the slider. One with a single value picker. One with a minimum and maximum value.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.UserPicker
Returns: IPublishedContent
The user picker opens a panel to pick a specific user from the Users section. The value saved is of type IPublishedContent.
Getting the Value of the property will return the user ID - properties of the User can be accessed by referencing UserService.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
The Block Editors are property editors that enabled you to build advanced editor tools using a set of predefined Document Types.
This article is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice.
Umbraco CMS currently ships with two Block Editors: the Block List and the Block Grid.
Learn how to create custom views for the blocks used in your Block Grid or Block List property editors.
Get an overview of available configurations for the label properties.
Alias: Umbraco.MultipleTextstring
Returns: array of strings
The Repeatable textstrings property editor enables a content editor to make a list of text items. For best use with an unordered-list.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
To add multiple values to the repeatable text strings property editor you have to put each value on a new line. This can be achieved using either \r\n\
or Environment.NewLine
.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Alias: Umbraco.BlockGrid
Returns: BlockGridModel
The Block Grid property editor enables editors to layout their content in the Umbraco backoffice. The content is made of Blocks that can contain different types of data.
This article is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice.
When testing out the property editor, you can use a set of predefined Blocks. The option will only be possible when there are no other Data Types using the Block Grid property editor.
Create a new Data Type.
Select the Block Grid as the Property editor.
Install the "Sample Configuration".
4 Blocks will be added to the property, ready for testing.
The Block Grid property editor is configured via the Data Types backoffice interface.
To set up the Block Grid property editor, follow these steps:
Navigate to the Settings section in the Umbraco backoffice.
Click ... next to the Data Types folder.
Select Create -> New Data Type.
Select Block Grid from the list of available property editors.
You will see the configuration options for a Block Grid property editor as shown below:
The Data Type editor allows you to configure the following properties:
Amount - Sets the minimum and/or the maximum number of Blocks that should be allowed at the root of the layout.
Live editing mode - Enabling this option will allow you to see the changes as you are editing them.
Editor width - Overwrites the width of the property editor. This field takes any valid CSS value for "max-width". For example: 100% or 800px.
Grid Columns - Define the number of columns in your Block Grid. The default is 12 columns.
Layout Stylesheet - Replaces the built-in Layout Stylesheet. Additionally, you can retrieve the default layout stylesheet to use as a base for your own inspiration or for writing your own stylesheet.
Create Button Label - Overwrites the label on the Create button.
Once you have added an Element Type as a Block Type on your Block Grid Data Type you have the option to configure it.
Blocks can also be grouped. This is visible in the Block Catalogue and can also be used to allow a group of Blocks in an Area.
Each Block has a set of properties that are optional to configure. These are described below.
Customize the user experience for your content editors when they work with the Blocks in the Content section.
Label - Defines a label for the appearance of the Block in the editor. The label can use AngularJS template-string-syntax to display values of properties.
Label example: "My Block {{myPropertyAlias}}" will be shown as: "My Block FooBar".
You can also use more advanced expression using AngularJS filters, like {{myPropertyAlias | limitTo:100}}
or for a property using Richtext editor {{myPropertyAlias | ncRichText | truncate:true:100}}
. It is also possible to use properties from the Settings model by using {{$settings.propertyAlias}}
.
Content model - Presents the Element Type used as model for the Content section of this Block. This cannot be changed but you can open the Element Type to perform edits or view the properties available. Useful when writing your Label.
Settings model - Adds a Settings section to your Block based on a given Element Type. When selected you can open the Element Type or choose to remove the Settings section again.
Customize the Blocks size in the Grid. If you define multiple options, the Block becomes scalable.
By default, a Block takes up the available width.
A Block can be resized in two ways:
A Block can have one or more Column Span options defined.
A Column Span option is used to define the width of a Block. With multiple Column Span options defined, the Content Editor can scale the Block to fit specific needs.
Additionally, Blocks can be configured to span rows, this enables one Block to be placed next to a few rows containing other Blocks.
Available column spans - Defines one or more columns, the Block spans across. For example: in a 12 columns grid, 6 columns is equivalent to half width. By enabling 6 columns and 12 columns, the Block can be scaled to either half width or full width.
Available row spans - Defines the amount of rows the Block spans across.
These properties refer to how the Block is presented in the Block catalogue when editors choose which Blocks to use for their content.
Background color - Defines a background color to be displayed beneath the icon or thumbnail. Example: #424242
.
Icon color - Changes the color of the Element Type icon. Example: #242424
.
Thumbnail - Pick an image or Scalable Vector Graphics (SVG) file to replace the icon of the Block in the catalogue.
The thumbnails for the catalogue are presented in the format of 16:10. We recommend a resolution of 400px width and 250px height.
Allow in root - Determines whether the Block can be created at the root of your layout. Turn this off if you only want a Block to appear within Block Areas.
Allow in areas - Determines whether the Block can be created inside Areas of other Blocks. If this is turned off it can still be allowed in Block Areas by defining specific allowed Blocks.
Blocks can nest other Blocks to support specific compositions. These compositions can be used as a layout for other Blocks.
To achieve nesting, a Block must have one or more Areas defined. Each Area can contain one or more Blocks.
Each Area has a size, defined by column and rows spans. The grid for the Areas are based on the same amount of columns as your root grid, unless you choose to change it.
To scale an Area, click and drag the scale-button in the bottom-right corner of an Area.
Grid Columns for Areas - Overwrites the amount of columns used for the Area grid.
Areas - Determines whether the Block can be created inside Areas of other Blocks.
Alias - The alias is used to identify this Area. It is being printed by GetBlockGridHTML()
and used as name for the Area slot in Custom Views. The alias is also available for CSS Selectors to target the HTML-Element representing an Area.
Create Button Label - Overwrites the Create Button Label of the Area.
Number of blocks - Determines the total number of Blocks in an Area.
Allowed block types - When this is empty, all Blocks with Permissions for creation in Areas, will be available. This can be overwritten by specifying the allowed Blocks. Define the types of Blocks or Groups of Blocks that are allowed. Additionally, you can also set how many Blocks of each type/group should be present.
When allowing a Group of Blocks, you might want to require a specific amount for a certain Block of that Group. This can be done by adding that Block Type to the list as well and set the requirements.
These properties are relevant when working with custom views or complex projects.
Custom view - Overwrites the AngularJS view for the block presentation in the Content editor. Use this view to make a more visual presentation of the Block or make your own editing experience by adding your own AngularJS controller to the view.
Notice that any styling of a Block is scoped. This means that the default backoffice styles are not present for the view of this Block.
Custom stylesheet - Pick your own stylesheet to be used by the Block in the Content editor.
Overlay editor size - Sets the size for the Content editor overlay for editing this block.
Hide content editor - Hides the UI for editing the content in a Block Editor. This is only relevant if you made a custom view that provides the UI for editing of content.
When viewing a Block Grid property editor in the Content section for the first time, you will be presented with the option to Add content.
Clicking the Add content button opens up the Block Catalogue.
The Block Catalogue looks different depending on the amount of available Blocks and their catalogue appearance.
Click the Block Type you wish to create and a new Block will appear in the layout.
More Blocks can be added to the layout by clicking the Add content button. Alternatively, use the Add content button that appears on hover to add new Blocks between, besides, or above the existing Blocks.
To delete a Block, click the trash icon which appears on the mouse hover.
Blocks can be rearranged using the click and drag feature. Move them up or down to place them in the desired order.
Moving a Block from one Area to another is done in the same way. If a Block is not allowed in the given position, the area will display a red color and not allow the new position.
If a Block has multiple size options it can be scaled via the UI. This appears in the bottom left corner of the Block.
The Block is resized using a click-and-drag feature. Moving the mouse will change the size to the size options closest to the mouse pointer.
Rendering the stored value of your Block Grid property editor can be done in two ways:
You can choose to use the built-in rendering mechanism for rendering Blocks using a Partial View for each block.
The default rendering method is named GetBlockGridHtmlAsync()
and comes with a few options - for example:
In the sample above "myGrid"
is the alias of the Block Grid editor.
If you are using ModelsBuilder, the example will look like this:
To use the GetBlockGridHtmlAsync()
method, you will need to create a Partial View for each Block Type. The Partial View must be named using the alias of the Element Type that is being used as Content Model for the Block Type.
These Partial View files need to go into the Views/Partials/blockgrid/Components/
folder.
Example: Views/Partials/blockgrid/Components/MyElementTypeAliasOfContent.cshtml
.
The Partial Views will receive a model of type Umbraco.Cms.Core.Models.Blocks.BlockGridItem
. This model contains Content
and Settings
from your block, as well as the configured RowSpan
, ColumnSpan
, and Areas
of the Block.
The Partial View for the Block is responsible for rendering its own Block Areas. This is done using another built-in rendering mechanism:
Here you will need to create a Partial View for each Block Type within the Block Area. For the name, use the alias of the Element Type that is being used as Content Model for the Block Type.
These Partial Views must be placed in the same folder as before, (Views/Partials/blockgrid/Components/
), and will receive a model of type Umbraco.Cms.Core.Models.Blocks.BlockGridItem
.
The following is an example of a Partial View for a Block Type of type MyElementTypeAliasOfContent
.
If you are using ModelsBuilder, you can make the property rendering strongly typed by letting your view accept a model of type BlockGridItem<T>
. For example:
Using the default rendering together with your layout stylesheet will provide what you need for rendering the layout.
If you like to use the Default Layout Stylesheet, you must copy the stylesheet to your frontend. You can download the default layout stylesheet from the link within the DataType, we recommend putting the file in the css
folder, example: wwwroot/css/umbraco-blockgridlayout.css
.
A set of built-in Partial Views are responsible for rendering the Blocks and Areas in a Block Grid. If you want to tweak or change the way the Block Grid is rendered, you can use the built-in Partial Views as a template:
Clone the views from <a href="https://github.com/umbraco/Umbraco-CMS/">GitHub</a>
. They can be found in /src/Umbraco.Cms.StaticAssets/Views/Partials/blockgrid/
Copy the cloned views to the local folder Views/Partials/blockgrid/
Make changes to your copied views. The entry point for GetBlockGridHtmlAsync()
is the view default.cshtml
The built-in value converter for the Block Grid property editor lets you use the block data as you like. Call the Value<T>
method with a type of BlockGridModel
to have the stored value returned as a BlockGridModel
instance.
BlockGridModel
contains the Block Grid configuration (like the number of columns as GridColumns
) whilst also being an implementation of IEnumerable<BlockGridItem>
(see details for BlockGridItem
above).
The following example mimics the built-in rendering mechanism for rendering Blocks using Partial Views:
If you do not want to use Partial Views, you can access the block item data directly within your rendering:
The default layout stylesheet is using CSS Grid. This can be modified to fit your implementation and your project.
To make additions or overwrite parts of the default layout stylesheet, import the default stylesheet at the top of your own file.
You need to copy the Default Layout Stylesheet to your frontend. You can download the default layout stylesheet from the link within the DataType, we recommend putting the file in the css
folder, example: wwwroot/css/umbraco-blockgridlayout.css
.
In this case, you would have to write the layout from scratch.
You are free to pick any style, meaning there is no requirement to use CSS Grid. It is, however, recommended to use CSS Grid to ensure complete compatibility with the Umbraco backoffice.
When extending or writing your own layout, you need to know the structure and what data is available.
For example: You can use the below HTML structure:
Building Custom Views for Block representations in Backoffice is based on the same API for all Block Editors.
In this example, we will be creating content programmatically for a "spot" Blocks in a Block Grid.
On a Document Type add a property called blockGrid.
Then add as editor Block Grid.
In the Block Grid add a new block and click to Create new Element Type
Name this element type spotElement with the following properties:
A property called title with the editor of Textstring
A property called text with the editor of Textstring
Then on the Settings model click to add a new Setting.
Then click to Create new Element Type.
Name this element type spotSettings with the following properties:
A property called featured with the editor of True/false.
The raw input data for the spots looks like this:
The resulting JSON object stored for the Block Grid will look like this:
For each item in the raw data, we need to create:
One contentData
entry with the title and text.
One settingsData
entry with the featured value (the checkbox expects "0"
or "1"
as data value).
One layout
entry with the desired column and row spans.
All contentData
and layoutData
entries need their own unique Udi
as well as the ID (key) of their corresponding Element Types. In this sample, we only have one Element Type for content (spotElement
) and one for settings (spotSettings
). In a real life scenario, there could be any number of Element Type combinations.
First and foremost, we need models to transform the raw data into Block Grid compatible JSON. Create a class called Model.cs containing the following:
For the above code IContent? content = _contentService.GetById(1203);
change the id with your content node that is using the Block Grid.
In order to test this implementation, run the project and add /umbraco/api/blockgridtest/create
after your domain name. If the result shows as Saved then check your content node and you will see the 2 spotElement contents.
This can also be tested via Postman as well if preffered.
Returns: Boolean
Toggle is a standard checkbox which saves either 0 or 1, depending on the checkbox being checked or not.
The Toggle property has a setting which allows you to set the default value of the checkbox, either checked (true) or unchecked (false).
It is also possible to define a label, that will be displayed next to the checkbox on the content.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the .
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the .
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the .
You can use dictionary items to translate the values of a Radiobutton List property editor in a multilingual setup. For more details, see the article.
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the .
Function | Shortcut | Further explanation |
---|
Function | Shortcut |
---|
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the .
See the example below to learn how a value can be added or changed programmatically to a Textarea property. To update a value of a property editor you need the .
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the .
There are built-in property value converters, which means you don't need to worry about writing them yourself or parse the JSON output when choosing "JSON" in the storage type field. Therefore on this page will work out of the box without further ado.
More on working with Tags (query all of them) can be found at the
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the .
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the .
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the .
Blocks - Defines the Block Types available for use in the property. For more information, see .
Block Types are based on . These can be created beforehand or while setting up your Block Types.
Get more tips on how to use AngularJS filters in Umbraco CMS from this community-made .
When a Block is placed in an Area, it will fit to the Areas width. Learn more about .
See the section of this article for an example of how scaling works.
By injecting and into an API controller, we can transform the raw data into Block Grid JSON. It can then be saved to the target content item. Create a class called BlockGridTestController.cs containing the following:
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the .
toggle bold text | Ctrl + B |
toggle italic text | Ctrl + I |
insert link | Ctrl + L | This opens the Select Link interface. |
toggle quote | Ctrl + Q |
toggle code block | Ctrl + K |
insert image | Ctrl + G | This opens the Select Media interface. |
toggle ordered list | Ctrl + O |
toggle unordered list | Ctrl + U |
toggle heading | Ctrl + H | This toggles between h1, h2 and off. |
toggle a hr |
undo | Ctrl + Z |
redo | Ctrl + Y |
select all | Ctrl + A |
copy | Ctrl + C |
paste | Ctrl + V |
Previous versions of Umbraco used AngularJS expressions and filters for advanced label rendering.
With the removal of AngularJS in Umbraco 14, this has been replaced using native web components. Advanced label rendering is done using Umbraco Flavored Markdown.
When configuring a Block, the label property allows you to define a label for the appearance of the Block in the editor. The label can use Umbraco Flavored Markdown (UFM) syntax to display values of properties. Example: My Block {=myPropertyAlias}
will be shown as: My Block FooBar
.
Currently, Umbraco 14.1 only supports rendering a block's content properties. Special variables like $index
, $contentTypeName
, $settings
, and so on will be expanded in upcoming releases.
In the meantime, you can create your own custom UFM components. For more information, see the Umbraco Flavored Markdown article. From there, you will be able to consume the UMB_BLOCK_ENTRY_CONTEXT
to access the entire data of a block item.
Information on how to work with Tiptap extensions in the rich text editor.
The Rich Text Editor (RTE) in Umbraco is based on the open-source editor Tiptap.
Out of the box, Tiptap has limited capabilities and everything is an extension by design. Basic text formatting features such as bold, italic, and underline are their own extensions. This offers great flexibility, making the rich text editor highly configurable. The implementation in Umbraco offers a wide range of built-in extensions to enhance the Tiptap editor capabilities.
Using the same extension points, this article will show you how to add a custom extension to the rich text editor.
Tiptap has a library of supported native extensions. You can find a list of these extensions on the Tiptap website. While many of these are open source, there are also pro extensions available for commercial subscriptions.
There are two types of extension: tiptapExtension
and tiptapToolbarExtension
.
The tiptapExtension
extension is used to register a native Tiptap Extension. These will enhance the capabilities of the rich text editor itself. For example, to enable text formatting, drag-and-drop functionality and spell-checking.
The tiptapToolbarExtension
extension adds a toolbar action that interacts with the Tiptap editor (and native Tiptap extensions).
This example assumes that you will be creating an Umbraco package using the Vite/Lit/TypeScript setup. You can learn how to do this Vite Package Setup article.
In this example, you will take the native Tiptap open-source extension Highlight. Then register it with the rich text editor and add a toolbar button to invoke the Task List action.
Install the Highlight extension from the npm registry.
Create the code to register the native Tiptap extensions in the rich text editor.
Create the toolbar action to invoke the Highlight extension.
Once you have the above code in place, they can be referenced in the package manifest file.
Upon restarting Umbraco, the new extension and toolbar action will be available in the Tiptap Data Type configuration settings.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the Version specific upgrades article.
Schema Alias: Umbraco.RichText
UI Alias: Umb.PropertyEditorUi.TipTap
Returns: HTML
In Umbraco 15, the Rich Text Editor has a new default property editor UI that introduces Tiptap as an alternative.
You can continue to use the TinyMCE UI for the Rich Text Editor. This UI will be removed in Umbraco 16.
Current limitations
The Tiptap UI currently does not support using custom styles for your rich text.
Resizing media images has not been implemented yet.
The Rich Text Editor (RTE) Tiptap property editor is highly configurable and based on Tiptap. Depending on the configuration setup, it provides editors a lot of flexibility when working with content.
Customize everything from toolbar options to editor size to where pasted images are saved.
Use Blocks to define specific parts that can be added as part of the markup of the Rich Text Editor.
Extend the functionality of the Rich Text Editor with extensions.
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the Content Service.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string.
Schema Alias: Umbraco.RichText
UI Alias: Umb.PropertyEditorUi.TinyMCE
Returns: HTML
This article is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice.
The Rich Text Editor (RTE) is highly configurable and based on TinyMCE. Depending on the configuration, it will give your content editors more flexibility when working with content that should be more than plain text.
Are you using custom configurations or plugins with TinyMCE?
In Umbraco 11 the TinyMCE version supported has been upgraded from version 4 to version 6. You need to migrate to the latest version if you are using TinyMCE plugins or custom configuration.
If your site is upgraded from an older version, follow the migration guides below to upgrade the TinyMCE version as well.
Customize everything from toolbar options to editor size to where pasted images are saved.
Use CSS to define specific editor styles and add them as formatting options of the Rich Text Editor.
Use Blocks to define specific parts that can be added as part of the markup of the Rich Text Editor.
Extend the functionality of the Rich Text Editor with plugins.
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the Content Service.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string.
Information on how to work with TinyMCE plugins in the rich text editor.
The Rich Text Editor (RTE) in Umbraco is based on the open source editor TinyMCE. TinyMCE is a highly customizable editor, and it is possible to extend the functionality of the editor by adding plugins.
TinyMCE comes with a lot of plugins out of the box, but it is also possible to create your own plugins. This article will show you how to add a custom plugin to the rich text editor.
TinyMCE has a lot of open-source plugins available. You can find a list of these plugins on the TinyMCE website.
TinyMCE also has a number of premium plugins available. These plugins are only available for paid TinyMCE subscriptions. They can be added to the rich text editor by adding a bit of configuration.
To enable plugins in the rich text editor, you need to add an extension type called tinyMcePlugin
in a manifest file. The manifest file is a JSON file that describes the plugin and how it should be loaded. You can add a plugin such as the open source Word Count Plugin to the rich text editor. You can also define your own custom plugin to extend the functionality of the editor. This way you can add custom buttons, dialogs, or other features to the editor.
The manifest file should be placed in a folder in App_Plugins/{YourPackageName}
, with the name umbraco-package.json
. Learn how to use the package manifests.
The example above shows how to add the open-source Word Count Plugin to the rich text editor. The plugin is added to the Plugins
array in the configuration. The plugin itself will be shown in the statusbar of the rich text editor, so the statusbar
option is also added to the config
object.
If you want to create your own plugin, you should in general follow the TinyMCE documentation. However, there are a few things you need to be aware of to load the plugin in Umbraco. See the example below.
Load a custom plugin that gives you the ability to interact with the global tinymce
editor object.
Here we are loading a custom plugin called myrteplugin
and adding a button to the editor called myrtebutton
. When the button is clicked, it will insert the text Hello World!
into the editor.
1.Add a manifest file
First we create an umbraco-package.json
file which will contain the manifest for the plugin. This adds a button to the toolbar in the rich text editor, which editors can enable on the Data Type. We are also letting the rich text editor know it should load the plugin from the plugin.js
file.
2.Add the plugin.js file
The plugin.js
file should contain the JavaScript code for the plugin. The file is loaded as a JavaScript module and must export a default class that extends the UmbTinyMcePluginBase
class.
The UmbTinyMcePluginBase
class is a class provided by Umbraco that you can use to create your own plugins. The class is a wrapper around the TinyMCE plugin API. We can use the args
object on the constructor to access the TinyMCE editor instance and other useful properties.
The button must be added to the toolbar in the rich text editor configuration.
You can go to any Document Type that uses the rich text editor and click the button to insert the text Hello World!
after.
You have full access to the tinymce
editor object, so you can create any custom functionality you need.
To add a premium plugin, you need to add the plugin name to the plugins
array in the config
object of a tinyMcePlugin
extension. You also need to add a JavaScript module that can load up the cloud-hosted TinyMCE premium plugins bundle.
Premium plugins require a subscription at TinyMCE Cloud. You can go there and sign up for a free trial. You will get a Cloud API key that you can use to try out the premium plugins.
Declaring the plugin
Let us first add the powerpaste plugin to the rich text editor. This plugin is a premium plugin that helps you paste content from Word documents and other sources. We will configure the plugin to allow local images and clean the HTML when pasting Word documents.
Creating the plugin.js file
The plugin.js
file should contain the JavaScript code to load the cloud-hosted TinyMCE premium plugins bundle. You must replace {Cloud API Key}
with your own Cloud API key.
We have now enabled the powerpaste
plugin. We have configured it to allow pasting in local images. It will prompt when pasting Word documents, but for HTML documents it will clean the HTML without prompting.
You can enable as many plugins as you want through the plugins
array in the config
object. You can even combine premium, open-source, and your own plugins as you see fit.
See all the available premium plugins on the TinyMCE website.
In this article you can learn about the different options you have for configuring the Rich Text Editor (RTE).
You have full control over which options should be available on the RTE.
In the example above, all 27 options have been enabled. These options include font styles like bold and italics, bullet lists, and options to embed videos and insert images.
You can customize the look of the toolbar:
Enhance the capabilities of the toolbar by enabling or disabling extensions.
Use the Toolbar designer to group together items and add additional rows if needed.
Define height
and width
of the editor displayed in the content section.
Define the maximum size for images added through the Rich Text Editor.
If inserted images are larger than the dimensions defined here, the images will be resized automatically.
Select the width of the link picker overlay. The overlay size comes in three sizes: Small, Medium, Large, and Full.
Blocks can be added as elements in the Rich Text Editor. Configuration and rendering of Blocks are described in the Blocks in Rich Text Editor article.
Images added through the RTE are by default added to the root of the Media library.
Sometimes you might want to add the images to a specific folder. This folder can be configured using the "Image Upload Folder" setting.
Some of the backoffice users might be restricted to a specific part of the content tree. When the "Ignore User Start Nodes" is checked, the users can pick any piece of content from the content tree, when adding internal links through the RTE.
An intro to achieving content variance at block level.
In a variant context, a Block Editor behaves like any other Umbraco property editor by default. The Blocks contained within the editor "belong" to the Document variant, and there is no connection between Blocks across variants.
In other words, both Block content and structure can vary between each Document variant.
This is the desired behavior for many cases. However, in some cases it is preferable to have a shared Block structure across all variants, where only the Block content varies.
This is known as Block Level Variance:
Block Level Variance is achieved when:
The Document Type is configured for variance, and
The Block Editor property is not configured for variance, and
The Block Editor property editor is configured to use Element Types that do vary.
When adding a new variant Block to one Document variant, it is automatically added to all variants of the Document.
The Block will start out in an "unexposed" state for all other Document variants than the one where it was added. It will remain like that for each variant until it is edited in that variant.
The "unexposed" state is visualized by a dimmed-down icon and title (or likely a missing title, if Umbraco Flavored Markdown is used):
"Unexposed" Blocks are omitted from the published Document output. So, you do not need to worry about defensive coding to avoid rendering these Blocks.
It is entirely possible to mix and match variance and invariance within the scope of Block Level Variance. Invariance is fully supported, both at Block level and at Block property level.
Invariance within Block Level Variance follows the same rules as invariance at Document level:
Invariant content is added to and updated across all Document variants.
Invariant content is explicitly published for all published Document variants when one or more variants are published.
Consider a Document with English and Danish language variants, which is published in both languages.
An editor opens the English variant.
They add an invariant Block, and
They re-publish the English variant.
Result: The new block will appear in both the English and Danish published content.
An editor opens the Danish variant.
They update an invariant property value in a variant Block, and
They re-publish the Danish variant.
Result: The updated property value appears in both the English and Danish published content.
The Block Editor structure is invariant for Block Level Variance. This means that the structure follows the same rules for invariance as outlined in the section above.
In other words: If an editor changes the order of the Blocks in one Document variant, it changes for all Document variants. The change is applied to all published Document variants, as soon as one or more variants are published.
This article is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice.
It is possible to insert Blocks into the markup of the Rich Text Editor. Block can be created directly inside the Rich Text editor when
You have defined the Block Type as part of the RTE Data Type, and
Enabled the Blocks Toolbar Option.
The Block List property editor is configured in the same way as any standard property editor, via the Data Types admin interface.
To set up your Block List Editor property, create a new Data Type and select Block List from the list of available property editors.
Then you will see the configuration options for a Block List as shown below.
The Data Type editor allows you to configure the following properties:
Available Blocks - Here you will define the Block Types to be available for use in the property. Read more on how to set up Block Types below.
Blocks Live editing mode - Enabling this will edit a Block directly to the Rich Text Editor, making changes appear as you type.
Block Types are Element Types that need to be created before you can start configuring them as Block Types. This can be done either directly from the property editor setup process, or you can set them up beforehand. If they are set beforehand then they need to be added to the Rich Text Editor afterward.
Once you add an Element Type as a Block Type on your Rich Text Editor Data Type you will have options to configure it further.
Each Block has a set of properties that are optional to configure. They are described below.
By configuring the properties in the group you can customize the experience for your editors when they work with blocks in the Content section.
Label - Define a label for the appearance of the Block in the editor. The label can use AngularJS template string syntax to display values of properties. Examples and more details about labels and AngularJS templates.
Display Inline with text - When turned on the Block Element will be able to stay in line with text or other elements. If not the Block will stay on its own line.
Custom view - Overwrite the AngularJS view for the block presentation in the Content editor. Use this to make a more visual presentation of the block or even make your own editing experience by adding your own AngularJS controller to the view.
Custom stylesheet - Pick your own stylesheet to be used for this block in the Content editor. By adding a stylesheet the styling of this block will become scoped. Meaning that backoffice styles are no longer present for the view of this block.
Overlay editor size - Set the size for the Content editor overlay for editing this block.
It is possible to use two separate Element Types for your Block Types. It's required to have one for Content and optional to add one for Settings.
Content model - This presents the Element Type used as a model for the content section of this Block. This cannot be changed, but you can open the Element Type to perform edits or view the properties available. Useful when writing your Label.
Settings model - Add a Settings section to your Block based on a given Element Type. When picked you can open the Element Type or choose to remove the settings section again.
These properties refer to how the Block is presented in the Block catalog when editors choose which Blocks to use for their content.
Background color - Define a background color to be displayed beneath the icon or thumbnail. Eg. #424242
.
Icon Color - Change the color of the Element Type icon. Eg. #242424
.
Thumbnail - Pick an image or Scalable Vector Graphics (SVG) file to replace the icon of this Block in the catalog.
The thumbnails for the catalog are presented in the format of 16:10, and we recommend a resolution of 400px width and 250px height.
These properties are relevant when you work with custom views.
Force hide content editor - If you made a custom view that enables you to edit the content part of a block and you are using default editing mode (not inline) you might want to hide the content editor from the block editor overlay.
To render Blocks in the frontend, you must create Partial Views for each Block.
The Partial Views must be:
Named by the alias of the Element Type that is being used as the Content Model for the Block.
Placed in the folder Views/Partials/RichText/Components/
.
For example, if the Element Type alias of the Content Model is myBlockType
, a Partial View must be created at Views/Partials/RichText/Components/MyBlockType.cshtml
.
The Partial View will receive the model of Umbraco.Cms.Core.Models.Blocks.RichTextBlockItem
. This gives you the option to access properties of the Content and Settings Models of your Block, as illustrated in the following sample:
If you use ModelsBuilder, you can specify the Content Model (and optionally the Settings Model) in the Partial View model. This allows for type-safe access to the Block data.
The following example shows a Partial View of a Block with MyBlockType
as the Content Model and MyBlockSettingsType
as the Settings Model:
Building Custom Views for Block representations in Backoffice is the same for all Block Editors. Read about building a Custom View for Blocks here.
Alias: Umbraco.DropDown.Flexible
Returns: String
or IEnumerable<string>
Displays a list of preset values. Either a single value or multiple values (formatted as a collection of strings) can be returned.
If enabled, editors will be able to select multiple values from the dropdown otherwise only a single value can be selected.
Options are the values which are shown in the dropdown list. You can add, edit, or remove values here.
You can use dictionary items to translate the options in a Dropdown property editor in a multilingual setup. For more details, see the Creating a Multilingual Site article.
See the example below to see how a value can be added or changed programmatically. To update a value of a property editor you need the Content Service.
The example below demonstrates how to add values programmatically using a Razor view. However, this is used for illustrative purposes only and is not the recommended method for production environments.
Although the use of a GUID is preferable, you can also use the numeric ID to get the page:
If Modelsbuilder is enabled you can get the alias of the desired property without using a magic string:
Umbraco 15 includes two options for rich text editing: Tiptap and TinyMCE. TinyMCE will eventually be phased out of the CMS.
This article will guide you through switching from TinyMCE UI to the new Tiptap UI.
The following steps will guide you through changing the property editor used for rich text on an existing Document Type.
The first step in this guide is to create a new Rich Text Editor Data Type using the Tiptap property editor.
As an alternative, you can create a new Data Type using the Tiptap property editor when updating the Document Type.
When swapping the UI used for the Rich Text Editor, you may need to reconfigure the toolbar.
Navigate to the Settings section of the Umbraco Backoffice.
Select + next to the Data Types folder.
Select New Data Type....
Give the new Data Type a name.
Click Select a property editor.
Choose Rich Text Editor [Tiptap].
Configure the Data Type to match your needs.
Save the Data Type.
Once you have prepared the new Data Type you need to update the Document Types that should use it.
Expand the Document Types folder.
Select a Document Type that needs to be updated.
Click on the Property used for rich text.
Hover over the selected property editor and click Change.
Search for the newly created Data Type and select it.
Submit the changes.
Save the Document Type.
Repeat steps 2-7 for each Document Type that needs to use the new Data Type.
When you have updated all the relevant Document Types, it is recommended to verify the content that uses the Rich Text Editor.
Alias: Umbraco.BlockList
Returns: IEnumerable<BlockListItem>
This article is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice.
Block List is a list editing property editor, using Element Types to define the list item schema.
The Block List replaces the obsolete Nested Content editor.
The Block List property editor is configured in the same way as any standard property editor, via the Data Types admin interface.
To set up your Block List Editor property, create a new Data Type and select Block List from the list of available property editors.
Then you will see the configuration options for a Block List as shown below.
The Data Type editor allows you to configure the following properties:
Available Blocks - Here you will define the Block Types to be available for use in the property. Read more on how to set up Block Types below.
Amount - Sets the minimum and/or maximum number of blocks that should be allowed in the list.
Single block mode - When in Single block mode, the output will be BlockListItem<>
instead of BlockListModel
Live editing mode - Enabling this will make editing of a block happening directly to the document model, making changes appear as you type.
Inline editing mode - Enabling this will change editing experience to inline, meaning that editing the data of blocks happens at sight as accordions.
Property editor width - Overwrite the width of the property editor. This field takes any valid css value for "max-width".
Block Types are Element Types which need to be created before you can start configuring them as Block Types. This can be done either directly from the property editor setup process, or you can set them up beforehand and add them to the block list after.
Once you have added an element type as a Block Type on your Block List Data Type you will have the option to configure it further.
Each Block has a set of properties that are optional to configure. They are described below.
By configuring the properties in the group you can customize the user experience for your content editors when they work with the blocks in the Content section.
Label - Define a label for the appearance of the Block in the editor. The label can use AngularJS template string syntax to display values of properties. Examples and more details about labels and AngularJS templates.
Custom view - Overwrite the AngularJS view for the block presentation in the Content editor. Use this to make a more visual presentation of the block or even make your own editing experience by adding your own AngularJS controller to the view.
Custom stylesheet - Pick your own stylesheet to be used for this block in the Content editor. By adding a stylesheet the styling of this block will become scoped. Meaning that backoffice styles are no longer present for the view of this block.
Overlay editor size - Set the size for the Content editor overlay for editing this block.
It is possible to use two separate Element Types for your Block Types. Its required to have one for Content and optional to add one for Settings.
Content model - This presents the Element Type used as model for the content section of this Block. This cannot be changed, but you can open the Element Type to perform edits or view the properties available. Useful when writing your Label.
Settings model - Add a Settings section to your Block based on a given Element Type. When picked you can open the Element Type or choose to remove the settings section again.
These properties refer to how the Block is presented in the Block catalogue, when editors choose which Blocks to use for their content.
Background color - Define a background color to be displayed beneath the icon or thumbnail. Eg. #424242
.
Icon color - Change the color of the Element Type icon. Eg. #242424
.
Thumbnail - Pick an image or SVG file to replace the icon of this Block in the catalogue.
The thumbnails for the catalogue are presented in the format of 16:10, and we recommend a resolution of 400px width and 250px height.
These properties are relevant when you work with custom views.
Force hide content editor - If you made a custom view that enables you to edit the content part of a block and you are using default editing mode (not inline) you might want to hide the content-editor from the block editor overlay.
When viewing a Block List editor in the Content section for the first time, you will be presented with the option to Add content.
Clicking the Add content button brings up the Block Catalogue.
The Block Catalogue looks different depending on the amount of available Blocks and their catalogue appearance.
Click the Block Type you wish to create and a new Block will appear in the list.
Depending on whether your Block List Editor is setup to use default or inline editing mode you will see one of the following things happening:
In default mode you will enter the editing overlay of that Block:
In inline editing mode the new Blocks will expand to show its inline editor:
More Blocks can be added to the list by clicking the Add content button or using the inline Add content button that appears on hover between or above existing Blocks.
To reorder the Blocks, click and drag a Block up or down to place in the desired order.
To delete a Block click the trash-bin icon appearing on hover.
Rendering the stored value of your Block List property can be done in two ways.
You can choose to use the built-in rendering mechanism for rendering blocks via a Partial View for each block.
The default rendering method is named GetBlockListHtml()
and comes with a few options to go with it. The typical use could be:
"MyBlocks" above is the alias for the Block List editor.
If using ModelsBuilder the example can be simplified:
Example:
To make this work you will need to create a Partial View for each block, named by the alias of the Element Type that is being used as Content Model.
These partial views must be placed in this folder: Views/Partials/BlockList/Components/
. Example: Views/Partials/BlockList/Components/MyElementTypeAliasOfContent.cshtml
.
A Partial View will receive the model of Umbraco.Core.Models.Blocks.BlockListItem
. This gives you the option to access properties of the Content and Settings section of your Block.
In the following example of a Partial view for a Block Type, please note that the MyElementTypeAliasOfContent
and MyElementTypeAliasOfSettings
should correspond with the selected Element Type Alias for the given model in your case.
Example:
With ModelsBuilder:
A built-in value converter is available to use the data as you like. Call the Value<T>
method with a generic type of IEnumerable<BlockListItem>
and the stored value will be returned as a list of BlockListItem
entities.
Example:
Each item is a BlockListItem
entity that contains two main properties Content
and Settings
. Each of these is a IPublishedElement
which means you can use all the value converters you are used to using.
Example:
In some cases, you might want to use the Block List Editor to hold some data and not necessarily render a view since the data should be presented in different areas on a page. An example could be a product page with variants stored in a Block List Editor.
In this case, you can extract the variant's data using the following, which returns IEnumerable<IPublishedElement>
.
Example:
If using ModelsBuilder the example can be simplified:
Example:
If you know the Block List Editor only uses a single block, you can cast the collection to a specific type T
using .OfType<T>()
otherwise the return value will be IEnumerable<IPublishedElement>
.
Building Custom Views for Block representations in Backoffice is the same for all Block Editors. Read about building a Custom View for Blocks here
It is possible to define specific styles and fonts for the Rich Text Editor (RTE). Once you have defined the styles, and enabled them on the RTE Data Type, the styles can be accessed directly in the Content section.
The RTE styles are created and managed in the Umbraco backoffice.
Find the Stylesheets folder in the Settings section.
Click ... next to the Stylesheets folder and select Create....
Choose New Rich Text Editor style sheet file.
Give the new stylesheet a name and Save it.
This will generate an empty CSS file in your project.
At this point, you can start adding specific styles, that your editors can then use in the Content section when creating and writing new content.
The image above is an example of how an RTE style can be configured. When working with these styles, the Preview feature will show you how the style will look when applied.
Every style you add, will automatically be added to the CSS file. The file will be placed in the same location as the rest of your CSS files. It is possible to edit the file directly from the backoffice as well. Access it from the Code tab in the top-right corner.
In order for your editors to be able to use the styles when working with content, two things needs to be done.
The styles will be accessed by the editors using the "Formats" dropdown in the toolbar of the RTE. In order the enable the dropdown, the "Style select" toolbar option needs to be checked.
This can be done by accessing the RTE Data Type directly from the "Info" tab on the Content. You can also find the RTE Data Type in the Settings section of the backoffice and make the changes from there. Learn more about the configuration options in the RTE Config article.
You can have as many different styles for your RTEs as you want. You might want to have different styles for different RTE Data Types.
When configuring your RTE Data Types, you can select which stylesheets your content editors should be able to use.
This article is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice.
It is possible to insert Blocks into the markup of the Rich Text Editor (RTE). Once you've defined the Block Type as part of the RTE Data Type and enabled the Blocks Toolbar Option. Then Blocks can be created directly inside the Rich Text Editor.
The Block List property editor is configured in the same way as any standard property editor, via the Data Types admin interface.
To set up your Block List Editor property, create a new Data Type and select Block List from the list of available property editors.
Then you will see the configuration options for a Block List as shown below.
The Data Type editor allows you to configure the following properties:
Available Blocks - Here you will define the Block Types to be available for use in the property. Read more on how to set up Block Types below.
Blocks Live editing mode - Enabling this will make editing of a Block happen directly to the Rich Text Editor, making changes appear as you type.
Block Types are Element Types that need to be created before you can start configuring them as Block Types. This can be done either directly from the property editor setup process, or you can set them up beforehand. If they are set beforehand then they need to be added to the Rich Text Editor afterward.
Once you add an Element Type as a Block Type on your Rich Text Editor Data Type you will have options to configure it further.
Each Block has a set of properties that are optional to configure. They are described below.
By configuring the properties in the group you can customize the user experience for your content editors when they work with the blocks in the Content section.
Label - Define a label for the appearance of the Block in the editor. The label can use AngularJS template string syntax to display values of properties. Examples and more details about labels and AngularJS templates.
Display Inline with text - When turned on the Block Element will be able to stay in line with text or other elements. If not the Block will stay on its own line.
Custom view - Overwrite the AngularJS view for the block presentation in the Content editor. Use this to make a more visual presentation of the block or even make your own editing experience by adding your own AngularJS controller to the view.
Custom stylesheet - Pick your own stylesheet to be used for this block in the Content editor. By adding a stylesheet the styling of this block will become scoped. Meaning that backoffice styles are no longer present for the view of this block.
Overlay editor size - Set the size for the Content editor overlay for editing this block.
It is possible to use two separate Element Types for your Block Types. It's required to have one for Content and optional to add one for Settings.
Content model - This presents the Element Type used as a model for the content section of this Block. This cannot be changed, but you can open the Element Type to perform edits or view the properties available. Useful when writing your Label.
Settings model - Add a Settings section to your Block based on a given Element Type. When picked you can open the Element Type or choose to remove the settings section again.
These properties refer to how the Block is presented in the Block catalog when editors choose which Blocks to use for their content.
Background color - Define a background color to be displayed beneath the icon or thumbnail. Eg. #424242
.
Icon Color - Change the color of the Element Type icon. Eg. #242424
.
Thumbnail - Pick an image or Scalable Vector Graphics (SVG) file to replace the icon of this Block in the catalog.
The thumbnails for the catalog are presented in the format of 16:10, and we recommend a resolution of 400px width and 250px height.
These properties are relevant when you work with custom views.
Force hide content editor - If you made a custom view that enables you to edit the content part of a block and you are using default editing mode (not inline) you might want to hide the content editor from the block editor overlay.
To render Blocks in the frontend, you must create Partial Views for each Block.
The Partial Views must be:
Named by the alias of the Element Type that is being used as the Content Model for the Block.
Placed in the folder Views/Partials/RichText/Components/
.
For example, if the Element Type alias of the Content Model is myBlockType
, a Partial View must be created at Views/Partials/RichText/Components/MyBlockType.cshtml
.
The Partial View will receive the model of Umbraco.Cms.Core.Models.Blocks.RichTextBlockItem
. This gives you the option to access properties of the Content and Settings Models of your Block, as illustrated in the following sample:
If you use ModelsBuilder, you can specify the Content Model (and optionally the Settings Model) in the Partial View model. This allows for type-safe access to the Block data.
The following example shows a Partial View of a Block with MyBlockType
as Content Model and MyBlockSettingsType
as Settings Model:
Building Custom Views for Block representations in Backoffice is the same for all Block Editors. Read about building a Custom View for Blocks here.
In this article, you will learn about different ways to configure the Rich Text Editor (RTE).
You have full control over which options should be available on the RTE.
In the example above, all 34 options have been enabled. These options include copy/paste buttons, font styles like bold and italics, bullet lists, and options to embed videos and insert images.
It is possible to define specific styles that can be used when editing content using the RTE. You can use as many of these styles with the RTE as you want.
The RTE styles are defined in CSS files which can be created in the Settings section. Read the RTE Styles article to learn more about this feature.
Define the height
and width
of the editor displayed in the Content section.
Define the maximum size for images added through the Rich Text Editor.
If inserted images are larger than the dimensions defined here, the images will be resized automatically.
The Rich Text Editor comes in two different modes: Classic and Inline.
The default mode which displays the toolbar at the top.
In this mode, the toolbar is hidden and only shows up when content in the editor is highlighted.
Blocks can be added as elements in the Rich Text Editor. Configuration and rendering of Blocks are described in the Blocks in Rich Text Editor article.
Select the width of the link picker overlay. The overlay size comes in three sizes: Small, Medium, and Large.
When this option is checked the label and description for the RTE property will be hidden.
Some backoffice users might be restricted to specific parts of the Content tree. When the "Ignore User Start Nodes" option is checked, users can pick any piece of content, when adding internal links.
Images added through the RTE are by default added to the root of the Media library.
Sometimes you might want to add the images to a specific folder. This folder can be configured using the "Image Upload Folder" setting.
The following example uses IPublishedSnapshotAccessor
, which is obsolete in Umbraco 15 and will be removed in a future version. For more information, see the article.