Changes to a block's text field not saved when ckeditor source mode is active

I'm seeing this also regardless if you using the source mode or not. Any filtered text field in a layout builder block with CKEditor doesn't seem to be updating even though I change the contents.

Confirmed that I'm seeing this when editing and then switching to source mode and then saving (w/out switching back to wysiwyg mode).

If I switch back to non-source, WYSIWYG mode before saving, I don't loose the changes.

I'm experiencing this also, switching back to WYSIWYG after finishing my edits in source mode as matt_paz mentioned is the only workaround I've found at the moment.

Is this also reproducible in the standard Block UI, or only within LB?

In testing, as others have indicated, this issue seems to only affect Layout Builder blocks.

I was able to reproduce this issue inside a modal when saving a block content and sourcedialog is open no changes made to textarea sourcedialog go through if we save directly . Are there any suggested workarounds or even possibly a related fix as yet ?

If it helps anyone this is my workaround for this which is more intuitive to end-user as we do not have to click on Source first and then save.:

var origBeforeSubmit = Drupal.Ajax.prototype.beforeSubmit;

  Drupal.Ajax.prototype.beforeSubmit = function (formValues, element, options) {
    if (typeof(CKEDITOR) !== 'undefined' && CKEDITOR.instances) {
      const instances = Object.values(CKEDITOR.instances);
      instances.forEach(editor => {
        formValues.forEach(formField => {
          // Get field name from the id in the editor so that it covers all
          // fields using ckeditor.
          let fieldName = document.querySelector(`#${editor.name}`).getAttribute('name');
          if (formField.name === fieldName && editor.mode === 'source') {
            formField.value = editor.getData();
          }
        });
      });
    }
    origBeforeSubmit.call(formValues, element, options);
  };

Workaround in #16 almost solved the issue. When opening a block in layout builder a second time I got the following error:

An error occurred while attempting to process /layout_builder/update/block/overrides/...... Cannot read property 'getAttribute' of null

Fixed by a minor change that checks if the element exists first.

  var origBeforeSubmit = Drupal.Ajax.prototype.beforeSubmit;
  Drupal.Ajax.prototype.beforeSubmit = function (formValues, element, options) {
    if (typeof(CKEDITOR) !== 'undefined' && CKEDITOR.instances) {
      const instances = Object.values(CKEDITOR.instances);
      instances.forEach(editor => {
        formValues.forEach(formField => {
          // Get field name from the id in the editor so that it covers all
          // fields using ckeditor.
          let element = document.querySelector(`#${editor.name}`)
          if (element) {
            let fieldName = element.getAttribute('name');
            if (formField.name === fieldName && editor.mode === 'source') {
              formField.value = editor.getData();
            }
          }
        });
      });
    }
    origBeforeSubmit.call(formValues, element, options);
  };

Tested this with #17 in the website's global javascript file. And this works like a charm!

I don't know where the script belongs. I expect somewhere in the CkEditor module javascript.
In core/modules/ckeditor/js/ckeditor.es6.js there are comments like 'dialogs that are saved, sending data back to CKEditor'. But the ckeditor.es6.js // ckeditor.js is not loaded when editing a layout-builder block.
On a different project that uses paragraphs+ckeditor and not layout-builder I do see that ckeditor.js is loaded. That could be something to look further into 🤷‍♂️

#17 works perfect to resolve the issue. Thanks

Is this fixed for everyone? It is not because a fix exists that the issue is fixed. It's when the fix has been committed

#17 works! Just not clear where to put it. If put to theme's js, it only works on frontpage theme, and not on admin pages.

I currently have #17 in a custom module JS behavior, as well as #3108085 for entity_embed, and #3102249 for core's Media library embed.

These 2 patches and JS behavior (for this current issue) all solve similar bugs related to retaining changes made in Ckeditor, either within an inline entity form, or layout builder. The behavior does not happen for an exposed textarea field that is not in a nested form, for example, a node's body field on the standard node edit form, or a paragraph textarea field. We are not currently using layout_builder, yet!, but intend to add it to the project soon.

I guess we are covered by having #17 in a custom module, but I just wanted to mention this ongoing side effect of CKeditor not retaining changes is present across core and contrib projects.

After using this fix for a while we ran into an issue where Ajax uploads through webforms would not work. The call to the original submit handler will not have this set correctly. This can be fixed to replacing that with return origBeforeSubmit.apply(this, arguments);

