The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.When using ckeditor on a form textarea, if that textarea fails validation, the wysiwyg editor is not highlighted like other form fields. Also, if submitting the form in an AJAX callback, old CKEditor instances are attempt to replace the textarea. I have attached a patch to fix both issues.
| Comment | File | Size | Author |
|---|---|---|---|
| ckeditor-3.0.js_.patch | 660 bytes | DaddyMacCadillac |
Comments
Comment #1
twodPlease only fix one issue per patch if they aren't directly related.
The AJAX issue should not be fixed that way. Any CKEditor instances lingering after an AJAX operation are likely to be invalid and may in the worst case cause data loss by not correctly syncing changes back to the original textarea (references lost) when submitting the form. Instances should be cleaned up by calling
Drupal.detachBehaviors(replacedElements, settings, 'serialize')before the AJAX response commands overwrite the elements belonging to old instances. Wysiwyg will then correctly remove any references to instances within the affected elements and re-create them onceDrupal.attachBehaviors()gets called on the new elements created by the AJAX response commands. (This is normally done automatically for you when the FAPI property #ajax is used and#ajax['wrapper']is the id of a div or other element within the form (not the form element itself since Drupal Core keeps references to that which can't be replaced).Fetching the border from the original textarea and assigning it to the editor is a nice idea, but the code needs a few tweaks.
We could store the reference from
$('#' + params.field)in a variable to avoid multiple lookups, and make sure Drupal coding style guidelines are followed with whitespaces etc (no tabs).We should also implement this for the other editors.
Comment #2
steinmb commentedI assume this still is the case in HEAD.