Update TinyMCE from v4 to v5

Update: This has moved to a research plugin to help navigate implementation. ~ @wadestriebel

According to Tiny’s support window announcement, support and fixes for v4 have officially ended.

Today [Oct 10, 2019] we are announcing the end of support for TinyMCE version 4.x. It will be officially supported through to December 31, 2020.

They have provided a blog post and a migration guide to help users get up to the latest version. It looks fairly straight-forward.


TinyMCE was last updated in WP 4.8 to version 4.6.2. Since then, TinyMCE 4.x has had 37 releases.

Additionally, released in Feb 2019, TinyMCE 5.0.0 has had 39 releases (not counting any of the previews, betas, or RCs.)

We’re already way behind. The concern here is that this will be the next “support for dead PHP versions” that kicks along for 10 years without being addressed. Note that this petition isn’t geared toward “adding new features” to ClassicPress – it’s more about “avoiding technical debt” that becomes more and more difficult to shed later. Possibly, upgrading the editor might further solidify ClassicPress’ commitment to using a traditional editor.

Possible implementation

A research repo may provide a path forward.

Will you be able to help with the implementation?

Yes, although it will be a few months down the road.


Hi there! I just had a play with this on their website, and from an accessibility standpoint, I only have good things to say about this change. I provided them with extensive help in the TinyMCE 4 days to get accessibility up to standards, and that’s in part why WordPress became so much more popular among blind people to blog with.

I have two questions, if this is implemented:

  1. How will we deal with frequent updates? Will we still be packaging the community edition?
  2. And if the question to number 1 is yes, will there be a way to let users switch to the cloud-based offering, either free or paid, for their individual website, which would then in turn disable our bundled version? I am specifically thinking about their offering of an accessibility checker in the Professional plans. For certain publishers, and therefore customers of agents delivering ClassicPress as the CMS, this could become very interesting to make easy and another “selling point” for ClassicPress. This could be as simple as offering to input one’s API key in the Writing section of Settings, and if present, ignore the bundled version and pull in the cloud version instead. What users then get would of course depend on their free or paid plan.

What do you think?


Hi Marco,

The petition doesn’t cover the implementation details, so, I can only guess how it might play out.

  1. It seems likely that the basic, free version would be included and that it would not follow the same update schedule that Tiny follows. Namely, their release cycle is far more aggressive than ours and there’s no way we could keep up with it.

  2. I doubt such an option would be included as that would make it much more difficult to maintain compatibility. More likely, Tiny would be updated to a specific version and left at that for the next n years. It would probably just be an updated version of Tiny without the extra (ie, cloud-based, premium, etc) features.

Again, these are just guesses. On the other hand, the petition only got a few upvotes, so, it seems unlikely that any time will be spent on it outside of this forum post.

The question for me is how is Tiny implemented in WP/CP. Does either of you know how it’s done, or some resources you could point to about it?

I ask because I like Marco’s idea of being able to switch to the Pro plan, and I’d be interested in helping with modifying any hooks for that.

I don’t know of any docs regarding the WP/CP implementation, its development, or how to go about testing within the system.

The links posted above are all I could find regarding upgrading. The TinyMCE docs (before v5) are notoriously poor. While the upgrade process seems straight-forward, the other aspects – particularly testing – just aren’t covered anywhere that I could find.

Yes, that’s my experience too, unfortunately. This seems like something that ought to be straightforward, but I can’t work out whether it really isn’t or whether it’s just poorly documented.

Here is the ticket for WP: https://core.trac.wordpress.org/ticket/47218
which lists a few obstacles.

1 Like

Thanks for the link, Joy – I saw that ticket awhile back and just reviewed it again. I didn’t see anything of use in it. Given that the ticket is sitting in “second opinion” status 2 years after it was opened, I suspect it will be like many others that have lived on for years until finally being unceremoniously closed.

I was wondering if we could kind of fork the Classic Editor plugin and start experimenting with upgrading that to TinyMCE 5 and see how it goes. Or work on this in a feature branch in ClassicPress repository itself.

The biggest hurdle to creating a development fork is that there’s no one to put in the work.

The Classic Editor plugin is more about providing a way to choose between two editors and removing actions for the block editor than it is about editing. Currently, WP still bundles TinyMCE, and it is even used in the block editor for Classic blocks. There are a lot of plugins that use the bundled script, so it didn’t hurt them to say they would keep it around.
It wouldn’t further anything to mess with Classic Editor plugin. The issue is the JS that is bundled with core.


Thanks for the clarification, this helps a lot in understanding how things hang together.

This doc makes mention tiny mce advanced WP plugin that got GB into it. However, if memory serves me right, CodePotent had forked this.

Could this be the right place to experiment the idea?

That’s correct. I forked TinyMCE Advanced (into Enriched Editor). The fork uses the existing Tiny v4 that ships with core, so, it’s not truly a step forward – it’s basically just a rename of the plugin to ensure it didn’t go bye-bye on us.

Unfortunately, many things have changed from Tiny v4 to v5, making it exceptionally likely that anything depending on v4, such as plugins/themes that interface with it, will break.

Given the potential for breakage here, I am wondering if it might be best to explore the TinyMCE v5 upgrade first using a plugin.

For projects like this, it can be necessary to add a few new hooks in core to allow overriding or cancelling certain behaviors that the plugin should take care of instead. I would be happy to ship any such changes as part of ClassicPress.


If we can figure out a way to upgrade TinyMCE to v5, that would be a great differentiator for ClassicPress. TinyMCE v5 has security patches, and people do want it upgraded in WP. The ticket mentioned has recent comments asking for an update on it.

Since we value security, this probably should be added to the top of the list of major changes. First as a plugin, and then integrated into the core. This would give CP a security edge over WP.

I would say this is probably more important long term than core plugins or custom fields API.

Improving security should (is?) be our priority.

If anyone is willing to put some work into a research plugin, I think everyone would welcome it.

1 Like

I just noticed that the guy doing winnipress updated TinyMCE in his repo, but he doesn’t care about back-compat. I wonder if CalmPress has looked at it.

1 Like

Doesn’t look like he did it yet.

Winnipress implementation might help us better understand what needs to be done in the core. It can be a good starting point.

@Code_Potent are you still willing or able to help with plugin implementation of the TinyMCE upgrade to v5? I know you stopped doing plugin dev for CP, so I’m curious if you’re still willing to help on this.


I won’t be able to contribute to the implementation at this time.