Make WordPress Core

Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#24067 closed task (blessed) (fixed)

TinyMCE 4.0

Reported by: josh401's profile josh401 Owned by: azaozz's profile 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 10 years ago.
24067.diff (631 bytes) - added by kovshenin 10 years ago.
24067-selection-var.patch (397 bytes) - added by TobiasBg 10 years ago.
Re-add selection variable.
24067.2.diff (2.1 KB) - added by kovshenin 10 years ago.
24067.2.patch (493 bytes) - added by iseulde 10 years ago.

Change History (160)

#1 @markoheijnen
11 years 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.

#2 @josh401
11 years 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.

#3 @markoheijnen
11 years ago

Yes, this ticket will be used to track the changes

#4 @alex-ye
11 years ago

  • Cc nashwan.doaqan@… added

Will be so great :)

#5 @SergeyBiryukov
11 years ago

  • Summary changed from Tinymce 4.0 to TinyMCE 4.0

#6 @josh401
11 years ago

Yes, this ticket will be used to track the changes

Perfect! Thank you very much!

#7 @Jayjdk
11 years ago

  • Cc kontakt@… added

#8 @thee17
11 years ago

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

#9 @ace_dent
11 years ago

  • Cc ace_dent added

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

#10 @nacin
11 years ago

#25027 was marked as a duplicate.

#11 @iseulde
11 years ago

  • Cc avrylnoxke@… added

#12 @josh401
11 years 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!

#13 @adamsilverstein
11 years ago

  • Cc adamsilverstein@… added

#14 @WraithKenny
11 years ago

  • Cc Ken@… added

#16 @azaozz
11 years 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

#17 follow-up: @josh401
11 years 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.

#18 @azaozz
11 years 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.

#19 in reply to: ↑ 17 @azaozz
11 years 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.

#20 @josh401
11 years 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.

#21 @azaozz
11 years ago

I have set up a ​Test Site...

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

#22 @naomicbush
11 years ago

  • Cc naomicbush added

#23 @melchoyce
11 years ago

  • Cc melissachoyce@… added

#24 @wycks
11 years ago

  • Cc bob.ellison@… added

#25 @tollmanz
10 years ago

  • Cc tollmanz@… added

#26 @Denis-de-Bernardy
10 years ago

  • Cc ddebernardy@… added

@azaozz
10 years ago

#27 @azaozz
10 years 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 :)

#28 @azaozz
10 years ago

  • Milestone changed from Future Release to 3.9

#29 @jrbeilke
10 years ago

  • Cc jrbeilke@… added

#30 follow-ups: @josh401
10 years 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.

#31 in reply to: ↑ 30 @adamsilverstein
10 years 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.

#32 @helen
10 years 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.

#33 @josh401
10 years 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.

#34 in reply to: ↑ 30 ; follow-up: @azaozz
10 years 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.

#35 @adamsilverstein
10 years 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!

#36 follow-up: @adamsilverstein
10 years 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.

#37 in reply to: ↑ 36 @azaozz
10 years 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.

#38 @netweb
10 years ago

  • Cc stephen@… added

#39 @mindctrl
10 years ago

  • Cc public@… added

#40 @samuelsidler
10 years ago

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

#41 follow-up: @azaozz
10 years 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.

#42 in reply to: ↑ 41 @adamsilverstein
10 years 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!

#43 follow-up: @azaozz
10 years 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 10 years ago by azaozz (previous) (diff)

#44 @azaozz
10 years 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?

#45 in reply to: ↑ 34 @josh401
10 years 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.

#46 follow-up: @josh401
10 years 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 10 years ago by josh401 (previous) (diff)

#47 in reply to: ↑ 46 @netweb
10 years 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'

#48 @josh401
10 years 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!

#49 @azaozz
10 years ago

In 26877:

Bump the TinyMCE version, see #24067.

#50 follow-up: @azaozz
10 years 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.

#51 @iseulde
10 years ago

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

#52 @azaozz
10 years 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.

#53 @azaozz
10 years ago

In [26882]:

TinyMCE:

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

See #24067.

#54 in reply to: ↑ 50 @celloexpressions
10 years 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).

#55 follow-up: @ocean90
10 years 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.

#56 @azaozz
10 years 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.

#57 @azaozz
10 years ago

In 26896:

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

#58 in reply to: ↑ 55 @azaozz
10 years 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.

#59 @azaozz
10 years ago

In 26897:

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

#60 @3flex
10 years ago

  • Cc 3flex added

#61 @Jayjdk
10 years ago

  • Cc kontakt@… removed

#62 @azaozz
10 years 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.

#63 @azaozz
10 years ago

In 26899:

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

#64 @azaozz
10 years ago

In 26900:

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

#66 @azaozz
10 years ago

In 26930:

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

#67 @azaozz
10 years ago

In 26934:

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

#68 @azaozz
10 years ago

In 26941:

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

#69 @azaozz
10 years ago

In 26942:

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

#70 @azaozz
10 years 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.

#71 follow-up: @azaozz
10 years 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.

#72 @azaozz
10 years ago

Also see #24789 re: spellchecker.

#73 follow-up: @programmin
10 years 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.

@kovshenin
10 years ago

