TinyMCE Basics

Introduction

In Optimizely CMS 12 (PaaS), TinyMCE is the default rich text editor used for properties of type XhtmlString. For developers building structured content models and editorial experiences, understanding how TinyMCE is integrated, configured, and extended is critical. Although editors experience TinyMCE as a toolbar and a content area, developers interact with it through configuration pipelines, initialization modules, and content model attributes.

This article explores the technical foundation of TinyMCE in CMS 12, how it is registered and configured, what its default behavior looks like, and how developers can influence its behavior at the application level.

The focus is strictly on the PaaS (DXP-compatible) version of CMS 12.

1. How TinyMCE is integrated in CMS 12

In CMS 12, TinyMCE is not manually embedded into views. Instead, it is automatically wired into the editorial UI when the CMS detects a property of type XhtmlString.

For example:

When this property is rendered in Edit mode, CMS attaches TinyMCE as the editing surface.

Under the hood:

• The CMS UI loads the TinyMCE integration package.
• Configuration is resolved from dependency injection.
• Default settings are applied unless overridden.
• Content is stored as HTML in the database.

This means that TinyMCE configuration is not view-driven but service-driven.

2. Default TinyMCE behavior in CMS 12

Out of the box, CMS 12 provides a default TinyMCE configuration. Developers do not need to manually register plugins or toolbars unless customization is required.

The default configuration is designed to support:

• Valid HTML structure
• CMS-aware link management
• Media references stored as content links
• Safe rendering within the CMS UI

These defaults are defined by Optimizely and can be extended.

3. Configuration pipeline in CMS 12

TinyMCE configuration in CMS 12 is performed during application startup using dependency injection. Configuration is done by implementing IConfigureOptions<TinyMceConfiguration>.

Example:

Then register the configuration in Program.cs:

This approach:

• Uses .NET Core dependency injection
• Keeps configuration centralized
• Avoids per-view customization
• Makes behavior consistent across environments

4. The Default() configuration scope

config.Default() applies settings globally to all XhtmlString properties unless a more specific configuration is defined.

You can also target specific property names:

This allows granular control while preserving global defaults.

Configuration hierarchy works as follows:

• Global default
• Content-type specific
• Property-specific override

This layered model prevents duplication while allowing fine-grained tuning.

5. Plugins and toolbar customization

TinyMCE operates through plugins. CMS 12 allows you to enable or disable plugins using the fluent configuration API.

Example enabling additional plugins:

Important considerations for developers:

• Enabling a toolbar button without enabling its plugin will not work.
• Some plugins require additional configuration parameters.
• Overexposing plugins may lead to inconsistent editorial markup.

Because content is stored as HTML, toolbar decisions directly affect frontend output.

6. Content output and storage

TinyMCE outputs HTML that is stored in the CMS database as an XhtmlString. This is not sanitized by default at render time — it is expected that configuration enforces allowed markup.

When rendering in Razor:

The CMS rendering pipeline ensures:

• Internal links are resolved
• Content references are mapped
• Permanent links are translated

The HTML remains structured and content-aware.

This means developers must:

• Avoid overly permissive configuration
• Align TinyMCE capabilities with frontend rendering expectations
• Ensure CSS matches allowed elements

7. Default settings and allowed elements

CMS 12 provides default settings governing:

• Allowed block elements
• Valid inline elements
• Paste behavior
• Formatting rules

These defaults prevent editors from inserting arbitrary HTML. If stricter control is required, developers can modify valid elements:

This restricts output to specific HTML elements.

Such restrictions are essential in structured design systems where markup consistency matters.

8. Relationship between CMS UI and TinyMCE

TinyMCE operates inside the CMS editing interface, not the frontend application.

Important technical implications:

• It runs in an isolated editing iframe.
• It loads CMS-specific plugins.
• It integrates with the asset pane.
• It supports drag-and-drop content references.

Because of this integration:

• Link dialogs are CMS-aware.
• Media selection uses the content repository.
• References are stored as internal identifiers.

Developers should understand that TinyMCE is not a standalone editor instance — it is deeply integrated into the CMS UI framework.

9. Extensibility considerations

TinyMCE in CMS 12 can be extended by:

• Adding custom plugins
• Injecting custom configuration settings
• Registering custom styles
• Modifying content CSS

Example custom style registration:

This enables structured content patterns controlled by frontend styling.

Developers should align TinyMCE configuration with:

• Component-based frontend architectures
• Accessibility standards
• Security best practices
• Brand guidelines

10. Operational best practices in PaaS

In a PaaS (DXP) environment:

• Configuration is part of the deployed codebase.
• No direct production UI configuration should be relied upon.
• Changes require CI/CD deployment.

Best practices include:

• Version-controlling TinyMCE configuration
• Keeping configuration minimal and intentional
• Avoiding environment-specific overrides
• Testing HTML output before promoting to higher environments

Because content persists across deployments, configuration changes must consider backward compatibility of stored markup.

Conclusion

TinyMCE in Optimizely CMS 12 is more than a rich text editor — it is a structured content input system tightly integrated with the CMS editing framework. For developers, understanding how it is registered, configured, and scoped through dependency injection is essential.

Default configurations provide a safe and functional baseline, but production-grade solutions require deliberate control over plugins, toolbars, and valid markup. In PaaS deployments, these configurations become part of the application architecture and must be managed through code and CI/CD pipelines.

Mastering TinyMCE basics in CMS 12 lays the foundation for implementing rich editorial experiences while maintaining structural integrity and frontend consistency.