TinyMCE 4.0 and missing/changed ID attributes

[GregRoss]

I pulled down the development release with TinyMCE 4.0 in it and started to test my plugin (​http://wordpress.org/plugins/just-writing/) with the new code (let's just say I knew it was going to be ugly)

Many of the old ID tags on elements have either been dropped, changed to classes or made virtually useless.

For example:

• In WP3.8, the fullscreen button was an 'a' link with the id of 'content_wp_fullscreen' in WP3.9 it is now a 'div' with an id of 'mce_28' (if you dig a little deeper there's an 'i' with a class of 'mce-i-wp_fullscreen'.

• In distraction free writing mode, the title input box used to have an ID of 'wp-fullscreen-title', now there is no ID and it has a class of 'wp-fullscreen-title'.

• In distraction free writing mode, the body input div use to have an ID of 'wp-fullscreen-container' now it has an id of 'wp-content-editor-container'.

Some of these are probably TinyMCE (like the buttons) but for those that can be maintained it would be nice to have the ID's present and consistent with 3.8 if possible.

[nacin]

Thanks for the report GregRoss. Would be great to address this. For what were you using the IDs?

[GregRoss]

The fullscreen button id I was using to tell when TinyMCE was loaded and then executing the full screen mode automatically.

Both the title and body id's were used to change the outline style of the areas.

I haven't look too much farther yet but I use several more id's to find/replace various parts of the distraction free interface.

I can probably work around most of them but it's going to require a lot of jQuery in comparison to a simple getElementByID call.

I suspect I'll end up rewriting a good chunk of it, but the more I can keep the same between 3.8 and 3.9 the better.

[azaozz]

In WP3.8, the fullscreen button was an 'a' link with the id of 'content_wp_fullscreen' in WP3.9 it is now a 'div' with an id of 'mce_28' (if you dig a little deeper there's an 'i' with a class of 'mce-i-wp_fullscreen'.

This is part of the new TinyMCE UI. All buttons are now <button> and the icons are added from the icon font (that is replaced with dashicons) on <i> elements.

In distraction free writing mode, the title input box used to have an ID of 'wp-fullscreen-title', now there is no ID and it has a class of 'wp-fullscreen-title'.

In distraction free writing mode, the body input div use to have an ID of 'wp-fullscreen-container' now it has an id of 'wp-content-editor-container'.

DFW was upgraded too. Before it used to create another TinyMCE instance and title field, now it "rises" the existing editor instance and title, and adds a blocker div behind them. This simplifies its operation quite a bit.

As before, DFW can be opened by executing tinymce.execCommand('wpFullScreen'), no need to search for the button, etc. Also most of the rest of DFW is the same, only there are no new title and editor.

[GregRoss]

I figured the button changes were part of 4.0, but it would still be nice to have more meaningful id's like they had before. Any idea if the numbers will change based on the buttons that are visible in the toolbar? For example if another addon adds additional buttons and reorders them could dfwm's mce_28 change to mce_30 or something else?

I don't track the dfwm button to 'click' it, but to wait for tinyMCE to finish loading (I wait for it to exist in the dom tree). If you execute tinymce.execCommand('wpFullScreen') too early in the page load it fails. Tracking to see if the buttons had loaded was an easy way to do this.

[azaozz]

Yeah, think the buttons IDs change depending on the button position and the instance. They are auto-generated from an incrementing value. Same for the toolbars and other containers.

There are better ways to determine when the editor is "ready". For example can use tinymce.on( 'AddEditor', function( editor ) { editor.on( 'init', function() { [your code] } ); });. Also thinking to fire a custom jQuery event when an editor instance is initialized, perhaps something like jQuery( document ).trigger( 'wp-tinymce-init', [ editor instance ] );.

Ref: ​http://www.tinymce.com/wiki.php/api4:class.tinymce, ​http://www.tinymce.com/wiki.php/api4:class.tinymce.Editor.

[GregRoss]

Tinymce.on won't work for me as my javascript could execute before the tinymce object is created, the trigger looks like it could work, but would require different code for 3.8 and 3.9. I can also just update my current code to look for the new 'i' and it's class, or just pick a low numbered mce_ id that will always be present. Lots of ways to get around the issue.

However, while I may be the only one with the issue, if it can be consistent with the old version then it may avoid breaking other plugins as well.

The mce_#s kind of seem useless now as you can't use them to identify any given button, only a random button.

[azaozz]

Replying to GregRoss:

Tinymce.on won't work for me as my javascript could execute before the tinymce object is created

It would. TinyMCE is loaded on 'admin_print_footer_scripts' with priority of 50: https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-editor.php#L158. You can output a small script on the same action with priority of 51 that will "bootstrap" the rest of your JS.

...the trigger looks like it could work, but would require different code for 3.8 and 3.9.

Think that custom event will be quite useful for many plugins. Can probably be used in core too. That would make it much easier to hook into the editor instance and run some JS pretty much in the same way as from a TinyMCE plugin.

Lots of ways to get around the issue.

Yep, or can simply use $('#wp-content-editor-container .button-class'). jQuery is optimized to handle these selectors nicely.

The mce_#s kind of seem useless now as you can't use them to identify any given button, only a random button.

As far as I see they are intended for internal use. TinyMCE has API methods for selecting and manipulating all UI elements.

[azaozz]

In [26983]:

TinyMCE: add a custom jQuery event 'tinymce-editor-init' triggered on initialization of every editor instance. This makes it a lot more convenient to hook into the instance compared to the init.setup callback. See #24067, see #26872.

[azaozz]

Going to close this as "worksforme". Plugins that change DFW a lot will have to be upgraded in any case. Feel free to reopen with a patch/suggestions if we can improve back-compat.

The idea to be able to load the Edit Post screen directly in DFW is quite nice. Can try to make that easier or even include it as an option, perhaps in Screen Options.

[GregRoss]

That's fine, it was mostly an informational item in general. I knew most of the 'hacks' I'd used to get the plugin working would likely break in future version of TinyMCE/WordPress (I'm acutally suprised it hasn't broken before this).

You might want to take a look my plugin, from a features perspective, it expands a lot on DFW. The auto load code can be set to run in a few different ways; when you create a new post, when you edit a post or through an additional link added to the posts lists table for each post.

I'll probably get a chance to dig deeper in to the code in the next few days and I'll see if there's anything worth trying to patch.