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:

• The official Episerver documentation for adding a TinyMCE plugin
• The download page for the specific TinyMCE plugin I’m adding
• The Commerce Demo Kit project on Episerver’s Github, which has a class you can use as an example. Even though this one is non-visual and the one I’m adding has a button, I found it useful.
• The TinyMCE documentation where I found the AChecker plugin

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
{
    [TinyMCEPluginButton(
        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.