🇺🇸United States @mark_fullmer

I believe this is an issue with the Drupal module Editor Advanced Link, not Linkit, which only provides the autocomplete functionality. See https://drupal.org/project/editor_advanced_link

Will this fix be backported to 6.x? If not, then 6.x should be updated to require <10.5

Thanks. This will not be backported to 6.1.x. I've reflected this in the 6.1.8 core version compatibility: https://www.drupal.org/project/linkit/releases/6.1.8 →

This is due to a design change coming from CKEditor version 45 (see https://ckeditor.com/blog/ckeditor-45-0-0-release-highlights/#smarter-li... ). Basically, some types of link decorators are moved into a "Link properties" sub menu that is only visible and available **after** the original link has been added. This is not a change coming from the Drupal module, per se, but from CKEditor version 45. The "Open in new tab" option behaves differently than other options in Editor Advanced Link because it is defined differently, as a link decorator, in https://git.drupalcode.org/project/editor_advanced_link/-/blob/2.2.x/src...

I've merged a number of changes related to CKEditor v45 compatibility to reduce the surface area here. The originally reported problem still remains, so this is "Needs work."

mark_fullmer → created an issue.

Adding a max-width makes good sense here! Merging as-is. Tests are failing for unrelated reasons -- CKEditor v45 changes, to be addressed in 🐛 Cannot replace 'Displayed text' of existing links Active .

mark_fullmer → made their first commit to this issue’s fork.

Hi Jannahka,

Thanks so much for digging into the CKEditor v45 changes. These are certainly a priority. I'd begun some similar work, refactoring tests and refactoring for the problematic behavior in 🐛 Cannot replace 'Displayed text' of existing links Active . Ideally, I'd like to make only the minimal changes necessary and see if it is possible to retain backward compatibility with previous versions of CKEditor so that we don't have to change the core_version_requirement in a new release.

To that end, it will be important to document exactly what is known to be breaking, with steps to reproduce, so that we can ensure that we're only changing what is necessary and not breaking other things.

Thanks for reporting this. I am able to reproduce. Specifically, using a generic installation of the Standard profile, adding Linkit to the Basic HTML text format:

1. Click the "Link" icon.
2. Enter a "Displayed text" value.
3. Enter the first character of an existing node and use Linkit's autocomplete to choose a result from the dropdown. Confirm that the internal path to the node is populated in the "Link URL" field.
4. Quickly(!) Remove the contents from the "Displayed text" input and quickly enter new text and press "Insert."
5. Link text will not be updated and the console will show the Uncaught CKEditorError: Cannot read properties of undefined (reading 'attributes') error.

Additionally, this is something else that doesn't work correctly.
1. Click the "Link" icon.
2. Enter a "Displayed text" value.
3. Enter the first character of an existing node and use Linkit's autocomplete to choose a result from the dropdown. Confirm that the internal path to the node is populated in the "Link URL" field.
4. Now click "Link URL" field again and enter the first character of another node and use Linkit's autocomplete to choose a different result.
5. The link field will NOT correctly populate the internal path to the node but will simply populate the character you entered.

This is the first time I am posting; unsure how to proceed. If appropriate I can supply some code snippets related to the info_alter option.

Code snippets in a comment would be a great start. I can then move them into a new page under the documentation at https://www.drupal.org/docs/contributed-modules/bibliography-citation →

Seems a few other block--system-menu-block.html.twig in core. Is there a place we can add an assertion to?

Agreed that modifying the Twig templates is not the best approach here. Instead, we can supply the ID attribute to all templates through the SystemMenuBlock::build() method. The rendering logic for a unique ID can be modeled exactly on block/src/Hook/BlockHooks::preprocessBlock(), per below:

    // Create a valid HTML ID and make sure it is unique.
    if (!empty($variables['elements']['#id'])) {
      $variables['attributes']['id'] = Html::getUniqueId('block-' . $variables['elements']['#id']);
    }

I've created an alternate merge request, at https://git.drupalcode.org/project/drupal/-/merge_requests/12664

My previous comment was wrong. This is still an issue in Drupal core, though it only manifests in the context of placing a menu block using Layout Builder.

This appears no longer to be an issue as of 11.3.x. Placing a menu block on the page successfully generates unique ID attributes; placing a second instance of the same menu block confirms that the ID attributes and corresponding aria-labelledby attributes are unique. I haven't tracked down the core commit responsible for this yet, but will set this to "Postponed" given the above.

Example markup of first instance of menu block:

<nav id="block-olivero-mainnavigation" class="contextual-region primary-nav block block-menu navigation menu--main" aria-labelledby="block-olivero-mainnavigation-menu" role="navigation">
      
  <h2 class="block__title" id="block-olivero-mainnavigation-menu">Main navigation</h2>

Example markup of second instance of menu block:

<nav id="block-olivero-mainnavigation-2" class="contextual-region primary-nav block block-menu navigation menu--main" aria-labelledby="block-olivero-mainnavigation-2-menu" role="navigation">
      
  <h2 class="block__title" id="block-olivero-mainnavigation-2-menu">Main navigation</h2>

mark_fullmer → made their first commit to this issue’s fork.

This analysis is comprehensive and logical, and the proposed resolution of placing the executing code in a try/catch statement to avoid a fatal error, modeled after the behavior in Drupal core, is safe and uncontroversial. Thanks so much for the report, the analysis, and the code change fix!

mark_fullmer → made their first commit to this issue’s fork.

As of Drupal 10.5 and Drupal 11.2, version 45 of CKEditor is used, which places the Editor Advanced Link items in its own collapsible fieldset within the CKEditor Link editor. Given this, it is is likely that this proposed change is outdated. I'll not close the issue just yet, but I'm going to set its status to "Postponed" to evaluate the impact of version 45 of CKEditor.

Okay, changing this to a "Support request." Let's try to add some documentation that shows example usage of both HOOK__preprocess_bibcite_citation() and HOOK_bibcite_bibcite_processor_info_alter()

I believe the new version of CKEditor that is included with Drupal 10.5 caused some changes to the buttons.

Okay, thanks! That was the missing piece for me. I've added a change that should make the link editor width fit the available content.

Reviewing the use of the Gulp build process in this module and the resulting output, I conclude that it does so little that it is more of a liability to keep the build process in the codebase than it is an asset: there is a a fair amount of boilerplate code for SCSS that doesn't exist, and the JS is only very slightly modified. I propose that we work directly from the relatively small JS file in /assets.

If others in the community feel strongly that the build process should continue to be used, it can be reverted -- I'm not strictly opposed to that, but I will proceed to do the removal here in the absence of other strong opinions. Thanks!

This change creates a dependency on the presence of the media module for loading the form options, so we need to check if that module is active...

mark_fullmer → changed the visibility of the branch 3381766-linkit-dialog-list to hidden.

I've confirmed that the recent series of patches do not correctly handle both scenarios that need to be supported. They fix the dialog when used in CKEditor, but break the dialog when it is associated with a Link field, as was indicated by berdir in #20.

I've created a new MR, https://git.drupalcode.org/project/linkit/-/merge_requests/113 , which scopes the absolute positioning to the Link field by excluding that CSS from the CKEditor context. Can others confirm that this resolves the display issues for them in CKEditor? (It does for me, but as has been observed in this discussion, part of the issue has to do with the order in which CSS files are loaded, which may differ depending on site configuration.)

I feel like the LinkIt popup is unnecessarily narrow. It would be nice if it could automatically expand a little wider on larger screens.

Can you clarify which version of LinkIt and CKEditor you are using? Based on the screenshot, this does not appear to be the latest version, unless you've added some custom CSS to render the "Insert" button differently?

Individual sites could also potentially rewrite such URLs as actual hyperlinks by implementing HOOK__preprocess_bibcite_citation(), which provides access to the already-rendered citation. Presumably you could use regular expressions to find/replace specific markup with hyperlinks. This would not be as elegant a solution as using Lambda functions to modify the citation processor itself, as described in https://github.com/seboettg/citeproc-php#use-lambda-functions-to-setup-c... , but might be more straightforward for some developers.

This change makes sense, is uncontroversial, and tests pass. Merging!

Okay, I'm going to merge this! Thanks everyone -- this was a long-running issue spanning 6 years!

Commit 2354202e adds test coverage to demonstrate that the following variations are matched successfully, to address the concerns in #115:

https://<domainname>/<internal-path>
https://<domainname>/<alias>
https://<domainname>/<subdomain>/<internal-path>
https://<domainname>/<subdomain>/<alias>
https://<domainname>/<language-prefix>/<internal-path>
https://<domainname>/<language-prefix>/<alias>
https://<domainname>/<subdomain>/<language-prefix>/<internal-path>
https://<domainname>/<subdomain>/<language-prefix>/<alias>

mark_fullmer → made their first commit to this issue’s fork.

This meta issue was reviewed by me, a new maintainer in June 30. Each of the issues identified has been separately triaged and appropriate progress is being made. I'll therefore close this meta issue. Thanks!

This covers the testing (T) and I reviewed the changes (R) in Comment #6, so RTBC.

From one member of the C to another, thank you :)