#74 @kovshenin
10 years ago

I'm getting the following error after r26876:

Uncaught TypeError: Cannot read property 'off' of undefined

24067.diff should fix it.

#75 @azaozz
10 years ago

In 26966:

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

#76 @azaozz
10 years 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.

#77 in reply to: ↑ 73 @azaozz
10 years 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/.

#78 @azaozz
10 years 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.

#79 follow-up: @rickalee
10 years ago

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

#80 @azaozz
10 years 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.

#81 in reply to: ↑ 79 @azaozz
10 years 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.

#82 follow-up: @josh401
10 years 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.

#83 @azaozz
10 years ago

In 26994:

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

#84 in reply to: ↑ 82 ; follow-up: @azaozz
10 years 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 :)

#85 in reply to: ↑ 84 @josh401
10 years 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 10 years ago by josh401 (previous) (diff)

#86 follow-up: @josh401
10 years 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 10 years ago by josh401 (previous) (diff)

#87 @azaozz
10 years 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.

#88 in reply to: ↑ 86 @azaozz
10 years 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.

#89 @josh401
10 years 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.

#90 @nacin
10 years ago

  • Summary changed from . to TinyMCE 4.0

#91 @azaozz
10 years 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.

#92 @josh401
10 years 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.

#93 @azaozz
10 years 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.

#94 @azaozz
10 years 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.

#95 @azaozz
10 years 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.

#96 @azaozz
10 years ago

In 27039:

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

#97 @josh401
10 years 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 10 years ago by josh401 (previous) (diff)

#98 @azaozz
10 years ago

In 27044:

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

#99 follow-up: @azaozz
10 years 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.

#100 in reply to: ↑ 99 ; follow-up: @josh401
10 years 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)...

#101 in reply to: ↑ 100 ; follow-up: @azaozz
10 years ago

Replying to josh401:

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

#102 in reply to: ↑ 101 @josh401
10 years 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)?

#103 @azaozz
10 years 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.

#104 @josh401
10 years 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!!

#105 @azaozz
10 years ago

In 27052:

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

#106 @helen
10 years ago

#24831 was marked as a duplicate.

#107 @Apiweb
10 years 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.

#108 @azaozz
10 years 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.

#109 @azaozz
10 years ago

In 27060:

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

#110 @azaozz
10 years ago

In 27062:

TinyMCE: update to 4.0.16, see #24067.

#111 in reply to: ↑ 43 @josh401
10 years 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?

#112 follow-up: @azaozz
10 years 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.

#113 in reply to: ↑ 112 @josh401
10 years 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!

#114 in reply to: ↑ 71 @GregRoss
10 years 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.

#115 @azaozz
10 years 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.

#116 @TobiasBg
10 years ago

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

@TobiasBg
10 years ago

Re-add selection variable.

#117 @azaozz
10 years 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.

#118 @azaozz
10 years ago

In 27084:

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

#119 @azaozz
10 years ago

In 27085:

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

#120 @azaozz
10 years ago

In 27098:

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

#121 follow-up: @programmin
10 years 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?

#122 in reply to: ↑ 121 @josh401
10 years 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.

#123 @azaozz
10 years 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.

@kovshenin
10 years ago

#124 @kovshenin
10 years 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.

#125 @needle
10 years 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;
}

#126 @programmin
10 years 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 10 years ago by programmin (previous) (diff)

#127 follow-up: @josh401
10 years 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?

#128 in reply to: ↑ 127 ; follow-ups: @azaozz
10 years 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.

#129 @azaozz
10 years 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

#130 in reply to: ↑ 128 @programmin
10 years 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?

#131 @azaozz
10 years ago

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

#132 in reply to: ↑ 128 @josh401
10 years 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

@iseulde
10 years ago

#133 @iseulde
10 years 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.

#134 @azaozz
10 years ago

In 27345:

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

#135 @nacin
10 years 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!

#136 @azaozz
10 years ago

In 27387:

TinyMCE: update to 4.0.18, see #24067

#137 @azaozz
10 years ago

In 27391:

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

#138 @azaozz
10 years ago

In 27602:

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

#139 @azaozz
10 years ago

In 27603:

TinyMCE: update to 4.0.20, see #24067

#140 @nacin
10 years ago

In 27618:

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

see #27453, #24067.

#141 @azaozz
10 years 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

#142 @johnstonphilip
10 years 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 10 years ago by johnstonphilip (previous) (diff)

#143 @programmin
10 years 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

#144 follow-up: @johnstonphilip
10 years 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.

#145 in reply to: ↑ 144 ; follow-up: @nacin
10 years 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.

#146 follow-up: @Bueltge
10 years 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 10 years ago by Bueltge (previous) (diff)

#147 in reply to: ↑ 145 @johnstonphilip
10 years 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

#148 in reply to: ↑ 146 ; follow-up: @azaozz
10 years 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.

#149 in reply to: ↑ 148 @Bueltge
10 years 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.

#150 @GDragoN
10 years 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?

#151 @azaozz
10 years ago

In 27897:

TinyMCE: update to 4.0.21, see #24067

#153 @azaozz
10 years 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

#154 @azaozz
10 years ago

In 27927:

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

#155 @nacin
10 years 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.