Aug 5, 2016
(4 votes)

Adding ACheck Plugin to Episerver TinyMCE

Every now and then, I get a minor challenge from the sales team. They need to demo something and they don’t have the availability to create or test it out. So they check if I’m willing to do it and, well, it gives me the chance to try something new in Episerver that I’ve not done before. Great! I’m in!

On this occasion, I was tasked with the simple addition of the Accessibility Checker plugin for TinyMCE. Seriously, if you know what you’re doing, this should take only about a quarter of an hour, if that. Since I had never explored this side of things, it took me about two hours to figure it out (and over-come one of those blasted things that, like any developer, was bloody simple and I overlooked the shit out of it).

First off, the resources you’ll want to check out:

First, add the folder structure for the plugin. According to the Episerver documentation (linked above), you have a couple of options. 

The first, and more secure option, is to use a Virtual Directory and map a path for ~Utils/Editor/tinymce/plugins to it (or just map ~/Util and add the rest of the folder structure to that root folder). The only real advantage I see here is that it helps keep the editor files out of the web root. But that’s not something I am worried about for a proof-of-concept.

In my case, I wanted it to be something I could easily zip up and distribute to the sales team. So I opted for simply creating that same folder structure as part of my project.

Download the “achecker” plugin (via the link above), uncompress it, and add it to the plugins folder you just created.

Next, I created the class, which is just an empty class with an attribute used to inform Episerver of the additional plugin and its configuration options. Definitely check out the documentation above for the complete set of options. Mine uses the TinyMCEPluginButton attribute because it’s a visual plugin (it has a button).

using EPiServer.Editor.TinyMCE;

namespace OxxCommerceStarterKit.Web.EditorDescriptors.TinyMcePlugins
        PlugInName = "acheck",
        ButtonName = "acheck",
        GroupName = "misc",
        LanguagePath = "admin/tinymce/plugins/acheck",
        IconUrl = "Editor/tinymce/plugins/acheck/img/acheck.gif",
        Description = "Accessibility Checker",
        DisplayName = "Accessibility Check")]
    public class ACheck

The properties are as follows:

  • PlugInName & ButtonName - These both need to be the same as the name of the plugin being added. If you inspect the *_src.js file of the plugin, you’ll find the plugin being added with a name. There’s also code in the file for adding a named button. I assume these can be different, but it’s likely convention for them to be the same, if this plugin is any example.
  • GroupName - Puts the button into one of the groups in the admin view of Episerver. These really are standard TinyMCE button groups. It doesn’t affect where the button is placed in the toolbar (you get to configure that), but rather where you find the button in order to add it to your custom tools.
  • LanguagePath - If you know Episerver, you know this one. I only configured the English language.
  • I assume Description and DisplayName to be self-explanatory.

Really, the approach taken should work for any plugin. However, there might be compatibility issues or conflicts with the plugins Episerver has created. Still, it’s pretty cool to know that it’s a simple matter of a plugin, a class, and (optionally) a language file to add some new functionality to Episerver.

Relevant source files and basic instructions can be found on Github.

Happy coding.

Aug 05, 2016


Aug 5, 2016 10:38 PM

Love it James!

Aug 8, 2016 04:24 PM

Sweet! I was just wondering how to do those kind of checks as an editor easily...

Please login to comment.
Latest blogs
Zombie Properties want to Eat Your Brains

It’s a story as old as time. You work hard to build a great site. You have all the right properties – with descriptive names – that the content...

Joe Mayberry | Mar 29, 2023 | Syndicated blog

Optimizely finally releases new and improved list properties!

For years, the Generic PropertyList has been widely used, despite it being unsupported. Today a better option is released!

Tomas Hensrud Gulla | Mar 28, 2023 | Syndicated blog

Official List property support

Introduction Until now users were able to store list properties in three ways: Store simple types (int, string, DateTime, double) as native...

Bartosz Sekula | Mar 28, 2023

New dashboard implemented in CMS UI 12.18.0

As part of the CMS UI 12.18.0 release , a new dashboard has been added as a ‘one stop shop’ to enable editors to access all of their content items,...

Matthew Slim | Mar 28, 2023