Hooks for bibtex

Hmm, I overlooked sth. for exporting: <modulename>_biblio_bibtex_export allows for altering the settings before the bibtex output is generated.

But in case you want to add other fields to your output, e.g. the DOI field, we need another hook to add stuff to the bibtex output. The new patch adds <modulename>_biblio_bibtex_export_add for this.

The import_hook is sufficient to import additional fields like the DOI.

Well, we need another hook in look ahead of another patch that I will submit soon to correct the author import for bibtex (the import pendant to http://drupal.org/node/335892).

To get the ct_id calculated right for the authors/editors, the biblio_type must be set before. E.g. when you want to split @incollection from @book (biblio by default imports both into the biblio book type), you must set the biblio_type first, because a normal primary author has a different ct_id for every biblio type.

So we now have 4 hooks:

• hook_biblio_bibtex_export_pre: called after the bibtex type is set but before any output is calculated. Allows to set bibtex types not defined in biblio, e.g. export as @incollection
• hook_biblio_bibtex_export_post: called after all bibtex output but the authors/editors has been defined. Allows to add additional fields for a bibtex entry, like "doi = xxx,"
• hook_biblio_bibtex_import_pre: called after biblio_type has been set. Allows to change it to split bibtex types like @incollection into a custom type instead of into the biblio book type. Neccessary to get the right ct_id calculated for authors/editors.
• hook_biblio_bibtex_import_post: called after all biblio fields have been defined from the bibtex entry. Allows to alter them, e.g. @inproceedings can have both, "booktitle" and "series" while biblio by default replaces booktitle by series if it is defined. Or to add additional fields like a DOI field

Ron, do you think this concept is now kind of "clean" enough to maybe make it into biblio? Although it looks like no one but me ever needed this so far :-)

Hi Ron,
no DOI is not a bibtex standard. That's exactly why I thought a hooking system could be useful. At our site we want to export and import the DOI field as we create bibtex entries from other systems, too, where we include e.g. the doi.

We could indeed let biblio im- and export every non-standard field if it has a biblio pendant but I didn't try to offer a patch for this because I thought this might blow the bibtex exports up too much. One might also have "private" fields for internal marking etc. that shouldn't go into the exports. I guess a really clean solution would be to let the user chose which fields to export for every type, but that would change the database scheme up.

I also didn't try to patch everything I stepped onto because it would change the database. E.g., inproceedings needs different fields for organization and publisher according to the bibtex definition, so the db must be changed for the 103 type and I never feel comfortable when it comes to db changes :-) I always feel I don't overlook the consequences such changes might have.

For the thesis stuff one would need an additional field to store the type of thesis (as type_of_work must stay for user input according to bibtex), I guess one could find a field for this, but it would again need some db change for the field title.

Of course fixing everything in biblio is the better way! Only when you use custom types for anything and want those to go into any kind of bibtex import/export (or the predefined type for a non-standard bibtex entry, say you want a bibtex export for "Newspaper article"), you will need a hooking system like this.

Yes, I use them for separating @incollection from @book, or for exporting all type=2 authors as authors instead of editors (by just changing the type to 1). And I'm using an additional hook that allows to alter the WHERE clause for biblio_db_search, so that we can distinguish between public and private papers etc. (e.g. the 1993 paper at http://drupal-test.bio.ifi.lmu.de/mitarbeiter/volker-heun doesn't show up at http://drupal-test.bio.ifi.lmu.de/publications as it was not published at our chair, but the user wants to have it at his private publication list, of course).

But I think that this is all kind of very special to our site so I'm fine with re-adding this patch for every new biblio release.

If you are interested in adding such hooks, I can make a clean patch with better names etc. Of course, hooks should never harm, but as long as only I need them, the don't need to be in the module :-)