Closed (outdated)
Project:
Bibliography Module
Version:
6.x-1.15
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
3 Nov 2011 at 15:37 UTC
Updated:
21 Dec 2018 at 20:34 UTC
Jump to comment: Most recent
Comments
Comment #1
rjerome commentedThat issue sounds vaguely familiar, I just want to confirm that it's the 6.x-1.15 version you are seeing this with.
Comment #2
bstoppel commentedI am using 6.x-1.15
Comment #3
bstoppel commentedJust had a user email me that this happened to them again. Is there a patch that I can apply? Or can you point me to the place in the code to work out a solution?
Comment #4
rjerome commentedI haven't been able to reproduce this issue, so I can't offer any patches to fix it.
I can tell you that if the user changes ANYTHING in the author name it will generate a new author.
The code that determines if any changes have been made is at line 188 in biblio.contributors.inc
Comment #5
tomr commentedWe seem to have the same problem using 7.x-1.0-rc3, although not for every user...
Comment #6
tomr commentedI think I found a workaround. What I did when the problem occurred, was to merge the new author (with one publication) into the existing one (with many publications). This would solve the problem, but it would reappear after the user made the next edit. I now do the merge the other way around, so merge the old author with the new one. If I do that, the problem does not reappear if the user edits a publication again.
Comment #7
rjerome commentedIf you can reproduce this, I would really love to see the database records (in biblo_contributor_data) for the two authors before the merge. Hopefully that would lead to a resolution of this problem.
Ron.
Comment #8
bstoppel commentedInteresting tip tomr. I'm going to try that method.
Ron, here are the database records you requested. The first query is before, the second is after.
Comment #9
bstoppel commentedTomr's workaround in comment #6 works for me too.
Comment #10
rjerome commentedHmm, those database dumps don't get me a lot closer to a solution, the only thing that pops out is that in the first instance the biblio author is associated with a Drupal user ID.
I'll do a bit of testing and see if that is somehow related.
Ron.
Comment #11
rjerome commentedStill can't reproduce this, but I'm wondering if it has anything to do with collation (character encoding). If you notice in the two records the md5 values are different (which is why a new record is being created). The md5 value is calculated by combining the firstname,initial and lastname values then doing an md5sum on the result. To the naked eye those values appear to be the same in both records, however if the collation was different, then the actual byte values of the characters could be different, leading to differing md5sum values.
How did the entries get into the database originally? Were they imported from file? Do you have UTF-8 character encoding in both your database and webserver?
Comment #12
bstoppel commentedI'm definitely not a MySQL guru, so this is testing my knowledge :) But first, answers to the questions.
The records are entered in a couple of ways. The initial imports were done using a file import from a EndNote Bibtex export on a Mac. (Aside: I have found importing EndNote XML exports to be more reliable and to capture more data. For now, that is my preferred method.) Authors add new publications using another Bibtex export or, more likely, manually entry. I've trained them to do both, but I think the latter is easier for them to grok.
When I view the page info on the import and entry forms using Firefox, it reports UTF-8 encoding.
Below is a a query of the biblio tables' status.
Let me know if there is anything you'd like me to try.
Comment #13
rjerome commentedThanks, the DB collation looks good. It would be good if you could confirm/deny that the problematic entries came from a file import, that might narrow it down a bit. If they did come from a file, then if would help if I could get a copy of that file (contact me via my contact form to get my email address).
Ron.
Comment #14
liam morlandThis version is no longer maintained. If this issue is still relevant to the Drupal 7 version, please re-open and provide details.