WordPress.org

Make WordPress Core

Opened 12 months ago

Closed 7 weeks ago

Last modified 5 days ago

#24067 closed task (blessed) (fixed)

TinyMCE 4.0

Reported by: josh401 Owned by: azaozz
Milestone: 3.9 Priority: high
Severity: minor Version: 3.8
Component: TinyMCE Keywords:
Focuses: Cc:

Description (last modified by azaozz)

TinyMCE 4.0 was released couple of months ago (2013-06-13). It has tons of improvements in all areas:

  • Completely new UI.
  • New, simpler and much faster dialogs.
  • New and improved APIs and default plugins, better code quality, improved unit tests, etc.

There is a slideshow that highlights some of the changes.

As the UI API, the internal events API and the file structure have changed, most of the TinyMCE 3.x plugins need to be updated to work with 4.x.

Attachments (5)

24067.patch (3.5 MB) - added by azaozz 4 months ago.
24067.diff (631 bytes) - added by kovshenin 3 months ago.
24067-selection-var.patch (397 bytes) - added by TobiasBg 2 months ago.
Re-add selection variable.
24067.2.diff (2.1 KB) - added by kovshenin 2 months ago.
24067.2.patch (493 bytes) - added by avryl 7 weeks ago.

Change History (160)

comment:1 markoheijnen12 months ago

  • Keywords ui-feedback removed

It's still in beta so it really depends on when it's going to be released. Who knows it will end up in 3.7 but hard to say.

comment:2 josh40112 months ago

Thanks @markoheijnen,

My plugin (Ultimate Tinymce) obviously relies heavily on this framework. So is trac the best place to watch for changes? I'm still a noob with trac.

comment:3 markoheijnen12 months ago

Yes, this ticket will be used to track the changes

comment:4 alex-ye12 months ago

  • Cc nashwan.doaqan@… added

Will be so great :)

comment:5 SergeyBiryukov12 months ago

  • Summary changed from Tinymce 4.0 to TinyMCE 4.0

comment:6 josh40112 months ago

Yes, this ticket will be used to track the changes

Perfect! Thank you very much!

comment:7 Jayjdk12 months ago

  • Cc kontakt@… added

comment:8 thee1710 months ago

It appears that it has now been released. I guess too late for 3.6.

comment:9 ace_dent9 months ago

  • Cc ace_dent added

Would be a substantial improvement, with nice ability to add and edit tables.

comment:10 nacin8 months ago

#25027 was marked as a duplicate.

comment:11 avryl8 months ago

  • Cc avrylnoxke@… added

comment:12 josh4018 months ago

I am seeing some movement on this ticket and just wondering if there is 'talk' circulating. If so, I'm very interested to understand how this will impact plugins/themes which add buttons to the editor. Will it now follow this format mentioned Herehttp://www.tinymce.com/wiki.php/Configuration:toolbar%3CN%3E?

It appears there are only two toolbar rows available, instead of the usual four rows in version 3.x.

Thanks!

comment:13 adamsilverstein8 months ago

  • Cc adamsilverstein@… added

comment:14 WraithKenny8 months ago

  • Cc Ken@… added

comment:16 azaozz8 months ago

  • Description modified (diff)
  • Milestone changed from Awaiting Review to Future Release
  • Owner set to azaozz
  • Status changed from new to accepted
  • Version changed from 3.5.1 to trunk

comment:17 follow-up: josh4018 months ago

Hi Andrew,

I have never been involved in WP core; but I would love to assist. If it's not an inconvenience, please let me know how I can help.

comment:18 azaozz8 months ago

Upgrading our implementation to TinyMCE 4.0 is a huge task. Additionally all WordPress plugins that add TinyMCE plugins or custom code will need to be updated (there are lots of them). There is a "compat3x" TinyMCE plugin which only includes several files that have been removed from 4.0 for now.

I'm on the fence on whether we should work on this upgrade in a "core plugin", the same way new features are being developed. All it would need is an action in wp_editor() so a different _WP_Editors class can be used and couple of feature checks in JS: if ( tinymce.onAddEditor )..., etc.

Proposing the following (loose) schedule:

  1. Upgrade the basic WordPress implementation of TinyMCE to 4.0.
    • Translations work differently in 4.0, refactor tinymce/langs/wp-langs.php.
    • Refactor WP_Editors as needed.
    • Upgrade/refactor the 'wordpress' plugin. It contains most of our specific changes.
    • Upgrade the rest of our custom plugins.
  1. Decide on default UI settings. Are we showing the menubar plus one row toolbar or are we going to stick to two rows toolbar with hidden second row? Default drop-downs to show in the menubar?
  1. Add as much back-compat fixes as possible. As a minimum running any external JS or loading 3.x plugins should never break TinyMCE or throw errors.

comment:19 in reply to: ↑ 17 azaozz8 months ago

Replying to josh401:

I have never been involved in WP core; but I would love to assist. If it's not an inconvenience, please let me know how I can help.

Sure, there are many ways to get involved: http://codex.wordpress.org/Contributing_to_WordPress. It's going to be some time before the first patch (or usable core plugin) is good enough for testing. In the meantime perhaps have a look at the main differences between TinyMCE 3.x and 4.x and what will be needed to make sure 3.x code doesn't break. For example we will probably need to add back all the old-style events: editor.onClick.add(), editor.onKeyDown.add(), tinymce.onAddEditor.add(), etc. to at least avoid fatal errors.

comment:20 josh4018 months ago

Thanks Andrew. I'll get started on those links asap.

Agreed. I have been digging in the TinyMCE documentation the last few days; I have set up a Test Site where I am beginning to experiment with adding old style addons into the new 4.x interface (taking note of what adjustments need to be made).

Will be in touch again soon.

comment:21 azaozz8 months ago

I have set up a ​Test Site...

Also TinyMCE has a really nice fiddle for testing the configuration and default plugins.

comment:22 naomicbush8 months ago

  • Cc naomicbush added

comment:23 melchoyce7 months ago

  • Cc melissachoyce@… added

comment:24 wycks7 months ago

  • Cc bob.ellison@… added

comment:25 tollmanz6 months ago

  • Cc tollmanz@… added

comment:26 Denis-de-Bernardy6 months ago

  • Cc ddebernardy@… added

azaozz4 months ago

comment:27 azaozz4 months ago

In 24067.patch: TinyMCE 4.0.12, first run. Still needs work mostly on the css side and in DFW but all base functionality is there. Includes the non-minified tinymce.js for now to make it easier to debug. Will remove it before release or maybe it can stay in /src but not get copied to /build (size is 900KB with all the inline docs). Caution: the size of this patch is 3.5MB :)

