Closed (duplicate)
Project:
Wysiwyg
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
25 Jul 2010 at 14:23 UTC
Updated:
30 Jul 2011 at 02:40 UTC
When I click "Add another item" on a node edit form (where the field is a textarea), all WYSIWYG editors disappear and I see this exception:
Error: uncaught exception: [CKEDITOR.editor] The instance "edit-field-bulletins-0-value-field-body-0-value" already exists.
Comments
Comment #1
wmostrey commentedI can confirm this error, although I get similar behavior when working directly with the differente RTE modules: ckeditor, tinymce, tinytinymce. Getting a wysiwyg to work with multi-value fields seems to be a daunting task.
Comment #2
wmostrey commentedFor everyone interested, I wrote down my solution for wysiwygs and multi-value fields. Short version: it only works with Wysiwyg + FCKeditor along with WysiwygCCK. All others editors have specific issues.
Comment #3
lpalgarvio commentedthe editor just disappears along with the text and all it's left is a blank borderless, unselectable box.
using CKEditor 3.3.2.5805, WYSIWYG 2.1, WysiwygCCK 1.1 and Drupal 6.19
Comment #4
twodThis all comes from the fact that D6 has a standard way to attach behaviors when elements are added (
Drupal.behaviors.myAttachCallback = function (...) {...}, but no standard way to detach them when elemnts are removed.This has been improved on in D7, where one can now register two callbacks, and modules should also call
Drupal.detachBehaviors(context)before removing elements.Without the detach callback (and depending on the available jQuery version) Wysiwyg can not determine if a form is being submitted in the background and take the appropriate actions. This would include synchronizing the editor contents to the original twxtarea and actively destroying the editor instance, but only for the fields which will be replaced by AHAH.
Instead, what happens is that Wyssiwyg gets order to [re]attach its behaviors to an element, and does so to re-initialize the editor, but the editor still has internal representations of the editor instance and thinks it already exists.
The CTools module has implemented detachBehaviors for D6, and there's an issue about providing a callback for Wysiswyg somewhere, just can't find it now. We'd still have to rely on other modules calling the CTools detachBehaviors function before removing anything tho. I don't think an actual dependency on CTools would be required for any of the involved modules, just a check to see if the function exists before calling it.
EDIT: I made an assumption above that CTools had already implemented this but it looks like the issue regarding detachBehaviors was still at "needs work". #350035: Implement Drupal.detachBehaviors() We need this to be fixed before any changes made to Wysiwyg module will have any effect.
Comment #5
gooddesignusa commenteddarn just when i thought the wysiwyg module was working for this site i have to scrap it b/c of this issue. subscribing. Tried what wmostrey suggested but it didn't work with CKEditor.
update: I tried the standalone CKEditor but this also has the same issue. I'm now back to using the wysiwyg module but just using plain text for ccks for now.
Comment #6
wmostrey commentedIt does indeed only work with FCKeditor, and I'm afraid that is currently the only solution.
Comment #7
sunIt's possible that this might have been fixed through the patch in #679056: ENTER in autocomplete widget disables tinymce
If not, then as TwoD already mentioned, this cannot be reliably fixed prior to D7 - for which we'll still have to rewrite the central attaching and detaching logic in Wysiwyg API, which has to be tackled in a separate issue as it's going to require larger/substantial changes.
Comment #8
lpalgarvio commentedis this module still useful at all?
http://drupal.org/project/wysiwygcck
it was made to fix issues like the one described here.
EDIT: wysiwygcck will not get a D7 port and is semi-abandoned, not being updated. so don't use it