Add FCKeditor (Wysiwyg) integration

No solution (sorry), but I have the same problem - the Image Assist button (camera icon) on the editor toolbar does nothing.

I have tried Image Assist with the FCKeditor module (instead of the WYSIWYG API). No problem there with the Image Assist button, but the downside is that, in the editing area, the images are replaced by placeholder gifs. See #425500: Image Assist shows placeholder instead of image when editing.

Yes, I've had to revert back to the FCKeditor module with Image Assist. This at least allows for the uploading & inlining of new images, but I also find that the FCKeditor disappears whenever a form dynamically adds fields, which adds it own set of problems.

The impression I've gotten of the various editor modules, WYSIWYG, Image Assist etc is that you need to clearly identify exactly which features are of most importance, then try and find a combination of modules & releases that actually provides as many of those features as possible. Which has made this whole process incredibly confusing and painful to implement, something I really wasn't expecting from a project coming up to its 7th major release.

Thanks for confirming the issue, though!

Did you try whether it works with the latest development snapshot of Wysiwyg 2.x?

Also, which browser did you test this in?

Yes, after posting I installed Wysiwyg 6.x-2.x-dev (May 25th release), but had the exact same result.

I've tested this on Firefox (OSX & XP), Safari, Chrome and IE7, with the same behaviour on all 4.

Tagging.

I have set up a new Drupal site from scratch to demonstrate the problem of the Image Assist button doing nothing. I used the latest development snapshots of Wysiwyg API, Image and Image Assist.

A possibly interesting thing that I have just spotted is that, when viewed with Google Chrome, Opera and Safari, the Image Assist button is greyed out (and does nothing). It is fully visible in IE6, IE8 and Firefox, but does nothing.

sun - I will email you and wuwei23 a username and password that gives you access to the site, including the admin pages. Please feel free to reconfigure anything that may help diagnose the problem.

I am confused, BTW, by the note about the "optional" module Inline API on http://drupal.org/node/358296. It says this module is "Required for Image Assist and various other modules that allow to embed rich contents in a content.", but I have not installed it and nothing has complained. I have previously tried installing it on another site in an attempt to solve the present problem, but it made no difference.

timjh, I've been working a lot with FCKeditor and Image Assist lately, would you mind me taking a look as well?

TwoD - I have emailed you the necessary details

The FCKeditor implementation does not yet support dialogs created by Drupal plugins, that's why nothing happens when clicking the image assist button in the toolbar.
I should have noticed this earlier but I guess I was thinking about TinyMCE.

Using the Image Assist button for textareas won't work when a WYSIWYG editor is enabled for some reason (an unknown error when accessing the selected range), because FCKeditor hides it I guess.
In any case, if Image Assist could insert the content into the textarea it would still not work as expected. Changes in the textarea are not automatically transferred to the editing area iframe and would be overwritten once FCKeditor updates it.

I think the solution to this problem depends on how soon we can rewrite the plugin API in Wysiwyg API to be more wrapper API-like, if that makes sense.
In short, we need something like what I mention in this issue: #409938: Support for insertion of text and HTML from external sources. All editors do not yet have an insert method, but once they do, Image Assist could simply call Drupal.wysiwyg.insert(filtertag, textarea) or fall back to the textarea specific code if Wysiwyg API is not present.

TwoD seems to be saying that, at present, Image Assist just will not work with FCKeditor under Wysiwyg API. So can somebody explain why the Image Assist project page says "Currently, it can be used with TinyMCE and FCKeditor via Wysiwyg API"?

Yes, if FCKeditor isn't working with Wysiwyg & Image Assist, it shouldn't be stated as working on the project page, nor should this configuration be touted as a solution for a number of issues.

I just noticed that there were new releases of Image Assist (6.x-3.x-dev) and Wysiwyg API (6.x-2.0) yesterday and today, so I installed them on my test site.

The problem remains.

Yes. the problem will most likely remain until Wysiwyg API includes CTools as a dependancy, as we'll use its Modal features as a generic dialog for all Drupal plugins.
Image Assist contains some TinyMCE specific code which will removed with that transition.

oh. Now that you mention it - I think I originally did not only want to depend on CTools, but also on Popups API. Not sure whether that makes sense, but as the name implies, the module focuses on implementing AJAX-compatible popups/dialogs/overlays in Drupal. I guess we'll find out when implementing CTools... ;)

Project page has been corrected. Let's fix this.

fckeditor module - interesting:

We pass an object.

A hack.

Now, TwoD will yell: "Hey, we discussed we won't implement native popups!?!"

Yes. Maybe not. :P

If we can accomplish that the 2 major editors support Drupal plugins, we get the usual 80% pareto principle. All the rest, we leave for 3.x (we badly need to discuss -- when do you have time for brainstorming in IRC?). :)

Hey, we disscussed... nah, I'm not gonna yell. Figured we probably need to do something about this earlier than we bring in dependencies since people seem to need it very much.

Only problem I see with the #17 patch is that we can't easily get the correct data from the selection, and we assume that Drupal plugins always want to open a dialog when invoked.

Anyway, I've got some stuff to do today but I'll be on IRC later this evening so we can begin discussions then.

Hmm... not for all Drupal plugins:

This means we register the button to open a dialog only if the Drupal plugin defines dialog settings. Makes sense? :)

Ah yes, of course I did not mean the plugins which actually don't need a dialog. My emphasis was more on the fact that the plugin cannot opt out of opening the dialog when the button is pressed. (As of now, it simply does not call openDialog() from invoke().)

[02:43] tha_sun TwoD: You mean that there might be a plugin that provides a dialog, but doesn't want to invoke it when pressing the button?
[02:44] TwoD tha_sun, yes, say the selection is somehow invalid and the dialog makes no sense if noting is selected.
[02:44] tha_sun Sure, that would be possible

