Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.This should really belong to 7.x-2.x but this branch does not exist yet.
Biblio could benefit from using a core taxonomy field instead of its own logic. Here are a few benefits:
- less confusion, see for instance #439086: Improve integration of Biblio Keywords and Taxonomy
- biblio code base becomes lighter, no need to reinvent the wheel
- biblio keywords can have a weight, a hierarchy and a description if needed
- the keyword field can be moved around via the Field UI, administrators and developers can treat it like they are used to with a regular field.
- no work required to integrate with Drupal modules eco-system (Views and all the numerous taxonomy modules in contrib)
Taxonomy has seen some performance improvement in D7, and we should consider leveraging that. I'm creating this issue to discuss whether the reasons which initially led biblio to having its own keywords management are still applicable in D7. From looking at the table structure, I see a direct equivalence between these sets of database tables:
- the custom biblio_keyword and the new denormalized table taxonomy_index for storing relation between nodes and their terms.
- the custom biblio_keyword_data and taxonomy_term_data for storing term data.
Comments
Comment #1
rjerome commentedHi Stéphane,
The similarities between the keyword and taxonomy database tables is no accident, I copied much of its functionality. Which begs the question why? The answer is that I did go the taxonomy only route for keywords at one point, but this issue is that keywords then fall out of the control of the biblio module and then can be changed or removed at will. So if someone comes along and says "I don't like this vocabulary... and deletes it, there is (or at least wasn't) any way for the module it intervene and say Woh there budy, are you sure you want to permanently delete ALL the biblio keywords? And you can never get the linkages back! Alternatively, if the same keywords are associated with other content types and they get changed by the other content type, they would also show up changed in biblio nodes, maybe thats desirable, but maybe not.
Now, if I recall correctly this issue may have been addressed in D7, meaning modules can take ownership of fields. If this is the case, then maybe this can be revisited
Regards,
Ron.
Comment #2
scor commentedI don't think you need to take care of site admins who don't know what they are doing, and at the same time penalize those who do know what they are doing. This is how core works, look at the forum module for example, you can delete the forum vocabulary, but it warns you like this:
This is the designated forum vocabulary. Some of the normal vocabulary options have been removed.Deleting a vocabulary will delete all the terms in it. This action cannot be undone.Again, much like forum.module, biblio should definitely create its own vocabulary. The problem above would only appear if a site admin was to associate this vocabulary with another content types, and again, it's their problem, not yours.
In any of the scenario above, you could do fancy hook_form_alter to warn or even deny removal operations but you really have to draw the line before that, otherwise biblio will get swamped in its own growing code base.
Comment #3
tourendal commentedsubscribing
Comment #4
rjerome commentedThis will come when everything is moved to "fields". I toyed with making this change now, but it created more problems that it solved, and I really would rather get a working D7 version out there.
Comment #5
scor commenteddefinitely agree, you should not work on new features until there is a D7 port ready...
Comment #6
tekken commentedSubscribing. Any progress on this?