Okay, thanks for the update. I'll go ahead and close this issue.

If you inspect the rendering of the title field, are the characters encoded or escaped? Also, if you can confirm that this is not happening on a basic node, such as "Basic Page," then this would seem to not be relate to Bibcite and you could search Drupal core issues for similar reports.

perhaps this can be mentioned in the README as a 'use at your own risk' as I think it is very usefull towards content editors?

Excellent suggestion. I've added a new documentation page at https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

To work with the nature of the Linkit configuration described above, I propose that a new setting be added to the text filter for setting "Media entity URL substitution", with three choices:

1. Use metadata from when the link was created
2. Direct URL to file
3. Standalone media URL (e.g., /media/{id})

This will allow sites to update their text formats to normalize how media links are substituted. By choosing either option 2 or 3, they effectively instruct the processor to ignore the metadata value in the link and do one of the two available URL methods.

Okay, thanks. Closing this as out of scope for the Linkit module.

Following up on this, as an immediate workaround that would force rendering of any media matchers as direct URLs, people could modify the CKEditor text format filter as shown below:

diff --git a/src/Plugin/Filter/LinkitFilter.php b/src/Plugin/Filter/LinkitFilter.php
index 1b91e51..de9fc43 100644
--- a/src/Plugin/Filter/LinkitFilter.php
+++ b/src/Plugin/Filter/LinkitFilter.php
@@ -116,7 +116,9 @@ class LinkitFilter extends FilterBase implements ContainerFactoryPluginInterface
           if (!$substitution_type = $element->getAttribute('data-entity-substitution')) {
             $substitution_type = $entity_type === 'file' ? 'file' : SubstitutionManagerInterface::DEFAULT_SUBSTITUTION;
           }
