Breaking Free: Troublesome Rich Text
Rich Text or WYSIWYG editors leave the impression to editors that what they see must be how the consuming end user sees it. So much so that an editor may hack a Rich Text field to accomplish the right display of the content on a page.[3]
This leads to complexity that is hard to manage in content that needs to be distributed.
If a field combines the body of content with inserted call-to-actions, tables, pull quotes, and images, it becomes complex to separate it when it needs to be distributed and carry its meaning to the right channels. The Rich Text field doesn't facilitate the ability to use the meaningful parts.
A good way to look at it is:
"If HTML markup and styling were stripped from the rich text field, would any content retain its meaning?"[1]
Content that is tightly coupled with presentation creates issues for it to be portable.
In her book Designing Connected Content, Carrie Hane calls it "Chunking."[2]
She explains that chunks are the smallest form of the defined piece of content. It should aim at what technical writers call "minimum reusable units."
To keep a Rich Text field from hindering portability, there are a few recommendations to keep in mind:
- A defined piece of content needs to be entered into a Rich Text field so that it makes sense on its own. Even if all markup is stripped from the field, it should still retain its meaning
[1]
. - Review the content model to separate things like pull quotes, images, and call-to-actions away from Rich Text fields. An example of this is adding a call-to-action within the content of the Rich Text. It may link to a podcast, an e-learning course, or a product, but it alters the meaning and abstracts away what is being linked.

- Plan a content strategy around rich text fields, defining a consistent process of content creation that fits the niche yet limits the usage of markup that aligns with text portability.
- Pages should be modular without becoming a dumping ground for a Rich Text field. Modular parts can be assembled in the proper presentation at their final distribution.
- Finally, with the Rich Text fields you do have, consider storing that content around the Portable Text Specification. Your current CMS may not support it, so this option may be limited.
Finding a Content Strategy with Rich Text
To carry out a good strategy, it is essential to consider how content editors create content in Rich Text fields. A successful strategy would encompass:
- Understand how content editors create content with Rich Text today. This should involve interviews with content editors, marketing, and other subject matter experts involved in the content creation process. Consider auditing the current usage of Rich Text fields. The goal is to understand how markup is currently used and the use cases.
- Plan for how metadata can be incorporated when creating content. Consider how that may affect the distribution of content to other channels.
- Develop a strategy around these fields that strips down the formatting options so the editor focuses strictly on the written word. Remove the distractions of editors spending too much time formatting content. Start the basic minimum options for Rich Text and add what is necessary. It can be things like:
- You can't change font family, color, or size.
- No table inserts are allowed.
- Limit formatting options to bold, italics,
- Allow only sub-heads (two levels deep), block quotes, and links.
Implementing a Strategy with Rich Text
Sitecore has the ability to configure Rich Text field types with an HTML Editor Profile. It may be tempting to give the editor the full profile. However, as Sitecore moves toward being a content repository with several APIs to get at data, it would be beneficial to consider what is the proper configuration. If the editor needs to create a lot of complex content with a Rich Text field, then that is the complexity you will need to deal with downstream. It may seem that this can indicate that the content model may need to be revisited.
HTML Editor Profiles
The HTML Editor Profiles that are provided in Sitecore are found in the Core database:
/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 editor already is configured with a toolbar that gives us some basic defaults.

This toolbar will get us most of the way there, but a few things need to be addressed to fit our content strategy. We determined we want editors to do the following:
- You can't change font family, color, or size.
- No table inserts are allowed.
- Limit formatting options to bold, italics,
- Allow only sub-heads (two levels deep), block quotes, and links.
What needs to be done is add the ability to insert headings (two levels deep) with reserving the <h1>
tag for the page title. We also need to allow block-quotes and remove the ability to insert symbols. Finally, the toolbar option, Pasting from Microsoft Word, will be removed.
It presents a problem of allowing formatting beyond the ideal state. For example, the editor can write their content in Microsoft Word and use different headings like <h4>
or <h5>
. If it is part of the content strategy to limit the number of headings and believe it is a distraction for the editor.
To make this change, the Rich Text Default profile can be duplicated into a Rich Text Minimal profile

Second, we will need to test along the way. I usually open another browser and log into Content Editor to test Rich Text fields from the content in the Master database. But, we will need to configure a field to use the new HTML Profile we created. To do this go to the data template for the content item that has a Rich Text field and update the Source as with /sitecore/system/Settings/Html Editor Profiles/Rich Text Minimal

