Working with noneditable content in TinyMCE

This article was written for and originally appeared on Blueprint by Tiny.

The noneditable plugin is a core plugin of TinyMCE, and is available to all users, whether you’re self-hosting or using the cloud-based version. Its purpose is clear: to mark specific elements as not editable by your authors.

When you have parts of your content - especially when using templates - that you don’t want your authors to edit, incorporating the noneditable plugin with your TinyMCE configuration can be incredibly useful.

For example, when we looked at the “template” plugin in the previous post, we looked at using templates for letter responses. Maybe your letters need to include specific statements for legal reasons. This is a great opportunity to use noneditable: while still giving your users the ability to edit the letter content, you can also prevent them from editing the must-never-change legal statements.

To get started with the noneditable plugin, make sure that you have added it to your plugins array:

By default, the noneditable plugin will be fully functional with no additional configuration needed, and uses two classes to determine what is and is not editable - “mceEditable” and “mceNonEditable”.

However, if you want to use your own classes to determine this, you can add two additional configuration options to set your own classes, such as:

For the examples in this article, the defaults of “mceNonEditable” and “mceEditable” will be used.

By default, everything within the editor instance is editable. Using the noneditable plugin, we can make specific elements not editable by the user.

Non-editable elements aren’t something the majority of users can create themselves, and would come from markup generated by a custom plugin you have written, or from markup in the templates plugin.

The editability state of an element is controlled by whether the element has the “noneditable” class applied to it.

By default, this class is “mceNonEditable”. Just remember, if your project has a different naming approach, you can change this with the “noneditable_noneditable_class” configuration option.

This means that any element that has the class “mceNonEditable” will not be editable within the TinyMCE editor. 

This is a great feature to have for sections of content that you may not want your authors to be able to change. 

For example, consider a scenario in which your users can write letters based on a set of predefined templates. These are set up within your templates configuration, and include specific legal statements that may be required by your industry. You could wrap those statements with the “mceNonEditable” class, and prevent authors from making changes to those, while still allowing them to work around the block and personalise the letter for the recipient.

Now that you understand how to make an element noneditable, did you also know that you can make specific child elements editable?

The “mceNonEditable” class is used to make an element not editable - and all we need to do to make a child of that element editable is add the class “mceEditable”. 

It really is as simple as that.

This all is really straightforward... but the question is, when would you actually need to use it?

Let’s consider another example: imagine your template is a table that includes set column dimensions and heading cells, but can be made up of many rows that you want your users to add to.

The problem we have here is that if we make the table noneditable, nothing can be changed - cells can’t be adjusted and rows can’t be added.

However, what we can do is make the <table> be noneditable, and make specific elements within the table be editable.

Let’s break our table structure down - our table is made up of an outer <table> element, and within it, a <thead>, <tbody> and <tfoot> to give it structure - maybe it is for a quote or an invoice:

When our authors use this table, we don’t want them to edit the headings at all - but we want them to be able to add more rows (line items) plus update the total dollar value.

So there’s two things we need to do:

1. Add the class “mceNonEditable” to the table

2. Add the class “mceEditable” to the elements we do want to be edited

Given we want to ensure that our authors can add rows, that means that they need to be able to edit the <tbody> element. 

And we also need the total to be updatable - but we don’t need them to be able to edit the entire footer area.

To achieve this, we can add “mceEditable” to the <tbody> element, and also to the cell that contains the total.

In the end, our template would look like:

This gives our authors the ability to change the areas we want them to - but also preserve the overall layout and structure of our table - and is also a great companion to use with the templates plugin.

Implementing noneditable (and editable) sections is incredibly easy - but when to use it is a little more complicated, and varies based on the needs of your project.

If your organisation has specific legal requirements or statements that must be included in specific communications, then making these noneditable ensures you are meeting your obligations.

It could even be simpler than that, and you have specific style guidelines around how letters are authored, with a set structure for the greeting and salutation (and non-editable, populated by your CRM or system or even replacing values using the templates plugin), and mceNonEditable and mceEditable gives you the ability to allow parts of the letter to be changed, but others to strictly follow your style guide.

Using the code plugin to allow authors to view source code means that the entire noneditable concept can be completely disabled. 

If authors can see the source code, they can change the “mceNonEditable” class, and therefore make any change they need.

One way to try to overcome this is to carefully consider your TinyMCE configurations, and even tie some plugins to specific user permissions or roles. For example, the “code” plugin may only appear for advanced users or managers, and is absent for day to day content authors, meaning plugins like noneditable have more usefulness for less privileged users. For example, you can see a simple and advanced configuration here. 

If you’re using the “mceNonEditable” class approach, remember that it is just that - a class. 

And we can style elements with classes using our content_css styles - even mceNonEditable.

This is a handy way to provide visual cues to your users as to why they cannot edit specific areas - and makes it clear that this particular content is not editable.  

Even with nested content, you can then apply styles to “mceEditable” too if you need to highlight the editable areas of the content.

The control freak in me likes things to be a certain way. And making parts of my user’s content noneditable keeps the parts I really care about fully intact. 

This is such a powerful technique to use when paired with templates too - giving your authors the ability to change the parts that you want them to, but also locking down specific areas for your organisation’s legal, brand and style requirements.

If you’re already using templates, maybe take a look at your template code to see if noneditable is a good fit for your users. It might just scratch that control freak itch inside you too.