comment:28 azaozz4 months ago

  • Milestone changed from Future Release to 3.9

comment:29 jrbeilke4 months ago

  • Cc jrbeilke@… added

comment:30 follow-ups: josh4014 months ago

Wow - what a miraculous patch.
I'm having a heck of a time figuring out how to get the latest trunk of WP and this patch installed. I'm eager to try this out.. and was wondering if there were a way I could download a copy of WP with this patch already installed? Either way, I will continue to figure out svn.. it's just slowing me down.

Thank you.

comment:31 in reply to: ↑ 30 adamsilverstein4 months ago

Replying to josh401:

Wow - what a miraculous patch.
I'm having a heck of a time figuring out how to get the latest trunk of WP and this patch installed. I'm eager to try this out.. and was wondering if there were a way I could download a copy of WP with this patch already installed? Either way, I will continue to figure out svn.. it's just slowing me down.

Thank you.

Josh - instructions for installing WordPress from svn are here - http://codex.wordpress.org/Installing/Updating_WordPress_with_Subversion
another option would be to install the beta testers plugin -http://wordpress.org/plugins/wordpress-beta-tester/ which can be set to install the latest version. Either way, you will still need to use the command line to apply the patch - its a little tricky to figure out at first - well worth the effort because you will then be set up to test any patch in trac and provide valuable feedback.

comment:32 helen4 months ago

After holding down enter for approximately half an hour to make it through all the "The next patch would empty out the file" warnings, the patch took, and things seem to work well enough for a first run. I think some images might be missing for placeholders, and I'm sure there are things that we'll discover are broken or need tweaking with more testing, but I'd endorse an early first run this week.

comment:33 josh4014 months ago

Either way, you will still need to use the command line to apply the patch - its a little tricky to figure out at first - well worth the effort because you will then be set up to test any patch in trac and provide valuable feedback.

Perfect. Thank you for the clear explanation. I missed that link in my browsing.. that looks exactly like what I need. Thanks Adam.

comment:34 in reply to: ↑ 30 ; follow-up: azaozz4 months ago

Replying to josh401:

If you're on Windows, I'd recommend installing Tortoise SVN. Makes your life a lot easier :)

Then all you need to do is make new folder at the root of your local *AMP install, right-click it and select "SVN Checkout". Then paste the URL to trunk: http://develop.svn.wordpress.org/trunk in the source field and click OK. That's all. Then svn up, svn diff, svn revert, and pretty much all SVN commands are available on the right-click menu, and you'll be able to run WordPress from the /src directory.

Applying patches is quite easier too: download the patch, right-click on that folder and select "Apply Patch".

Planning to put the first run in core tomorrow or the day after, still tweaking DFW.

comment:35 adamsilverstein4 months ago

Great job! Applied the patch and in general seems to work great. Seeing a few console errors, also a few rejected pieces when applying the patch. Looking forward to more testing - very excited to see the improvements!

comment:36 follow-up: adamsilverstein4 months ago

after a little more testing, one issue I noticed after applying this patch - I am no longer able to tab from the title field to the content editor. tabbing out of the editor works fine.

comment:37 in reply to: ↑ 36 azaozz4 months ago

Replying to adamsilverstein:

Yeah, that's one of the "small things" that still needs fixing. The hidden <a> used to focus the editor in 3.x is now gone. Will fix before adding to trunk.

comment:38 netweb4 months ago

  • Cc stephen@… added

comment:39 mindctrl4 months ago

  • Cc public@… added

comment:40 samuelsidler4 months ago

  • Priority changed from normal to high
  • Severity changed from normal to minor

comment:41 follow-up: azaozz4 months ago

In 26876:

TinyMCE 4.0.12, first run.

  • Removes wp-tinymce-schema.js and mark-loaded.js, no longer needed.
  • Removes the inlinepopups and most of the wpdialogs plugins; wpdialog.js is moved to wp-includes/js.
  • Adds charmap, compat3x, image, link and textcolor plugins, previously contained in /themes/advanced.
  • Updates the wordpress, wpeditimage, wpfullscreen, wpgallery and wplink plugins.
  • Updates DFW, wp-admin/js/wp-fullscreen.js.

See #24067.

comment:42 in reply to: ↑ 41 adamsilverstein4 months ago

Replying to azaozz:

In 26876:

TinyMCE 4.0.12, first run.

  • Removes wp-tinymce-schema.js and mark-loaded.js, no longer needed.
  • Removes the inlinepopups and most of the wpdialogs plugins; wpdialog.js is moved to wp-includes/js.
  • Adds charmap, compat3x, image, link and textcolor plugins, previously contained in /themes/advanced.
  • Updates the wordpress, wpeditimage, wpfullscreen, wpgallery and wplink plugins.
  • Updates DFW, wp-admin/js/wp-fullscreen.js.

See #24067.

Bravo! Super excited to see the many improvements in TinyMCE 4 making it into WordPress - thanks for your work on this... Let the testing begin!

comment:43 follow-up: azaozz4 months ago

Let the testing begin!

Yep, and hope there will be lots of it :)

This is still a work-in-progress. Things may change or move around. There are several TODOs, but more importantly there are few to-be-decided:

  • Should we switch to the jQuery TinyMCE build? As TinyMCE also uses Sizzle, it can use the one included in jQuery, so its size will be reduced a bit. We require jQuery for both DFW and wpLink, but the basic TinyMCE outputted from WP_Editor can still be used without jQuery.
  • Should we remove the 'spellchecker' plugin? It has been disabled since 3.6 and currently doesn't work with the PHP back-end (throws an error).
  • Regarding the new UI, do we still want the second row of buttons or should we show/hide the (new) toolbar? The toolbar contains all available menu items so the user will have access to more "kitchen sink" stuff in there.

TODO:

  • Styling for the new TinyMCE dialogs. The old styling was in the 'inlinepopups' plugin that doesn't exist any more.
  • Further refinement of DFW. It was updated to avoid using another editor instance and some of the js and css was simplified. This makes it easier to use anywhere.
  • Another look through WP_Editor and editor.js.
  • Perhaps some refinements for the "Read more..." styling inside the editor and the gallery placeholder and functionality (currently it selects the placeholder on first click, opens the gallery for editing in the media modal on second click).
Last edited 4 months ago by azaozz (previous) (diff)

comment:44 azaozz4 months ago

