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:
- Use metadata from when the link was created
- Direct URL to file
- 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.
Merging the latest changes from 3.0.x.... let's see what the automated tests think!
mark_fullmer → made their first commit to this issue’s fork.
I was unable to reproduce this behavior. Here are the steps I took.
1. Add the CDN script to the HTML head of the site as indicated on https://www.mathjax.org/#gettingstarted
2. Populate a reference title field with MathJax syntax, such as the following:
When \(a \ne 0\), there are two solutions to \(ax^2 + bx + c = 0\) and they are
\[x = {-b \pm \sqrt{b^2-4ac} \over 2a}.\]3. View the reference entity. The MathJax logic does convert the shortcode syntax as expected.
(Note that the conversion won't necessarily happen in the *administrative* portion of the site if you are using a different admin theme and the JS script has not been added to that theme. If you want it to work in the admin theme, you would need to do something like a hook_page_attachments implementation (see https://www.drupal.org/docs/develop/creating-modules/adding-assets-css-j... → ):
mymodule.module:
/**
* Implements hook_page_attachments().
*/
function mymodule_page_attachments(array &$attachments) {
$attachments['#attached']['library'][] = 'mymodule/mathjax';
}
mymodule.libraries.yml:
mathjax:
js:
https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js: { type: external, minified: true }
Are there any ways to change the order of family and given name in the name expression according to the language?
Based on the screenshot provided, it appears that the rendering is being accomplished via the "Table" style as set at admin/structure/bibcite/reference/settings. If you change the "Reference page view mode" to "Citation," you can use any of the standard citation formats for displaying the bibliographic information. These formats are much more robust, and most formats (such as APA style) automatically display the last name first.
My understanding is that the public display of references really should be using "Citation" rather than "Table" display, where the "Table" display is really only intended for internal use to list all of the data associated with a reference.
Of course, you may really want to use the "Table" display. Since this is a Drupal view mode for an entity type, you should be able to use the "Manage Display" interface for "Contributors" at /admin/structure/bibcite/contributor/settings/display to rearrange that display.
Marking this a "Patch (to be ported)" for now, since the current proposed solution works for some instances but probably isn't a good generic solution for all sites.
Merge request created from the provided patch to confirm automated test coverage.
Noting that the library dependency academicpuma/locales still does not have a tagged release, so sites wanting to use this will still need to use the method described in #4, above.
The library https://github.com/researchgate/libris does indeed seem to be one of the more regularly maintained forked of technosophos/libris, including recent commits for PHP 8.2 support. Given that the latter has not been updated in ~14 years, it is probably worth the "risk" of switching to this fork. Merge request stages the change.
This change makes sense to me. RTBC!
mark_fullmer → made their first commit to this issue’s fork.
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...
Thanks for the iterations, work and reviews. This looks good to me! Merging.
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,
Well, there was a core CKEditor version change between Drupal 10.0 and 10.1, from version 35 to 36, which involved API-breaking changes for implementers of the CKEditor Link widget. But if you're noticing the breakage between 10.1 and 10.2, that might not be the issue.
It sounds like you're doing the right thing by peeling away other factors -- disabling Linkit and Editor Advanced Link -- and I guess you should keep going in that direction. You could also try going the other direction by starting with an installation of the "Standard" install profile and building up the configuration to match your site to find where the breakage occurs. Good luck!
Need a fix to the module's 6.1.x version to be compatible with v45 of CKEditor 5.
It would be preferable to update to the 7.0.x release cycle. As far as I know, there shouldn't be any incompatibilities between Drupal 10.1 and above on that branch.
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
Looks like it might possibly be to do with a clash with the Editor Advanced Link module - that might explain the rearrange layout?
Yes, I note that the console error reported is actually coming from Editor Advanced Link. I think the issue may be with that module ( 🐛 D11.2: Uncaught CKEditorError: Cannot read properties of undefined (reading 'viewUid') Active ), and your update to 7.0.5 was just a coincidence.
In fact, release 7.0.5 of Linkit was intended to prevent such an error from occurring. Happy to help troubleshoot further if it does seem to have something to do with Linkit.
This should be resolved as of release https://www.drupal.org/project/linkit/releases/7.0.5 → . If you're still encountering issues, let us know!
This was resolved as part of the D11 compatibility work.
mark_fullmer → created an issue.
mark_fullmer → made their first commit to this issue’s fork.
This should be configurable globally to control the format.
Damien, given the statement above, is there additional work needed for a full solution so that this *can* be configured in the UI, separate from the fix that assumes either mm/yyyy or mm/dd/yyyy in the patch above?
Hrmm... this seems like a rather complicated one to use Drupal's DeprecationHelper logic ( https://www.drupal.org/node/3379306 → ) to employ different class method syntax to support older versions of Symfony.
Given that Drupal 9 is now unsupported, I'm not sure it's in the best interest of the maintainability of this module to go that route to preserve D9 compatibility with the 3.0.x branch.
Therefore, I'd propose "resolving" this by marking the 3.0.x branch as no longer compatible with Drupal 9, and leaving this issue for visibility so that people still on D9 can use the patch in #4 for continued compatibility.
How does that sound to folks? Trying to do the right thing by the community!
I was able to reproduce the problem and confirm that the proposed fix prevents the problem. Committing and marking as "Fixed." Thanks, Brian!
This appears to be a duplicate of 🐛 Extra space for given name causes double period for rendered citation Active , which now has more information associated with it, so I'll go ahead and close this issue as a duplicate.
I attempted to reproduce this problem on the 3.0.x-dev branch today and was unable to do so. Steps taken:
1. Create a new Contributor at /admin/content/bibcite/contributor , entering a Middle Name and a Surname, but not a First Name.
2. Create a Reference and associate it with this Contributor.
3. Render this using the (default) APA style citation formatter provided by the module.
4. Observe that there is no duplicative "double period" as described in the issue report.
I also tried populating a whitespace character for the first name, and separately for the middle name.
If this is still a problem, please provide additional steps to reproduce. Also, if it is a problem, it might more appropriately be addressed in https://github.com/ADCI/full-name-parser, which is a dependency of this module.
mark_fullmer → created an issue.
Agreed that this is important to review. Setting to "Major."
The proposal above involves adding an empty settings form. It appears that there are no intended settings for the Bibcite Keyword entity at this point in time, so I would instead recommend removing the route/links that are erroneously referencing it. I've created a separate merge request for that.
If there is a reason that we should have an empty settings form for keyword entities, please explain!
mark_fullmer → made their first commit to this issue’s fork.
When I tested the RIS import using the test file located in this module (https://git.drupalcode.org/project/bibcite/-/blob/2.0.x/modules/bibcite_...), the "SP" value was successfully imported. Note, please, that the "SP" value corresponds to the "Number of Pages," not the "Start Page" as indicated in the issue summary.
Can you test the file indicated above and report back if you get a different result compared to your file?
After another review of the changes, another confirmation that the automated tests are passing, and functional testing with an existing configured site, I confirm this should be committed, providing Drupal 11 compatibility while not changing support for previous supported versions of Drupal core.
Big thanks to @mmarler for his work on refactoring the denormalization!
This issue was created in 2017 at a time when Composer was not fully adopted by the Drupal community. In 2025, it is standard practice. Therefore I'm going to close this issue as outdated, as this module should not need to provide generalized documentation on how to use Composer. Thanks!