Update Drupal.wysiwyg.activeId with FCKeditor

Man, I should work less on core, more on my modules. How could I miss this fine issue?

I'll point TwoD to this issue (you can most often also ping him in IRC), since he spent *a lot* of time with implementing FCKeditor support.

Hmmm, I should have looked closer at the TinyMCE implementation, completely missed that variable. Good catch quicksketch!

I agree with quicksketch, FCKeditor_OnComplete() should not be needed by anything else when using Wysiwyg API. Even Wysiwyg plugins should not need it as they aren't supposed to know which editor is active, so if they rely on that callback they're doing it wrong.

However, we don't actually need to use that callback to get the event handler in there.
Event handlers can be attached in a custom configuration file (fckeditor.config.js in our case). The code in that file gets executed while the editor instance is loading, before FCKeditor_OnComplete() is called, so the handler is guaranteed to be ready even before plugins are loaded.

To keep that config file as clean and generic as possible for different versions of FCKeditor, we call Drupal.wysiwyg.editor.instance.fckeditor.init() from that config file and pass it the "editor area instance" (the FCKeditor iframe's window object) as instance.
instance.FCK.Events will then be the equivalent of editorInstance.Events in the OnComplete callback.

Yes the value changes for me, but it does not appear to be working if you just type Drupal.wysiwyg.activeId into the Firebug watch list. But if you run alert(Drupal.wysiwyg.activeId) in the console (or type javascript:alert(Drupal.wysiwyg.activeId) in the address bar) you should see the correct id. And of course you should also see it change if you put a breakpoint around there.

Now that I think about it a bit more, there is actually one case in which init() isn't called, and that's if you use the default settings for FCKeditor. The init() method must be called from the custom config file like I said before, but the custom config file is not loaded unless needed (which it usually is since people tend to want to change at least one setting/plugin/button). Not calling init works just fine in current HEAD as "all" it does is attach the Data Processor used by the Wysiwyg plugins. If there are no Wysiwyg plugins, the Data Processor is not needed.

Damn situation. Looks like we need to invoke our custom initialization for the default configuration, too.

I would love to use the imagefield / imagecache along with Fckeditor, but I am unsure of how to apply this patch.

I have downloaded and installed the Filefield insert module. but again, I am not sure how to apply this patch.. could someone please help me out here...

ian

@itower This patch is made against the Wysiwyg API module and should thus be applied at the wysiwyg folder. See http://drupal.org/patch/apply for more detailed info.

I am not sure if this affects anything related to how FCKeditor works together with imagefield / imagecache, but if your problem involves Wysiwyg API being unaware of which field is actually active it might help.

(Btw, see the note about default settings in #4 if this appears to still not work.)

TwoD,

thanks for the help..... I had not caught that.... I have installed the WYSIWYG API and the tinymce via WYSIWYG, and everything is mostly working.... but I still have 2 issues...

1. I am using imagecache, and the imagefield image is supposed to link to the full size image and be displayed with thickbox. This works find when the image is below the body, and not part of it, but when it in the body the link gets stripped out for some reason... Any ideas?

2. How do I get the text in the body to "wrap" around the image once it is inserted into the body....(with fckeditor standalone, all you had to do was go to the image settings and "image align" right or left and the text would wrap).

Thanks for the work on this....

This module will be a godsend if I can get it to work the way I want it to..

Do we want to commit this patch as is and tackle the instance initialization of FCKeditor without custom configuration in a separate issue?

If I'm not mistaken, that would allow quicksketch to (basically) remove the notice from filefield_insert's project page, because most people will (hopefully) configure the editor before trying anything.

Committed TwoD's patch from #479514-2: FCKeditor: Add internal, native plugins, which somehow ended up in issue nirvana ;)

Summary: We always intialize FCKeditor now, even if we want to apply the default settings.

This means that quicksketch can remove the notice from filefield_insert's project page when the next alpha of Wysiwyg API is out.