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.
When disabling the rich text editor with the link provided right below it, after an ajax request gets made (by other stuff on the page), the editor gets enabled again.
The problem is that the JS method Drupal.ckeditorOff() removes the "ckeditor-processed" class from the textarea, and after each ajax call the Drupal behaviors get called again, initiating the ckeditor behavior again for already ckeditor enabled elements.
Suggested solution: remove this line from the JS method Drupal.ckeditorOff():
$("#" + textarea_id).removeClass("ckeditor-processed");
Comments
Comment #1
jcisio CreditAttribution: jcisio commentedYes, or use the context parameter in the behavior so that only textarea in that context is processed.
Comment #2
dczepierga CreditAttribution: dczepierga commentedChanges commited to CVS.
Please check the latest dev release and let me know if you notice any poblems with it. Remember to clear Drupal cache and browsers cache before testing.
Comment #4
domidc CreditAttribution: domidc commentedThis problem persists. We have detected that this function is only ran when other elements on the node form do ajax calls.
in ckeditor.utils.
detach:
function(context){
$(context).find("textarea.ckeditor-mod.ckeditor-processed").each(function () {
var ta_id=$(this).attr("id");
if (CKEDITOR.instances[ta_id])
$('#'+ta_id).val(CKEDITOR.instances[ta_id].getData());
Drupal.ckeditorOff(ta_id);
}).removeClass('ckeditor-processed');
}
We could not detect any wysiwyg related call go thru this function.We disabled this. We are not sure why this is still used? Perhaps a better solution is needed than just disabling this piece of code.
Comment #5
mkesicki CreditAttribution: mkesicki commented@domidc can you give example of ajax call that turn on CKEditor ?
Can you test this with latest DEV version ?
Comment #6
mkesicki CreditAttribution: mkesicki commented