Reviewing the history of this issue, the approach proposed in #23 appears to have broad community support, and seems to me to be a 'good enough' solution for something that the community clearly feels is a "major" level bug. Therefore, let's proceed to add this approach, to be included in the upcoming 2.0.0-alpha2 release, and go from there, based on community availability and need for RFC compliance. Thanks, everyone!
mark_fullmer → made their first commit to this issue’s fork.
Thanks, everyone! This has been committed and will be included in the upcoming 2.0.0-alpha2 release.
Thanks everyone, for the implementation, and for the reviews above. This has been merged.
Thanks! This has been included in the 8.x-3.16 release
Thanks, everyone, for the contribution! This is included in the 8.x-3.16 release of Features.
Posting a comment to show that I am still interested in becoming a co-maintainer of the Features module.
This should be fixed, per the code changes added to the 7.0.9 → release of Linkit. Note, however, that the other issue related to CKEditor v45 (i.e., Drupal 10.5+ and Drupal 11.2+), 🐛 Editing Displayed text generates multiple links Active , remains.
mark_fullmer → changed the visibility of the branch 3535098-unable-update-link to hidden.
What if, during the processing that converts these links to span tags, we added a Drupal log message that flagged the occurrence? Would this be a way to surface these problematic links to assiduous content creators, thus mitigating the fact that these "valid errors" are no longer showing up in QA/SEO tools?
Reflecting further on my own proposal above, I think that reporting this through a Drupal log message really shouldn't be the purlieu of the Linkit module. Instead, people looking for that information about broken links should probably use something like https://www.drupal.org/project/linkchecker →
A new merge request, https://git.drupalcode.org/project/addtoany/-/merge_requests/32 , set to merge into 2.0.x-dev, has been added that implements the maintainer's request for this as an opt-in feature, per comments #17, #20, and #34.
This is ready for community review!
mark_fullmer → made their first commit to this issue’s fork.
mark_fullmer → changed the visibility of the branch 3535479-refactor-linkit to active.
and I cannot make any edits anywhere anymore (editor freezing).
Thanks for reporting this, @agnesliu, and sorry to hear about the problematic editing. Given that you describe the editor "freezing," can you check whether the browser console reports any JavaScript errors when this happens? If so, can you post the error message here? Also, are you using any other modules or plugins related to CKEditor on the problem site, or is it just plain Drupal core 10.5.2 and Linkit 7.0.8?
we try not to rely on ids for styling and JS so the id could be random and it'd still work.
Indeed, separate from styling and JS targets, HTML ID attributes, especially, as in this case, when associated with HTML heading tags, are used as in-page anchor links. Having a "permalink" through a consistent HTML ID, therefore, is preferable to a random one.
The approach in https://git.drupalcode.org/project/drupal/-/merge_requests/6965 would seem to provide a consistent ID, so if the Drupal core practice is to register HTML IDs in Twig templates, then MR 6965 would seem to be the right approach.
The disadvantage, for the sake of stating it explicitly, of updating (multiple) core Twig templates is that any sites that have defined their own block--system-menu-block templates will not receive this change. In my experience in Drupal development, the menu block template is frequently modified on a per site basis.
I shared this feature request with some colleagues, and they had some observations that I think are worth considering as we finalize the implementation:
1. Part of the stated motivation for this issue is "this leads [...] valid errors in QA/SEO tools (e.g., Ryte) when internal links return 404." If we are describing these as _valid_ errors, then why would we be effectively hiding these errors from QA/SEO tools? Put another way, if a site transforms broken links into plaintext, doesn't that take away a tool for someone using a QA/SEO tool to identify broken links on their site?
2. What if, during the processing that converts these links to span tags, we added a Drupal log message that flagged the occurrence? Would this be a way to surface these problematic links to assiduous content creators, thus mitigating the fact that these "valid errors" are no longer showing up in QA/SEO tools?
3. While we agree that a broken link provides a poor user experience to a site visitor, one of my colleagues wondered whether a plaintext rendering with a title attribute that displays "The referenced content is not available" would likely also be confusing, since most site visitors wouldn't be able to have any clear indicate of where, in a paragraph of text, the message is referring to: hovering over some parts of the text show the title attribute, and others don't. Given this, would it make sense to provide a default visual styling of the "linkit-unavailable" class? What about using a text-decoration-style: wavy;? Conventionally, this CSS style is associated with potentially problematic text, most commonly potentially mispelled words; semantically, this is pretty close to what we're trying to indicate, namely, "there's something wrong with this link."
Version 2.0.0-alpha1 → has been released, providing a tagged version of this module that is compatible with Drupal 11. Subsequent releases of the 2.x version will focus on critical bugfixes and long-running, community-requested features. Drupal community members who have been following this issue, please make an effort to comment on issues in the MimeMail issue queue that you see as particularly pressing or important, to raise the visibility of those issues to the maintainers of this module. Thanks!
Cross reference documentation on Linkit for link fields
Make title parallel with others in documentation section
Add caveat about ordering text format filters
mark_fullmer → changed the visibility of the branch 3022261-anchor-support-bc to hidden.
mark_fullmer → changed the visibility of the branch 3022261-add-better-support to hidden.
mark_fullmer → changed the visibility of the branch 7.1.x to hidden.
mark_fullmer → changed the visibility of the branch 8.x-5.x to hidden.
When adding the url fragment linkit removes the data attributes. It actually is caused by https://www.drupal.org/project/linkit/issues/3443845 🐛 When [Enter] key is used to replace a link, the previous link's attributes are not removed Fixed . Commenting out those lines fixes the issue:
Agreed that this was a consequence of that change. I've updated the MR to clear out external URLs' data attributes later on in the execution, making it compatible with the logic for updating link anchors here.
The latest changes in the MR are compatible with Linkit 7.1.x.
From #74:
I am however NOT able to:
Add a node URL with an anochor, e.g. node/123#test
Click the first suggested node -> Anchor disappears.
With the latest changes, I am able to perform the steps above and have the anchor persist. Please confirm.
This is ready for further review!
Assigning to myself for review...
Please post a comment after 14 days, if your offer has not been declined. It will show you are still interested in maintaining this project and it will serve as reminder an action is required for this offer.
As it has been more than 14 days, I am posting a comment to indicate that I am still interested in maintaining this project. Thanks!
Weighing in as a maintainer of the Linkit module, I would point out that there are others in the community who want the entity title to show: ✨ Show entity title after autocomplete selection instead of internal route (e.g., /node/123) Needs work . This, plus the fact that it is possible to configure the Linkit metadata to render the entity title in the matcher information, makes me disinclined to plan to include this in a release of Linkit. Community members are free to use the patch here, of course, but I'd really recommend going the route of adjusting the autocomplete metadata in the Linkit settings.
Weighing in as a maintainer of the Linkit module, I would point out that there are others in the community who want the URL alias to show: 📌 Link shown after the autocomplete selection is the bare node/xxx link, not the alias Needs work . This, plus the fact that it is possible to configure the Linkit metadata to render the entity title in the matcher information, makes me disinclined to plan to include this in a release of Linkit. Community members are free to use the patch here, of course, but I'd really recommend going the route of adjusting the autocomplete metadata in the Linkit settings.
My code review of this checks out, and I also did functional tests. Everything works as stated/designed, with one exception. In comment #6, there was the implication that removing unavailable links will only affect users that do not have the "view own unpublished" permission:
and the link shows up as a link in the WYSIWYG to an admin, but the link is rendered as a span to users that don't have permissions to view unpublished content
In my review of the code, I didn't see this permission check anywhere, and a functional test shows that even for user 1 (bypassing all permissions), the link is rendered as plaintext. I'm open to considering that the current implementation is how this should be designed -- i.e., that for all users, the link should be rendered as a span. I think the consistent behavior here would reduce the likelihood of confusion where a user with elevated privileges sees the link and doesn't understand why an anonymous user doesn't see the link. But I'd like to hear from the community.
All LinkItemInterface items had a uri, so I wrote a little function based around that as a starting point to test if entities load
I tend to agree with the reasoning in #11, that this should be evaluated based on UUID information, rather than trying to determine this from the URL (and besides, #10's proposal doesn't handle entities types other than nodes):
this feature is about the existence of the UUID data attribute, which provides proof that a node had been found by the LinkitWidget at the time the node had been edited
Responding to the questions for the maintainer:
Is
spanthe preferred neutral markup for the fallback, or should an alternative be considered?
This seems to be semantically as good an option as any other. The title attribute can be used on any HTML tag, so that's not a problem, and span does not denote any other meaning, so it's effectively neutral. I also considered whether this should remain an a tag without an href attribute, but that seems like it would be confusing to site visitors, and https://css-tricks.com/how-to-disable-links/ supports that thinking
Should the title text be made configurable or is translation sufficient?
It seems sufficient to start with it not being configurable and see where community demand goes, rather than building in the configurable text from the beginning.
I've added a documentation page at https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → , since the configuration between the link fields and the text format may not be intuitive.
Add documentation on styling disabled links
Updated to accommodate tests! Ready for further review.
I'll note that if the "Help" module is installed, the presumably helpful text "This layout builder tool allows you to configure the layout of the main content area. To manage other areas of the page, use the block administration page. Forms and links inside the content of the layout builder tool have been disabled." is embedded in this confirmation page, causing the important new text to be deemphasized:
This importance could be elevated by boldfacing the text, if desired. That being said, the language per the latest changes is accurate and grammatically correct, so I'm setting this to RTBC.
mark_fullmer → changed the visibility of the branch 3073895-layout-builder-menu-blocks to active.
mark_fullmer → changed the visibility of the branch 3073895-layout-builder-menu-blocks to hidden.
It has been two weeks since I created this issue and reached out to a project maintainer via the Contact tab. I'm therefore transferring this issue to "Drupal project ownership" per https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → . Thanks for consideration and any communication from the maintainers of the Features module regarding this offer!
FYI, as a maintainer of Linkit, this feature makes good sense, and the implementation is sensible. I approve of this being an opt-in feature. Assigning to myself for closer review of the code...
mark_fullmer → made their first commit to this issue’s fork.
Okay, thanks for the clarification. I'll close this issue as "works as designed."
Thanks for this report. To answer the question, I think we'd need a little more information. If you can look at the browser console output when you load a page using Linkit and Editor Advanced Link, if there is an error message in the console, please share. The fact that you're not seeing the autocomplete for Linkit probably means that there is a JavaScript error at some point in the rendering process and that this is causing the rest of the Javascript not to load. So it may or may not be a problem with Linkit.
Thanks in advance for the additional information!
mark_fullmer → created an issue.
Per https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → , this issue has remained in the project issue queue for more than 14 days without a response from the maintainer.
The maintainer responded to the community need in https://www.drupal.org/project/mimemail/issues/3504194#comment-16111148 📌 Plan for 2.x release? Active , suggesting openness to co-maintainership, but has not communicated since 16 May 2025.
I am therefore transferring this issue to "Drupal.org project ownership."
I've confirmed that changes staged in the merge request for 🐛 Editing Displayed text generates multiple links Active do resolve this issue's problem, and would love confirmation of that from someone else: using that branch, confirm that the "Steps to Reproduce" from #16 above result in successfully being able to change link text.
The problem of duplicated links is still present in the merge request for 🐛 Editing Displayed text generates multiple links Active , so I'm continuing to work on that...
mark_fullmer → changed the visibility of the branch 3535098-ckeditor-insert-fix to hidden.
mark_fullmer → changed the visibility of the branch 3535098-ckeditor-v45-cannot to hidden.
Thanks for reporting this! If I'm interpreting the steps to reproduce correctly, I think this may be by design in CKEditor? Specifically, from step 6 above, "Now hit Enter and click again on Link button from CKEditor," upon pressing "Enter" the CKEditor selection will remain on the link that was just created. Immediately pressing the "Link button" from the CKEditor toolbar will, by design, open the editing interface for that link. This can be seen visually because after pressing enter, CKEditor retains the ck-link_selected class on the link and it has a light highlight color.
This behavior can be reproduced using Editor Advanced Link's latest commit to 2.3.x, and without Linkit being enabled.
If I'm misunderstanding the steps to reproduce, please clarify. Otherwise, I think this can be closed as "Works as designed" or, alternatively, transferred to the Editor Advanced Link module's issue queue.
use 7.0.7 and MR122 from https://www.drupal.org/project/linkit/issues/3535479 📌 Refactor Linkit plugin for CKEditor5 v45+ Active (hidden branch)
In my testing today, using that MR does not have any effect or resolving this particular issue. Regardless of whether Editor Advanced Link is being used, the problem described above still happens, triggered by clicking within the link text and editing the link, as shown in the screencast below.
I have opened a new merge request that applies to the new 7.1.x branch and which replays the proposed changes from MR122 from 📌 Refactor Linkit plugin for CKEditor5 v45+ Active , specifically switching to the CKEditor balloon API, replacing previous code that was a workaround. As you'll see, the problem described in that issue is still present with those changes.
I'll keep working on this, but to me, this suggests that the solution may NOT require backwards compatibility-breaking changes. Rather the underlying problem seems to do with how Linkit is find the CKEditor link start and end (i.e., the "selection range" when an existing link is clicked on.
I've created a new target development branch, 7.1.x, for this work, since it will require introducing backwards-compatibility-breaking changes. See https://www.drupal.org/project/linkit/releases/7.1.x-dev →
I've created a new target development branch, 7.1.x, for this work, since it will require introducing backwards-compatibility-breaking changes. See https://www.drupal.org/project/linkit/releases/7.1.x-dev →
@mark_fullmer - Linkit plugin needs to be refactored for CKEditor 45+ anyway - 7.0.8 is just a temp solution:
I assume by that you mean that the refactoring would require breaking backwards compatibility with CKEditor <= v45, in which case, we'd want to reflect this in semantic versioning, i.e., switching from 7.0.x to 7.1.x...
Please re-open (or open a new bug) https://www.drupal.org/project/linkit/issues/3535479 📌 Refactor Linkit plugin for CKEditor5 v45+ Active and indicate to the maintainer that proper CKEditor 45+ refactoring is required.
An issue for this has been created in the Linkit issue queue at 🐛 Editing Displayed text generates multiple links Active
see my comment in #3534699-14: Refactor plugin for CKEditor5 v45+ for another bug that is related to CKEditor 45...Of course, I can also open a separate issue if that is preferred.
It appears that another community member created a separate issue for that today: 🐛 Editing Displayed text generates multiple links Active . I think it makes sense to initially keep that issue and this one tracked separately; if the fix ends up fixing both, fine :)
Thanks!
Thanks for reporting this. On a fresh installation of Drupal core 10.5.1 with Linkit 7.0.8 I am not able to reproduce, given the provided Steps to Reproduce. Have you added any other CKEditor-related plugins, etc. in the context where you observed the issue? Can you reproduce on a "vanilla" installation of the "Standard" installation profile?
The 7.0.8 release did include a change that removed some checking that definitely corresponds to the error you're reporting in the console, so I believe you that there is a problem and I believe we can resolve it by restoring some of the code in https://git.drupalcode.org/project/linkit/-/commit/3582746022e08364383f9...
But I'd first like to be able to reproduce the problem so I can understand it. Notably, this is also not triggering issues in any of Linkit's automated tests.
Thanks for noting this! I did a bit of searching. Per https://www.drupal.org/forum/support/module-development-and-code-questio... → , there doesn't seem to be a design for existing releases to be able to be removed.
I think this issue helps document the problem, and I will add a note to the project page to help clarify.
Reviewing the commentary on the merge request, it appears that the only question holding this up is whether and how this module should leverage the new parameter, $previous_config_names, available in ConfigInstaller::findPreExistingConfiguration, per https://git.drupalcode.org/project/features/-/merge_requests/39#note_494953
This new parameter was introduced in Drupal core (11.2.x) as part of 📌 Add the ability to install multiple modules and only do a single container rebuild to ModuleInstaller Active . Per that issue summary, the role of this parameter is a way of identifying when a container rebuild can be bypassed during the installation of a new module:
A $previously_checked_config argument is added to the protected methods \Drupal\Core\Config\ConfigInstaller::findPreExistingConfiguration() and \Drupal\Core\Config\ConfigInstaller::findDefaultConfigWithUnmetDependencies(). This argument is a list of previously checked configuration, keyed by collection name.
As this relates to the role of the Features module, as a tool for executing configuration imports on behalf of bundled configuration, I don't see this module as having a role in determining whether certain configuration changes can skip the container rebuild. That would be relevant only in the context of a finite, curated set of configuration in, say, a module, where the developer knows that a container rebuild is not necessary.
Furthermore, this has been implemented in Drupal core's business logic as an addition to a conditional that checks for $active_storage->exists($config_name), so in the context of Features imports, the core code already checks what it needs to check: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...
Therefore, I conclude that the Features implementation of should simply pass along the second parameter as is already staged in the merge request, array $previous_config_names = [].
Thus this issue remains, in my opinion, RTBC. A timely merge and release for Drupal 11 compatibility is important to the community!
Noting that this change is already accounted for in the issue for Drupal 11 compatibility, per https://git.drupalcode.org/project/features/-/merge_requests/39#note_494953 . So, presumably, this issue can be closed in favor of the comprehensive changes in 📌 Drupal 11 compatibility for Features module Active
But as far as I can tell, it's not that important and affects only people using LinkIt with CKE4. Given that's deprecated I think it's best not to touch it.
Okay, thanks for the clarification. I agree with the rationale to leave it alone.
Maintainers, please add users "mahde" and "deulenko" to issue credits.
Done. Thanks for being conscientious!
Thanks (again!) for the cleanup and especially the dependency injection rewrites :)
Setting to "Needs work" per #37
mark_fullmer → made their first commit to this issue’s fork.
Everything looks good. Thanks, everyone!
I manually tested and also executed the relevant automated tests against Drupal 10.4.8 to ensure that this is backwards compatible with sites that are using Linkit with CKEditor v44 or below. Everything checks out, so this change does not need to change the core version compatibility for the 7.x branch of Linkit. Thanks, everyone for the contributions!
Thanks for the rework! Assigning myself for review...
example of two modules that are removing LinkIt attributes when used:
Okay, thanks for helping connect the dots, @chrisla. Per https://www.drupal.org/project/editor_advanced_link/issues/3534044#comme... 🐛 Adding "Open in new window" removes all other attributes Active , another developer suggests that, contrary to intuition, this is not the responsibility of those modules to not remove other attributes, but rather, the responsibility of LinkIt to ensure the "persistence" of its attributes. I'll start looking into that.
As this is an opt-feature, I feel comfortable merging this in; should there need to be refinements, we can work those out subsequently.
Noting that this library now uses seboettg/citeproc-php, which declares a dependency on citation-style-language/locales, which has tagged releases. I can confirm that this module can be installed when the composer minimum-stability is set to beta; it still doesn't support stable since there is no full release of Bibcite -- we should remedy that!
After thinking about this further, I think that this is a common, reasonable request that should not require a developer in order to accomplish. I therefore propose adding a new, global setting to Bibcite for "Convert URLs into hyperlinks".
When enabled, this will pass the already-processed citation through Drupal core's _filter_url() function, which is robust and designed to handled a wide range of HTML content.
This approach does not give sites the ability to have some URLs be hyperlinks and others not be hyperlinks -- that, I feel, still should be the purlieu of developers and custom code.
This should no longer be an issue in 2025, using the standard Composer installation process. Closing as outdated.
Link updated in project page. Closing as complete!
I've confirmed that I can reproduce the problem and that the original proposed solution works sufficiently. Committed and included in today's 3.0.1 release of the module: https://www.drupal.org/project/iframe_title_filter/releases/3.0.1 →
Thanks for revisiting this, and the companion 🐛 title attribute still not added to oEmbed iframe Postponed . Associating this issue with the latest version branch of this module...