D11.2: Uncaught CKEditorError: Cannot read properties of undefined (reading 'viewUid')

Also started seeing this after update last night on D10.5.0 :-/

Clicking the link button on the editor toolbar triggers the console error for new and existing links.

A

This is due to an API-breaking change in CKEditor 45. The report and fix for the Linkit module may provide a good roadmap for the fix here: 🐛 Future compatibility fix for v45 of CKEditor5 Active

Just to add that we are seeing exactly the same symptom with identical Drupal version update 10.47 > 10.50 - Editor Advanced Link dialogue layout is broken and the same JS errors in the Console.

This is a critical bug :)

Tagging this issue appropriately as it happens on both 10.5 and 11.2

With D10.5, after updating "Linkit " from 7.04 to 7.05, the dialogue layout in CKEditor doesn't work, it is impossible to find everything.
Disabling "Editor Advanced link" (version 2.2.6), the dialogue layout comes back working...

On my build at least, for any version of Drupal core >=10.2.0, the CKEditor link button is completely non-functional, even with Linkit and Editor Advanced Link disabled, database updates run, and caches cleared.

Additionally, there are no console errors triggered by clicking the button.

Reverting back to core 10.1.x fixes the issue.

Not sure how to fix this one... :-/

A

What other ckeditor modules do you have installed?

