#24067 closed task (blessed) (fixed)
TinyMCE 4.0
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 3.9 | Priority: | high |
| Severity: | minor | Version: | 3.8 |
| Component: | TinyMCE | Keywords: | |
| Focuses: | Cc: |
Description (last modified by )
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)
Change History (160)
#2
@
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.
#9
@
11 years ago
- Cc ace_dent added
Would be a substantial improvement, with nice ability to add and edit tables.
#12
@
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!
#16
@
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:
↓ 19
@
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
@
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:
- Upgrade the basic WordPress implementation of TinyMCE to 4.0.
- Translations work differently in 4.0, refactor tinymce/langs/wp-langs.php.
- Refactor
WP_Editorsas needed. - Upgrade/refactor the 'wordpress' plugin. It contains most of our specific changes.
- Upgrade the rest of our custom plugins.
- 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?
- 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
@
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
@
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
@
11 years ago
I have set up a Test Site...
Also TinyMCE has a really nice fiddle for testing the configuration and default plugins.
#27
@
11 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 :)
#30
follow-ups:
↓ 31
↓ 34
@
11 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
@
11 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
@
11 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
@
11 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:
↓ 45
@
11 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
@
11 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:
↓ 37
@
11 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
@
11 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.
#43
follow-up:
↓ 111
@
11 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_Editorcan 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).
#44
@
11 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
@
11 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:
↓ 47
@
11 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?
#47
in reply to:
↑ 46
@
11 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
@
11 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!
#50
follow-up:
↓ 54
@
11 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.
#54
in reply to:
↑ 50
@
11 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:
↓ 58
@
11 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.
#58
in reply to:
↑ 55
@
11 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.
#73
follow-up:
↓ 77
@
11 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.
#74
@
11 years ago
I'm getting the following error after r26876:
Uncaught TypeError: Cannot read property 'off' of undefined
24067.diff should fix it.
#77
in reply to:
↑ 73
@
11 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/.
#79
follow-up:
↓ 81
@
11 years ago
Looking great. Plans to bring back image action overlays on hover to access Media or staying with default TinyMCE handling from Toolbar?
#81
in reply to:
↑ 79
@
11 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:
↓ 84
@
11 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.
#84
in reply to:
↑ 82
;
follow-up:
↓ 85
@
11 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
@
11 years ago
#86
follow-up:
↓ 88
@
11 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?
#88
in reply to:
↑ 86
@
11 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
@
11 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:
- I see a few tinymce filters have changed;
theme_advanced_buttonstotoolbarfor example. Will themce_buttonsfilter still be used? Or will this be changed?
- Codex Page: Do you plan to udpate the existing, or create a new? I'd be happy to contribute.
- TortoiseSVN: To udpate to the latest nightly build; do I just update the
srcfolder?
Many thanks.
#91
@
11 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
@
11 years ago
- No, no other plugins. Perhaps a FF plugin or addon? I'll keep an eye on it.
- Awesome-sauce. I didn't think they would be adjusted.. but wanted to make sure. Thanks.
- 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/
- Got it. Updated successfully. Thank you.
#93
@
11 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.
#97
@
11 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!
#99
follow-up:
↓ 100
@
11 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:
↓ 101
@
11 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:
↓ 102
@
11 years ago
Replying to josh401:
No problems :) The button still needed a "dashicon".
#102
in reply to:
↑ 101
@
11 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
@
11 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
@
11 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!!
#107
@
11 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
@
11 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.
#111
in reply to:
↑ 43
@
11 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_Editorcan 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:
↓ 113
@
11 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
@
11 years ago
Replying to azaozz:
We can enqueue jQuery from WP_Editor, then use it in
editor.jsand 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
@
11 years ago
Replying to azaozz:
In 26958:
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
@
11 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
@
11 years ago
[26876] removed the selection variable from htmlUpdate, although it's used and required. Patch 24067-selection-var.patch re-adds it.
#121
follow-up:
↓ 122
@
11 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
@
11 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:
- Add your plugin to the 'PluginManager'...
tinymce.PluginManager.add('yourPlugin', function(editor, url) {
... replace 'yourPlugin' with the name of your plugin.
- 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
@
11 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.
#124
@
11 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
@
11 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
@
11 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?
#127
follow-up:
↓ 128
@
11 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:
↓ 130
↓ 132
@
11 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.
#130
in reply to:
↑ 128
@
11 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_pluginsvariable 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?
#132
in reply to:
↑ 128
@
11 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?
#133
@
11 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.
#135
@
11 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!
#142
@
11 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.
#143
@
11 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:
↓ 145
@
11 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:
↓ 147
@
11 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:
↓ 148
@
11 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
#147
in reply to:
↑ 145
@
11 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:
↓ 149
@
11 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
@
11 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
@
11 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?
#152
@
11 years ago
Changelog for 4.0.21: https://github.com/tinymce/tinymce/blob/master/changelog.txt
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.