TinyMCE 3.x support

Yes, that's on the todo list already. However, the next step is #268838: Port to 6.x for now.

Also, I want to see a clean patch that does not break support for TinyMCE 2.x.

The Drupal core version compatibility really doesn't matter for this issue at all, because the editor initialization code is handled in JavaScript in Wysiwyg Editor module. Also, code-wise, 6.x does not differ that much from 5.x.

Although you're probably right that a new major version of an editor should be treated as a different editor, there's not yet code to support this in Wysiwyg Editor. So this would be definitely the best solution, but requires a well thought-out concept and implementation.

Subscribing, I really would like to see Wysiwyg support TinyMCE 3.x for Drupal 5.7,
This will be a absolute motivation to change current TinyMCE module into Wysiwyg module on my sites and I think that it will be same for lot of other admins.

Thanks for your work
Igorik
http://www.somvprahe.sk

Subscribing as well. I'm thorn between using the TinyMCE module and TinyMCE 3.x or change to this module and downgrade to TinyMCE 2.x. This module seems like the future but then again the downgrade of TinyMCE engine is something I'd like to avoid.

Using D5 of course (D6 still seems like far away until everything settles, but that's another story).

So, will TinyMCE 3.X work with Drupal 5.7? Should I download TinyMCE 2.x?

As the title of this issue implies, support for TinyMCE 3.x is not yet implemented.

Ok I was just asking. I wasn't sure...

Hi All,
ok, here's a first pass at getting wysiwyg editor to work with tinyMCE 3.x. The attached patch fixes the enable/disable toggle link. I've done it in such a way that it works with 2.x or 3.x.
Where the real problem lies though is with plugins as the API has changed completely when it comes to registering plugins. I think the only way around it is to have 2.x plugins and 3.x plugins and the module code will have to make sure that only the correct ones get loaded in the wysiwyg_editor_load_plugins() function.
I've had a go at converting the break plugin to be 3.x-compatible - so far I've managed to get rid of all the calls to undefined functions :-P but that's about it - the plugin isn't working yet :-/ and I have not included it in this patch. I'll keep working on it.
Oh and I only tested this in Drupal 5.
I look forward to feedback and suggestions as to how to proceed.

regards,
Katherine

Yay! Thanks, but, ugh... diff -up ? 8)

Is it possible that this patch touches the same or similar lines like #282717: Add FCKeditor support? If it is, then we definitely need to treat different editor versions like different editors, and committing this "proprietary" fix/feature would probably make that abstraction harder.

sorry, still getting the hang of this stuff :-P attached a new patch in the preferred format :-)
I think the general changes between tinyMCE 2.x and tinyMCE 3.x are small enough not to need to treat them like separate editors (the differences between these two are nothing compared to the differences between tinyMCE and FCKeditor) - but as I said the plugins pose a real problem here because they are implemented completely differently.

I'm still considering the all-in-one-for-each-editor stub plugin as outlined in wysiwyg.module that would implement the editor's API functions, but load/invoke an external Drupal script for each plugin (function).

This sounds great but of course it would be problematic if the editor in question had two different sets of API functions for plugins depending on which version. Ugly switch statements? I think this is easier to justify than having a whole separate "case:" in wysiwyg_editor.js for tinyMCE 3.x which has far more similarities than differences vis-a-vis tinyMCE 2.x.
Those are my initial thoughts anway.

/me tinkers about this, too...

Counter-argument: If completely different editor plugins are required for two editor versions, I think it would be inconsistent if only the plugins but not the editor configuration/initialization would be separated by version.

This patch introduces an if statement (instead of a switch statement ;) to determine the proper editor initialization for TinyMCE 2.x/3.x. Now, let's consider we want to add support for FCKeditor 2.4.x and 2.6.x - that would result in a) another if/switch conditional during the main invocation (to decide between TinyMCE and FCKeditor) and b) two more if/switch conditionals just like those for TinyMCE 2.x/3.x in this patch. For each new/other editor, the conditional statements would get larger.

Since we ultimately need to assign an editor to each profile, we already know which editor(s) and version(s) we need to load/configure/initialize. I guess, the best approach would be to separate all editor-specific functions into editor-specific JavaScript files ("includes"), so in wysiwyg_editor.js we can do (*simplified*):

wysiwygEditorAttach = function () {
  var profile = Drupal.settings.wysiwygEditorProfile;
  var function = Drupal.settings.wysiwygEditorProfile['editor'] + 'Attach';
  if (typeof function == 'function') {
    function(profile);
  }
}

...or similar and load for example tinymce-2.x.js as separate JavaScript file in front of above code example is invoked. What do you think?

Yes! I really like this idea :-) It is a much cleaner and more elegant approach. It will require lots of restructuring of the code so let me know how I can help.
Oh and yes, I agree it is logically more consistent to have plugin code versions inherited from the editor version ;-) I guess I was just thinking of a quick fix for tinyMCE 3.x...

Subscribing to this patch, if I can help for testing..

I applied the patch #11 on 6.x-0.3 and now I have tinymce3.

billion thanks katbailey.
-----------
chic

Subscribed.

TinyMCE 3.x is now supported.

However, please bear in mind that TinyMCE's plugin system is completely different in 3.x, which means that there is probably not one compatible Drupal plugin for it yet.

Re-opening to remind me to apply the patch in http://drupal.org/node/245799#comment-1052363 after the awesome input format attach patch has landed.

Committed.