tinymce-rails: TinyMCE 8 as a Rails asset pipeline citizen

A small gem with one job

tinymce-rails integrates the TinyMCE editor with the Rails asset pipeline, and that is the entire scope. It is compatible with Rails 5.1 and higher.

The repository is small and shaped like a gem rather than an application. The top level holds app/, lib/, spec/, a sandbox/ application for manual testing, gemfiles/ for testing against several Rails versions, a vendor/ directory, the gemspec, a Guardfile for the watch workflow, and a .rspec file. The presence of multiple gemfiles and a continuous integration workflow points to a project whose main maintenance burden is compatibility across Rails and TinyMCE versions rather than features.

That narrowness is a virtue for the adopter. There is one configuration file, one helper to include the assets and one helper to initialize the editor, and everything else is standard Rails. The README even notes that using the tinymce helper and the global configuration file is entirely optional, because TinyMCE's own tinymce.init function can be called by hand, so the gem is a convenience layer you can step out of at any point.

The GPL turn and the branch per major version scheme

One note in the README deserves to be read before anything else. As of version 7, TinyMCE, and therefore this project, is licensed under the GPL. The repository listing shows the licence as Other, because the file itself is a custom one that GitHub cannot categorise, and the terms that matter are the GPL terms TinyMCE 7 and later carry.

That matters for anyone who was using TinyMCE 6 or earlier under a more permissive licence, and for anyone whose application is closed source. A GPL editor embedded in a Rails application has licensing consequences for how that application is distributed, and the gem cannot change that.

Alongside the licence change there is a versioning scheme. The main branch is the TinyMCE 8 branch, and the repository keeps separate branches for TinyMCE 7, TinyMCE 6, TinyMCE 5, TinyMCE 4 and TinyMCE 3.5.x. A team that cannot move to the current licence has to stay on an older branch of the same gem, and the maintenance burden of that choice is the trade they are making.

The releases move with the upstream editor. The tags v8.10.0 dated 2026-10-18, v8.9.3 dated 2026-10-06 and v8.9.0 dated 2026-08-31 track TinyMCE's own release numbering, and the last push was on 2026-10-17.

config/tinymce.yml and named configuration sets

Global configuration lives in config/tinymce.yml, and the smallest useful file looks like this:

license_key: gpl
toolbar:
  - styleselect | bold italic | undo redo
  - image | link
plugins:
  - image
  - link

The license_key line is not optional any more. As of TinyMCE 8 a licence key must be specified, and the README links to the upstream documentation for licence keys. The value shown here, gpl, is the key that matches the GPL licensing of the editor itself.

The file can define several named configurations using YAML anchors, with a default that the others inherit:

default: &default
  license_key: gpl
  plugins:
    - image
    - link

alternate:
  <<: *default
  toolbar: styleselect | bold italic | undo redo | table
  plugins:
    - table

A default configuration has to exist, and the named sets are then selectable per call site, which is how a team gives one editor a table plugin and another a plain toolbar.

One practical note: the Rails server no longer needs to be restarted when this file is updated in development mode. For a gem whose job is mostly configuration, that is the kind of detail that decides whether the editing loop is pleasant.

Including the assets on Sprockets or Propshaft

There are two supported ways to get the editor into the page, and which one you use depends on your asset pipeline.

With Sprockets you can add a require directive to application.js:

//= require tinymce

Or you can let the gem emit the tags in your layout with the tinymce_assets helper, passing data attributes such as turbo_track: "reload" so the script is reloaded when Turbo handles. The helper renders a script tag pointing at the digested asset path.

The Propshaft case is the one that differs. There, the tinymce_assets helper adds multiple script tags, including the pre-init code that the tinymce_preinit helper exposes, plus tinymce/tinymce.js and tinymce/rails.js. The README notes you may prefer to include those manually depending on your requirements. With Sprockets, by contrast, everything is bundled together into one script tag.

The difference matters because TinyMCE loads most of its files dynamically at runtime. The editor needs its own assets addressable under predictable paths, and how they get there is the subject of the next section.

The precompile symlink workaround and three install methods