If you want to set up this profile for every Rich Text field, the configuration can be updated by patching it follows:
<sitecore>
<settings>
<setting name="HtmlEditor.DefaultProfile" value="/sitecore/system/Settings/Html Editor Profiles/Rich Text Default" />
</settings>
</sitecore>
Now, we can test the toolbar as we make changes.
Next, let's delete paste from Microsoft Word, which will be an option under Toolbar 1

If we test the Rich Text Editor back in our other browser session, we should see the Paste option for Microsoft Word has been removed:

We did find something better that would assist editors in pasting written word from another source: the ability to paste as plain text.
You can create this option from the Html Editor Button
data template, name it Paste Plain Text,
and fill in the click field as PastePlainText

Once this is added, you can test it in the Rich Text Editor:

Next, let's add the ability to manage our headings and block-quotes. We can expand the Paragraphs node and add options for Heading 2, Heading 3, and Blockquote. Notice the fields for Header and Value when creating the option. The Value field will hold the element used to insert the element around the text.

Finally, we just need to add the Format Block with setting the Click field value as FormatBlock

Once this is complete, the Rich Text Minimal profile is where we need it to be:

Handling Access to Markup
Our next task is to lock down the ability to edit markup. Planning out security for Sitecore and roles you can use to assign editors is always recommended. We will use roles to assign permissions to allow functionality for administrators or power users and limit the functionality for editors. In this scenario, you may want to set up another account that would function like a typical editor. In this case, we are using the sitecore\Author
role to assign to our test user.
The Content Editor will add a link above the Rich Text field to allow editing of the markup. This link is where we will add permissions.

Let's configure permissions for this. By going back to the Core database under our Administrator account, we need to find the item Edit Html
. This item can be found under /sitecore/system/Field types/Simple Types/Rich Text/Menu/

Find the Security field and assign security for this item. For the example, sitecore\Author
role was used to limit Read access to this item while allowing sitecore\Sitecore Local Administrators
to have Read access.
Next, open a browser session to log in with your test editor account and test going to a Rich Text field on a content item.

We will notice that Edit HTML
is no longer an option.
Also, the Rich Text Editor will provide a way to toggle between Design and HTML.

This option can be removed completely by deleting HTML View
from the profile.

Once this is deleted (or you can set permissions to not read the item with a defined editor role), the toggles should be removed:

This configuration should carry over to Sitecore Experience Editor.The benefit of Sitecore XM was that configuring a profile for Rich Text fields was only done in one place. However, there is one problem if we take these changes to XM Cloud.
The Trouble With Sitecore Pages in XM Cloud
Sitecore Pages is a much lighter editing interface than Sitecore Experience Editor. It provides inline editing of page content.

In the Skater Park demo site in XM Cloud, the right sidebar provides many formatting options and access to the markup. While Sitecore Pages provides many benefits, it currently does not have options to tailor the Rich Text editing to our content strategy.
It allows the use of <h1>
tags, which breaks our consistency with heading tags and will impact SEO.

Until Sitecore can manage our Rich Text editing profiles across the platform in XM Cloud, our ability to implement our content strategy will be limited.
Summary
In conclusion, optimizing Rich Text fields in Sitecore requires a balance between functionality and control. Limiting formatting options, managing markup access, and tailoring HTML Editor Profiles allow you to streamline the editor experience and ensure content consistency across platforms. While Sitecore’s Rich Text capabilities are robust, aligning them with your content strategy is important to maintain portability and flexibility. Challenges like those found in XM Cloud highlight the need for ongoing adjustments as technology evolves. Implementing these best practices will enhance content creation and improve overall site performance and SEO.
The upcoming blog post will focus on how thinking in the context of structured content can improve content portability. Then we will focus on how we can add Portable Text Specification to Sitecore.
Footnotes:
- Daniel Jacobson, "Content Portability: Building an API is Not Enough", Programmable Web, November 11, 2009
- "Designing Connected Content", Mike Atherton and Carrie Hane, Pearson, 2018, pg 134
- Jeff Eaton, "Inline Editing and the Cost of Leaky Abstractions", December 11, 2012, https://www.lullabot.com/articles/inline-editing-and-the-cost-of-leaky-abstractions