Normal cacheing has been turned on our website, and biblio started behaving strangely. When selecting filtering and then selecting an author, it showed the full content (as if the filter would have matched everything). After selecting a biblio entry and then going back to the list, the filter suddenly became active. Turning off drupal caching appears to have fixed the problem. Note: 6.x-1.x-dev version Jun-04 (i.e. not the latest).

Comments

rjerome’s picture

rjerome commented

Indeed, caching has been a bit of an issue which I haven't resolved as of yet.

I will try to get to the bottom of it though.

Ron.

gabork’s picture

gabork commented

I would recommend documenting in a readme that the cacheing be better turned off.

One user did this: edited an existing biblio entry, by removing an author (say. X) from the entry, adding another author (say, Y), and rearranging the author's list (such that Y appeared in the same position where X was before). Now X has been completely removed from the *database*, and all entries where X was used before have been replaced by Y. Ouch. I don't know if this was a cache problem, but cachine was on when happened.

rjerome’s picture

rjerome commented

Yes that is a serious problem which will I will deal with, and to be honest, I don't think that was cache related, I think that is a (big) bug in the update logic.

Thanks for reporting that.

Ron.

tobiass’s picture

tobiass commented

Hi

Normal cacheing has been turned on our website, and biblio started behaving strangely. When selecting filtering and then selecting an author, it showed the full content

Same issue for Biblio Version 5.x

Cheers

wehall’s picture

wehall commented
Title: cache interferes with biblio? » author update problem (was: cache interferes with biblio?)
Version: 6.x-1.x-dev » 6.x-1.0-beta8

Any changes related to this problem? We're still seeing it with all caching turned off...

wehall’s picture

wehall commented

Anyone found any fix for this problem? Appears to affect import as well as creation via manual input.

rjerome’s picture

rjerome commented

I haven't had a chance to look into this yet, but hopefully in the next week or so.

Ron.

wehall’s picture

wehall commented

Any news on these fixes in the 6.x version? We're continuing to use the 6.x version with user changes turned off, but the users are getting anxious to update their publications.

polli’s picture

polli commented

Suppose author-id1 has author-name1 attached to it (in table biblio_contributor_data). When you edit a biblio entry and change the author to some other existing author with author_name2, the author_id1 will be associated to author_name2.

Result:
author_id1->author_name2
author_id2->author_name2
and author_name1 is lost.

The place where this happens is _save_contributors in biblio.contributors.inc. I found this condition
($update && !empty ($author['cid']) && $author['cid'] != array_search($author['md5'], $md5))
which I interpret as: "when the new author exists but is different".

I cannot think of any reason to modify an existent entry in the table biblio_contributor_data during the modification of a biblio entry. I think that when you want to edit the author name associated to an id this has to be done in an extra dialog.

So would it be enough to remove the $update_record part in the above function?

polli’s picture

polli commented

Update: the _biblio_contributor_form contains a hidden field that has for existent biblio entries the author id as default value. When an author is modified the old id together with the new name is given to _save_contributors.

As a hack we could set an empty string as default value, which would result in the same behaviour as for new entries.

rjerome’s picture

rjerome commented
Status: Active » Fixed

This has now been fixed in CVS and will appear in the next release.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.