Creating an inline editor in Kentico 12

David te Kloese

With the release of Kentico 12 last week we get a whole bunch of new features. One of the major items is of course the Page Builder support for MVC sites. I've spent some time integrating a new Rich Text editor as an Inline Editor. In this post my results and tips.

What are inline editors

When developing widgets for MVC sites, you can let content editors interact with properties to alter or change the widget content or behavior. This can be done directly in the Kentico administration interface. To enable these interactions you'll have to implement an inline editor. You can think things like a color picker, an image uploader, path selector or text manipulation tools.

The Dancing Goat MVC Sample site has the Medium.js Rich Text inline editor implemented.

I wanted to create an alternative Rich Text Editor to see how flexible or complicated this would be. I choose to implement the Alloy Editor. Since it's quite known, multi language support and can be extended. It's also build upon the familiar CKEditor, which Kentico uses as a Rich Text editor in the Admin interface.

Let's start with the final result. This is how the actual implemented editor looks like when used in the Admin interface. At the end of the clip I reload the actual MVC site.


Start developing
So what is needed and how does it hook up to the application.

First you set up the Model located at
which contains in my case 2 fields for the Text itself and I needed a Unique ID (talk about that later).


Secondly you need the View of the Inline Editor. Located at
Here you'll initiate the editor as part of the page builder and what data you want to pass to the editor.


Next you'll have the inline editor script itself that is placed in
which is the initialization script for your editor. This is where the real magic happens. Here you register your editor and you'll connect the Kentico parts with the your Custom editor logic.
  Note this is just a quick sample after a few nights debugging.

You also need to update the actual Widget that is going to use your Inline editor. I updated the Text Widget to use my new Text Editor. With the original name Text2Editor.
Located in


So where did my files end up?
First thing to think about is the way Kentico handles assets for your editors. The system automatically creates bundles containing all .js and .css files located under ~/Content/InlineEditors. The bundles are then linked on all pages with page builder editable areas.

So you have no influence in the order or location of loaded assets. I had to move a few assets to alternative location because they were expected on a specific path. Things like language files, configuration files or Font files.

For the Alloy Editor I needed to overwrite the default location for it's assets. Depending on your setup you might need an alternative path.

While you change those assets location, be sure to check if you application is configured to serve all file types. You can still spend lots of time on missing support for .woff and .svg file type serving.

Script debugging
Console.log and actually the browser developer Consoles in general are your new best friend. Since you're working with client side Javascript  which is packaged and rendered in a different application you can expect small but hard to pinpoint issues. Think of things like wrong relative paths, missing assets, or empty HTML elements. Easy to correct, but can be searching for a needle in a haystack.

Let Kentico know you've changed something.
Because you're actively changing rendered HTML data, you need to inform Kentico whenever you change something. You need to tell Kentico what field you changed, what's the new value and if it needs to re-render the content.


In our case I inform Kentico on every change to the value. Because it could be triggered by typing on the Keyboard or pressing one of the toolbar buttons.

Note this is not the save event for the page itself, but more to inform Kentico what is the latest state of that field when you hit the actual save button.

Styling inline editor
Because the way editor assets are rendered you might end up with conflicting styling for which the editor css is overwritten. Simply because something else is loaded later. Suggestion is to use a unique prefix key in classes and selectors, but in case all fails or isn't possible an !important notation might help you out. The inline editor assets are only loaded in the Admin Interface so the impact is contained.
Multi instance support
Don't forget you editor might be used by multiple widgets on the same page. So make sure the initializing of your editor registers to a unique element. I added a unique ID to the Model and View of my editor. I passed it along as a Data attribute for easy retrieval in the Editor JavaScript.


Things to keep in mind
  • A widget can change location and being dragged and dropped in another zone. You can add optional logic to the "dragStart or dragStop function". These will be called by the Page builder when used.
  • Same go's for when a user deletes a widget. But as you might have guessed there is also an optional "destroy function" you could use to dispose your editor.

I think this is a very dynamic solution for adding inline editors to your pages. The best thing is that because they are setup so stand alone you can reuse them quite easily in another project. Finally, although you do the setup in the MVC site of you application, all scripts and assets are only loaded in the CMS application, and won't be used on the live site at all.
A lot of info can also be found in the Kentico documentation.

Best for Last

In an attempt to show how dynamic this really can get I added a modulo operator to my Inline editor selection. Every even second it selects the Medium.js Inline editor, the other it selects my new Alloy Editor Inline Editor. Which after a few attempts got me this recording