Hi,

I'm having a problem using CKEditor with boxes. I have it inserted in the box text-area but when I edit a box, save it and edit it another time the wysiwyg doesn't apear and blok the textarea. Searching it with firebug I found the follow error:
uncaught exception: [CKEDITOR.editor] The instance "edit-body" already exists.

May be the editor should destroy the instance when saved or maybe caught the exception?

thanks a lot in advance, and if someone helps me with the code of the module I can try to report a patch.

Comments

twod’s picture

twod
Primary language Swedish
Location Sweden
commented
Status: Active » Postponed (maintainer needs more info)

Boxes? Can you be a bit more specific? Do you mean blocks?
Wysiwyg destroys the editor instances when the form is submitted or "Disable rich-text" is clicked.

Have you tried the latest Wysiwyg 6.x-2.x-dev snapshot to see if this has already been fixed?

quiron’s picture

quiron
Primary language Catalan
Location Barcelona
commented

hey,

sorry, Boxes means the boxes module: http://drupal.org/project/boxes

I'm using the version of wysiwyg 6.x-2.1

twod’s picture

twod
Primary language Swedish
Location Sweden
commented
Status: Postponed (maintainer needs more info) » Closed (won't fix)

Ah, I see. The Boxes module uses AJAX to submit the form in the background.
Wysiwyg module is unable to detect and respond to this because there's no global event to listen for in the version of jQuery.forms used by D6. Wysiwyg would need such an event to know when to detach any active editors - which would properly sync content back to the original textarea and remove the editor instance.

The code snippet you added in ckeditor-3.0.js (from #716034-24: WYSIWYG issue with Boxes) tell CKEditor to sync content to the textarea, but Wysiwyg is never made aware that it needs to completely destroy the editor instance. Since the instance isn't destroyed, it can't be created anew when the form appears again - hence the error you're seeing.

Because this error happens after you've modified the module, we can't provide a fix for this specific issue, sorry.

A start would be to instead call Drupal.wysiwyg.instances[field_id].detach() from Boxes (if an instance for the field exists) when the submit button is clicked, just before the form is submitted.
That allows Wysiwyg to do its thing and properly detach the editor, getting things to work smoothly on re-edits could be a little trickier.

This problem is basically the same as the one encountered in #570466: Text in textarea dissappears when clicking cck's "Add another item" and #864136: "Add another item" button breaks all WYSIWYG editors on edit form (Those two are probably duplicates.)

To solve this best, we'd need a way to detach behaviors when content is removed/moved/changed on the page like we can in D7. All modules would have to trigger that event, like they trigger attaching behaviors when adding new content. CTools recently added support for something similar to that: #947676: Support new CTools event for detaching when the modal closes. I'm a bit surprised that wasn't mentioned in another issue in their queue though: #350035: Implement Drupal.detachBehaviors()

If all modules can agree on triggering that event when destroying elements on the page, Wysiwyg would be much more likely to work with all the AJAX/AHAH-using modules out there. How to deal with Core would still be a problem, but a bit easier to adapt to from Wysiwyg's perspective than having to write custom code for every contrib module out there.