I'm sorry to say that the tech talk about plugins and dialogs goes right over my head, but I'm happy to test anything you guys come up with. Is the patch in #17 above by itself intended to fix the inoperative camera icon?

BTW, I can insert images on my test site with Image Assist by using the "Disable rich-text" button and the Image Assist Textarea image link (both of which appear below the FCKeditor editing area). This is a usable work-around for any users who are not going to be stunned by the sight of a naked image assist tag, but it's not exactly wysiwyg.

timjh, yes the patch in #17 should make the dialog appear when the camera icon is clicked (allthough it does not work as intended on already inserted images, it will simply open in "insert" and not "update" mode).

Not quite there yet.

I upgraded to the latest (13 June) version of Wysiwyg API 6.x-2.x-dev and applied the patch by hand to sites/all/modules/wysiwyg/editors/js/fckeditor-2.6.js (see attached listing, saved as txt).

Now the camera icon pops up a box with the heading "undefined" which just sits there displaying an animated pattern, as in the attached image. It does the same thing in both insert and update modes.

Ah, that's right, I should also have mentioned that to actually display the contents of the dialog, Image Assist will also require some modifications. The form is already there, just hidden behind the loading screen.
FCKeditor requires that the scripts in a native FCKeditor dialog makes a call to the editor api and ask for a reference to an editor instance, only then is the loading screen removed.
At the moment, Image Assist needs custom code to communicate with each editor, something we hope to change in the next major version.

Thank you for testing and I'm sorry my previous post was misleading.

No problem - I feared that there might be a bit more to it. I'll keep an eye open for further developments to test. I wish there was more I could do to help, but although I'm happy with HTML, CSS, PHP, - and many other programming languages that are now mostly buried and forgotten (anyone for PL/I?) - I still haven't got to grips with JavaScript. All that OO and AHAH stuff makes me think of Frankie Howerd rather than web technology.

I'm actually having a similar problem... I'm on a updated drupalv6, fckeditor module, fckeditor, and image assist. Everything works as expected except that on Safari on a Mac I can't upload an image. The strange thing is this problem is intermittent. Sometimes I get a blank upload page. Other times everything works fine.

@epiphanydigital, note that this issue is related to how Image Assist behaves together with Wysiwyg Module (through a "Drupal plugin" implemented in Image Assist), not the FCKeditor Module. FCKeditor (and most other editor implementations) do not yet support Drupal plugins using dialogs, so Image Assist won't work together with FCKeditor in any browser yet.

@TwoD: that's not exactly true, I've had to fall back to using FCKEditor 6.x-2.0-beta1 with Image Assist 6.x-2.x-dev, which is more or less working for me under FF, IE & Safari, barring the lack of displaying inlined images in the editor.

Now, I couldn't upgrade Drupal to 6.13 and continue for the above to be true, but that's a different issue :)

And I spoke to soon, the latest security update has effectively killed my FCKEditor + Image Assist setup dead.

So what's the answer here? Do I spend the next few days pulling out FCKEditor and installing TinyMCE + WysiwygAPI instead? Do I just hope and pray it'll work, and that it'll continue working after every update? Is there any guarantee that support for TinyMCE won't just magically disappear when it becomes too difficult to provide, which is what it feels like has happened with FCK?

The whole wysiwyg/image insertion process in Drupal has been SO GODDAMN PAINFUL that I can no longer in good faith recommend that the university I work for continue to start new project work using it. That something so fundamental to a CMS is in such a mess is just downright embarrassing.

I have the same issue with Image Assist 6.x-2.x (and 6.x-3.x) and both FCKeditor.module and Wysiwyg.module.

Luckily there is still one working fallback: using FCKEditor 6.x-2.0-beta1 with Image Assist 6.x-1.x. It works with the latest security update (Image Assist 6.x-1.1). You just have to copy the file img_assist_fckeditor.js from FCKeditor module folder to Image Assist module folder.

Anyway, from statistics, FCKEditor is the most widely used WYSIWYG editor among Drupal installations, so compatibility should not be overlooked.

As of now, Image Assist works only with TinyMCE (via Wysiwyg module). FCKeditor (via Wysiwyg module), is what this issue is about. Setting proper title and category.

FCKeditor module (the stand-alone module) provided a "hack" that was compatible with Image Assist 1.x at least... Not sure whether it still works with higher versions.

I can understand your frustration. But please keep in mind that it is us (basically TwoD + me), who want to change and improve the overall situation. All that fiasco with editors and modules like Image Assist was caused by modules like tinymce module or fckeditor module in the past, developed in parallel, and without any central entry point (API) for modules like Image Assist. Improving the overall situation and finding solutions that work takes much time and a lot of work and effort. We are slowly getting there, but in effect, we do all of this for free in our spare time. In the end, I can understand your frustration, but at the same time, rants like this are highly discouraging. I was even inclined to mark this issue simply won't fix, because we are no slaves of anyone and this is not the way things have a chance to be improved.

subscribing

Fixed as part of #538194: Support Image Assist 2.0 in the latest 6.x-2.x release of FCKeditor.module. I'll leave it to the wysiwyg.module authors to decide what to do with this issue.

@Jorrit: Thanks for letting us know! We'll point users to use FCKeditor 6.x-2.x-dev or 6.x-2.0-beta2+ (whichever is available) then.

This issue is about making Image Assist 3.x comptible with Wysiwyg module 2.x/3.x though. Either we manage to get the previously posted patch working with Wysiwyg 2.x, or we have to postpone this issue until Wysiwyg 3.x-dev is available, because it is very likely that we will replace the entire dialog/popup handling there (to also support dialogs for editors that do not support dialogs natively).

Subscribing.

Subscribing