Body text gets lost when using fupload and wysiwyg API

As you can see, the issue queue is quite long at the moment.
Because FUpload is fully based on Drupal's Ajax functions to be able to retrieve the data from the fields, WYSIWYG is not fully compatible to that.
So, it's not only fupload's fault.
I don't have much time at the moment, please provide patches. I will concentrate on checking and submitting them.

Subscribe. Having the same issue. Will try to find source of problem.

Seeing this happen with current (DRUPAL-6--2) version of FCKEditor as well.

This is a relatively new phenoma

grandcat suggests that the issue lies with the visual editor (WYSIWYG/FCKeditor) rather than image_fupload. I created an issue under the fckeditor project:

http://drupal.org/node/653718

I say this is a recent phenomena with FCKeditor as my site was working fine up until a few weeks ago (not exactly certain of the time). I've no experience with WYSIWYG w/r/t this issue.

It's a conflict in the load procedure of FUpload and all other editors.
If someone has the time, a patch would be very helpful.

subscribing

I can't confirm the problem is gone when using CKeditor.

@deepM: Are you using CKeditor with the Wysiwyg module or are you using the seperate CKeditor module? This issue is about incompatibilities with the Wysiwyg module. So, if you are using Wysiwyg, could you tell us about all your settings for Wysiwyg and CKeditor? Maybe that will help to finally track down the problem.

Oh sorry, didnt use WYS... module, just CKeditor. I did have problem with FCK editor before, also without WYS...

I am unable to reproduce this issue with Wysiwyg and TinyMCE, CKEditor or FCKeditor.

1. I set image_fupload to attach multiple images to a single node (via imagefield). Setting it to create multiple nodes per image just hid the body field without saying why (a wtf on its own, IMHO), so no editor is available in that case.
2. typed some content into the body of a new node with an editor active
3. selected/queued a few images
4. uploaded them with the "Save" button.
5. clicked "Next stage" button
6. typed in image descriptions, saved
7. got redirected to the saved node which has all the content I addded

I need the exact steps to recreate the circumstances where the body content is dropped when clicking the "Next step" button on a new node.

The only case where I see dropped body content is if I edit an existing node, add some more images using image_fupload and then hit "Next stage". In that case the button simply changes redirects to the new page without ever posting the node form, so there's nothing Wysiwyg module can do about that without completely overriding that button's click handler.
(I'm actually considering filing a usability issue for image_fupload, as one would expect the 'Next stage' button to submit the form this time as well.)

Well i have messed arround with a bug today which could be related today. Upload.module with the AHAH file upload seems to background-submit the whole form. What happens then is, that the onbeforegetcontent handlers are fired of the WYSIWYG-editors, because well the form is submitted.

While the WYSIWYG module is more clever and binds its event to the submit button, those events are anyway fired. So most of the plugins handling wyswiyg module evens might work, but there is a possibility that editor intern modules still fire on the editor specific beforeContentGet events.

In my case the editors round-robbin feature gets weared and my body is not correctly formatted, because i have an old plugin listen on the editor events directly ( tinyMCE editor).

Not sure this helps here, just thought that this can actually be related.

Also i encountered some strange issues with memcache + ajax calls ( could be APC related ). So if you both use memcache or APC try it without, there are some strange things concerning those with the current D 6.x core.

Wouldnt bet on that.

Maybe the CKeditor does not register internal onbeforecontentget handlers or they are not critical enaugh. TinyMCE is a beast anyway, so i pretty expect something to break there. If you wont a advice, dont use tinyMCE. After ~4 years of usage iam burning to get a way. And i will do so after portining the old plugin to the WYSIWYG api.

Back to the topic, it could depend on the editor, as those handlers are editor specific and actually installed on the edit-textfield

Subscribing - would love to see the conflict here get solved! Current workaround for me is saving nodes with images first, then creating the text and saving again

I'm still unable to reproduce the problem using the procedure and module versions from #18 using FF 3.6.3.
Each time I upload images to the imagefield using Image FUpload and click "Save" then "Next step" and finally go to the rendered node, it's all intact.
IE (8) acts weird altogether and wants to download a file after all images have been uploaded, and it completely ignores the uploaded images after that, so I've not been able to complete the tests using that browser.

Fupload module's code (or at least the part dealing with imagefields) doesn't seem very Drupal friendly so I would actually expect all kinds of things to go wrong with a number of other modules as well.
First, it overrides window.onload without respecting any previously assigned handler. This does not affect Wysiwyg module directly, but may cause problems for other modules.

When "Save" is clicked after selecting a couple of images, the Flash part of SWFUpload seems to take the whole form and submit it in the background, to which the editors react (their onsubmit handlers get called, causing them to sync their contents back to the original textarea). Wysiwyg doesn't react as the form's real "Save" button wasn't the one clicked, but a replacement for it created by image_fupload. That first part is what saves whatever I type into the editor - before uploading any images - to the database.

When the "Next step" buttons/links are clicked, image_fupload blindly does a brutal window.location = url without ever submitting the form again. Any changes made to the body field (or almost anything else for that matter) after uploading images are always lost, regardless of an Wysiwyg's state. As the form is not submitted - or its original buttons clicked - Wysiwyg module has no part in what happens when the "Next step" is taken. Nor should it need to, considering it's a GET request which itself should not change anything on the server.
All the editors do at this point is to run their cleanup methods to prevent memory leaks (mostly in IE). There would be no point for them to sync their contents with the original field as no POST is being made. Normally, their onsubmit handlers would have fired before this, if it the user intended for changes to be saved.

To summarize: IMHO, the way image_fupload[_imagefield] works is flawed. It should follow Drupal's conventions regarding how "onload" code is run, via Drupal.behaviors to avoid the risk of interfering with, or being disrupted by, other scripts running on the document. (The amount of code added to the header is also quite large, I'm sure there would be a way to break it out into an external script during the transition to Drupal.behaviors.)
Image FUpload needs to be rewritten so that an actual POST is made once "Next Step" is clicked, by turning it into an actual submit handler that redirects to the step between uploading and seeing the created node. As soon as that is accomplished, any module relying on the form being properly submitted will have a much easier way to integrate with the module. It would also allow users to change any field after images have been uploaded.

You mean this new module?

http://drupal.org/project/swfupload

i will try it, been long time with fupload, never liked it, from its icon to workflow from all this other problems, hope this one works better!

Well i did try it but having problems with installation, grey button issue, will work on it but its seems its very beta that module.

swfupload looks nice but there's a bunch of pending patches to fix quite a few issues. Seems it's still a couple months away from being there

@31: image_fupload is tagged stable but can be seen as alpha.

Given TwoD's excellent summary, and the fact that swfupload module has been reported to work, this sounds like a bug in fupload module.

I implemented the SWFUpload module instead and am delighted to say that it works perfectly so far. Solves this issue for me. I'll be using SWFUpload from now on instead of Image FUpload. Thanks!!!