Skip to main content

Getting More from the RTE: Snippets and Styling

Developers often push aside the rich text editor because we would rather of use separate components with data sources. However, sometimes we need to rely on the rich text editor to empower the content editor to edit more directly or to reduce complexity on the page. We can use snippets to reduce complexity or give the editor more options by inserting some predefined HTML into the rich text editor. In this example, we will learn how to get more out of the rich text editor by changing which editor we use, adding new snippets, and styling the added content.

First we need to switch from the default basic rich text editor to either one of the other existing editors or to a custom editor.

The Rich Text Default view - just the basics:

We can change the default editor on a field-by-field basis. Update the Source Property for the Rich Text field so that it references the specific rich text editor we want to use in the core database:

On your template, enter the item path for the editor of your choice into the source field for the rich text field.

For a site-wide approach, you can  change the Sitecore.config file on the setting “HtmlEditor.DefaultProfile” to update all rich text fields by default: 

With the updated rich text editor, we can now see our Snippets Option:

Snippets are simply blocks of raw html that can be placed on the page and controlled in the Core database. Once you know what html you need to add, it’s very easy to create a new one in Core by navigating to the Snippets folder within the Html Editor Profile you’re currently using and either adding it via the menu, or by duplicating and modifying an existing snippet.

Once we save our snippet and head back to the Master DB and open the rich text editor, we’ll see our new Fancy Blockquote Snippet!

Clicking on our new snippet will insert it into the text at the cursor location, but currently it isn’t all that fancy:

We can stop here and call it a day but if we want our styling to appear within the editor as we are editing we need to make a final update to the sitecore stylesheet used by the editor.

To make this update we can either edit the default style sheet (modify default.css) or reference our own to include the styling used by your snippets (and anything else you’d like represented). The stylesheet is defined once again in Sitecore.config as “WebStylesheet.” 

Once the file is updated you’ll immediately see your classes represented in both the page editor preview as well as the editor:

In the editor:
And that’s it - snippets are an easy way to add some quick and editable html! With the updated stylesheet you can view your content appropriately to get a little more mileage from your rich text fields when you need to use them!

Comments

  1. Hi Amy,

    I'm doing exactly the same as you have mentioned above, except that the quote being inserted has p tags and footer tags inside it.

    What I am seeing in the RTE (in some instances - not always) , is that it is reorganizing the mark-up being inserted so that the blockquote tag is around the footer.

    Any ideas as to why this might happen?

    Thanks,

    James.

    ReplyDelete
    Replies
    1. p tags specifically do some weird stuff by default within the editor - i'd limit these custom snippets to html that isn't going to be hit by the filters (p tags, and depending on your config also script tags) - or- you can also override the methods that do this from Sitecore.Shell.Controls.RichTextEditor.EditorConfiguration - but that involves having a custom configuration for your RTE.

      Delete
    2. I have a custom EditorConfiguration where i disabled EditorFilters.ConvertToXhtml but snippets still get code removed or changed. Any idea how to fix with snippets?

      Delete
  2. This comment has been removed by a blog administrator.

    ReplyDelete

Post a Comment

Popular posts from this blog

Using the Source Property

For each of the properties in your template you can set a source for it, this isn’t always used but can improve user experience drastically when done throughout a site. The source field comes in to play whenever you are using any of the following fields: Droplink, Droplist, Droptree, File, Grouped Droplink, Grouped Droplist, Image, Multilist, Treelist, Rich text field and a number of others. There are various ways of setting these up to achieve different results – but in general you are using the source to limit the set of items that can be used, and this requirement can also help you determine what kind of field to use. For example, if you have a Set of items all split down into sub folders and want the content editor to make use of the tree, you could use a TreeList or Drop Tree, but if you just want a set of items without the opportunity to see where those items are – multilists or droplinks are the way to go. For Images you’re generally just specifying where to look for and put th...

Web Forms for Marketers: Send Email

To have the save action for your form actually send email, you will need to change one of the settings, otherwise you will receive this error whenever submitting the form: We experience a technical difficulty while processing your request. Your data may not have been correctly saved. Also in your log (/data/logs/newest log file) you will see this error after the form has been submitted: Exception: System.Net.WebException Message: The remote name could not be resolved: 'example.host' Source: System at System.Net.ServicePoint.GetConnection(PooledStream PooledStream, Object owner, Boolean async, IPAddress& address, Socket& abortSocket, Socket& abortSocket6, Int32 timeout) at System.Net.PooledStream.Activate(Object owningObject, Boolean async, Int32 timeout, GeneralAsyncDelegate asyncCallback) at System.Net.PooledStream.Activate(Object owningObject, GeneralAsyncDelegate asyncCallback) at System.Net.ConnectionPool.GetConnection(Object owningObject, GeneralA...

Determining Page Editor Status with Javascript

     Often you’ll need to know if you are inside or outside the Experience/Page Editor in order perform an action. If you are on the server-side in code-behind you can check the Sitecore.Context.PageMode to determine which mode you are in. But what about at runtime? Javascript per usual can save the day! Though you can find PageModes through the Sitecore object if it is available to the browser, it may not be there. Depending on how things have been set up with your solution, the Sitecore object may not return a null as would be expected when checking to see if you can access it. Instead Sitecore may be undefined.  Contrary to some examples on the web with only null checks, this quick little change in your script can correctly let you know if you are in the page editor: Just take a look to see if isPageEditor is true or false and you’re set!