How to Set Up Collaborative TinyMCE Plugin Features (2026)

In today’s digital world, collaborative tools are not just a luxury, they are a necessity. When building web applications with a rich text editor, providing features like revision history, track changes, and inline comments can transform a simple text box into a powerful collaborative hub. This guide explores the core functionalities you can add with a TinyMCE plugin, turning your editor into an environment rivaling platforms like Google Docs or Microsoft Word.

We will break down three essential types of collaborative plugins: Revision History, Suggested Edits (also known as Track Changes), and Comments. Understanding how they work is the first step to integrating them effectively into your application.

What is a Revision History Plugin?

A Revision History TinyMCE plugin is a powerful tool that captures and stores different versions of a document over time. Think of it as a time machine for your content. It allows users to view, compare, and restore previous snapshots of their work, providing a complete audit trail of every change made. This is indispensable for content management systems, legal documents, or any environment where tracking a document’s evolution is critical.

While some editors offer this as a premium feature, you can also find powerful third party solutions. For instance, developers looking for robust version tracking might explore tools like Loop Index’s Track Changes plugin, which brings similar capabilities to various editor integrations.

How It Works: Behind the Scenes

The plugin itself doesn’t store the document versions. Instead, it relies on your application to do the heavy lifting. When a user wants to view the document’s history, the plugin calls a function you provide to fetch an array of all saved revisions from your server or database. It then displays these versions, often in a sidebar, allowing users to click and preview past content.

To make comparisons easy, the plugin can generate a “diff”, visually highlighting what changed between two versions. Typically, added text is wrapped in an <ins> tag and deleted text is wrapped in a <del> tag, with different colors for clarity.

Basic Setup and Configuration

To get a revision history TinyMCE plugin running, you need to follow a few key steps:

1. Enable the plugin: Add the plugin to your TinyMCE initialization configuration.
2. Add a UI control: Include a toolbar button or menu item so users can access the feature.
3. Provide the fetch callback: This is the most crucial step. You must configure the revisionhistory_fetch function, which is responsible for retrieving the list of revisions. Without this, the plugin has no data to display.

Once configured, users can open the history view and see a timestamped list of all available document versions.

Understanding Revision Types

The system categorizes changes primarily into two types: insertions (additions) and deletions (removals). Some systems may also track formatting modifications. When comparing versions, the plugin visually distinguishes these changes. For example, if “The cat sat” becomes “The dog sat”, the word “cat” is marked as a deletion and “dog” as an insertion. By default, these changes get CSS classes like added or removed, allowing you to style them with custom colors, underlines, or strikethroughs.

The Data Structure of a Revision

Each saved version is represented by a structured object. This object typically contains:

• A unique ID (revisionId) for that specific version.
• A timestamp (createdAt) indicating when it was saved.
• The full HTML content of the document at that time.
• Author information, including a user ID, name, and even an avatar URL.

This structured data makes it possible to build a rich, informative timeline of who changed what, and when.

Key Configuration Options for this TinyMCE Plugin

You can tailor the behavior of the revision history feature using several configuration options. These are set during the editor’s initialization.

• revisionhistory_fetch: This is a required callback function that the plugin uses to get the list of all saved revisions. It must return a JavaScript Promise that resolves to an array of revision objects. It’s best practice to return these in reverse chronological order so users see the most recent changes first.
• revisionhistory_fetch_revision: This optional callback is a performance optimization. You can use it to “lazy load” the full content of a specific revision only when a user clicks on it. This is useful for documents with very long histories, as it avoids loading all the content at once.
• revisionhistory_allow_restore: A simple boolean (true or false) that controls whether users can restore an old version. If set to false, the restore button is hidden, turning the feature into a view only history viewer.
• user_id: This option specifies the unique identifier for the current user. When new revisions are saved, this ID is used to attribute the changes to the correct person, which is crucial for collaborative environments.
• revisionhistory_css_url: This lets you provide a URL to your own CSS file to style the difference highlights. If you want insertions to be blue instead of green, this is the option you would use.
• revisionhistory_diff_classes: This option gives you full control over the CSS class names applied to changes. You can map additions, removals, and modifications to your own custom class names, which should then be defined in your custom stylesheet.

User Interface and Interaction

Users typically interact with the revision history TinyMCE plugin through a few standard UI elements.

• Toolbar Button: A dedicated button, usually with a clock icon, can be added to the toolbar. Clicking it toggles the revision history sidebar.
• Menu Item: The feature is also accessible via a menu item, often found under the “View” menu.
• Command: Programmatically, you can open or close the history view by executing the revisionHistory command. This is useful if you want to show the history panel automatically when the editor loads.
• Show View on Editor Load: While there isn’t a direct option, you can call the editor.execCommand('revisionHistory'); command in an initialization callback to have the history panel open by default.

Events and API: Talking to the Plugin

The plugin also provides hooks for developers. When a user restores a version, the plugin fires a VersionRestored event. You can listen for this event to trigger other actions in your application, like updating the UI or logging the rollback action.

Additionally, the plugin exposes an API. The most notable method is diff(), which takes two HTML strings and returns a new string with the differences highlighted using <ins> and <del> tags. This allows you to generate and display content comparisons anywhere in your application, even outside the editor itself.

Bringing “Track Changes” to the Web: The Suggested Edits Plugin

For real time collaboration, the Suggested Edits plugin is a game changer. It introduces functionality similar to “Track Changes” in Microsoft Word or “Suggesting” mode in Google Docs. Instead of editing the document directly, users’ changes are captured as “suggestions” that can be reviewed, accepted, or rejected by others.

