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...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Schema Alias: Umbraco.CheckBoxList
UI Alias: Umb.PropertyEditorUi.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.
You can use dictionary items to translate the options in a Checkbox List 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:
Learn more about the default property editors that ships with an Umbraco installation.
A Property Editor is the editor that a Data Type references. A Data Type is defined by a user in the Umbraco backoffice and references a Property Editor. In Umbraco a Property Editor is defined in a JSON manifest file and associated JavaScript files.
Are you looking for the Grid Layout or Nested Content?
The following Property Editors have been removed with the release of Umbraco 14:
Grid Layout
Nested content
We recommend using the Block Editor or the Rich Text Editor Blocks instead.
When creating a Data Type, specify the property editor for the Data Type to use by selecting from the "Property editor" list (as shown below).
Umbraco comes pre-installed with many useful property editors.
Schema Alias: Umbraco.ColorPicker
UI Alias: Umb.PropertyEditorUi.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.
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.ContentPicker
UI Alias: Umb.PropertyEditorUi.DocumentPicker
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:
Learn more about the Umbraco backoffice which is the admin side of your Umbraco website
In this article you can learn more about the common terms and concepts that are used throughout the Umbraco backoffice.
When you go to the backoffice for the first time, you're presented with the login screen.
Read more about the login screen.
A section in Umbraco is where you do specific tasks related to that section. For example Content, Settings and Users. You can navigate between the different sections of the backoffice by clicking the corresponding icon in the section menu.
The Section menu is the horizontal menu located on the top of the backoffice.
Read more about the section menu.
A tree is a hierarchical list of items related (and usually restricted) to a specific concept, like for example content or media.
A node is an item in a tree. Media section items appear as nodes in the Media tree, while pages and content are displayed in the Content tree, and so on.
A dashboard is the main view you are presented with when entering a section within the backoffice. It can be used to show valuable information to the users of the system.
An editor is what you use to edit different items within the backoffice. There are editors specific to editing stylesheets, there are editors for editing Partial Views, and so forth.
Content is what you find in the Content section. Each item in the tree is called a content node. Each content node in the content tree consists of different fields, and each of them is defined by a Document Type.
Document Types define the types of content nodes that backoffice users can create in the content tree. Each Document Type contains different properties. Each property has a specific Data Type for example text or number.
Every Document Type has properties. These are the fields that the content editor is allowed to edit for the content node.
Each Document Type property has a Data Type that defines the type of input of that property. Data Types reference a Property Editor and are configured in the Umbraco backoffice in the Settings section. A Data Type can be something basic (text string, number, true/false) or more complex (multi-node tree picker, image cropper, etc).
A property editor is a view used by Data Types to insert content into Umbraco. An example of a property editor is the Textarea. It's possible to have many Textarea Data Types with different settings that all use the Textarea property editor.
Read more about Property Editors
Media items are used to store assets like images and video within the Media section and can be referenced from your content.
Media Types are similar to Document Types in Umbraco, except they are specifically for media items in the Media section.
Umbraco includes the following default Media Types - Article, Audio, File, Folder, Image, Vector Graphics (SVG), and Video.
A member is someone who has access to signup, register, and login into your public website and is not to be confused with Users.
Similar to a Document Type and a Media Type. You are able to define custom properties to store on a member such as Twitter username or website URL.
A Template is where you define the HTML markup of your website and also where you output the data from your content nodes.
A package is the Umbraco term for an add-on or plugin used to extend the core functionalities in Umbraco. The packages can be found on the Umbraco Marketplace, and the can also be browsed directly in the backoffice of the Umbraco CMS.
A user is someone who has access to the Umbraco backoffice and is not to be confused with Members. When Umbraco has been installed a user will automatically be generated with the login (email) and password entered during installation. Users can be created, edited, and managed in the User section.
Document Blueprint provide a blueprint for content nodes based on an existing node.
Schema Alias: Umbraco.ListView
UI Alias: Umb.PropertyEditorUi.Collection
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.
Schema Alias: Umbraco.ContentPicker
UI Alias: Umb.PropertyEditorUi.DocumentPicker
Returns: IPublishedContent
The Document Picker opens a panel to pick a specific page from the content structure. The value saved is the selected nodes UDI.
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.
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:
In this article you can learn more about the various sections you can find within the Umbraco Backoffice.
A section in Umbraco is where you perform specific tasks related to a particular area of Umbraco. For example, Content, Settings, and Users are all sections. You can navigate between the different sections by clicking the corresponding icon in the section menu positioned at the top of the Backoffice.
Below is a short overview of the default sections in Umbraco CMS:
The Content section contains the content nodes that make up the website. Content is displayed as nodes in the Content tree.
Nodes in Umbraco can display the following content states:
Grayed-out nodes are not published yet.
To create content, you must define it using Document Types.
For more information, see the Defining Content article.
The Media section contains the media for the website. You can create folders and upload media files, such as images and PDFs. Additionally, you can customize the existing Media Types or define your own from the Settings section.
For more information, see the Creating Media article.
The Settings section allows you to manage website layout files, languages, media, and content types. It also gives you access to more advanced features such as the Log Viewer and extension insights.
The Settings section consists of:
Structure
Document Types
Media Types
Member Types
Data Types
Languages
Document Blueprints
Templating
Templates (.cshtml
files)
Partial views (.cshtml
files)
Stylesheets (.css
files)
Scripts (.js
files)
Advanced
Relations
Log Viewer
Extension Insights
Webhooks
The Settings section in the Umbraco backoffice has its own set of default dashboards.
For more information, see the Settings Dashboards article.
In this section, you can browse the different packages available for your Umbraco solution. You can also get an overview of all the packages you have installed or created.
For more information, see the Packages article.
The Users section allows administrators to manage user accounts, assign permissions, set user roles, and monitor user activity within the backoffice. It provides control over who can access and modify content, media, and settings in the CMS.
For more information, see the Users article.
The Members section allows to create and manage member profiles, set up member groups, and control Member's access to restricted content on the website.
For more information, see the Members article.
The Dictionary section is where you create and manage Dictionary Items. By managing these dictionary items, you can ensure consistent and efficient content translation and maintenance across different languages.
For more information, see the Dictionary Items article.
To enhance Umbraco's functionality, you can integrate plugins and extensions tailored to specific needs. These add-ons expand Umbraco's capabilities, allowing for a more customized and powerful content management experience.
For example, you can start with core Umbraco features and later decide to integrate additional products. Currently, Umbraco supports add-on products like:
Forms: Simplifies the creation and management of Forms.
Deploy: Facilitates smooth deployment processes.
Workflow: Enhances content workflows and approval processes.
Commerce: Adds e-commerce capabilities to your site.
UI Builder: Helps in designing and customizing the user interface.
When you add an add-on product to Umbraco, it appears in the Backoffice as a new section, seamlessly extending your content management capabilities.
If you wish to explore the unique features and use cases of Umbraco products, see the Exploring the Umbraco Products article.
For more information about extending the Umbraco platform through packages and integrations, see the Umbraco DXP documentation.
The Help section in Umbraco provides documentation and resources to assist in understanding and effectively using the Umbraco CMS. It typically includes the following in the Getting Started Dashboard:
Documentation: Comprehensive guides, tutorials, and references covering different aspects of Umbraco.
Community Forums: Access to forums where you can ask questions, share knowledge, and seek assistance from other Umbraco community members.
Resources: Stay updated with the latest news, access documentation, watch free video tutorials, and register for live demos.
Training: Learn how to effectively use Umbraco through structured courses, webinars, and hands-on tutorials designed to enhance your proficiency with the CMS.
The Help section serves as a valuable resource hub in navigating and leveraging the capabilities of the Umbraco CMS effectively.
Along with the default sections that come with Umbraco, you can create your own Custom Sections.
A User can access a particular section based on the User Group permissions.
Learn more about how to configure the permissions in the article about backoffice users.
Schema Alias: Umbraco.DateTime
UI Alias: Umb.PropertyEditorUi.DatePicker
Returns: Date
Displays a calendar UI for selecting dates which are saved as a DateTime value.
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 MomentJS.com for the supported formats.
See Common pitfalls for more information about why the dynamic approach is obsolete.
Schema Alias: Umbraco.DateTime
UI Alias: Umb.PropertyEditorUi.DatePicker
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.
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 MomentJS.com for the supported formats.
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.
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:
In this article you can learn how to use the build in email property editor
Schema Alias: Umbraco.EmailAddress
UI Alias: Umb.PropertyEditorUi.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.
Schema Alias: Umbraco.Decimal
UI Alias: Umb.PropertyEditorUi.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:
Schema Alias: Umbraco.ImageCropper
UI Alias: Umb.PropertyEditorUi.ImageCropper
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 .
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.
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
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:
Schema Alias: Umbraco.Label
UI Alias: Umb.PropertyEditorUi.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:
Schema Alias: Umbraco.ColorPicker.EyeDropper
UI Alias: Umb.PropertyEditorUi.EyeDropper
Returns: string
The Eye Dropper Color picker allows you to choose a color from the full color spectrum using HEX and RGBA.
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.MultiUrlPicker
UI Alias: Umb.PropertyEditorUi.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
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.MediaPicker3
UI Alias: Umb.PropertyEditorUi.MediaPicker
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:
Schema Alias: Umbraco.UploadField
UI Alias: Umb.PropertyEditorUi.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 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.
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.MemberPicker
UI Alias: Umb.PropertyEditorUi.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.
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.MarkdownEditor
UI Alias: Umb.PropertyEditorUi.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:
Schema Alias: Umbraco.MultipleTextstring
UI Alias: Umb.PropertyEditorUi.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:
Schema Alias: Umbraco.MemberGroupPicker
UI Alias: Umb.PropertyEditorUi.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:
You can expand trees by clicking the side arrow to the left of the node.
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:
Nodes that are currently locked using the Public Access feature.
Content nodes that contain a collection of nodes.
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 .
To update a content property value you need the .
Below the example to output a PNG using ImageSharp.Web command.
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 .
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 .
Instead, we recommend using the 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 and 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 .
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 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 .
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 |
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.
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.
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.
Schema Alias: Umbraco.Slider
UI Alias: Umb.PropertyEditorUi.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.
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.Tags
UI Alias: Umb.PropertyEditorUi.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.
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 the last code example on this page will work out of the box without further ado.
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:
More on working with Tags (query all of them) can be found at the UmbracoHelper reference page
Schema Alias: Umbraco.TrueFalse
UI Alias: Umb.PropertyEditorUi.Toggle
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.
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:
How to use the TextBox property editors in Umbraco CMS.
Schema Alias: Umbraco.TextBox
UI Alias: Umb.PropertyEditorUi.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.
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.Integer
UI Alias: Umb.PropertyEditorUi.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:
Schema Alias: Umbraco.RadioButtonList
UI Alias: Umb.PropertyEditorUi.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.
You can use dictionary items to translate the values of a Radiobutton List 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:
Schema Alias: Umbraco.UserPicker
UI Alias: Umb.PropertyEditorUi.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.
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.TextArea
UI Alias: Umb.PropertyEditorUi.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.
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 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.DropDown.Flexible
UI Alias: Umb.PropertyEditorUi.Dropdown
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:
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.
Schema Alias: Umbraco.BlockList
UI Alias: Umb.PropertyEditorUi.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
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.
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.
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.
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.
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.
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.
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:
Information on using the Umbraco log viewer
Umbraco ships with a built-in Log Viewer feature. This allows you to filter and view log entries and perform much more complex search queries. This helps you find the log entries that you are interested in. You can find the Log viewer in the Settings section.
Have you ever wanted to find all log entries which contain the same request ID? Or find all items in the log where a property called duration is greater than 1000ms?
With the power of structured logging and a query language, we are able to search and find log items for specific scenarios. When debugging the site you should now have more power to see and find patterns in your log files and get rid of those errors.
Here are a handful of example queries to get you started, however, the saved searches contain some further examples. For more details on the syntax head over to the https://github.com/serilog/serilog-filters-expressions project.
Find all logs that are from the namespace 'Umbraco.Core'
StartsWith(SourceContext, 'Umbraco.Core')
\
Find all logs that have the property 'Duration' and the duration is greater than 1000ms
Has(Duration) and Duration > 1000
\
Find all logs where the message has localhost in it with SQL like
@Message like '%localhost%'
\
Sometimes you want to use a custom query more often. It is possible to save a query and use the dropdown to re-use your saved search. To add a new saved search, use the search box to type your query and click the star icon. In doing so you can give it a friendly name. The saved queries are saved in the database in the table umbracoLogViewerQuery
.
With the flexibility of Umbraco, we give you the power to implement your own ILogViewer
. This makes it possible to fetch logs and the saved searches from a different location such as Azure table storage.
To do this we can implement a base class SerilogLogViewerSourceBase
from Umbraco.Cms.Core.Logging.Viewer
like so.
This uses the Azure.Data.Tables
NuGet package.
Keep in mind that we have to implement our own version of a LogEventEntity
. This is because the TableClient
needs whatever it is fetching to implement the ITableEntity
interface.
Umbraco needs to be made aware that there is a new implementation of an ILogViewer
to register. We also need to replace the default JSON LogViewer that we ship in the core of Umbraco.
Now with the above two classes, we have the plumbing in place to view logs from an Azure Table. However, we are not persisting our logs into the Azure table storage account. So we need to configure the Serilog logging pipeline to store our logs in Azure table storage.
Install Serilog.Sinks.AzureTableStorage from Nuget
Add a new sink to the appsettings with credentials (so logs persist to Azure)
This is a desktop tool for viewing & querying JSON log files from disk in the same way as the built-in logviewer dashboard of Umbraco.
In this article you can learn the various ways of customizing the Umbraco backoffice login screen and form.
To access the backoffice, you will need to login. You can do this by adding /umbraco
at the end of your website URL, for example http://mywebsite.com/umbraco
.
You will be presented with a login form similar to this:
The login screen contains a short greeting, a login form and an optional Forgotten password link.
Below, you will find instructions on how to customize the login screen.
The login screen features a greeting text: The "Welcome" headline. This can be personalized by overriding the existing language translation keys.
To do this follow the steps below:
Register a 'localization' manifest for the default language of your Umbraco site, (usually en-US) to override the greetings.
Add an en-us.js
file containing the following:
This will override the default greetings with the ones you provide. The login screen will now display "It is Sunday" instead of "Welcome" for example.
The Forgotten password? link allows your backoffice users to reset their password. To use this feature, you will need to add the following key to the Umbraco.Cms.Security
section in the appsettings.json
file:
Set it to true
to enable the password reset feature, and false
to disable the feature.
You will also need to configure a Simple Mail Transfer Protocol (SMTP) server in your appsettings.json
file. When you get a successful result on the SMTP configuration when running a health check in the backoffice, you are good to go!
An example:
It is possible to customize the background image and the logo for the backoffice login screen by adding the "Content"
section in the appsettings.json
file:
The LoginBackgroundImage
, LoginLogoImage
, and LoginLogoImageAlternative
are referenced from the /wwwroot/umbraco/
folder.
The LoginLogoImage
is displayed on top of the LoginBackgroundImage
and the LoginLogoImageAlternative
is displayed when the LoginLogoImage
is not available, for example on small resolutions.
You can also customize the login screen by adding a custom CSS file. To do this, you will need to add a new file inside the ~/App_Plugins
folder, for example ~/App_Plugins/Login/my-custom-login-screen.css
.
You can then add your custom CSS to the file:
This will change the color of the SVG graphics (curves) shown on the login screen. You can also hide the curves by adding the following CSS:
To tell Umbraco about your custom CSS file, you will need to add a umbraco-package.json
file. The umbraco-package.json
file should look like this:
Next add a JavaScript file, for example ~/App_Plugins/Login/my-custom-login-screen.js
, and add the following code to load the custom CSS file:
This will load the custom CSS file into Umbraco.
Be aware that the custom CSS file will be loaded on all Umbraco screens, not only the login screen.
The following CSS properties are available for customization:
The time out screen is displayed when the user has been inactive for a certain amount of time. The screen resembles the login screen in many ways and the two are sometimes confused. The most notable difference is that the time out screen does not have a login form. It only has a message and a button to log in again with Umbraco.
If you have added more than one login provider, the users will also see this screen first. This is because they need to choose which provider to use first. In that case, the screen is also referred to as the Choose provider screen.
You can customize the time out screen in the same way as the login screen. The time out screen uses the same localization files as the rest of the Backoffice and not those of the login screen. The notable difference is that the time out screen is scoped to the login
section. The login screen is scoped to the auth
section of the localization files.
To update the greeting message on this screen, you will have to change the section to login
:
The en-us.js
file should contain the following:
The instruction
key is shown when the user has timed out, and the greeting0..6
keys are shown when the user has to choose a login provider.
You can update the image on the time out screen through a custom CSS variable. The default value is --umb-login-image
and it is set to the same value as the login screen. You can override this value in your custom CSS file:
Schema Alias: Umbraco.BlockGrid
UI Alias: Umb.PropertyEditorUi.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.
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 . 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 . 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.
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 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 also has a number of available. These plugins are only available for . They can be added to the rich text editor by .
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 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 .
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.
Declaring the plugin
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.
This section explains how the concept of infinite editing using the Sidebar in the Umbraco backoffice works.
Sidebar was previously called Infinite editor.
This feature enables you to work with your content without losing the context of what you are doing.
Document Types are in different sections than content but the sidebar enables you to make changes to them directly from the content you are editing.
In the example showcased above, new options are being added to a Data Type, without losing the context of the content. The example also shows how you can edit images, without being sent to the 'Media' section.
The sidebar is a feature that comes out of the box with Umbraco. The feature can be customized, which enables you as a developer to improve the workflow for your editors.
In this article you can learn about how to create and use Document Blueprints in Umbraco.
Document Blueprints was previously called Content Templates.
Document Blueprints allows a content editor to create a blueprint for new content nodes based on an existing node.
Before following this method you should have some created beforehand.
Select a Content node from the Content menu:
Click ... next to the Content node and select the Create Document Blueprint option.
Give your document blueprint a Name:
Click the Save button and if the creation was successful, you will see a success notification:
The new document blueprint will be created in Document Blueprints node of the Settings tree:
Refresh your browser, if you do not see the new document blueprint in the Document Blueprints folder.
Go to the Settings section:
Click ... next to the Document Blueprints tree and select the Create Document Blueprint menu item:
Select the Document Type you want to create a document blueprint for:
You can create document blueprints only from Document Types or Document Types with Templates
Give your document blueprint a Name and click the Save button:
The new document blueprint will be created in Document Blueprints folder of the Settings tree:
To edit an existing document blueprint, select a document blueprint from the Document Blueprints folder of the Settings tree. When you have finished editing click the Save button:
Once you have created a document blueprint, you can use the template to create new content nodes. To use a document blueprint, Click ... next to the Content tree and select Create:
When you click on a Document Type that has a document blueprint, you will see two options:
Create a new node based on a document blueprint
Create a blank one
Learn how to use language variants to output your content in multiple languages.
Language Variants allows you to vary content by culture, so you can allow a content node to exist in multiple languages.
This article will cover the different aspects of enabling and working with language variants on your Umbraco website.
To work with Language Variants you need to have more than one language enabled. This can be done from the Settings
section:
You will always have one default language but each language can be set to mandatory.
Now that there are two languages to vary the content with, it needs to be enabled on the Document Types. To do so:
Go to the Document Type in the structure section.
Open the settings page.
Toggle Allow vary by culture.
To allow a property on the Document Type to be varied it will have to be enabled for the property:
When you return to your content node you will notice two things:
At the top of the Content tree there will now be a dropdown so you can show the Content tree in the language of your choice.
To the right of the content name there is now a dropdown where you can select a language. You can also open a split view so you can see two languages at once.
Each Property Editor that does not allow variants (an Invariant Property) will by default need to be unlocked in order to be edited. The lock exists to make it clear that this change will affect more languages. Since the value of the invariant properties are shared between all variants on the website.
Whether or not the lock is enabled on the invariant properties depends on the AllowEditInvariantFromNonDefault
setting in the appsettings.json
file.
For projects created on Umbraco version 10.2 or later, the setting is true
, by default. If the project is upgraded to version 10.2 or later, the setting will by default be false
.
Culture and hostnames must be added to your language sites before the content can be tested for variants:
Click ... next to the Home node and select Culture and Hostnames.
The Info content app should now show specific URLs for your language variants.
This feature is available from Umbraco version 10.2.
When you are working with a multilingual site you might want to control who can edit the different variations of the content on the website.
This can be controlled on a User Group level. All default User Groups, except the Sensitive data group, have access to all languages out of the box.
When "Allow access to all languages" is not checked, languages can be added and/or removed. This is to determine which variants the users in the user group have access to.
Even though the language permissions have been set, a user will still be able to view and browse all the language variations. The permission setting will ensure that only the added languages are editable by users of the User Group.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
A guide displaying the options available in the Settings section in Umbraco CMS backoffice.
The Settings section of the Umbraco backoffice has its own set of default dashboards. In this article, you can get an overview of each dashboard available in the Settings section:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Building Custom Views for Block representations in Backoffice is the same for all Block Editors. .
The following sink needs to be added to the array .
For more in-depth information about logging and how to configure it, please read the .
The login screen has its own set of localization files independent of the rest of the Backoffice. You can read more about Backoffice localization in the article.
You can customize other text on the login screen as well. First, grab the default values and keys from the in the Umbraco CMS GitHub repository. Thereafter copy the ones you want to translate into ~/App_Plugins/Login/umbraco-package.json
file.
CSS Property | Description | Default Value |
---|
The CSS custom properties may change in future versions of Umbraco. You can always find the latest values in the in the Umbraco CMS GitHub repository.
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 .
The example above shows how to add the open-source 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 . However, there are a few things you need to be aware of to load the plugin in Umbraco. See the example below.
Premium plugins require a subscription at . 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.
Let us first add the 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.
See all the on the TinyMCE website.
Learn more about the AllowEditInvariantFromNonDefault
setting in the article.
To read about how you render variant content in Templates, check out the .
Add a specific URL per language and save. For eg: An English language variant with English (United States) as the language can be given a specific URL and a Danish language variant can be given a specific URL .
For more information about MiniProfiler, see the section in the article.
For more information about Package Telemetry, see the section in the Umbraco 9.2 Release Blog Post.
| The background of the layout |
|
| The color of the headline |
|
| The color of the text |
|
| The font-size of the headline |
|
| The font-size of the headline on large screens |
|
| The font-size of the secondary headline |
|
| The background of the image wrapper |
| The display of the image wrapper |
|
| The border-radius of the image wrapper |
|
| The background of the content wrapper |
|
| The display of the content wrapper |
|
| The width of the content wrapper |
|
| The height of the content wrapper |
|
| The border-radius of the content wrapper |
|
| The align-items of the main wrapper |
|
| The border-radius of the buttons |
|
| The color of the curves |
|
| The display of the curves |
|
The value of the setting