Also: do we want to keep the Help editor button and popup? It doesn't exist any more in TinyMCE 4.0. Perhaps can move the content to the Help tab on the Edit Post screen?

comment:45 in reply to: ↑ 34 josh4014 months ago

Replying to azaozz:

If you're on Windows, I'd recommend installing Tortoise SVN. Makes your life a lot easier :)

Thanks Andrew. I am familiar with Tortoise SVN (use it for my WP plugins). Your instructions are very clear, thank you, and I'm getting ready to get it going. I really want to contribute to this part of the project.. and I feel my input would be very useful.

Be back soon!

Replying to josh401:

If you're on Windows, I'd recommend installing Tortoise SVN. Makes your life a lot easier :)

Then all you need to do is make new folder at the root of your local *AMP install, right-click it and select "SVN Checkout". Then paste the URL to trunk: http://develop.svn.wordpress.org/trunk in the source field and click OK. That's all. Then svn up, svn diff, svn revert, and pretty much all SVN commands are available on the right-click menu, and you'll be able to run WordPress from the /src directory.

Applying patches is quite easier too: download the patch, right-click on that folder and select "Apply Patch".

Planning to put the first run in core tomorrow or the day after, still tweaking DFW.

comment:46 follow-up: josh4014 months ago

Hey Andrew,

I'm almost there. I have xampp, local install, and svn pulling from the trunk successfully. Thank you.
However, when I go to apply the patch.. I receive a ton of "Rejected Patch Hunk..." errors.

Any idea? Is the patch file supposed to be in the root xampp directory; or another specific location when applying?

Last edited 4 months ago by josh401 (previous) (diff)

comment:47 in reply to: ↑ 46 netweb4 months ago

Replying to josh401:

Hey Andrew,

I'm almost there. I have xampp, local install, and svn pulling from the trunk successfully. Thank you.
However, when I go to apply the patch.. I receive a ton of "Rejected Patch Hunk..." errors.

Any idea? Is the patch file supposed to be in the root xampp directory; or another specific location when applying?

As you are now using SVN there is no need to manually apply the patch in this ticket as this has now been committed to core. Simply go to the root directory eg C:\xampp\htdocs\ right click and select 'SVN Update'

comment:48 josh4014 months ago

Replying to @netweb,

Thank you! That worked. The interface is so similar; I thought it was still the older version when I installed trunk. Only after clicking the link or image button, did I see it was using the new interface.

Thanks to EVERYONE for the help!

comment:49 azaozz4 months ago

In 26877:

Bump the TinyMCE version, see #24067.

comment:50 follow-up: azaozz4 months ago

With so many files deleted, added or changed, the one to forget was the version :)

The interface is so similar; I thought it was still the older version

Yeah, trying to keep our UI unchanged as much as possible.

comment:51 avryl4 months ago

+1 for moving the help button to the help tab.

comment:52 azaozz4 months ago

In 26880:

TinyMCE:

  • Fix toolbar icons in IE9.
  • Remove background gradients in IE < 10.
  • Lint our plugins.
  • Add draggable attribute to the caption wrapper and make the captioned images non-draggable in Chrome.

See #24067.

comment:53 azaozz4 months ago

In [26882]:

TinyMCE:

  • Fix removing leftovers from broken captions.
  • Better filter for line breaks and <br> tags when editing captions.

See #24067.

comment:54 in reply to: ↑ 50 celloexpressions4 months ago

Replying to azaozz:

The interface is so similar; I thought it was still the older version

Yeah, trying to keep our UI unchanged as much as possible.

Perhaps we should take this opportunity to explore some small iterative changes. These could take the form of re-evaluating the default buttons/layout, as well as doing an iteration on the skinning (other than Dashicons, still feels fairly pre-3.8 visually).

comment:55 follow-up: ocean904 months ago

In WebKit browsers the buttons in DFW do nothing. Tested in Chrome, Safari and Opera. No JS error, works in Firefox.

Also noticed that the width of the title input changes after closing DFW, see https://cloudup.com/i3rAuP1bK1y.

comment:56 azaozz4 months ago

In 26890:

TinyMCE: add stubs for the missing tinymce.util.Cookie, windowManager.onOpen and windowManager.onClose to the compat3x plugin. See #24067, fixes #26750.

comment:57 azaozz4 months ago

In 26896:

DFW: fix buttons and the title width, make the fade out/in when opening and closing a bit faster. See #24067.

comment:58 in reply to: ↑ 55 azaozz4 months ago

Replying to ocean90:

In WebKit browsers the buttons in DFW do nothing.

For some reason the event.target in FF and IE is the button, but in Chrome it is the button's content <i>. Should be fixed in 26896.

comment:59 azaozz4 months ago

In 26897:

TinyMCE: add stub for the missing editor.controlManager to the compat3x plugin. See #24067.

comment:60 3flex4 months ago

  • Cc 3flex added

comment:61 Jayjdk4 months ago

  • Cc kontakt@… removed

comment:62 azaozz4 months ago

In 26898:

Thickbox is needed for the media modal back-compat. Are there plugins that still use this? Also needed for PressThis. See #24067.

comment:63 azaozz4 months ago

In 26899:

TinyMCE: back-compat, refresh and re-enable the 'wpdialogs' plugin, and mark it as deprecated. See #24067.

comment:64 azaozz3 months ago

In 26900:

TinyMCE: 'wpdialogs' plugin, don't add the (external) UI dialogs element to the internal windows array, fix .close(). See #24067.

comment:66 azaozz3 months ago

In 26930:

TinyMCE: update compat3x.min.js and bump $tinymce_version. See #24067, fixes #26750.

comment:67 azaozz3 months ago

In 26934:

TinyMCE: re-enable soft resizing of images inside the editor. See #24067.

comment:68 azaozz3 months ago

In 26941:

TinyMCE: improve handling of Read More and Nextpage tags. See #24067, fixes #16239.

comment:69 azaozz3 months ago

In 26942:

TinyMCE: add/remove the 'alignnone' class when aligning images without captions. See #24067.

comment:70 azaozz3 months ago

In 26945:

TinyMCE: fix send_to_editor(). It no longer needs to replace shortcode strings with html placeholers before inserting them in the editor. This is handled properly by the editor's 'BeforeSetContent' event callbacks. See #24067.

comment:71 follow-up: azaozz3 months ago

In 26958:

TinyMCE: remove the 'spellchecker' plugin. It has been disabled for a while and the back-end currently doesn't work. See #24067.

comment:72 azaozz3 months ago

