[BibTeX] Import fails when using "{...}" instead of {...}

If the maintainers think that renanbr/bibtex-parser is the right replacement, then I think I can prepare a MR to do it.

There is probably room for improvement in the attached patch.

@mark_fullmer:

Thanks for the encouragement. I will try the newer package and see if that helps.

I also ran into another problem: using the input below, I get four authors instead of six when I import, and the fourth is "Chino" instead of "Haruka Chino". It seems that just the first line of the author entry is being processed. I will keep my fingers crossed and see whether the newer parser fixes that problem, too.

@ARTICLE{Gao2025-hy,
  title    = "Structures of human organellar {SPFH} protein complexes",
  author   = "Gao, Jingjing and Sherpa, Dawafuti and Kupko, Nikita and Chino,
              Haruka and Zeng, Jianwei and Shao, Sichen",
  abstract = "Stomatin, Prohibitin, Flotillin, and HflK/C (SPFH) family
              proteins are found in all kingdoms of life and in multiple
              eukaryotic organelles. SPFH proteins assemble into homo- or
              hetero-oligomeric rings that form domed structures. Most SPFH
              assemblies also abut a cellular membrane, where they are
              implicated in diverse functions ranging from membrane
              organization to protein quality control. However, the precise
              architectures of different SPFH complexes remain unclear. Here,
              we report single-particle cryo-EM structures of the endoplasmic
              reticulum (ER)-resident Erlin1/2 complex and the mitochondrial
              prohibitin (PHB1/2) complex, revealing assemblies of 13
              heterodimers of Erlin1 and Erlin2 and 11 heterodimers of PHB1 and
              PHB2, respectively. We also describe key interactions underlying
              the architecture of each complex and conformational heterogeneity
              of the PHB1/2 complex. Our findings elucidate the distinct
              stoichiometries and properties of human organellar SPFH complexes
              and highlight common principles of SPFH complex organization.",
  journal  = "Nature Communications",
  volume   =  16,
  number   =  1,
  pages    = "10064",
  month    =  nov,
  year     =  2025
}

This is definitely a work in progress, but I think the hard part is done.

For testing purposes, I added the line

        "renanbr/bibtex-parser": "^2.2.0"

to my project's composer.json, under the require key.

I tested it on the BibTeX entry in Comment #5. It works pretty well: the only problem I notice is that the braces are still in the title: "{SPFH}". As I hoped, it fixes the problem I mentioned there.

There are some new @todo comments in the code, and obviously I need to test it on some more varied BibTeX input.

Oh, good: there is a failing test. That tells me what to do next.

I still want to do more of my own testing, with real-life .bib files, but the automated tests are now passing, so I am setting the issue status to NR in case someone else is eager to help test.

@mark_fullmer:

I have imported over 100 BibTeX entries without errors. I will try to get someone at work to spot-check that they imported correctly.

I notice a couple of other problems:

1. Both BibTeX and RIS formats set bibcite_date without respecting the mm/yyyy format.
2. Unmapped reference types do not seem to default to Miscellaneous.

For (1), BibTeX (by default) maps month to bibcite_date. RIS maps DA to bibcite_date. I added a fix for that (both formats) in the last commit, but I am happy to move that to a separate issue, since it is not really in scope for this one. Also, since it affects at least two formats, I wonder if there is a better place to fix it. At work, we have entity validation (after #3553399: Missing entity validation during import).

For (2), I notice the code comment in Drupal\bibcite_entity\Normalizer\ReferenceNormalizerBase:

  /**
   * Default reference type. Will be assigned for types without mapping.
   *
   * @var string
   */
  const DEFAULT_REF_TYPE = 'miscellaneous';

I have not tested on a plain Drupal install, so maybe we have done something to break it, but I get the error

Entry has not been parsed. 'incollection' type is not mapped to reference type. Check mapping configuration.

when the reference type is not mapped. I am not sure whether this is just for BibTeX. Probably I should open a separate issue for that.

@mark_fullmer:

There are six commits on the main branch since the latest release (2.2.0), one with the commit message

PHP 8.4 support

Should we reach out to the maintainers and encourage them to make a new release? Should we require the main branch or a specific (untagged) commit? It might also be worth looking at the 16 forks of the project. Maybe one of them is more actively maintained.

I will try to find time next week to see what I can do about the braces and the linebreaks.

In Comment #10, I wrote,

Unmapped reference types do not seem to default to Miscellaneous.
...
I have not tested on a plain Drupal install, so maybe we have done something to break it, ...

I did some more testing, and confirmed that we did something to break it.

@mark_fullmer:

Date format

From Comment #11:

… if we’re sure that this is an incorrect default mapping for both BibTex and RIS, rather than a subjective judgment call, …

I do not think the mapping is the problem. The DA field (RIS) and the month and year fields (BibTex) should be mapped to the bibcite_date field. The problem is the format: bibcite_date expects "mm/YYYY", and the examples I am looking at have "2026/01/14" (RIS) and "oct", "2021" (BibTex).

Braces in author names

The new(er) parser does not treat the braces specially. In the example we have been looking at, I see "Milton {Abramowitz}" and "Irene A. {Stegun}". The problem seems to be when the Contributor entity is created, the name gets parsed into first, middle, and last: "Milton", "{", "Abramowitz}" or "Irene", "A. {", "Stegun}". Then the first and last are combined to get "Milton Abramowitz}" or "Irene Stegun}".

But that is just for the sake of curiosity. I think, to keep backwards compatibility with the old(er) parser, I can just strip braces from author names, titles, abstracts, etc.

Line breaks in titles

We already strip newlines from abstracts. I can do the same thing for titles. Again, this will improve backwards compatibility.

@mark_fullmer:

Thanks for the kind words, and for adding the test coverage.

I replied on the MR about PHP versions.

The new decode() method has custom handling for the following fields:

• abstract
• title
• author
• editor
• month

and encode() (indirectly, via buildEntry() and buildLine()) has custom handling for author and keywords. So it would be good to add these fields to at least one of the test entities:

• abstract (with line breaks)
• editor (same format as author: separated by "and", maybe with line breaks)
• keywords

Another open question: in Comment #13, I asked,

Should we reach out to the maintainers and encourage them to make a new release? Should we require the `main` branch or a specific (untagged) commit?

I created an issue for the library: https://github.com/renanbr/bibtex-parser/issues/117.

I do not like the idea of requiring a branch or an untagged commit in the module. We might suggest, in the release notes, that site owners do that in their own `composer.json`. I think that will work, but it is hard to test until this issue gets fixed.

The additional test looks good to me.

The next time we need an example, it will be one of my papers. ;)