Because TinyMCE loads most of its files dynamically, the assets have to be reachable under non-digested filenames, and Rails digesting them breaks that. The gem solves this with a set of install methods chosen through config.tinymce.install in config/application.rb, and they run during rake asset:precompile through Rake::Task#enhance, after the regular application assets are compiled.

The default method since version 4.5.2 is compile, which adds the TinyMCE paths to the Sprockets precompilation paths and then creates symlinks from the non-digested filenames to their digested versions. Setting it is a single line of Ruby:

config.tinymce.install = :compile

If the compile method causes trouble, the copy method copies the TinyMCE assets directly into public/assets and appends the file information into the asset manifest. There is also copy_no_preserve for filesystems where file modes cannot be preserved, which is a detail that bites on some container volume mounts.

One thing the README saves you from: if you include TinyMCE through application.js or through the tinymce_assets helper, you do not need to add the scripts to the Sprockets precompile paths by hand. The manual path exists for other setups.

Initializing editors, custom plugins and engine usage

Initialization has two halves. Each textarea you want to edit needs the tinymce class and a unique ID, which you can produce with the standard Rails helpers or with a form builder, and then the tinymce helper initializes the editor. Custom options can be passed to that helper to override the global configuration for one call site, for instance a different theme, a different language or a different plugin list, and a named configuration from the YAML file can be selected with tinymce :alternate.

If you prefer to drive it yourself, the helper and the global file are optional. You can call tinymce.init directly and select a textarea by selector:

  tinymce.init({
    selector: 'textarea.editor'
  });

Custom plugins and skins are added through the asset load path. The files have to be locatable beneath tinymce/plugins/ or tinymce/skins/, so a plugin called mycustomplugin with its main JavaScript file at app/assets/javascripts/tinymce/plugins/mycustomplugin/plugin.js is picked up, provided the custom paths are also added to the asset precompile paths.

Two more integration notes. Additional language packs live in a separate gem, tinymce-rails-langs. And if you consume this gem as a dependency of a Rails engine, you must require tinymce-rails explicitly in the engine file, because listing it in the gemspec is not enough.

Updating is simple: when a new TinyMCE is released, update the gem to the matching version. No extra rake tasks are needed apart from rake assets:precompile.

Where tinymce-rails is the wrong tool

The cases where this gem does not fit are clear.

If your application cannot be GPL licensed, stop here. The editor itself changed licence at version 7, and a Rails integration cannot work around that. Teams that need a permissively licensed rich text editor have to look elsewhere, and this gem's older branches keep TinyMCE 6 alive but not more.

If your requirement is a textarea with formatting limited to a few marks, the whole TinyMCE distribution is more than you need. The editor is a large JavaScript asset, it loads files dynamically, and it needs the precompile workarounds described above. A plain textarea, or a Markdown field with a preview, avoids all of that.

Third, the integration is Rails only and Sprockets or Propshaft only. There is no Sprockets-free path, no standalone script tag with CDN assets, and no support for other Rails versions below 5.1. The gem exists to solve the asset pipeline problem specifically, and if you are not running Rails the problem does not exist in the same form.

Finally, the versioning model has a cost. Six major version branches are maintained in one repository, and the configuration format itself changed when TinyMCE 8 introduced the mandatory licence key, so an application that upgrades the editor across several majors is doing a configuration migration as well as a code update. The README is honest about the branch layout, which is at least a good start.

Editorial conclusion

Adopt tinymce-rails if you run Rails 5.1 or later, want TinyMCE rather than a plain textarea, and would rather inherit the editor's assets, configuration file and precompile handling than assemble them by hand. Do not adopt it if your application must stay outside the GPL, since TinyMCE and this gem have been GPL licensed since version 7, and do not adopt it if you only need a textarea with a Markdown mode. Verify three things first: which major version branch you take, since the 8, 7, 6, 5, 4 and 3.5 branches exist separately and the configuration format changed with the licence key requirement in TinyMCE 8; which asset pipeline you run, because the Sprockets and Propshaft paths include the editor differently; and which install method you set in config/application.rb, since the compile method symlinks assets and the copy and copy_no_preserve methods behave differently on a filesystem that cannot preserve file modes. The last push was on 2026-10-17 and the latest release is v8.10.0 dated 2026-10-18.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. spohlenz/tinymce-rails on GitHub