Also see #24789 re: spellchecker.

comment:73 follow-up: programmin3 months ago

Will there be significant compatibility workarounds added to the WP TinyMCE 4, or will the editor-plugin authors have to change their code?

If the latter is the case, I hope the authors of the affected plugins will be notified well in advance.

kovshenin3 months ago

comment:74 kovshenin3 months ago

I'm getting the following error after r26876:

Uncaught TypeError: Cannot read property 'off' of undefined

24067.diff should fix it.

comment:75 azaozz3 months ago

In 26966:

DFW: fix reference to off() when pressing Esc. Props kovshenin, see #24067.

comment:76 azaozz3 months ago

In 26979:

TinyMCE: set the 'add_unload_trigger' option to false for the main editor. Prevents DOM problems in Firefox when reloading the page, see #24067.

comment:77 in reply to: ↑ 73 azaozz3 months ago

Replying to programmin:

Will there be significant compatibility workarounds added to the WP TinyMCE 4, or will the editor-plugin authors have to change their code?

Both :)

TinyMCE 4.0 includes the compat3x plugin that adds back most of the changed API methods and stubs for the missing parts. However all WordPress plugins that add something to TinyMCE will still need to be updated to use the new APIs. Many will probably still work, but can look and work better if updated.

Also see http://make.wordpress.org/core/2014/01/18/tinymce-4-0-is-in-core/.

comment:78 azaozz3 months ago

In 26982:

TinyMCE: fix 3.x callbacks added with init.setup as they run before the compat3x plugin is loaded. Ideally this will be fixed internally in TinyMCE, see #24067.

comment:79 follow-up: rickalee3 months ago

Looking great. Plans to bring back image action overlays on hover to access Media or staying with default TinyMCE handling from Toolbar?

comment:80 azaozz3 months ago

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.

comment:81 in reply to: ↑ 79 azaozz3 months ago

Replying to rickalee:

Plans to bring back image action overlays on hover to access Media or staying with default TinyMCE handling from Toolbar?

Yes, looking into it. Ideally there will be "single mode" in the media modal. It will also be used for editing images after inserting them in the editor.

comment:82 follow-up: josh4013 months ago

Hi Andrew,

Good lord it's hard keeping up with you! Thanks for your help with the local install, nightly build, and tortoiseSVN.. all is working great.

I noticed when saving a post, with all plugins deactivated and running TwentyFourteen, there is a notice in the console in latest version of FF.

The notice is:

Deprecated TinyMCE API call: <target>.onSubmit.add(..)

It relates to the file wp-includes/js/tinymce/plugins/compat3x/plugin.js... at line number 27. That part of the file runs a function to console.log deprecated api calls. However, I'm not sure where the deprecated api call is originating.

Any suggestions? Thank you.

comment:83 azaozz3 months ago

In 26994:

TinyMCE: fix error trying to translate non-existent button "title" in the compat3x plugin. See #24067.

comment:84 in reply to: ↑ 82 ; follow-up: azaozz3 months ago

Replying to josh401:

The notice is:

Deprecated TinyMCE API call: <target>.onSubmit.add(..)

This comes from autosave.js. Nearly ready testing all the changes there, will commit the autosave patch shortly :)

comment:85 in reply to: ↑ 84 josh4013 months ago

Replying to azaozz:

Replying to josh401:
This comes from autosave.js. Nearly ready testing all the changes there, will commit the autosave patch shortly :)

You're a js machine! Thanks for all your hard work here!!

Last edited 3 months ago by josh401 (previous) (diff)

comment:86 follow-up: josh4013 months ago

Not sure if this is a bug or not; but we are able to set the default tab of the editor (visual or html) via a filter:

add_filter( 'wp_default_editor', create_function(' ', 'return "html";') );

This works fine when setting the default view to 'html'.

However... if we attempt to change it to the 'visual' by defualt:

add_filter( 'wp_default_editor', create_function(' ', 'return "tmce";') );

or... (I also tried)

add_filter( 'wp_default_editor', create_function(' ', 'return "tinymce";') );

It breaks the visual side of the editor (no buttons, white text on white background).

