Stale data-entity-* attributes are retained when an existing link's href is replaced with a manually typed internal path

Opened MR !183.

Manual edits to a Linkit-created internal URL now clear entity metadata, while autocomplete selections and unchanged links retain it. The regression test updates an entity link to a manually entered internal path and confirms the data attributes are removed.

Checked locally:
- corepack yarn build
- php -l tests/src/FunctionalJavascript/LinkitDialogCKEditor5Test.php
- composer validate --no-check-publish
- git diff --check

Environment

• Drupal: 11.4.4
• PHP: 8.5.5
• Database: MariaDB 10.11.16
• DDEV: v1.25.2
• Linkit: 7.x-dev (0a84c12)
• Browser: Chrome

Prerequisites

• Enable the Linkit filter and the Linkit CKEditor 5 plugin on the Full HTML text format, using the default Linkit profile with the entity:node matcher and canonical substitution.
• Create two target articles with distinct URL aliases, so the difference between the stored and the rendered link target is visible:
  • "Linkit target ALPHA" with alias /alpha-target
  • "Linkit target BETA" with alias /beta-target
• Create a third article with a Body field using the Full HTML format, containing a paragraph with some link text.

The rendered page source is misleading on its own, because LinkitFilter::process() rewrites href from the stored UUID at render time. Compare the stored value against the rendered output instead:

ddev drush php:eval '
$n = \Drupal::entityTypeManager()->getStorage("node")->loadUnchanged(<NID>);
print "STORED: " . $n->body->value . "\n";
$b = \Drupal::entityTypeManager()->getViewBuilder("node")->view($n, "default");
if (preg_match("#<a [^>]*>my link</a>#", (string) \Drupal::service("renderer")->renderInIsolation($b), $m)) print "RENDERED: $m[0]\n";
'

Steps

1. Apply the fix from MR !183: the CKEditor 5 plugin now tracks whether the URL was picked from an autocomplete suggestion, resets that state when the link form opens or when the URL field is typed into, and clears the Linkit attributes when the URL was entered manually.
2. Rebuild caches: ddev drush cr
3. Edit the third article. Select the link text, open the link balloon, type part of the ALPHA article's title and click the autocomplete suggestion. Save the node.
4. Confirm the stored markup carries data-entity-type, data-entity-uuid (the ALPHA article's UUID) and data-entity-substitution.
5. Edit the node again. Click the existing link, click Edit link in the balloon, clear the URL field and type an internal path by hand — for example /node/<BETA NID> — without clicking any autocomplete suggestion. Confirm the change and save the node.
6. Compare the stored and the rendered markup, and open the rendered page to check where the link actually points.
7. Edit the link once more, this time picking the BETA article from the autocomplete suggestions, and save.
8. Compare the stored and the rendered markup again.

Expected results

• After a manual URL edit, the data-entity-type, data-entity-uuid and data-entity-substitution attributes are removed, so the rendered href matches the URL the editor typed.
• After an autocomplete selection, the attributes are still written, with the newly selected entity's UUID, and the rendered link resolves to that entity's alias.

Actual results

As expected. Before the fix, the manual URL edit stored <a href="/node/20" data-entity-type="node" data-entity-uuid="<ALPHA UUID>" data-entity-substitution="canonical">, while the rendered output was <a href="/alpha-target" data-entity-uuid="<ALPHA UUID>" title="Linkit target ALPHA"> — the published page kept pointing at the previous target, and the rendered page source looked unchanged across the edit, which is exactly what makes the bug easy to miss.

After applying MR !183, the same manual edit stored and rendered <a href="/node/20">my link</a> with no leftover entity attributes. Re-selecting the BETA article from the autocomplete suggestions produced <a href="/beta-target" data-entity-type="node" data-entity-uuid="<BETA UUID>" data-entity-substitution="canonical" title="Linkit target BETA">, so metadata is still written for genuine autocomplete selections.

Note: the LinkitDialogCKEditor5Test changes in the merge request could not be executed in this environment, since its Selenium version is not compatible with the Mink driver used by Drupal's FunctionalJavascript tests. The verification above was done manually in the browser; the test coverage is left to the pipeline.

Testing produced with the assistance of an LLM.

Thanks for MR !183 — I hit the same underlying bug from a different angle and wanted to share a variant that also covers it.

We use the Bookmark feature from the module "ckeditor5_plugin_pack". It supports adding and linking to URI fragment in the same page like "#map". But we noticed that if a user create a link pointing to an entity first and then switch it to a URI fragment (bookmark), it simply append the URI fragment to the previous entity URI instead of clearing the entity URI.

I tried the MR !183 but realized that it detects a manual edit while CKEditor 5 Plugin Pack's Bookmark feature sets the field's value programmatically when a bookmark is selected, which never fires a native input event. So all the data attributes stay the same.

Rather than trying to enumerate every possible way the field's value can change (typing, this provider, some future provider), the attached patch compares the href actually being submitted against a baseline captured when the link form opens (this._initialHref = linkitInput.value, set alongside the existing _autocompleteSelection = undefined reset).

Patch attached against 7.0.16 (source only — js/build/linkit.js isn't included since I assume a maintainer would want to rebuild it as part of merging). Happy to also open this as its own MR if that's preferred over folding it into !183.

Noticed a bug in my previous patch. Here is a new version with interdiff.

@kevin w your approach seems more robust. Can you create a MR and include the test coverage from MR 183, so both use cases are tested automatically?

Don't worry about the build file. It might conflict at some point, but can be regenerated from source once the branch is complete.

@idebr Thanks for the suggestion! I've created another MR 184 with 183's test updates.

@aaronsilber-0 may I move forward to Needs Review?

Rebased MR !184 against latest 7.x.

✅ Tested and works — applied MR !184, rebuilt js/build/linkit.js locally and caches, then on a node whose Linkit link pointed at node A replaced the URL with a manually typed /node/5 (no autocomplete) and clicked Update: the saved markup is <a href="/node/5">the target</a> without the data-entity-* attributes, and the rendered page links to /node/5 instead of node A's alias. Manually typed URLs no longer keep the previous entity's metadata.