I am only using Editor Advanced Link and run into this issue on 11.2.0.

    const buttons = [
      linkFormView.children.find((child) => child.template.attributes.class.indexOf('ck-button-save') > -1),
      linkFormView.children.find((child) => child.template.attributes.class.indexOf('ck-button-cancel') > -1),
    ];
    buttons.forEach((item, i) => {

The buttons here are now an array of undefined so potentially ck-button-save and ck-button-cancel no longer are found at that point in time.

I don't know if adding buttons.filter(e => undefined !== e).forEach would simply mask the issue.

@nicxvan - me? No other CKEditor modules.

Seems it _might_ be related to modals - specifically Entity Reference with Layout (Paragraphs) modals.

The buttons are not direct children of linkFormView, but seem to be one level deeper.

.ck-form__row_with-submit button.ck-button-action which is used for Update and Insert button labels.

ck-button-save and ck-button-cancel classes were removed in CKEditor 45 as part of 17230: Improved linking experience.

So adding another item to that array maybe?

    const buttons = [
      linkFormView.children.find((child) => child.template.attributes.class.indexOf('ck-button-save') > -1),
      linkFormView.children.find((child) => child.template.attributes.class.indexOf('ck-button-cancel') > -1),
      linkFormView.children.find((child) => child.template.attributes.class.indexOf('ck-form__row-with-submit') > -1)
         ?.find((child) => child.template.attributes.class.indexOf('ck-button-action') > -1),
    ].filter(item => undefined !== item);

That's looking kind of ugly, so maybe cleaning it up so it's not in the array instantiation?

But then _manualDecoratorSwitches is undefined later on. Whatever that means.

From notes in 🐛 Future compatibility fix for v45 of CKEditor5 Active :

The CKEditor v45 release creates a breaking change for the linkit decorator and additional attribute logic. When the link form is submitted, it now passes an additional displayedText argument with the submit arguments. Linkit has logic based on the length of the arguments object. Specifically, Linkit attempts to access or modify the decorators object, assuming it's the last item, which is now the displayedText argument, not the decorators object.

See the CKEditor5 LinkCommand docs for more details: https://ckeditor.com/docs/ckeditor5/latest/api/module_link_linkcommand-L...

The pertinent change in Linkit, which may be a model for the needed change in Editor Advanced Link, is here: https://git.drupalcode.org/project/linkit/-/merge_requests/96/diffs?comm...

As far as I can tell, I don't think the linkit change would apply here.

I think the entire formView changes need to be redone to comply with link properties/decorators.

Okay, I understand the change in linkit @mark_fullmer mentioned a bit more now, which is necessary for saving the form values. The button and target changes would also need to be made to get things functional.

There's a start that gets things mostly functional again.

For me it's

Uncaught CKEditorError: s is undefined

, but I think same root cause.

I think this is the same issue:
I have updated to core 10.5, which includes the CKE5 update to v45. And I've updated Linkit to 7.0.5. I get an error when adding or editing a link. In console, I see:
ckeditor5-dll.js?v=45.2.0:5 Uncaught CKEditorError: Cannot read properties of undefined (reading '_items')
I am able to add a link. And when I edit an existing link I can enter a link and save it. But when I edit an existing link it does not initially show the link that was there. I can only enter a new link.
Also, I have Linkit configured to add media links. But that is not working at all. The url field only accepts hard links.
Here's more of the js stack trace in console:

    at h._moveTargetDecoratorToAdvancedGroup (editorAdvancedLink.js?v=10.5.0:1:11611)
    at C.<anonymous> (editorAdvancedLink.js?v=10.5.0:1:10104)
    at C.fire (ckeditor5-dll.js?v=45.2.0:5:639290)
    at C.set [as visibleView] (ckeditor5-dll.js?v=45.2.0:5:641653)
    at C._showView (ckeditor5-dll.js?v=45.2.0:5:607964)
    at C.add (ckeditor5-dll.js?v=45.2.0:5:604887)

Hi, the attached patch fix this error

Thank you, @netsliver. Can you review the existing merge request and/or create a merge request with the source javascript changes in addition to the built javascript? It is hard to review the changes in the obfuscated built javascript.

The main changes in #21 based on an expanded diff (attached) are the following. If the _getGroup and _createExtraFormFields changes are necessary, then I think those can be applied to the merge request in source and built versions.

I think the other changes are basically equivalent to the changes in the merge request and probably has the same issues in the merge request that need to be addressed. The submit changes to check the keys may be a good thing to add as well.

•              _handleExtraFormFieldSubmit(e) {
                   const {
                       editor: t
  -                } = this, i = t.plugins.get("LinkUI").formView, r = t.commands.get("link");
  -                this.listenTo(i, "submit", (() => {
  -                    const t = e.reduce(((e, t) => (e[t] = i[t].fieldView.element.value, e)), {});
  -                    r.once("execute", ((e, i) => {
  -                        if (i.length < 3) i.push(t);
  -                        else {
  -                            if (3 !== i.length) throw Error("The link command has more than 3 arguments.");
  -                            Object.assign(i[2], t)
  -                        }
  +                } = this, r = t.plugins.get("LinkUI").formView, i = t.commands.get("link");
  +                this.listenTo(r, "submit", (() => {
  +                    const allKeys = Object.keys(s);
  +                    const t = allKeys.reduce((acc, key) => {
  +                        if (r[key] ? .fieldView ? .element ? .value != null) {
  +                            acc[key] = String(r[key].fieldView.element.value)
  +                        }
  +                        return acc
  +                    }, {});
  +                    i.once("execute", ((e, r) => {
  +                        r[1] = Object.assign({}, t, r[1] || {})
                       }), {
                           priority: "highest"
                       })
  

  _handleExtraFormFieldSubmit: only handles the new ckeditor args (not compatible with older release, so would require a version bump). It also changes the mapping of keys.

• @@ -247,22 +489,24 @@
                   const {
                       editor: e
                   } = this, t = e.plugins.get("LinkUI").formView;
  -                t.targetMoved || (t._manualDecoratorSwitches._items.forEach((e => {
  -                    e.label === Drupal.t("Open in new window") && this._getGroup("advanced").children.add(e)
  +                t.targetMoved || ((t._manualDecoratorSwitches && t._manualDecoratorSwitches._items || []).forEach((e => {
  +                    if (e.label === Drupal.t("Open in new window")) this._getGroup("advanced").children.add(e)
                   })), t.targetMoved = !0) 
               }   
  
  

  The _manualDecoratorSwitches error is resloved by checking if that exists. This is in the merge request.

•              _addGroupsToFormView() {
  @@ -228,18 +465,23 @@
                   Object.values(this.groups).reverse().forEach((e => {
                       e.added || (t.children.add(e, 2), e.parent = t, t._focusables.add(e, 2), t.focusTracker.add(e.element), e.added = !0)
                   }));
  -                [t.children.find((e => e.template.attributes.class.indexOf("ck-button-save") > -1)), t.children.find((e => e.template.attributes.class.indexOf("ck-button-cancel") > -1))].forEach(((e, i) => {
  -                    t.children.remove(e), t._focusables.remove(e), t.focusTracker.remove(e.element), t.children.add(e, 3 + i), t._focusables.add(e, 3 + i), t.focusTracker.add(e.element)
  -                }))
  +                const saveButton = t.children.find(e => e.template && e.template.attributes && e.template.attributes.class.includes("ck-button-save")),
  +                    cancelButton = t.children.find(e => e.template && e.template.attributes && e.template.attributes.class.includes("ck-button-cancel"));
  +                [saveButton, cancelButton].forEach((btn, r) => {
  +                    if (!btn) return;
  +                    t.children.remove(btn), t._focusables.remove(btn), t.focusTracker.remove(btn.element), t.children.add(btn, 3 + r), t._focusables.add(btn, 3 + r), t.focusTracker.add(btn.element)
  +                })
               }
  
  

  Changes the button finding logic in _addGroupsToFormView

•              _getGroup(e) {
                   if (!this.groups[e]) {
                       const {
                           editor: t
                       } = this, {
  -                        locale: i
  -                    } = t, r = new a.CollapsibleView(i);
  -                    r.label = n[e].label, r.set("isCollapsed", !0), this.groups[e] = r
  +                        locale: r
  +                    } = t;
  +                    this.groups[e] = new m(r, {
  +                        label: n[e].label
  +                    })
                   }
                   return this.groups[e]
               } 
  

  Changes the _getGroup method logic. Is this necessary?

• @@ -210,14 +447,14 @@
               }
               _createExtraFormField(e, t) {
                   const {
  -                    editor: i
  +                    editor: r
                   } = this, {
  -                    locale: r
  -                } = i, o = i.plugins.get("LinkUI").formView, n = i.commands.get("link");
  -                if (void 0 === o[e]) {
  -                    const i = t.group ? this._getGroup(t.group) : o,
  -                        s = new a.LabeledFieldView(r, a.createLabeledInputText);
  -                    s.label = t.label, i.children.add(s, i === o ? 1 : 0), t.group || (o._focusables.add(s, 1), o.focusTracker.add(s.element)), o[e] = s, o[e].fieldView.bind("value").to(n, e), o[e].fieldView.element.value = n[e] || ""
  +                    locale: i
  +                } = r, s = r.plugins.get("LinkUI").formView, n = r.commands.get("link");
  +                if (void 0 === s[e]) {
  +                    const r = t.group ? this._getGroup(t.group) : s,
  +                        o = new a.LabeledFieldView(i, a.createLabeledInputText);
  +                    o.label = t.label, r.children.add(o, 1), t.group || (s._focusables.add(o, 1), s.focusTracker.add(o.element)), s[e] = o, s[e].fieldView.bind("value").to(n, e), s[e].fieldView.element.value = n[e] || ""
                   }
               }
  

  There's a change when adding children in _createExtraFormFields that removes a condition. Not sure why.

• At the beginning of the file there's some webpack changes. But this may be due to yarn / npm changes that make me think there is an extra build process involved in the patch in #21 not present in the built javascript on drupal.org.

Some screenshots of old vs new:

Old

New

Merge request

Patch in #21

In order to resolve the look and feel,

the extra form fields should be added as ckeditor form rows, or maybe adding a class selector ck-form__row_large-top-padding to each extra field. The title field being outside of advanced probably just needs to become a ckeditor form row.

Then the focus order needs to be fixed.

And probably some @deprecated comments added to styles that no longer apply.

I feel this question needs to be asked; is there a way to pin CKEditor to the old version, please?

It seems like this bug is causing a great deal of unnecessary headaches for production sites which had no warning of this breaking change, and there seems to be virtually no benefit to having this update forced upon us.

Would anyone happen to know if there's something we can set in our composer.json, or a way we can patch core, to require the old CKEditor version to stop this issue and guard against this happening again in future?

(-:

/A

I was not able to use FormRowView for backwards-compatibility. Instead I added a class selector to fix the styles.

Focus order still needs to be addressed. I have not been able to figure that out. Hopefully someone can update the merge request to fix focus order in a way that is backwards-compatible.

I feel this question needs to be asked; is there a way to pin CKEditor to the old version, please?

Would it be sufficient to pin Drupal core to 11.1.x or 10.4.x?

> Would it be sufficient to pin Drupal core to 11.1.x or 10.4.x?

If that would fix the issue, then absolutely, yes - I'll give this a go tomorrow.

Thank you for the steer, Mark (-:

/A

If you've deployed this to production I would strongly recommend not downgrading.

If you've not deployed to production then waiting is an option.

Focus order has its own issue 🐛 Fix keyboard accessibility of advanced attribute fields Active .

Two behavior changes:

1. When linkTitle is enabled, the CKEditor Display text field is rendered after the Advanced section. Otherwise the Display text field is rendered before the Advanced section. This is probably a side effect of fieldParent.children.add(extraFieldView, fieldParent === linkFormView ? 1 : 0). Maybe this can be fixed or addressed later if it is a problem?
2. The target decorator remains as a separate interface per CKEditor UX changes (now requires extra clicks to use).

There seems to be an error with the PR. When I try to apply it and run a composer update, it tells me it can't apply the patch. Anyone know why?

The merge request applies to 2.2.x branch (2025.04.15), not to the 2.2.6 release (2024.08.09) which is several commits behind.

@nicxvan Thank you for the word of caution :-) It turns out this issue was compounded by Entity Reference Layout's modal CKEditors being broken in every version of Drupal >= 10.2; we jumped from 10.1 to 10.5, which muddied the waters somewhat.

In our case, thankfully, only one site had been moved from 10.1 and we were able to re-deploy 10.1 underneath the 10.5 database with only a serialisation error in Metatags on a handful of pages which was resolved by re-saving the node.

I will test the MR + D10.5 on some of our sites over the weekend; hopefully it fixes this mess :-( Many thanks @mradcliffe and everyone else who's working on a fix - this is not an area of code I've ever worked on so am unable to contribute, sadly.

/A

Facing the same issue with CI Automated Functional Testing and normal use.

Attached a static editor_advanced_link--2025-06-30--3531194--mr-35--for-02-02-06.patch file, to this point of MR35, but with re-role changes to work with 2.2.6
To be used with editor_advanced_link-2.2.6 and Composer Patches

#MR35 and #34 fixed the console error - thank you!

please push to stable release

Also, see the following patches for another modules with similar issue.

• 🐛 Uncaught CKEditorError: Cannot convert undefined or null to object Active
• 🐛 Drupal 10.5 support - replace usages of .once Active

Thanks all! 🧁
Committed!

Thanks everyone for all the quick work.

I have just upgraded and there are no more errors, but the 'Open in a new window' checkbox is not showing, even though it is setup to show for the text format.

In my format settings under Advanced links, I have both ID and target checked, but only ID is showing.
ID ()
Open in new window ()

Ive also tested adding other options, like 'CSS classes ()' which also appears fine.

Anyone else seeing this?

I still seem to be getting this error, even after updating the module. The weird thing is it works fine in my Pantheon dev/test sites, however, production is where it seems to break still. The autocomplete doesn't work and the console error, mentioned in this issue persists. I thought it may have been a cache thing, but I've cleared it all multiple times. Any suggestions to get it working in production?

@snowcoder - for some sites I have to un-aggregate CSS and JS and then turn it back on.
Don't forget, there are multiple modules affected. See #36 for other links plus I'm seeing reports of IMCE errors as of this morning.

Thanks, Vladimir, for the new smart switch of the mechanism to have a smoother update process.

I updated to the newest core (10.5.1) and Editor Advanced Link (2.3.0). However, although some aspects of the module overlay now work, the button to browse and link to files on the server is still missing. If I revert to Core 10.4.8 and version 2.2.7, the button comes back. See screenshots.

the fact IME button does not display is not an Editor advanced link problem.
In fact, the button is hidden behind the new insert button.
Here is the ticket I have opend on IMCE https://www.drupal.org/project/imce/issues/3532569 📌 imce link hidden by new insert ckeditor link Active

Thanks @marieascomedia and @rajab natshah.
@bsanders44: hopefully #45 answers your question.

I updated to the newest core (10.5.1) and Editor Advanced Link (2.3.0). However, when I replace link, it doesn't work. It keeps the last link.

Then the version of your linkit module would be interesting too, I guess ;-)

Whoever comes here next, please check comment #36 first and the following two links containing other broken CKEditor modules:

Why the module is not compatible with 11.1.X on version 2.3.0?

Confirming comment #51. If you are Core 11.1.x, you cannot install either 2.2.7 or 2.3.0.

@eduardo morales alberti : 2.3.x supports only CKEditor 45.2+ which is available on Drupal 11.2+. Read the comments above.

Good point @rajab natshah. I'll update the code.

What @kmonty pointed out is also correct. 2.2.7 is not installable on Drupal core. 11.1.x
Opened the regression here: 🐛 Regression: 2.2.7 is not installable on Drupal core. 11.1.x Active

My comment was incomplete; we were trying to update the module from 11.1.8, and we were stuck on 2.2.6.