This feature is often a premium add on for editors like TinyMCE. However, for developers needing this functionality across different editors, solutions like the Loop Index’s TinyMCE Track Changes plugin offer a flexible and powerful alternative.

The Brains of the Operation: The Suggested Edits Model

The magic behind suggested edits lies in its data model. This is typically a JSON object that lives alongside your document’s HTML content. It keeps a detailed record of every proposed change, including who made it, what was changed, and whether it has been resolved.

To ensure suggestions persist across editing sessions, this model must be saved with your document and loaded back into the editor upon initialization. If you fail to load the model, all previous suggestions will be lost.

The Review Process: Accepting and Rejecting Edits

When a user enters the “Review Edits” view, every suggestion is highlighted. A reviewer can then step through each change and decide to accept or reject it.

• Accepting a suggestion makes the change permanent.
• Rejecting a suggestion discards the proposed change, reverting to the original text.

This review workflow is the heart of track changes, providing a critical checkpoint for quality control and ensuring that no unauthorized changes make it into the final document. If you’re evaluating whether this fits your team, see Who is it for?

Getting Started: Initial Setup Guide

Setting up a suggested edits TinyMCE plugin requires careful configuration.

• Editor Mode: This feature typically requires the editor to be in classic (iframe) mode, as it relies on a more complex UI than the inline mode can support.
• Load the Model: When initializing the editor, you must provide any previously saved suggestions model using the suggestededits_model option.
• Sync Content: It is crucial that the HTML content and the suggestions model are in sync. Loading mismatched versions can cause unexpected behavior.
• Set User ID: Just like with revision history, you should provide a user_id to correctly attribute suggestions to each collaborator.

Essential Options for Your Suggested Edits TinyMCE Plugin

• suggestededits_model: This option is used to load the JSON model containing all existing suggestions into the editor. Without it, the plugin assumes it’s a new document with no pending changes.
• suggestededits_content: This option tells the plugin where to get its initial content. The default is 'html', which uses the HTML you provide. Setting it to 'model' tells the plugin to reconstruct the content from the provided suggestions model, which can simplify your data management by making the model the single source of truth.
• suggestededits_access: This powerful option lets you set user permissions. You can define whether a user has 'full' access (can accept/reject), 'feedback' access (can comment on suggestions but not resolve them), 'read' access (view only), or 'none'. This is essential for creating structured editorial workflows with different roles.

Fostering Collaboration with an Inline Comments Plugin

The final piece of the collaborative puzzle is the Comments plugin. This feature allows users to select a piece of text and attach a discussion thread to it, all without altering the content itself. It’s perfect for asking questions, leaving notes, or having contextual conversations right inside the document.

In TinyMCE, this is a premium feature known as Tiny Comments. When combined with suggested edits, it creates a complete collaborative environment. This is precisely the experience that tools like the Inline Comments plugin for TinyMCE aim to provide for various rich text editors. Teams using Froala can achieve the same result with the Froala Inline Comments plugin.

Capturing the Conversation: The getEventLog API

To save and manage comments, the plugin provides a getEventLog() API. This function returns a complete audit trail of all comment activity, including creations, replies, edits, and resolutions. Each event in the log is a structured object with a timestamp, author information, and the comment content. Developers can call this API when saving a document to get a full snapshot of the comment state and persist it to a database.

Staying in Sync: The CommentChange Event

For real time applications, the CommentChange event is key. This event fires anytime a comment is added, edited, deleted, or resolved. You can listen for this event to immediately sync changes with your server or update other parts of your application’s UI, such as a comment counter. The event object itself includes a getEventLog() function, giving you instant access to the latest state.

Final Thoughts

Integrating a collaborative TinyMCE plugin for revision history, suggested edits, or comments can dramatically enhance your application. These tools empower teams to work together more effectively, creating a transparent and controlled editing process. Whether you use the native premium plugins or explore versatile third‑party solutions like those from Loop Index, the investment in collaborative features pays dividends in productivity and content quality. For licensing tiers and MAU‑based options, see pricing.

Frequently Asked Questions (FAQ)

1. What is the best track changes plugin for TinyMCE?
The “best” plugin depends on your needs. TinyMCE offers a native “Suggested Edits” plugin as a premium feature. For more flexibility or multi‑editor support (including CKEditor 4 and Froala), third‑party solutions like the Froala Track Changes plugin are excellent alternatives that provide robust, Word‑like functionality.

2. How do I enable revision history in TinyMCE?
To enable the Revision History plugin, you must include it in your tinymce.init configuration, add its button to the toolbar, and most importantly, provide a revisionhistory_fetch callback function that retrieves document versions from your server.

3. Can I customize the look of tracked changes?
Yes. Both the Revision History and Suggested Edits plugins allow for customization. You can use the revisionhistory_css_url option to link to your own stylesheet and revisionhistory_diff_classes to define custom CSS class names for insertions and deletions.

4. Is a TinyMCE plugin for comments difficult to integrate?
Integration is straightforward if you follow the documentation. The key is to handle the comment data. You will need to use the getEventLog() API to retrieve comment data and the CommentChange event to listen for real time updates, which you then save to your backend.

5. What is the difference between revision history and suggested edits?
Revision history is a passive, chronological log of saved document versions. It is for looking back at the history of a document. Suggested edits (or track changes) is an active, collaborative feature where changes are proposed in real time and must be explicitly accepted or rejected before becoming part of the document.

6. Do I need a server to use these collaborative plugins?
Yes. For persistence, you need a server‑side component. The plugins themselves do not store revision history, suggestion models, or comment data. Your application is responsible for saving this information in a database and providing it back to the TinyMCE plugin upon request. If you need implementation guidance or an architecture review, contact us.