I really wanted the title of this blog post to be “Customizing the Telerik Rad Editor with DNN to Reinforce Consistent Content Administration Practices for your Content Editors and Other Implications of using Telerik Rad Editor as your Default HTML Editor in DNN” but that may have been a tad too long.

In DotNetNuke 5.4.0, the community edition of the platform included the Telerik RAD Editor. This is an exciting new development for the community edition of DNN. The flexibility of the HTML editor in DNN is one of the most commonly overlooked features. For most content editors, the HTML editor might be their only interaction with the system. For this reason, customizing the HTML editor for your content administrators is crucial to user adoption and creating a friendly workspace for your editors.

This blog entry is going to apply some of the same concepts from a previous blog entry for the FCKEditor, Optimizing the CKEditor for DNN, but as an evaluation of the Telerik RAD Editor for DNN. Chris Hammond introduced how to include these features on your site in a blog on DNN Daily. I’m going to build upon his implementation instruction with some opinionated configuration recommendations.

The Standard Toolbars

The Telerik HTML Editor has a very robust toolbar and many of the features function better than the features of the FCKEditor, but I’m still a firm believer that too many options just causes confusion.

The Telerik HTML Editor comes with a default toolbar configuration called “ToolsDefault.” This default toolbar has every feature turned on and looks like the figure below.

There is a second toolbar configuration file included with the Telerik HTML editor called “ToolsMinimal". This is nice attempt at paring down the toolbar and for demonstration purposes shows how far you can go, but it goes too far and still ignores some large problems (mainly the ability to add inline styling to content).

I like to create a streamlined, reorganized toolbar for users to group like functions and edit out unnecessary features. But first we should look at how you can plug new toolbars into DNN.

*One side note. Switching over to the Telerik provider does exclude you from some of the lesser used features of the FCKEditor. Most notably is the feature to have multiple toolbar configurations based on your role permissions.

To include a modified toolbar in your instance of DNN, you’ll need to do two things 1) create a new toolbar, 2) modify the web.config (create a backup) to use your new toolbar.

Creating a New Toolbar

The toolbar configuration files are located in your DNN file system at the following path [site root]\Providers\HtmlEditorProviders\Telerik\Config. You can simply create a copy of the ToolsDefault.xml file and rename it to your liking.

Setting the New Toolbar as Your Default

To set your new toolbar as default, you simply need to modify the HTMLEditor provider section of your web.config to set the path of the “ToolsFile.”

I combed through the toolbar options and created a custom toolbar that I find most fitting for content administrators. It eliminates the features that would create inline styles, and reorganizes features with like functions.

(Bonus) Define Custom CSS Selectors

One of the major misnomers of HTML editors is that they are perceived to be WYSIWYG. This is true if you can style your site to only use straight HTML tags or if your content editors have a basic, nearing advanced, understanding of HTML and CSS. The Telerik RAD editor now provides you as the site administrator the ability to define a list of CSS classes for which your content editors can apply to content.

The RadEditor now can inherit CSS classes from your site OR, find only classes you define for use. I’d strongly recommend explicitly defining the custom classes you want your editors to use. If you use the ToolsFile to specify the classes, Telerik RadEditor will search only for them, but will list them in the dropdown only if they exist.

To specify the classes you want your editors to use, there is a section in the ToolsFile for in which you can define the classes your wish to use in rich text editing and give them a friendly name.

If you’re going to provide a list of classes for editors to use, I would also recommend discretely calling these classes out in your skin.css. This is primarily for organization, but it can also serve as a way for you to explicitly define the styles you want your users to add/use from the rich text editor. The classes drop down will wrap your content in a span, so be aware that you’re going to be wrapping content in more markup. I’d recommend using this for special styling and try to style semantically correct markup to meet your needs as much as possible.

If you’ve read this far, I’d like your input. When you create a list of classes, should you create list of selectors that are only used by content editors in the rich text editor? Should you reuse classes you’re using for styles throughout the style sheet? Should you use the classes throughout the style sheet, but add a level of specificity – like .editor .button? I’d like to hear from you – leave your comments.