-
+          if ($entity_type === 'media') {
+            $substitution_type = 'media';
+          }
           $entity = $this->entityRepository->loadEntityByUuid($entity_type, $uuid);
           if ($entity) {

A more robust solution that would determine what the site's current setting for a given matcher is and use that is complicated. As far as I know, Drupal text filters do not have access to know which text format executed the request for processing. They only have access to the text format's settings for the given text filter. Unfortunately, Linkit stores the matcher being used in the *editor* configuration of a text format, rather than in the text filter. This means that the executing code can't query "what Linkit matcher is being used with this configuration?"

Of course, the straightforward workaround would be to add a global setting that provides a default for the media substitution plugin. But since Linkit has zero global settings right now, I'm hesitant to create one for this purpose. Thoughts?

Marking this as a duplicate of 💬 Links surrounding Media Library item strips data-entity-type and data-entity-uuid Postponed . The conclusion stated in https://www.drupal.org/project/linkit/issues/3396049#comment-15450593 💬 Links surrounding Media Library item strips data-entity-type and data-entity-uuid Postponed still appears to be valid.

The "Result description" was renamed to "Metadata" in https://git.drupalcode.org/project/linkit/-/commit/3b8e2a33bf26f944ff2ae... , and that is included in the current schema. I'm going to close this issue as outdated. If this is still an issue for anyone, please don't hesitate to create a new issue!

This issue appears no longer to be an issue in the latest release of Linkit. As such, and given there has been no activity on this issue for more than 5 years, I'm going to go ahead and close it as outdated. If this is still an issue for anyone, please don't hesitate to create a new issue!

Thanks for the suggestion! This change makes sense. I've created a merge request for it.

mark_fullmer → changed the visibility of the branch 3504398-add-convert-to to hidden.

mark_fullmer → made their first commit to this issue’s fork.

I think the custom code suggested in this issue is the right way to go, short of a new UI setting that would allow sites to enable Linkit for the menu link UI and to configure which Linkit profile should be used for that. My hope is that the forthcoming core solution in ✨ Drastically improve Drupal's default linking experience in text fields Needs work will support menu links, and that there will be no need for this to be provided in contributed code. So, for now, I think this should not be added to Linkit itself.

We are instead thinking about creating a separate linkit profile without the media matcher so we can still move forward with this.

That sounds like a reasonable approach. I don't think it's likely that there would be a need for a media matcher to be used in Drupal menus, so I'm disinclined to complexify the code by somehow modifying the rendering of menu links (beyond just the autocomplete selection provided by Linkit).

Thanks for reporting this! Can you confirm that the staged merge request resolves the issue? Thanks!

mark_fullmer → made their first commit to this issue’s fork.

Thanks for the cleanup work and the additional testing, richard.thomas. I've reviewed this today and the code changes look good to me. I'll set this to RTBC and, as a maintainer, plan to merge this soon unless anyone else sees problems with this approach.

I've converted the patch to a merge request so we can see what this does in automated test coverage. On the surface, the changes involved here look like they could have unintentional side effects.

Okay, the issue with the tests in fact demonstrates the scope change introduced by adding filter! In other words, without explicitly enabling the Linkit text format filter, it is NOT loading the JS, which is what this change is designed to accomplish. I updated the tests.

I can confirm the behavioral difference between the two links reported above. The proposed resolution makes sense to me and does not seem to carry a risk of unexpected consequences.

I've functionally confirmed that this is no longer an issue on Linkit for Link Field. Closing!

Thanks for the suggestion! I've added a merge request that stages the proposed change. Ready for community review.

mark_fullmer → made their first commit to this issue’s fork.

Thanks for this report! Does the small modification to the CSS in the staged merge request resolve the issue for you?

mark_fullmer → made their first commit to this issue’s fork.

Thanks for the report! The stage merge request adds a targetable unique id attribute to each autocomplete suggestion description and an aria-describedby attribute to the title. Representative output shown below:

<div class="linkit-result-line-wrapper published ui-menu-item-wrapper" id="ui-id-8" tabindex="-1">
  <span class="linkit-result-line--title" aria-describedby="title--deb05804-034b-4f7e-a94f-70f4a7157254">test</span>
  <span class="linkit-result-line--description" id="title--deb05804-034b-4f7e-a94f-70f4a7157254">Flex Page #1 | Thu, 26 Jun 2025 - 10:08 by admin</span>
</div>

mark_fullmer → made their first commit to this issue’s fork.

I'd offer some suggestions on the current proposed text, shown here:

This layout will be reverted to the default layout, any custom overrides will be lost. Are you sure you want to continue?

1. I'm not sure that for most content editors, the technical term "custom overrides" will be clear. Most content editors think of the changes they are making to a Layout Builder page as "adding content" or "modifying content." On top of this, it really depends on how Layout Builder is being used on a given site. If a Layout Builder entity view display is configured to display a bunch of fields from the entity, then what the content editor does with Layout Builder is a "modification" to the layout, or perhaps even an "override." If, however, the Layout Builder entity view display is more of a blank slate to which content editors add inline blocks of content, then content editors aren't going to think of this as a "modification/override" but as content additions.

2. From a grammatical perspective, a comma shouldn't be used to separate two independent clauses.

Proposed revised language that tries to find the right balance between Drupal technical terminology and content editor comprehension:

This layout will be reverted to its default state. All layout modifications and inline content will be reset. Are you sure you want to continue?

I'd offer some suggestions on the current proposed text, shown here:

This layout will be reverted to the default layout, any custom overrides will be lost. Are you sure you want to continue?

1. I'm not sure that for most content editors, the technical term "custom overrides" will be clear. Most content editors think of the changes they are making to a Layout Builder page as "adding content" or "modifying content." On top of this, it really depends on how Layout Builder is being used on a given site. If a Layout Builder entity view display is configured to display a bunch of fields from the entity, then what the content editor does with Layout Builder is a "modification" to the layout, or perhaps even an "override." If, however, the Layout Builder entity view display is more of a blank slate to which content editors add inline blocks of content, then content editors aren't going to think of this as a "modification/override" but as content additions.
2. From a grammatical perspective, a comma shouldn't be used to separate two independent clauses.

Proposed revised language that tries to find the right balance between Drupal technical terminology and content editor comprehension:

This layout will be reverted to its default state. All layout and inline content will be reset. Are you sure you want to continue?

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?

mark_fullmer → created an issue.

Similar to the comment above, our issue might be more related to the Editor Advanced Link plugin

Thanks for the update. I'll leave this issue open for now for visibility, but it does seem that at this point, all reports of problems are coming from people who are using Editor Advanced Link. Folks should head to 🐛 D11.2: Uncaught CKEditorError: Cannot read properties of undefined (reading 'viewUid') Active to follow progress there.

Reviewing the design of this module, I would recommend an alternate resolution: change the label of the "Number of pages" field to "Pages" and indicate in field help text that this can be entered as either a single page number (22) or a page range (22-25). The module is designed to pass that field value to the processors and render it correctly to show the page range.

This would seem to be preferable over math logic such as "[Start Page] + [Number of Pages] - 1".

This appears to be working as designed in the 3.0.x release. Is anyone still having an issue with how different types of contributors are rendered? Can we close this as outdated?

As with 🐛 Editor books are rendered wrong Active , I tested this today, using Chicago Style, and confirm that the editors are displaying correctly. I conclude that this issue is outdated and will close it as such. If this is still occurring for anyone using the latest version of Bibcite, please provide specific steps to reproduce!

I tested APA styles for both the 6th an 7th edition today, with one and two editors and no other authors. I was never able to reproduce a situation where the editor was omitted and the date was the first entry. In each test, the editors displayed according to the expected APA format, as compared to the output from Zotero.

Example:

Editor 1, & Editor 2 (Eds.). (2016) Jaghmīnī’s Mulakhkhaṣ: An Islamic Introduction to Ptolemaic Astronomy. Springer-Verlag.

Closing as outdated, but if this problem is still occurring for anyone, please provide specific steps to reproduce! Thanks!

Based on testing today, this issue appears to be resolved.

I confirmed, using Zotero, that the the title provided in the original issue description should render, in Chicago Manual of Style 17th edition as:

Jaghmīnī’s Mulakhkhaṣ: An Islamic Introduction to Ptolemaic Astronomy

I then tested entering that value into Bibcite and confirmed that it did not alter the title case.

I then tested entering a value that did not conform to Chicago Style ("Jaghmīnī’s Mulakhkhaṣ: an Islamic introduction to Ptolemaic Astronomy" and confirmed that it correctly modified the title case to match Chicago Style.

Marking as Closed -- outdated!

Cross-referencing 🐛 Publication Date should support more than "Year" (e.g., article in a newspaper APA format) Active , which involves changes to another field that is processed using the extractDate method described here.
In sum, there are three fields that would be affected:

    'bibcite_year',
    'bibcite_access_date',
    'bibcite_date',

is there additional work needed for a full solution so that this *can* be configured in the UI,

Thinking about this further, I conclude that this *does* need to be a configurable option in the UI, since there will be potentially existing sites who have entered date format in dd/mm/yyyy format, where this proposes to support mm/dd/yyyy, and a previous comment suggested matching the citeproc's yyyy/mm/dd format.

Therefore the remaining work, as I see it:
1. Decide on a new default for new installations of this module, or just decide to keep it supporting dd/mm/yyyy format to prevent disruption for people used to using this module currently. No change should occur to existing sites, regardless
2. Add a new UI setting for configuring whether the date format should be dd/mm/yyy, mm/dd/yyyy, or yyyy/mm/dd.
3. Add logic that will update the form fields' descriptions to match the site-configured setting in #2

Thanks for reporting this. This is indeed due to problematic logic in the module, which always adds a space to the "Given Name" even if there is no first name and last name. I've created a merge request that resolves this issue.

Thank you for the report. This is correct that the module does not properly support publication dates that should be rendered to include day/month values in addition to the year. I've added a merge request that modifies the field storage to allow publication dates to be entered as strings, so that a value like "03/01/1997" can be entered into the existing field and will correctly render per citation format.

It seems highly likely that this problem was caused by the Entity API module not being installed. Given that this original poster has not responded and the issue has not been commented on in 4 years, I'm going to close this as "Works as designed."

Reviewing the maintainer's response in #3, it seems like this may need to be something that is resolved through individual site updates to the CSL styles, in which case the best thing this module can do is provide comprehensive documentation on this.

Leaving this issue as "Active," and marking as "Major" since correct CSL formatting is quite important!

Categorizing this as a feature request, rather than a bug. Leaving as "Active."

As of today, I am unable to reproduce this problem using the latest version of this module (3.0.0-beta5) with Drupal 10.4. My Views configuration was as follows:

Format: Unformatted list
Show: Reference | Citation
Fields: The selected style or row format does not use fields.
Filter criteria: Reference: Published (= True)

Indicating in the issue title that this is specific to integration with the DisplaySuite module.