Can’t edit post_content in Classic Editor if plugin v5.0.1 or v5.0.2 is active

I seem to have reproduced the bug, and I’ll explain it below. I’ve included some additional detail here in case it helps someone at Toolset to be able to confirm or correct what I think I’ve found.

TL;DR: Toolset seems to be loading the tinymce JavaScript and/or modifying the tinymce global object in a way that conflicts with our plugin’s dependence on it. If so, then it doesn’t yet seem appropriate for us to change our plugin in order to work around this problem in Toolset.

Reproduction

• From a clean WordPress installation version 6.8.2
• Install, activate, and configure the Font Awesome plugin version 5.0.2
• Install and activate the Toolset Type plugin version 3.6.1
• In Toolset, create a post type such as “Buildings”. Change the Editor property to have the value “Classic”.
• In Toolset, create a post type such as “Addresses”. Change the Editor property to have the value “Classic”.
• In Toolset, create a new Relationship, of type One-to-one. Select Buildings for the left side and Addresses for the right side. (Adding the Relationship is the piece that I added in addition to my previous reproduction attempt. The bug does not manifest without adding the Relationship.)
• Create a new Buildings post.

Toggle between the Visual and Code tabs while viewing the JavaScript console to see the error message.

When SCRIPT_DEBUG is defined in WordPress, the stack trace for that JavaScript console error looks like this:

Uncaught TypeError: Cannot read properties of undefined (reading ‘getSelection’)
at findBookmarkedPosition (editor.js?ver=6.8.2:657:31)
at switchEditor (editor.js?ver=6.8.2:161:23)
at HTMLDocument. (editor.js?ver=6.8.2:38:7)
at C (tinymce.min.js?ver=49110-20250317:2:10800)
at HTMLDocument.d (tinymce.min.js?ver=49110-20250317:2:10946)

The code there in editor.js where undefined is encountered is here:

var TinyMCEWindow = editor.getWin(),
	selection = TinyMCEWindow.getSelection();

It’s TinyMCEWindow that is undefined. So invoking undefined.getSelection() throws the Error.

Our plugin code declares a dependency on tinymce, because our Classic Editor integration depends on tinymce. Here’s where that dependency is declared:

wp_register_script(
	self::RESOURCE_HANDLE_CLASSIC_EDITOR,
	trailingslashit( FONTAWESOME_DIR_URL ) . 'classic-editor/build/index.js',
	array(
		self::ADMIN_RESOURCE_HANDLE,
		self::RESOURCE_HANDLE_ICON_CHOOSER,
		'wp-tinymce',
		'jquery',
	),
	self::PLUGIN_VERSION,
	true
);

I think that’s a standard way for our plugin to declare its actual dependence on tinymce (what powers the WordPress Classic Editor).

When that 'wp-tinymce' line is commented out–thus removing our plugin’s explicit dependence on tinymce–the bug that’s reproduced by using the above steps disappears.

So, when our plugin declares its dependence on tinymce, then this produces undefined:

TinyMCEWindow = editor.getWin()

When our plugin does not declare its dependence on tinymce, that same line produce the expected result.

Declaring our plugin’s dependency on tinymce changes the order in which some of the related scripts are loaded in the browser, which seems to disrupt some of Toolset’s assumptions. Yet it seems to me that our plugin should declare its dependence on tinymce, because it does actually depend on it, and this is a standard way to declare that dependence.

This suggests that Toolset might be doing some modification of the tinymce global, or otherwise changing things such that it breaks when the scripts loading order changes or script execution timing changes. If so, then that would seem like a flaky, error-prone implementation in Toolset that should be corrected there. That could be causing a problem not only with the Font Awesome plugin, but any other theme or plugin that declares a dependence on tinymce.

If something like that in Toolset is indeed the root cause, then it’s not clear to me that we should try to change our plugin to accommodate it. Because, if I’ve understood correctly, it would amount to us hacking our code to work around a problem in Toolset.

After giving it some further thought, the risk may be low enough to omit our plugin’s explicit dependence on tinymce as a way to work around what I currently believe is an error in Toolset’s code. Would you join me in an experiment?

I’ve posted a development release here in our GitHub repo. It simply omits our plugin’s explicit dependence on wp-tinymce. Otherwise, it’s functionally equivalent to the 5.1.1 version of the plugin that I also released today (the curious can see diffs here).

For the bug as I was able to reproduce it above, this resolves it.

It would be helpful if those who’ve encountered the problem could try this development release, perhaps on a staging or development site, and let me know if it resolves your manifestation of the problem.

To try it:

1. Navigate to the Release Page in GitHub.
2. Click link to download font-awesome-5.1.2-1.zip from that page.
3. In WordPress admin, go to install a new plugin, click to Upload, and upload that zip file to install it.