Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I was running into a issue with a WYSIWYG inside a ctools modal (Panels IPE, specifically) where the field that the WYSIWYG was attached to was removed from the DOM before the wysiwyg detach behaviors had finished. This resulted in the following error message when the modal is closed:
uncaught exception: [CKEDITOR.editor.replace] The element with id or name "<field>" was not found.
I think the problem is that ctools is destroying the modal at the same time that the wysiwyg module is trying to destroy the editor instance, which results in a race condition.
This patch fixes the issue for the ckeditor plugin. I'm sure there is a plugin-agnostic way to do this as well, but when I tried to do something similar in Drupal.wysiwygDetach(), the issue still occurred.
| Comment | File | Size | Author |
|---|---|---|---|
| wysiwyg-ctools_modal_race_condition.patch | 592 bytes | theunraveler |
Comments
Comment #1
TwoDHmm, the problem is that the triggering field info in
[Drupal.]settings.wysiwyg.triggersstill exists after the field has been removed. We currently react to CTool'sCToolsDetachBehaviorsevent and detach editors when it is fired (which seems to happen after CTools has calledDrupal.detachBehaviors, so we don't really need that but it doesn't hurt). If we instead use that callback to remove any triggers found inside the context parameter, we should be fine when Drupal's AJAX code re-attaches behaviors.I'm not sure if we would be risking removing triggers for fields existing in both the modal and the main document, in case both contain similar forms. Duplicate ids are not valid, but I'm not sure the modal code is able to de-dupe them.
I've built a small manual test-case for this which I'll include with the patch when I have time to fix it.
Comment #1.0
TwoDChanging pre tags to code tags
Comment #2
TwoD#2284955: Can't close modal with latest version of WYSIWYG was reported long after this but in that case I found a different solution, which I'm fairly certain fixes this issue as well.
Turns out Drupal kept a reference to the remove form around, tricking Wysiwyg into thinking fields were still in the document. Instead of removing triggers from the settings object, we now do
document.getElementById(fieldId)to make sure the field exists in the actual document's DOM before even trying to attach an editor.If you're still experiencing this problem even with the latest 7.x-2.x-dev, please reopen this issue.