I'm working on updating a book review website from D4.7 to D6 at the moment and saw this module.

The current site has book info in the review nodes but I'm currently writing some code to split that up into users, roles, book with amazon module cck field, and review nodes.

I'm thinking that this module would be perfect but unsure as to the best way to import the data as I don't have it in one of the standard import formats.


rjerome’s picture

I would have to see the data, but if it's currently just a single string, it would be a bit of a pain since the string would have to be broken into the various parts (authors, title, journal, date, volume, pages, etc.)

Anonymous’s picture

Thanks for the quick reply.

Most of the data is in recognisable fields except for contributions which I'm currently writing the code to decipher as you say. Then I was using the 5.3 dev version of CCK and multigroup to store pairs of role references and user references for the contributions to a book node type.

Over the years the extra author fields have filled up with "Illustrations by A Name, B Name, and edited by C Name" etc.

So whilst I'm avoiding going through the final 750 one-off anomolies out of 12,000-odd records I thought I'd check out the biblio module again. I'd seen it a while back when I first started on this site but thought it looked way too complicated for what I was being asked to do at the time.

Now I'm up to 55 or so contributor roles (including such obscure ones as "paper engineer"!) it suddenly dawns on me... ;)

Anonymous’s picture

Title: Importing from nodes » Importing from nodes

Probably useful to add that currently I'm creating a custom module in the D4.7 version to import into the D6 version just using curl to fill the various node/add forms.

Which I guess i could do here too, just set up the types as I need them...

rjerome’s picture

It might be easier to write an export function to create a known file format, then importing that file into biblio. I would suggest looking at the biblio_endnote_tagged_export() function in the biblio.import.export.inc file as an example of how to write a "tagged" export file which could then be ingested by biblio. Alternatively, if you wanted to use XML, you could use the file endnote8_export.inc as a starting point.

Anonymous’s picture

That's the conclusion I was coming to, and those were the pointers I was looking for - thanks, will try them out.

Anonymous’s picture


I'm still a little confused as to using the biblio module, I'm not sure if once I've organised how to do the data import I'll be able to do what I need, for example storing five-star rating values.

I've listed the data types I have currently set up in D6 waiting for my data migration code to be finished. I've either got to write that to fit into my current setup, or to import to biblio. I'm also not sure what should be in biblio and what should be in CCK - looks like everything needs to go into biblio but maybe migrate to CCK in the future as I've read in some of the issue queue. At the moment my main task is to get the information online and easily searchable, which is why I think biblio is way forward as it's kinda made for it...

For example, it looks like I have to make a field for each author type as I add one as opposed to how I'm currently doing it using the new CCK multigroup feature to link a user reference with a particular role reference. I can't see at the moment how I enable all the 50-odd author types in my new publication type I need to set up for my own 'book' type.

Also, currently reviews, articles and editorial are linked to an 'Issue', but there are further editorials and articles which don't relate to any particular issue we want to put up in the future. Can biblio support the current 'Issue' linked framework there is?

I'm just worried that I'll get all the import code working but it won't support the structure I have and I'll have to go back to square 1. Any help/pointers most appreciated!

'Issue' type:

Title - Text (Issue number)
Date - Date (Published date)
Image - Image (Issue cover image)

'Book' type:

Title - Text
ISBN - Amazon CCK field so can link 'buy now' button
Authors - User reference, multiple allowed
Contributors - CCK content multigroup of User reference and Role reference pairs
Genre - taxonomy reference
Supplemental info - Text field, multiple entries allowed
Age Range - taxonomy reference

...rest of book info will come from Amazon at runtime, e.g. price, publisher, etc.

'Review' type:

Book - Node reference
Reviewer - User reference
Issue - Node reference
Rating - Fivestar Rating
New Talent - checkbox
Editors Choice - checkbox
Media type - Taxonomy reference
Review Series - Taxonomy reference
Review Text - Text
Running Order - Integer

'Article' type:

Title - Text
By Line - Text
Image - Image
Issue - Node Reference
Subject - Taxonomy Reference
Slot - Taxonomy Reference
Order - Text
Body - Text

'Editorial' type:

Title - Text
Body - Text
Issue - Node reference
Image - Image

'News' type:

Title - Text
Body - Text
Topic - Taxonomy reference
Organisation - Taxonomy reference

rjerome’s picture

Hi Steve,

If you give me a pointer to an existing site, it might help me visualize what you are doing. It's hard for me to say with any certainty whether biblio will fill you needs or not, but frankly I'm leaning towards maybe not, as it's meant to be more of a reference manager than a book review module.

Your right, there is an effort underway to add CCK support, however this is a ways off so I wouldn't hold my breath on that one.

It appears to me that in your current case, all of your authors must have a Drupal User ID? In biblio, this is not required but the two can be linked. In biblio, there are 4 tables associated with author handling... biblio_contributor, biblio_contributor_data, biblio_contributor_type and biblio_contributor_type_data. Author information is stored in the biblio_contributor_data table which is joined to the biblio table via the biblio_contributor. For every author on every biblio entry, there is an entry in the biblio_contributor table which not only identifies the authors and the order in which they are to be displayed, but the "type" and "category" of each author. Each author can fall into one of 5 categories (primary, secondary, tertiary, subsidiary or corporate) and can also be one of an unlimited number of "types". A link from an author to a Drupal User ID can also be stored in the biblio_contributor_data table. When contributors are loaded into a biblio node, they form a multi-dimensional array like this...

  $node->contributors[$author_category][$rank] => array('lastname' => 'Smith', 'firstname' => 'John', 'auth_type' => 5, etc...)

The $rank in the code above defines the order in which the authors are displayed.

In terms of linking with issues, I honestly don't know. A biblio node is no different than any other node, so there is nothing stopping you from adding CCK fields to a biblio type node to handle these references if this is possible.

I hope that helps more than confuses.



Anonymous’s picture

Hi Ron,

Thanks again for your reply - still stuck between the two choices, current way of thinking is that it'll be a lot more work to put it into biblio as all my types, views, etc. are already set up on my D6 install.

The current D4.7 site is http://booksforkeeps.co.uk - if you click on 'latest issue' you'll see how the parts of the mag are split up and displayed.

The current readership is mainly librarians and teachers who want easier finding out of information such as whom edited what books, which I'm currently planning on achieving using types, CCK, views, etc. but obviously the biblio module is more 'made for this' side of things hence my interest in using it.

Authors I am planning on being users - currently blocked but there may be a time soon when some accounts are used, e.g. reviewers might log on, add their bio, upload a review, etc.

Anonymous’s picture

OK I've decided as the rest of the site (types, views, etc.) is already set up I'm going to use that for the moment. I think it's going to take too much work to rewrite everything using biblio, although I will be keeping an eye on the CCK progress.

Thanks so much for your help, gained some more insight into this lovely module!

rjerome’s picture

Status: Active » Closed (fixed)

Fair enough, it's usually best not to use a hammer when a screwdriver is required ;-)



Aren Cambre’s picture

Status: Closed (fixed) » Closed (duplicate)