Together with #17 that looks like this now:

  var origBeforeSubmit = Drupal.Ajax.prototype.beforeSubmit;
  Drupal.Ajax.prototype.beforeSubmit = function (formValues, element, options) {
    if (typeof(CKEDITOR) !== 'undefined' && CKEDITOR.instances) {
      const instances = Object.values(CKEDITOR.instances);
      instances.forEach(editor => {
        formValues.forEach(formField => {
          // Get field name from the id in the editor so that it covers all
          // fields using ckeditor.
          let element = document.querySelector(`#${editor.name}`)
          if (element) {
            let fieldName = element.getAttribute('name');
            if (formField.name === fieldName && editor.mode === 'source') {
              formField.value = editor.getData();
            }
          }
        });
      });
    }
    return origBeforeSubmit.apply(this, arguments);
  };

I'm having the issue that the html tags appear in text regardless of source mode.
I made a related ticket for it: drupal.org/project/drupal/issues/3211961

The solution from #17 (and extended one from #26) just keep giving me javascript errors about formValues being undefined or the method 'option' not being available prior to initialization of the dialog at the moment, so this needs some more work I think.

To be more exact, when editing the inline block with 'preview content' turned on, in wysiwyg mode, you get a JS error if applying the suggested solution. (and I need the fix in wysiwyg mode)

Uncaught Error: cannot call methods on dialog prior to initialization; attempted to call method 'option'
    at Function.error (jquery.min.js?v=3.5.1:2)
    at HTMLDivElement.<anonymous> (widget-min.js?v=1.12.1:9)
    at Function.each (jquery.min.js?v=3.5.1:2)
    at S.fn.init.each (jquery.min.js?v=3.5.1:2)
    at S.fn.init.t.fn.<computed> [as dialog] (widget-min.js?v=1.12.1:9)
    at resetSize (dialog.position.js?v=9.1.7:57)
    at later (debounce.js?v=9.1.7:22)

The patch in #26 is a good work-around, but we need to get this into core. Where should this go in core?

Maybe here? Might not be the best place but it's a start. Also this will need test coverage written.

Moving this to CKEditor's queue for now, since from what I can see, the fix has nothing to do with Layout Builder (even if the steps to reproduce do include it).

This solutions #26 work for me but as #29 give me javascript errors about formValues so i get formValues object values as array and add one condition in case formValues be 'undefined'. I am testing but works for me. Thanks for your help.

var origBeforeSubmit = Drupal.Ajax.prototype.beforeSubmit;
      Drupal.Ajax.prototype.beforeSubmit = function (formValues, element, options) {
        if (typeof(CKEDITOR) !== 'undefined' && CKEDITOR.instances) {
          const instances = Object.values(CKEDITOR.instances);
          if (typeof(formValues) != "undefined") {
            instances.forEach(editor => {
              Object.values(formValues).forEach(formField => {
                // Get field name from the id in the editor so that it covers all
                // fields using ckeditor.
                let element = document.querySelector(`#${editor.name}`)
                if (element) {
                  let fieldName = element.getAttribute('name');
                  if (formField.name === fieldName && editor.mode === 'source') {
                    formField.value = editor.getData();
                  }
                }
              });
            });
          }
        }
        origBeforeSubmit.call(formValues, element, options);
      };

Per #33, adjusting the original issue summary to include remaining tasks.

Version 9.2 modifies the bug that cannot be saved in ckeditor source state

This is failing automated tests with this:

/var/www/html/core/modules/ckeditor/js/ckeditor.es6.js
404:41 error Use the rest parameters instead of 'arguments' prefer-rest-params

CKEditor has been removed from core, CKEditor 4 is removed from Drupal Core in 10.0.0

I hope the plan will be still to backport bug fixes to D9 however.

I've rerolled the patch from #38 to work with ckeditor the module, since previously it was for ckeditor within core. Merge request is at https://git.drupalcode.org/project/ckeditor/-/merge_requests/10 and The patch is available at https://git.drupalcode.org/project/ckeditor/-/merge_requests/10.diff for composer users.

When editing a block containing ckeditor in Layout Build, if you just click "Edit Media" to edit and then click the Save button, the edit will not take effect, and the edited data will be lost.

Hi
I tested the patch at the comment #45, however it's a .diff extension and we work with .patch. That's why I'm uploading the same file in .patch extension :

RE #46 and #47, please do not continue to post patch updates when we have open MRs and forks that effectively do the same thing. We're splitting up the development across two mediums, and that is unhelpful to getting this issue resolved.

Based on #43-#45, please use the correct fork and MR to update and collaboration on code.

So sorry, this problem still bugs me after I upgraded to 9.5.
Is there something wrong with my operation?
Allow me to update the documentation for #46 before doing so.

These patches no longer applies