Optimize the Rich Text Editor in Sitecore

When it comes to building a Sitecore site your first thought probably isn’t that you are going to need to make any setting updates or customization’s to the rich text editor. After all when you learn about building a site its mostly focused around creating components to add and remove from pages, but there are a couple of things that will greatly enhance your content editors experience.

Configure the toolbars

Out the box Sitecore ships with 4 toolbar configurations. These are defined in the core db here:

  • /sitecore/system/Settings/Html Editor Profiles/Rich Text Default
  • /sitecore/system/Settings/Html Editor Profiles/Rich Text Full
  • /sitecore/system/Settings/Html Editor Profiles/Rich Text IDE
  • /sitecore/system/Settings/Html Editor Profiles/Rich Text Medium

The “Rich Text Default” toolbar

Default Toolbar

The “Rich Text Full” toolbar

Full Toolbar

The “Rich Text IDE” toolbar

IDE Toolbar

The “Rich Text Medium” toolbar

Medium Toolbar

As the name suggests, by default your content editors will see the default toolbar that contains a very limited number of options. This may in-fact be to limited and you need to offer the content editors one of the toolbar’s with more options. Equally, the full toolbar may give to many options such as font’s and you would want to offer a more restricted set of options.

Setting a toolbar on a field

You can set a toolbar on each individual field by specifying the path in the template fields source field. This is particularly useful when a field needs specific options, such as a text area that should allow a user to configure bold, italics and links but shouldn’t ever contain an image.

Setting toolbar in on an individual field

Updating the default toolbar for a rich text field

When you want to change the toolbar for all rich text fields, a better option is to update which toolbar is used by default. You can do this with a patch config file.


<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <settings>
      <setting name="HtmlEditor.DefaultProfile" value="/sitecore/system/Settings/Html Editor Profiles/Rich Text Full" />
    </settings>
  </sitecore>
</configuration>

Updating the rich text editor css

A second way of customizing the rich text editor that you should consider is to make changes to the css file that the editor uses. By default this will use a css file called default.css that you will find in the root of the site. You can see this being referenced form a config setting if you look at the showconfig.aspx page.

<!--  WEB SITE STYLESHEET
    CSS file for HTML content of Sitecore database.
    The file pointed to by WebStylesheet setting is automatically included in Html and Rich Text fields.
    By using it, you can make the content of HTML fields look the same as the actual Web Site
-->
<setting name="WebStylesheet" value="/default.css" />

You can change this to use a different css file using a patch config file as follows:


<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <settings>
      <setting name="WebStylesheet">
        <patch:attribute name="value">/rich-text-editor.css</patch:attribute>
      </setting>
    </settings>
  </sitecore>
</configuration>

Now you may be wondering why you would want to do this, after all Sitecore offers an experience editor mode that will show the entire webpage as it will appear to visitors and also offers inline editing. However some aspects of a page can be better achieved using css styles rather than new components or new fields and content editor will need both an easy was to apply these style and a visual way to see that they have been applied, irrespective of if they are using the experience editor or the content editor.

For example, in this section of a blog post from Scott Hanselman he has highlighted some text as an aside which can easily be achieved in a rich text editor by applying a css class.

Hanselman Blog Aside

The first step to enabling this in Sitecore is to make sure you’re using a toolbar that allows the user to select css classes (that’s any but the default).

Next by creating a stylesheet that just contains the relevant style to be applied, the content editor can now select this in the css drop down;

.aside {
    border-left: 2px solid #e2842c;
    background-color: #f7f7f7;
    padding: 5px;
    margin: 5px;
    display: block;
}

CSS drop down

The preview will now also give visual feedback indicating what this is going to look like. It doesn’t have to look exactly like the webpage will, just enough for the content editor to understand.

Rich Text Editor

 

Sitecore Rendering Datasource Restrictions

Datasources on Sitecore Renderings are the basis for content authors to combine a variety of components to form a page, without the need for all the fields to exist in the context item. They also form the underpinnings of switching out content based on personalization rules.

To make life easier for content authors there are two properties which should always be set; Datasource Template and Datasource Location.

Datasource Template

The datasource template field is fairly straightforward to understand. It specifies what type of template is compatible with a rendering.

If the content editor try’s to select an incorrect template they will see an error message like this and the ok button will be disabled:

Incorrect template type

The template reference can point to either the final template that an instance of which will be created, or a template that had been inherited. So if you structure your templates using base template like I describe in my article on How I structure Sitecore Templates then you can reference the base template and anything including it will become available.

However there is a fundamental flaw in linking to a base template. As well as restricting the template that can be selected, specifying the template type also enables the ability to create new content, which will create it as the form of the template specified. So only link to the templates you want your editors to create.

Datasource Location

The datasource location property (as the name suggest) enables you to restrict where in the content tree items can be selected from (or new content created).

Simply specify the folder the content should be placed in and the rest of the content tree will now be hidden from content authors.

Datasource Location Fixed Path

Multi-site solutions

If your solution contains more than one website this may cause a problem as you likely want to be able to restrict certain content to certain sites and may additionally have a global content folder.

Datasource Location Multiple Folders

The first solution to this is to add multiple path’s separated by a pipe.

Datasource Location Multiple Folders Config

This will enable multiple folders to be shown to the user, but it wont enable any sort of restriction.

The second option is to add an xpath query find the relevant folder. This can also be used in conjunction with the static path by being pipe separated as in the last example.

A query like this:

Datasource Location XPath


/sitecore/content/Shared Components/Shared Hero Banners|query:./ancestor-or-self::*[@@templatename='Site']/Components/*[@@templatename='Hero Banners']

Will produce the desired output like this:

Datasource Location XPath Result

Here you can see the shared hero banners folder is available as is the specific hero banner folder for the current site, but not the hero banner folder from the other site.

Using template source restrictions in Sitecore

The source field on a template definition is a great and easy way to enhance your content editors experience.

With fields types such as a tree list, this can be used to restrict the content tree to the section that is relevant. e.g.

Adding a source property like this:

Source Restriction

Will change how a tree list displays from this:

Unrestricted Tree List

To this:

Restricted Tree List

Multi-Site Solutions

The source field however is far more powerful than just pasting in a fixed path to an item. Rather than a static path you can use xpath to make the results based on a query, such as restricting options on a droplink by template type.

In a multi-site solution this is particularly useful, by restricting the options to the site that your content item is on.

With a fixed path the best we could do in the above example would be to set the restriction to the nearest folder that could access both, resulting in a restriction like this:

Fixed restriction showing both sites

While this makes some improvement for the user, but not hugely and they can still select content from the wrong site.

By using an xpath query that utilizes the ancestor-or-self function with a template name, the restriction will dynamically be based on navigating up the content tree from the current item until the template is found and then showing items from it or in this example going back down to the home item.


query:ancestor-or-self::*[@@templatename='Site']/Home

Resulting in an output like the original example, but dynamically changing to be the correct items for where the current content item is located:

Treelist with dynamic restriction