Update TinyMCE from v4 to v5

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.

Context

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.

6 Likes

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?

1 Like

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.

2 Likes

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