I see in `wp-admin/js/editor.js' where you are checking if the mode is 'html' or 'tmce'... so I'm pretty sure the 'tmce' is still valid.

Can anyone else replicate this issue?

Last edited 3 months ago by josh401 (previous) (diff)

comment:87 azaozz3 months ago

In 27004:

TinyMCE: fix initializing TinyMCE when the default editor in getUserSetting() is overridden from PHP by using the 'wp_default_editor' filter. See #24067.

comment:88 in reply to: ↑ 86 azaozz3 months ago

Replying to josh401:

Not sure if this is a bug or not; but we are able to set the default tab of the editor (visual or html) via a filter

Good catch. Caused by the changes in the initialization js in WP_Editor. Was thinking we can put these 20-30 lines of JS in wp-admin/js/editor.js and move it to wp-includes/js/ as it is required when using wp_editor() on the front-end, similarly to wp-includes/css/editor.css.

comment:89 josh4013 months ago

  • Summary changed from TinyMCE 4.0 to .

Thanks Andrew.

Sorry to be a pest.. but I notice another warning in latest version of FF:

Use of getPreventDefault() is deprecated. Use defaultPrevented instead.

However, I'm not sure if this is specific to this trac ticket; as it appears to be occurring on every single admin page. Just thought I would mention it here.

A few additional questions:

  1. I see a few tinymce filters have changed; theme_advanced_buttons to toolbar for example. Will the mce_buttons filter still be used? Or will this be changed?
  1. Codex Page: Do you plan to udpate the existing, or create a new? I'd be happy to contribute.
  1. TortoiseSVN: To udpate to the latest nightly build; do I just update the src folder?

Many thanks.

comment:90 nacin3 months ago

  • Summary changed from . to TinyMCE 4.0

comment:91 azaozz3 months ago

The warning about getPreventDefault() comes from jQuery. Don't see that used anywhere in WP so probably used in a plugin?

The change from theme_advanced_buttons to toolbar is in the TinyMCE 4.0 init, visible only when using 'tiny_mce_before_init' to filter the entire array. The WordPress filters are still 'mce_buttons', 'mce_buttons_2', 'mce_buttons_3', etc. and haven't changed.

Wow, the codex page is very outdated... Nearly all of it needs rewriting.

When using svn, you usually update the whole "working copy", i.e. the folder where you did svn checkout.

comment:92 josh4013 months ago

  1. No, no other plugins. Perhaps a FF plugin or addon? I'll keep an eye on it.
  1. Awesome-sauce. I didn't think they would be adjusted.. but wanted to make sure. Thanks.
  1. Right?!! Can anyone contribute (me)... or is it for the 'elite only'?? Also, I certainly wouldn't mind seeing my plugin listed on that codex page :) Ultimate Tinymce : http://wordpress.org/plugins/ultimate-tinymce/
  1. Got it. Updated successfully. Thank you.

comment:93 azaozz3 months ago

Right?!! Can anyone contribute (me)... or is it for the 'elite only'?? Also, I certainly wouldn't mind seeing my plugin listed on that codex page :)

Sure, the codex is a wiki, anybody can contribute.

Don't think listing individual plugins is a good idea there, much better to link to plugin tags? So, for the TinyMCE codex page a link to http://wordpress.org/plugins/tags/tinymce would be nice.

comment:94 azaozz3 months ago

In 27030:

TinyMCE: fix the compat3x plugin appending 'en.' to button titles. Set charset to UTF-8 in html_entity_decode() for translated strings. See #24067, see #26875.

comment:95 azaozz3 months ago

In 27034:

TinyMCE: do not run preventDefault() on the tab key when Ctrl, Alt or Command key is also pressed. Ctrl + Tab is used to switch between browser tabs. See #24067, fixes #17261.

comment:96 azaozz3 months ago

In 27039:

DFW: remove unused #wp-fullscreen-title-prompt-text selectors. See #24067.

comment:97 josh4013 months ago

Hi Andrew,

I think there is something 'buggy' with the pagebreak button. If you could be so kind as to add it to one of your rows using pagebreak (which I'm sure you already know).

The issue comes when switching between the 'visual' and 'text' tabs; after you have created the page breaks.

For example, take this code being inserted into 'visual' mode:

Page 1
(click the pagebreak button)
Page 2
(click the pagebreak button)
Page 3

This results in the following html (on text side):

First Page<!--nextpage-->Second Page<!--nextpage-->Third Page

This works great when previewed.
But.. switch to the visual and back to text.
You will end up with something like this:

<!--nextpage-->
<!--nextpage-->
First PageSecond PageThird Page

This will break any pages when viewing on the front end.. if saved in this state.

I noticed when inserting a wp_more into the visual side... we get a nice little placeholder image. But if you do the same with the pagebreak... we get a weird dotted border.

NOTE: I had to modify the tinymce init filter:

pagebreak_separator = '<!--nextpage-->';

This makes the button insert the <!--nextpage--> text into the editor.

That's all I can determine for now. Thank you for your time!

Last edited 3 months ago by josh401 (previous) (diff)

comment:98 azaozz3 months ago

In 27044:

TinyMCE: add dashicon for the "wp_page" button, see #24067.

comment:99 follow-up: azaozz3 months ago

I think there is something 'buggy' with the pagebreak button.

Our implementation has its own "pagebreak" defined in the `wordpress` plugin, disabled by default. To use it add 'wp_page' to any toolbar.

The difference is that the html comment is always inserted in the body under the current block.

comment:100 in reply to: ↑ 99 ; follow-up: josh4013 months ago

Replying to azaozz:

Our implementation has its own "pagebreak" ...

Aghh.. that's right. I remember that now. Very sorry to have wasted your time... (tail between legs)...

comment:101 in reply to: ↑ 100 ; follow-up: azaozz3 months ago

Replying to josh401:

No problems :) The button still needed a "dashicon".

comment:102 in reply to: ↑ 101 josh4013 months ago

Replying to azaozz:

No problems :) The button still needed a "dashicon".

Thanks. I saw that... makes me feel a little better.. sniff sniff.

Question.. what's with the dashicons coming from multiple stylesheets? Some pull from wp-includes/js/tinymce/skins/lightgray/skin.min.css, while others (like the one you just added) are located at wp-includes/css/editor.css.

Is there any logic I'm missing? I've enqueued the dashicons.. but I still seem to have to pull from all three resources to get them all. Will there be a central location (or is there one already)?

comment:103 azaozz3 months ago

TinyMCE 4.0 comes with its own icons font, actually two fonts. They are used for all default buttons.

In editor.css we override the icons for the buttons used by default in WordPress with our own dashicons icon font, and add icons for the extra buttons. You don't need to enqueue dashicons separately, it's always included as it is a dependency for editor.css.

comment:104 josh4013 months ago

Ingenious. Makes perfect sense now. Thank you.

Actually, I've enqueued it on my plugin settings page to render the fonts exactly as they appear in the editor. Talk about a time saver with having to have font images in the tinymce plugin js folder, as well as in my plugin folder. Saves lots of lines of code.. and space! Love them dashicons!!

comment:105 azaozz3 months ago

In 27052:

TinyMCE: fix Ctrl + s shortcut (trigger autosave), see #24067.

comment:106 helen3 months ago

#24831 was marked as a duplicate.

comment:107 Apiweb3 months ago

TinyMCE has been updated to version 4.0.14, do not know if the changes to adapt it again to WordPress will be many, but it corrects enough bugs that occurred in that version 4.

comment:108 azaozz3 months ago

TinyMCE has been updated to version 4.0.14...

Yes, will be updating it later today. Several of the changes there were merged upstream from our implementation, so they are already in core.

comment:109 azaozz3 months ago

In 27060:

TinyMCE: update to 4.0.14. Remove the fix for using init.setup in old plugins, now fixed upstream. See #24067.

comment:110 azaozz3 months ago

In 27062:

TinyMCE: update to 4.0.16, see #24067.

comment:111 in reply to: ↑ 43 josh4013 months ago

Replying to azaozz:

  • Should we switch to the jQuery TinyMCE build? As TinyMCE also uses Sizzle, it can use the one included in jQuery, so its size will be reduced a bit. We require jQuery for both DFW and wpLink, but the basic TinyMCE outputted from WP_Editor can still be used without jQuery.

I hope it's not to late to cast a vote here... but after digging into my tinymce addons, I've realized how much nicer it would be to have jQuery built-in.

The size of the 4.0.16 TinyMCE non-jQuery build is 280KB; the jQuery build is 274KB. Lighter is better.. Yes??

Andrew, your pay grade is WAY above mine.. so I'm not sure I understand the implications of using the jQuery build within the scope of WordPress.

However... my vote is definitely to include the jQuery version. It makes developing additional plugins a breeze. And, if it still retains it's original functionality... even better.

What would be any downsides to using the jQuery build?

comment:112 follow-up: azaozz3 months ago

Looking at the differences between tinymce.js and tinymce.jquery.js, there are only couple of helper functions in the jQuery build that include Sizzle. No other differences.

There is also the jQuery addon that adds a few handy methods to jQuery mostly for initializing TinyMCE, but has to patch few of the methods. As far as I see this can be used without using the jQuery build.

Note that jQuery is not loaded inside the editor iframe, using it there can break things.

So using the jQuery build wouldn't make much of a difference except the slightly smaller size of wp-tinymce.js.gz. However there's a possibility that the version of Sizzle in jQuery might be different than the one in TinyMCE (some plugin loading old version of jQuery on the front-end and another plugin adding TinyMCE, etc.). So safest would be to use the standard build.

We can enqueue jQuery from WP_Editor, then use it in editor.js and the init script. That will simplify them a bit and ensure that jQuery is always present for use outside/around the editor.

comment:113 in reply to: ↑ 112 josh4013 months ago

Replying to azaozz:

We can enqueue jQuery from WP_Editor, then use it in editor.js and the init script. That will simplify them a bit and ensure that jQuery is always present for use outside/around the editor.

This sounds ideal :)

A question:
When we create a new addon for tinymce4, we write a plugin.js file. It always begins with tinymce.PluginManager.add() {...}. If I wanted to use jQuery in this file.. can I just wrap the entire contents with a jQuery wrapper? jQuery(document).ready(function($) { tinymce.pluginManager.add() {...}});

It seems to work fine.. but I was wondering if this method is okay... or if there is a better method. I thought the jQuery build of TinyMCE would allow jQuery to be used in the plugin.js files.. without a wrapper.

I don't mind either way.. but is there a 'best practice'?

Thank you!

comment:114 in reply to: ↑ 71 GregRoss2 months ago

Replying to azaozz:

In 26958:

TinyMCE: remove the 'spellchecker' plugin. It has been disabled for a while and the back-end currently doesn't work. See #24067.

Removing the spellchecker has some downstream consequences. For example the old After the Deadline plugin assumes it's there. In 3.6/7/8 After the Deadline worked just fine but without the plugin available the button is never added to the toolbar, so while it works, the user cannot access it.

comment:115 azaozz2 months ago

If I wanted to use jQuery in this file.. can I just wrap the entire contents with a jQuery wrapper?

I don't see why not. However that should run as soon as the JS file is loaded, not on DOM ready.

For example the old After the Deadline plugin assumes it's there.
...without the plugin available the button is never added to the toolbar

The old AtD plugin is not compatible with TinyMCE 4.0. It still adds the button: https://plugins.trac.wordpress.org/browser/after-the-deadline/tags/0.49008/after-the-deadline.php#L74 but cannot build the replacement words menu. AtD in Jetpack was updated and works well in 4.0.

comment:116 TobiasBg2 months ago

[26876] removed the selection variable from htmlUpdate, although it's used and required. Patch 24067-selection-var.patch re-adds it.

TobiasBg2 months ago

Re-add selection variable.

comment:117 azaozz2 months ago

In 27083:

TinyMCE: don't replace <i> with <em> and <b> with <strong> and don't remove them when empty, see #24067, see #23037.

comment:118 azaozz2 months ago

In 27084:

Add back missing var definition in wplink.js, props TobiasBg, see #24067

comment:119 azaozz2 months ago

In 27085:

Minor cleanup (jshint) of wp-fullscreen.js and /wordpress/plugin.js, see #24067

comment:120 azaozz2 months ago

In 27098:

TinyMCE: set the proper caption width when clicking image resize handle on image with caption. Props gcorne, fixes #27009, see #24067.

comment:121 follow-up: programmin2 months ago

I'm still getting deprecated-warnings for tinyMCE.onAddEditor.add.

However, I haven't found an equivalent way to add a handler for TinyMCE 4. An example is found here: https://github.com/ichord/At.js/wiki/usage-with-TinyMCE, but I'm not sure if I'd have to manually replace the part of the init (Replace it from PHP, where any other addon could replace it?) or a newer JS way of doing it (tinyMCE.on('AddEditor', function... doesn't seem to work.)

What is the recommended way to replace this function?

comment:122 in reply to: ↑ 121 josh4012 months ago

Replying to programmin:

What is the recommended way to replace this function?

I'm not sure how the 'ichord' plugin functions in it's entirety... but this is how I am converting mine:

  1. Add your plugin to the 'PluginManager'...

tinymce.PluginManager.add('yourPlugin', function(editor, url) {

... replace 'yourPlugin' with the name of your plugin.

  1. Then, you can add this for your init...

editor.on('init', function(args) {
Custom logic
});

The Tinymce Migration Page may be of help, also.

comment:123 azaozz2 months ago

tinymce.on('AddEditor', function()... works as expected but is somewhat hard to use. The JS has to run after tinymce.js is loaded (obviously) but before the tinymce.init() call for the instance. By default tinymce.init() is fired shortly after tinymce.js is loaded, so it's hard to time when to do 'AddEditor' especially from other JS.

As @josh401 suggested best would be if there is a small TinyMCE plugin that does this. Alternatively there is a (new) jQuery custom event fired on editor.init as long as the 'wordpress' plugin is loaded.

Also, looking at At.js: it is not a very good idea to manipulate the editor content (the iframe's body) with jQuery. Generally you can "look" but not "touch" as changing anything else that text strings would bypass the TinyMCE internal handling of events, node changes, etc.

kovshenin2 months ago

comment:124 kovshenin2 months ago

In the help dialog there's still a reference to the "Paste from Word" button and "one of the paste buttons." See 24067.2.diff.

comment:125 needle2 months ago

Just a heads-up that when including TinyMCE 4 via wp_editor() on the front-end in a BuddyPress context, the TinyMCE toolbar buttons inherit some button:hover{} styles. Adding something like the following to editor.css would help prevent TinyMCE's buttons from inheriting them:

.mce-toolbar .mce-btn button:hover {
	background: none;
	filter: none;
	border: none;
	color: #333;
}

comment:126 programmin2 months ago

Anyone else noticing that _WP_Editors::editor_settings doesn't output the plugin, when using

add_filter( 'mce_external_plugins', 'myfunction' ,12,1);

Myfunction being a function something like

function myfunction($plugin_array) {
   $plugin_array['pluginid'] = url to js
   return $plugin_array
 }

As documented here: http://codex.wordpress.org/Plugin_API/Filter_Reference/mce_external_plugins

Although I see the pluginid in the mceInit, I don't see the url referenced anywhere in the source of the page. On a frontend page, if that matters.

Is this a bug, or does MCE4 require different behavior? Update: This seems to be caused by this, around line 250 of class-wp-editor.php:

if ( ! empty( $mce_external_plugins ) ) {
						/**
						 * This filter loads translations for external TinyMCE 3.x plugins.
						 *
						 * Takes an associative array 'plugin_name' => 'path', where path is the
						 * include path to the file. The language file should follow the same format as
						 * wp_mce_translation() and should define a variable $strings that
						 * holds all translated strings.
						 */

(It continues to load the plugin, IF a translation is specified. Custom mce_external_language wasn't required before, to load mce_external_plugins.)

Last edited 2 months ago by programmin (previous) (diff)

comment:127 follow-up: josh4012 months ago

Hi Andrew,

I'm adding a tinymce split button from one of my addons:

editor.addButton('cleardiv', {
		
	type: 'splitbutton',
	tooltip: 'Clear Div',
	//text: 'Clear',
	image: url + '/images/cleardiv.gif',
	menu: 
	[
		{
			text: 'Clear Left',
			onclick: function() { insertClear('left'); }  // Execute function to clear left
		},
		{
			text: 'Clear Right',
			onclick: function() { insertClear('right'); }  // Execute function to clear right
		},
		{
			text: 'Clear Both',
			onclick: function() { insertClear('both'); }  // Execute function to clear both
		}
	]
			
});

I cannot seem to get the image for the icon to appear. I've tried using the image: and the icon: settings... but nothing. Everything else works perfectly.. just no image. The text will display fine if I use that setting; but I'd prefer to use an icon.

I see when adding a normal button, tinymce will add a style of background-image to the button; which displays the icon. I don't see this happening when it is a split button (the style isn't applied).

Does WordPress filter this setting? Or is it perhaps a tinymce bug?

comment:128 in reply to: ↑ 127 ; follow-ups: azaozz2 months ago

Replying to programmin:

Anyone else noticing that _WP_Editors::editor_settings doesn't output the plugin, when using add_filter( 'mce_external_plugins', 'myfunction' ,12,1);

Your code works as expected here. TinyMCE 4.0 loads external plugins differently: there is a init setting external_plugins: { 'plugin-name': 'url-to-the-plugin-file' } and WP_Editor sets that correctly.

This seems to be caused by this, around line 250 of class-wp-editor.php:

If you look closely you'll see that an old style translation file is not required. That code is there for back-compat only. These files are loaded only if set with the 'mce_external_languages' filter. Then each file is "marked as done" so TinyMCE doesn't try to load it again. Agree that keeping the old $ext_plugins variable name is confusing. Not too late to change.

The codex page needs updating. You're welcome to update it too :)

Replying to josh401:

No WP doesn't do anything to the toolbars or the buttons except overriding some of the font based icons in editor.css. Looks like a TinyMCE thing. Maybe use one of the "dashicons" or add the icon image as background from CSS? Both ways will need a little of CSS added to the page.

comment:129 azaozz2 months ago

In 27190:

TinyMCE: style the modals to match WordPress admin (first-run). Fix couple of IE problems in tiny_mce_popup.js. Props avryl, see #26952, see #24067

comment:130 in reply to: ↑ 128 programmin2 months ago

Replying to azaozz:

Replying to programmin:

Anyone else noticing that _WP_Editors::editor_settings doesn't output the plugin, when using add_filter( 'mce_external_plugins', 'myfunction' ,12,1);

Your code works as expected here. TinyMCE 4.0 loads external plugins differently: there is a init setting external_plugins: { 'plugin-name': 'url-to-the-plugin-file' } and WP_Editor sets that correctly.

This seems to be caused by this, around line 250 of class-wp-editor.php:

If you look closely you'll see that an old style translation file is not required. That code is there for back-compat only. These files are loaded only if set with the 'mce_external_languages' filter. Then each file is "marked as done" so TinyMCE doesn't try to load it again. Agree that keeping the old $ext_plugins variable name is confusing. Not too late to change.

The codex page needs updating. You're welcome to update it too :)

BTW I see the compat3x plugin is included, am I correct in assuming this will be included for the foreseeable future, for compatibility?

comment:131 azaozz2 months ago

Of course. It will be included as long as it is maintained by TinyMCE.

comment:132 in reply to: ↑ 128 josh4018 weeks ago

Replying to azaozz:

No WP doesn't do anything to the toolbars or the buttons except overriding some of the font based icons in editor.css. Looks like a TinyMCE thing. Maybe use one of the "dashicons" or add the icon image as background from CSS? Both ways will need a little of CSS added to the page.

Thank you. I was hoping to avoid having to add an entirely new stylesheet per addon. Fortunately, I was able to get around it using this line of code (posted here for prosperity):

text: '<img src="'+url+'/images/cleardiv.png" />'

Seems the 'text' object likes html :)

Another issue came up after I did the most recent commit changes last night (was working fine, prior). It has to do with dropdown (listbox) items, and their z-index.

See how the listbox items are behind both the tinymce overlay and the page overlay? There's also an extra little icon there.

Does this happen for you also?

http://joshlobe.com/images/tinymce_listbox.png

avryl7 weeks ago

comment:133 avryl7 weeks ago

Some themes add a box-shadow to images in the editor, so it should be removed for the more and nextpage placeholders. Patch above.

comment:134 azaozz7 weeks ago

In 27345:

TinyMCE: remove box-shadow from the "more" and "nextpage" placeholder images, props avryl, see #24067

comment:135 nacin7 weeks ago

  • Resolution set to fixed
  • Status changed from accepted to closed
  • Type changed from enhancement to task (blessed)

At this point, all bugs/tweaks/enhancements should go in new tickets.

If you have a support-related question, you can use the alpha/beta section of the forums.

Great work, everyone!

comment:136 azaozz7 weeks ago

In 27387:

TinyMCE: update to 4.0.18, see #24067

comment:137 azaozz7 weeks ago

In 27391:

DFW: revert adding the 'image' button, images are edited in the media modal. See #24067.

comment:138 azaozz4 weeks ago

In 27602:

TinyMCE show/hide toolbar row: fix the value for getUserSetting('hidetb'): 0 == hidden, 1 == visible, see #24067

comment:139 azaozz4 weeks ago

In 27603:

TinyMCE: update to 4.0.20, see #24067

comment:140 nacin4 weeks ago

In 27618:

TinyMCE strings: Merge, remove, reorganize, restore, clarify.

see #27453, #24067.

comment:141 azaozz4 weeks ago

In 27660:

TinyMCE:

  • Fix PressThis styling when the popup is resized.
  • Don't force loading of the media JS.
  • Add the 'image' plugin as fallback when no media button(s).
  • Add back the link icon tooltip/menu item string for translation.

See #24067, see #24409

comment:142 johnstonphilip4 weeks ago

@azaozz @programmin

My apologies for posting on a closed topic - however it seems most appropriate because this problem was mentioned here.

I am having the same issue @programmin mentioned above where a custom tinymce plugin hooked to 'mce_external_plugins' is not being loaded (in 3.8.2 it worked fine but does not in 3.9-beta2).

I noticed @azaozz mentioned that TinyMCE 4 requires a new way of loading external plugins and mentioned this (which I do not understand):

external_plugins: { 'plugin-name': 'url-to-the-plugin-file' }

Any clarification or guidance on how to properly load an external plugin now would be appreciated. I feel like this change will need to be clearly outlined if it is going to break all previously-working custom tinyMCE plugins.

Sidenote: Interestingly, it loads my custom external plugin if I set the $plugins var to be NULL by either:

a) returning NULL to the tiny_mce_plugins filter
b) set the $plugins var (line 342 of class-wp-editor.php) to be NULL

UPDATE:

Nevermind my previous comments here. My external plugin is now working fine because it was actually due to a problem with my code and an if statement I copied from the newly updated wpgallery plugin:

'wpview' handles the gallery shortcode when present
if ( ! editor.plugins.wpview ) {

That was restricting my plugin from actually running its functions (Though I'm still not sure why returning NULL to the $plugins array fixed it).

Anyway. Disregard and all appears to be working as it should. Thanks.

Last edited 4 weeks ago by johnstonphilip (previous) (diff)

comment:143 programmin3 weeks ago

By "returning NULL to the $plugins array fixed it", could it be that you were adding with tiny_mce_plugins, which gets the plugin removed in 3.9? I noticed this, and documented it here: http://codex.wordpress.org/Plugin_API/Filter_Reference/mce_external_plugins#Wordpress_3.9.2B_compatibility

comment:144 follow-up: johnstonphilip3 weeks ago

Thanks for adding to the codex.

I was adding my tinymce plugin using "mce_external_plugins". It didn't work if I did that. But if I ALSO returned NULL to "tiny_mce_plugins", my plugin worked.

I'm guessing that there may have been a conflict with a default plugin and my own - and that by removing all the default plugins (by returning NULL to "tiny_mce_plugins"), my plugin no longer had a conflict.

Sidenote:

It's no skin off my back either way, but, my personal opinion of a change of this magnitude with this little backwards compatibility is that this change should probably wait until 4.0.

comment:145 in reply to: ↑ 144 ; follow-up: nacin3 weeks ago

Replying to johnstonphilip:

It's no skin off my back either way, but, my personal opinion of a change of this magnitude with this little backwards compatibility is that this change should probably wait until 4.0.

3.9, 4.0, and 4.1 are all major releases. 4.0 doesn't mean anything different to us than 3.9 or 4.1. We count using base 10. You could just as easily think of them as 39, 40, 41. Yeah, it's weird, but we've been doing it for years and it's worked out alright.

comment:146 follow-up: Bueltge3 weeks ago

A externel Ressource to understand how we can add a a custom button.
http://wordpress.stackexchange.com/questions/139163/add-custom-tinymce-4-button-usable-since-wordpress-3-9-beta1

Also a gist to download, fork the plugin.
https://gist.github.com/bueltge/9758082

Last edited 3 weeks ago by Bueltge (previous) (diff)

comment:147 in reply to: ↑ 145 johnstonphilip3 weeks ago

Replying to nacin:

Replying to johnstonphilip:

It's no skin off my back either way, but, my personal opinion of a change of this magnitude with this little backwards compatibility is that this change should probably wait until 4.0.

3.9, 4.0, and 4.1 are all major releases. 4.0 doesn't mean anything different to us than 3.9 or 4.1. We count using base 10. You could just as easily think of them as 39, 40, 41. Yeah, it's weird, but we've been doing it for years and it's worked out alright.

Good to know! Thanks

comment:148 in reply to: ↑ 146 ; follow-up: azaozz3 weeks ago

Replying to johnstonphilip:

...all appears to be working as it should. Thanks.

Glad you figured it out. Yes, the way external plugins are loaded in TinyMCE 4.0 is different, but the WordPress filter still works in exactly the same way.

Replying to Bueltge:

Also a gist to download, fork the plugin.

There's a (copy/paste?) typo in the gist, line 30 in plugin.js is not needed. Many of the TinyMCE's default plugins add button and menu item. That serves as a good example.

comment:149 in reply to: ↑ 148 Bueltge3 weeks ago

Replying to azaozz:

There's a (copy/paste?) typo in the gist, line 30 in plugin.js is not needed. Many of the TinyMCE's default plugins add button and menu item. That serves as a good example.

You have right, now fixed. But I think a discussion is better on the gist or WPSE q&a.

I have also read, learn on the default plugins, but is not helpful on the WP side, the php part. But is many helpful to find the right button, like list, popup window etc.

comment:150 GDragoN3 weeks ago

I started adapting old code to new TinyMCE4, but there are many issues with windowManager. First of all, height value can't be "auto" anymore, when it is set to "auto", dialog is rendered at the top of the page (not cenetered). Also, there is no way to specify some inline HTML for the dialog body. You can set inline HTML for the whole dialog, but such dialog has no titlebar or buttons. Is there any real example of how to set windowManager to load HTML from inline DIV into the dialog body, and still have displayed title and buttons?

comment:151 azaozz2 weeks ago

In 27897:

TinyMCE: update to 4.0.21, see #24067

comment:153 azaozz2 weeks ago

In 27922:

TinyMCE:

  • Bring back loading of /langs/[locale].js and /langs/[locale]_dlg.js from PHP. Prevents errors with missing translation files when custom plugins use requireLangPack() without second argument.
  • Back to using ISO 639-1 (two letter) locales as the locale is used as part of the translation file name.

See #24067, fixes #27610

comment:154 azaozz2 weeks ago

In 27927:

TinyMCE: update translatable strings, see #27453, #24067

comment:155 nacin5 days ago

In 28112:

TinyMCE: Always load translations, even in English, as we modify some strings.

Move a setting to after the translations filter, and remove unused strings.

see #24067.

Note: See TracTickets for help on using tickets.