Porting Biblio to CCK

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
Coornail's picture

Overview

Implement the necessary CCK fields and views to be able to initiate the porting of the Biblio module.

Description:

Biblio is a Drupal module that allows users to manage and display lists of scholarly publications. It is currently used on approximately a 1000 installations (and raising). It's use in projects like The Science Collaboration Framework, however is bound to increase it's use even more.

Currently the module is still using custom nodes with it's own database tables instead of CCK nodes/fields. Because of this it has to implement and maintain it's own widgets, integration with CCK reduce redundancy in the Drupal contrib codebase.  Lately several features from Biblio have been reimplemented in the CCK framework. Also several glue-modules emerged that seek to incorporate functionality that already works for CCK

The advantage of porting the fields to CCK:

  • Smaller codebase for Biblio
  • Easier maintenance
  • Leverage the integration of CCK with several contrib/core modules
  • Prevention of duplication
  • Easier porting to Drupal 7

The goal of my summer of code:

Port the Biblio fields to CCK and integrate them with Views. From that point it will be easy to port the whole project to CCK and get integration with views and other modules.

Mentors:

  • Kristof Van Tomme - Local mentor, existing working relationship
  • Ron Jerome - Maintainer of Biblio module, Co-mentor

Other people who indicated their interest in being part of the mentorship:

  • Robert Douglass - Senior Drupal Advisor @ Acquia
  • Benjamin Melançon - Project leader of the Science Collaboration Framework

Difficulty: Medium

Comments

Mentor Confirmation

rjerome's picture

Note to Alex UA...

As stated above, I am willing to be a secondary mentor on this proposal and as such have completed the application on the GSOC site.

Cheers,

Ron.

Thank you for your support!

Coornail's picture

Thank you for your support!

This is wonderful news!!

talatnat's picture

Biblio is a superb module. Thanks, Ron.

Coornail, if you need help, especially with documentation, let me know.

Thanks for the offer, can I

Coornail's picture

Thanks for the offer, can I add you to the discussions we're doing on that (mails, skype)?

Yes, of course, add me to the list...

talatnat's picture

I see that the "Inherit" module is not getting much attention. But, with the number of content types multiplying yearly, and Biblio's inherent structure, it looks like the way to go.

I am very happy to hear that!

aboros's picture

I am only using Biblio for a short time now, but I definitely have to use it massively in the future. I really like this module and will do a great job for our website, still I'm suffering from lack of views integration and the approach that it uses its custom node type and all other stuff.

It would be unutterably fantastic to have Biblio built upon CCK.

I would be very happy to help in any kind of work, also I'm not a hardcore coder, but maybe you could also use some testing help. ;)

That would be great! I'm

Coornail's picture

That would be great!

I'm really happy to see that many people interested in Biblio, it really gives me the energy to do my best =)

(Keep it up, a few days, and it's going to roll now ;)

Status update?

talatnat's picture

Just curious how things are progressing...

any news or followup?

aboros's picture

i am very curious about this project, could you provide some followup?

Sorry, my exams took much

Coornail's picture

Sorry, my exams took much longer than I expected, but I'll be back with full force .o/

Schedule?

David Lesieur's picture

I'm also very interested by your project. Glad to see you back! :-)

If you could complete the wiki page with some sort of schedule, that would be great. I also need Biblio to integrate with CCK, and knowing more about your roadmap could help me (and perhaps others) plan for contributions that would complete your work rather than duplicate it. Thanks!

I'm on it, not sure about

Coornail's picture

I'm on it, not sure about the deadlines tough.

Are these the deadlines you

rjerome's picture

Are these the deadlines you are referring to?...

February 8: Program announced. Life is good.
March 9:
~12 noon PST / 19:00 UTC
Mentoring organizations can begin submitting applications to Google.
March 13:
3pm PDT / 22:00 UTC
Mentoring organization application deadline.
March 13-17: Google program administrators review organization applications.
March 18:
~12 noon PDT / 19:00 UTC
List of accepted mentoring organizations published on the Google Summer of Code 2009 site.
March 18-23: Would-be student participants discuss application ideas with mentoring organizations.
March 23:
~12 noon PDT / 19:00 UTC
Student application period opens.
April 3:
12 noon PDT / 19:00 UTC
Student application deadline.
Interim Period: Mentoring organizations review and rank student proposals; where necessary, mentoring organizations may request further proposal detail from the student applicant.
April 15:
  • All mentors must be signed up and all student proposals matched with a mentor - 07:00 UTC
  • Student ranking/scoring deadline. Please do not add private comments with a nonzero score or mark students as ineligible (unless doing so as part of resolving duplicate accepted students) after this deadline - 17:00 UTC
  • IRC meeting to resolve any outstanding duplicate accepted students - 18:00 UTC in #gsoc-resolve on Freenode
April 20:
~12 noon PDT / 19:00 UTC
Accepted student proposals announced on the Google Summer of Code 2009 site.
Community Bonding Period: Students get to know mentors, read documentation, get up to speed to begin working on their projects.
May 23:
  • Students begin coding for their GSoC projects;
  • Google begins issuing initial student payments provided tax forms are on file and students are in good standing with their communities.
Interim Period: Mentors give students a helping hand and guidance on their projects.
July 6:
~12 noon PDT / 19:00 UTC
Mentors and students can begin submitting mid-term evaluations.
July 13:
12 noon PDT / 19:00 UTC
  • Mid-term evaluations deadline;
  • Google begins issuing mid-term student payments provided passing student survey is on file.
Interim Period: Mentors give students a helping hand and guidance on their projects.
August 10: Suggested 'pencils down' date. Take a week to scrub code, write tests, improve documentation, etc.
August 17:
~12 noon PDT / 19:00 UTC
Firm 'pencils down' date. Mentors, students and organization administrators can begin submitting final evaluations to Google.
August 24:
12 noon PDT / 19:00 UTC
  • Final evaluation deadline;
  • Google begins issuing student and mentoring organization payments provided forms and evaluations are on file.
August 25:
12 noon PDT / 19:00 UTC

Final results of GSoC 2009 announced
September 3: Students can begin submitting required code samples to Google
October (date TBD):
Mentor Summit at Google: Representatives from each successfully participating organization are invited to Google to greet, collaborate and code. Our mission for the weekend: make the program even better, have fun and make new friends.

I have to split the project

Coornail's picture

I have to split the project into several points, and have to decide deadlines for them for the wiki page.

Sorry for being away that

Coornail's picture

Sorry for being away that long. Today I got into fast forward mode and started experimenting with Biblio.

I managed to parse the csv file that contains the field information, and generated the content types from it.
Next thing is to add the cck fields to the appropriate places. I'm going to use cck's shared field ability with it: http://drupal.org/node/112792

Tomorrow I'll submit the code I think, here's some screenshot until then:

30 new content types???

rjerome's picture

I'm not sure you want to create a different content type for each type of publication. You should have only one content type "biblio" and then a field to define what type of publication it is (just like we have now).

Agree and disagree

robertDouglass's picture

Advantages of keeping "biblio" type:

  • better upgrade path
  • less clutter
  • somewhat more polymorphic

Advantage of separate content types:

  • More natural to Drupal and CCK
  • Simplifies field logic
  • Makes Views and other type level tools easier/more flexible/more precise

The upgrade path is important, though. If you choose separate content types for each publication then you have to make sure there's a good upgrade path and you have to make sure you're not throwing out more of the existing code base than you need to.

I implemented the one

Coornail's picture

I implemented the one content type version, and now I see the advantage in it.

Views won't be a problem, since there is a "publication type" field so you can filter by that.
It will be also easier to find for example all the publications of an author if the author wrote several types of publications/software/etc.

I'm working on the field visibilty restriction now. I'll submit the exported content type to review, since I'm not sure some fo the field's type.

this is good to hear

aboros's picture

one content type approach is great news, it will make several things much more easier.
i cant wait to test it. :)

For multiple content types

David Lesieur's picture

I was a bit ambivalent about this issue, but giving it more thinking got me leaning towards separate content types.

Views could support multiple or single content types equally well, but many features in core or contrib modules are dependent on content types, such as create/edit/delete permissions per content type, associations of vocabularies with their content types, the ability to post comments, the toggle to show publishing information, the content type filter in core search, etc. If we go with a single type, then we don't free ourselves from one of Biblio's major limitations. I'm sure not all projects have been stumbling on those limitations, but most of our projects have.

In my idea, what is really needed is to assign "bibliographic meaning" to CCK fields. For example, mapping that field as the Collection, this other field as the Chapter, etc. The mappings could then be used for formatting citations and for importing/exporting bibliographic data. Any content type could have such mapping. Of course, predefined publication types (predefined content types with predefined mappings) could still be provided, but only as a convenient optional feature. Sites would never get overwhelmed by unwanted content types, since any publication type would be have to be explicitly enabled or custom-created. We might not be the typical user, but in our projects that involve Biblio, we don't use most of the predefined publication types, and always have to define custom ones.

scottrigby's picture

I agree with rjerome that 30 new content-types off the bat might feel a bit much, when most users won't want to use all (or even most) of them -- so i can understand why that approach was initially taken (it is kind of an elegant solution).

However David Lesieur's idea of offering biblio-cck-fields for use on any content-type (and maybe optionally enabling a number of defaults as a separate content types) sounds even more appealing to me -- it would address the same concern but in a way that leverages cck much more naturally (as robertDouglass said on the advantages of separate content types), and allow any content type to be "bibliographized" using biblio-cck-fields.

One small example - we currently add other cck fields to Biblio nodes (when custom biblio fields don't cut it, like date or nodereference fields). Unfortunately, these currently can't be made specific to one Biblio publication-type and not another - so our cck fields are present on all publication types even where we don't want them.

I'm sure there are other use cases that would make a case for the biblio-cck-fields option. How realistic do you think this is though?

Midterm evaluation

Coornail's picture

I found the "let's add bibliographic meanings to whatever we want" idea awesome, so it will be there, thanks!

Since the midterm evaluation is coming I set up a sandbox site so you can see how am I going:
http://biblio.pronovix.net/
The username is "test" with the password: "test".

You can read the details there.

Sandbox Code...

rjerome's picture

Hi Kornél,

Thanks for making the sandbox site available. I've looked at it and have a few questions/comments...

First off, the input form looks good in the way the it has admin selectable fields for each publication type. One comment though, you might notice on the current biblio form, the title of the input field also changes based on the publication type (i.e. "Secondary Title" becomes "Book Title" when the Book type is selected or "Conference Name" when the Conference Proceedings type is selected). You will find a file called biblio.field.type.data.csv in the biblio installation directory which contains these "database field" -> "input form title" mappings. If you open that file in Excel (or some other spreadsheet) you will find that the top row has the database field names, the second row has the default form titles and subsequent rows have the type specific titles for the input form. The function _add_custom_field_data() in the bilbio.install file is the one that parses this file.

In reality, what the database fields are called is really un-important, what is important is the title the user sees and the ability to relate the data stored in that field to a particular data type based on the publication type. In the most normal format, (rather than having a biblio table with 50 columns) there could be a "biblio_data" table with just 3 columns (vid, tid, data) where tid is used to identify the type of data (place published, conference name, short title, etc.) and the "data" column is just a "blob" of data. That being said, I suspect this is not relevant to CCK since (correct me if I'm wrong) it creates a table much like the bilbio table with a column for each field related to a particular content type.

I would be interested to see the database structure that is currently behind your "sandbox" installation to better understand how things might fit together.

One minor issue (and I know this is pre-alpha code, so it's not a criticism) but if you preview the input form all the fields disappear.

Also, we will need to think of output formatting, since (in my humble opinion) this is quite important. I'm referring here not to the "node" view, as that is fairly easy to deal with, but rather the list view where entries are give a particular (APA, AMA, Chicago, Vancouver, etc.) bibliographic style.

Which brings me to another question... What is the meaning of ”Bibliographed" on the /admin/settings/biblo_cck/type/xxx page?

Cheers,

Ron.

So title mappings, okay,

Coornail's picture

So title mappings, okay, will be there.

I'm posting the code on the sandbox page right now (the simple installation won't work tough).

I'll check out the preview.

Output formatting is on the way.

The bibliograped fields is the idea of David Lesieur at http://groups.drupal.org/node/20909#comment-81921. It's basically it's the ability to use other fields then the author and etc to search and order things (am I right?). Not sure it's the right word tough.

Thanks for your feedback!

Title mappings with CCK

David Lesieur's picture

When a CCK field is shared between content types, CCK lets us change some of the field's settings for each content type, including the field's title. So if publication types were separate content types, we'd get "title mappings" for free.

So yes, I'm back insisting that we need a distinct content type for each publication type. :-) That would free us from a major constraint of the Biblio module, and would allow us to leverage a lot more features from CCK, Drupal core, and other modules.

1 is more default use case I believe

kvantomme's picture

I think for the most use cases it's better to have 1 default biblio content type, it greatly reduces complexity. The 1 form select the type of publication approach is really how most people with less experience would use it.

Nothing however stops you from using the biblio fields that were created by biblio for other content types, or to add other CCK fields. That gives you the full power of CCK. If you need separate content types, you could still integrate with biblio.

The value in distinguishing between the types is if you need different behaviour for different types. For example if you need different permissions for different types. Kornel told me that it's easy to do this with some extra code. However again in most use cases that would just clutter the UI.

--

Check out more of my writing on our blog and my Twitter account.

Title mappings with CCK

rjerome's picture

@David OK, so I'm starting to understand your point of view, but I still think the users are not going to be terribly happy when they are faced with 35 content types to choose from. It's a pity that you can't "disable" a content type thus allowing the list to be pared down to only the essentials. I guess my other concern (and it's probably not a big deal) is that the default bibliographic listing typically includes ALL publication types which is simple enough now given they are all "biblio" node types however if they are all standalone types then one must first determine which content types are "biblio" types prior to filtering and sorting the listings.

Both approaches are not mutually exclusive

David Lesieur's picture

@Ron and Kristof: I think I also get your points. In many cases, the ease of working with a single type is an important advantage.

I think both of our approaches could be supported, as bibliographic meaning could be associated to a single "polymorphic" biblio type containing a publication type selector, or to arbitrary content types. In a way, I'm just advocating for an additional level of abstraction where the bibliographic meaning is decoupled from the actual field definitions.

I really don't want to start

Coornail's picture

I really don't want to start again (for the 2nd time), but hey, let's do a poll about that:
http://groups.drupal.org/node/24001

I really don't want to start

rjerome's picture

With all due respect Kornel, this is why we do Software Requirements Analysis and planing prior to coding.

I tought we settled with one

Coornail's picture

I tought we settled with one content type, but now it seems like we didn't.

unifying theories

kvantomme's picture

I think we don't need to get into this kind of discussions. Kornel is trying his best to accomodate the requests from this discussion. Besides I actually think that this is not an either or problem.

I discussed this afternoon with Kornel that we could do either a demo on how to make new content types that use the biblio fields using the CCK UI, or if there is time he could integrate simple CCK, a wizard that helps you create custom stand alone content types if you need them.

So I believe that the "1 CT method" is a solution that accomodates both use cases and combines usability of the 1 content type solution with the configurability for more advanced users that want to change more things.

The "bibliographing" or however you want to call it, would happen on a field level in stead of on a content type level. That is how it's more conform with the way CCK works, that also means that it's easy to add "bibliographed" fields to other content types.

--

Check out more of my writing on our blog and my Twitter account.

Assigning bibliographic meaning to CCK fields

David Lesieur's picture

Thanks for the demo installation, that really helps us better understand your work.

However, I'm not sure if the "bibliographed" field corresponds to what I meant. :-)

My suggestion is that a "CCK_Biblio" module could do the following:

  • Define a "bibliographic vocabulary", a list of terms that identifies the metadata we can find in a citation, e.g. "year of publication", "author", "title", "secondary title", "tertiary title", "volume", "section", "issue", "edition", "publisher", etc. (Note: I'm using the words "vocabulary" and "term" in a larger sense, not necessarily related to the taxonomy module)
  • Provide a way to associate any of these bibliographic terms to any CCK field in any content type. This is what I mean by "assigning bibliographic meaning" to CCK fields. This means that a site admin could, for example, decide that "field_fullname" is an "author" field, "field_date" is a "year of publication", etc. The actual fields and their mappings could vary from content type to content type, depending on how admins defines them. Bibliographic meaning could easily be added to existing (pre-CCK_Biblio) content types.
  • Leverage those term-field associations in citation style formatting functions (APA, AMA, etc).
  • Leverage those term-field associations in import/export functions.
  • For backward compatibility as well as convenience, provide optional pre-defined content types with pre-defined term-field associations for each of Biblio's current publication types, that site admins could enable if desired.

I realize that this is a different approach from the current Biblio module and from what you have implemented so far, but I believe it would be far more flexible.

Assigning bibliographic meaning to CCK fields

rjerome's picture

Ahh, I see now, and I like it. It's not really such a far cry from what currently exists just, as you mentioned, a further level of abstraction. The question now is how to make those associations? I presume this is not something CCK can do out of the box? We probably should have been having these discussions a few months ago :-(

How to...

David Lesieur's picture

I think we'd have to build something on top of CCK, as it does not provide the "mapping" capability out of the box...

Perhaps other modules such as Feed Element Mapper and Field Tool can provide some inspiration.

I hope Kornel's enthusiasm with the project will make up for the lateness of this discussion. :-)

Yea to Bibliographic CCK Schema Mapping

libsys-gdo's picture

Ok, this is a bit of a +1 comment (and about a month late), but I will just say that this is almost exactly what I have been considering - developing a bibliographic schema to layer on top of CCK.

For me, the value in such a feature would be that you could write code against the bibliographic field mappings and not have a ripple effect on your code base each time you changed something at the CCK layer. I'd like to replace direct calls to cck fields in my RIS, BibTex and OpenURL export code with something a little more stable.

Sorry to be so late to the game, I wish I'd noticed this thread before.

@Coornail Good luck on finishing up the SoC project, and thank you for your contribution :).

kvantomme's picture

I think I understand the problem now. Basically you are asking to make the functionality in Biblio compatible with other CCK types.

So what you are asking for is rather an abstraction layer for Biblio functionality than for CCK. This might actually be the easiest way to port all the import/export stuff that is now working with biblio's own data model.

Did I understand you ok?

--

Check out more of my writing on our blog and my Twitter account.

An additional layer of functionality

David Lesieur's picture

The additional layer would not so much be a data model abstraction layer than an extra layer of functionality for assigning bibliographic meaning to any CCK field in any content type. I think that the data model still needs to be based on CCK to leverage features provided by other modules that are also based on CCK.

defining bibliographic meaning

kvantomme's picture

The bibliographic meaning that's for using the biblio functions on it right? So it's a way to tell biblio what it should be querying right?

--

Check out more of my writing on our blog and my Twitter account.

Yeah, the mappings would

David Lesieur's picture

Yeah, the mappings would tell, for each content type, what CCK field to look up to find a particular piece of the bibliographic description.

entry fields go missing?

emmajane's picture

I took a quick peek but I'm having problems seeing the data entry field. The whole thing flashes but then I can only see the pub type, title and year of publication (even when editing). Is there some Javascript that's getting a little confused, maybe? I've attached a screenshot of what I can see after the flash that hides the rest of the fields. I'm on FF 3.0.11 on Ubuntu.

That's right, a Javascript

Coornail's picture

That's right, a Javascript is messing with the fields.

The reason why you don't have any fields, because there is no visible field set up to that type: http://biblio.pronovix.net/?q=admin/settings/biblio_cck
Try with the beginning of the list.
I know it is a bit confusing, but there will be a default list (like there is now), and normally you don't want to mess with that.

aha!

emmajane's picture

That makes sense, thanks! The flash is confusing and disconcerting because I can see other fields and then they go away. Switching the publication type to change the input fields doesn't feel intuitive because it's so "un-Drupal." Now that I see how the input form changing when I switch pub types, it makes more sense. I'm not sure if it's the best approach, but I'm having fun switching from one type to another. ;)

I'm currently working with a research group on a promotional site that lists the group's publications, conference presentations (etc). Here are a few things that I've run into:
- Theming is very important. If it doesn't look properly formatted, it isn't a bibliographic reference.
- They want the authors to be user references, but also want specific formatting for authors (we've entered this as two fields: one for user reference and one for "display of authors").
- Where relevant, the research groups wants to be able to link to off-site articles (i.e. the URI for the published article); and/or have an upload option to put the article into the Web site.
- Too many pub types can be really overwhelming. There needs to be a way to show only relevant pub types. If they are all in the same content type, I'm not sure how you will narrow down the list of publications that a user can enter.

These observations may not apply to this module, so feel free to ignore them. :)

Hi emmajane, Are you using

rjerome's picture

Hi emmajane,

Are you using the current incarnation (Non CCK) of Biblio?

Extended features

emmajane's picture

Unfortunately we are not. We had a weird combination of requirements that led me to decide that Biblio was not appropriate. For example:
- authors do not always have an account on the site, but should be tied to a user profile where possible. Solution: list authors as a CCK field with correct formatting (author last name and initial) and use user reference (second field) to connect related authors that do have accounts.
- upload PDF of presentation or article (I know Biblio lets you link off-site, but I couldn't find in the documentation how to upload the presentation as part of the Biblio node).
- highlight specific authors within a presentation (solution is messy, but it works: add bold tags to the field listing authors mentioned above)
- publications must be grouped by type of publication, but users shouldn't be overwhelmed by too many options (one data entry form with taxonomy for the "type" of pub; custom theming based on pub type to output correct format)
- Biblio seemed overkill for what this site wanted...they have less than 50 pubs listed (and only four types of pubs) and are trying to highlight the researcher profiles as much as the publication data.

What Kornel means is that

kvantomme's picture

What Kornel means is that the Journal article currently is set up to only have a title and a publication date. JS is used to hide all the other fields.

--

Check out more of my writing on our blog and my Twitter account.

JS degradable UI

kvantomme's picture

In case you are worrying about the JS requirement for CCK_Biblio to work: I've discussed this with Kornel and he'll be adding a fallback option.

--

Check out more of my writing on our blog and my Twitter account.

Handling non-deletion of fields?

Morbus Iff's picture

As someone interested in porting a custom node type into CCK, how are you handling user's deleting one of your custom fields? I have yet to come to terms with the idea that someone could destroy wide swaths of functionality in a CCK-based content type, simply by deleting an Important Field. How are you protecting them from doing that?

A feature request for CCK?

David Lesieur's picture

We always risk breaking a number of components when deleting a field. Should we add Biblio-specific safeguards? I don't think so. Do we need a new "administer field" permission for each field? That might be a valuable feature to add to CCK's Content Permissions module.

+1

scottrigby's picture

@David:

Do we need a new "administer field" permission for each field? That might be a valuable feature to add to CCK's Content Permissions module.

^^ this is a good idea.

it's interesting that when a module creates a custom content type, it can't be deleted - but the same isn't true for fields :/

The CCK Content Permission

Morbus Iff's picture

The CCK Content Permission module wouldn't help out at all - if I can't trust my users to leave required fields alone, I certainly can't trust them to set up CCK Permissions properly. (Note: I'm talking about users of my module, on sites that I have no control over.)

Mmmh, right, sometimes we

David Lesieur's picture

Mmmh, right, sometimes we can't trust the people who install modules and build sites... I was thinking on another level. I guess it would be interesting if CCK could distinguish module-required fields from custom fields. I'm not sure what is planned in Drupal 7 about this.

Handling non-deletion of fields?

rjerome's picture

That's a good point, and essentially why I pulled back from exclusively using taxonomy for the biblio keywords... If someone were to delete the keyword vocabulary (and yes it happened), then every single biblio entry which had a keyword is irrevocably affected.

Field-Level Locking as of cck 6.x-2.0-rc6

libsys-gdo's picture

This problem of programmatic field-level locking kept us from releasing some cck-based citation management code last year.

Recently, I noticed the following in the release notes of 6.x-2.0-rc6 (Aug '08):
- #289138 by dopry: Add support for 'locked' fields (for module-defined fields).

http://drupal.org/node/295736

If you look at something like content_field_overview_form(&$form_state, $type_name), you'll see things like:

if ($field['locked']) {
  $form[$name]['configure'] = array('#value' => t('Locked'));
  $form[$name]['remove'] = array();
  $form[$name]['#disabled_row'] = TRUE;
}

and this locked check extends to submit callback, validation hooks etc. There's an additional tiny int column in content_node_field called "locked". Set a field's value to "1" and the field is "locked."

I haven't dug too deeply into this feature, but it sure seems like a step in the right direction. Am I maybe missing something?

out of scope

kvantomme's picture

I think field management permissions per field for CCK is out of scope for Kornel's SoC. There is still plenty of work with porting more essential biblio features.

But for the sake of giving my 5 cents, you could consider changing the delete function into a remove function. That way as a site developer you can always resurrect content that was removed by accident. But that is a separate contrib module for CCK if you ask me and I'm not sure that it doesn't yet exist :D

--

Check out more of my writing on our blog and my Twitter account.

Hrm. That's probably a good

Morbus Iff's picture

Hrm. That's probably a good enough solution, actually - listen on form_alter for CCK field removals, check if it's one of your fields, throw up a big warning, and remove the actual "Confirm" button entirely.

Biblio Settings: Custom1 Label and default time

bekasu's picture

Coornail,
I just wanted to be sure that you plan to provide a way for us to override the Custom1 label as needed.
Also, defaulting the publication date to the current date is a bit distracting.. perhaps allowing an administrative override there or default it to blank.

Your implementation in the sandbox looks spot-on!

Stay focused.. you have many folks rooting for your success.

Bekasu

Conclusions?

David Lesieur's picture

Now that the SoC has completed, is there some kind of wrap-up report somewhere that we could check? Is there code that can be shared? Thanks.

Code

yes : and now ? subscribing

iko's picture

yes : and now ?

  • subscribing

subscribe

Stephen Winters's picture

subscribing

subscribing

Gerben Zaagsma's picture

subscribing

do not subscribe

greggles's picture

You can go to your account, click on Notifications tab, click on "add subscription" sub tab. Click on thread. Type in the name of the thread.

We'll make the UI easier "soon" but this is unnecessary.

CCK integration strategy

Aren Cambre's picture

I created issue 682044: Support fields (CCK) in D7 Bibliography Module to consolidate "support CCK fields" feature requests.

I think the biblio module should only do two things:

  1. A set of fields that satisfy biblio needs not achievable in native CCK fields or other well-supported, CCK-enabled modules.
  2. Logic that a site maintainer can use to manage biblio content types. It will either:
    • Create a content type, based on one of several templates, that meets the site owner's needs.
    • Modify an existing biblio content type through a guided interface.

The admin can also use standard CCK fields logic to maintain the content type.

Under this model, a lot of current Biblio functionality may be discarded in favor of Views and CCK fields, and the remainder would strictly be logic and constructs that manage bibliography-specific data.

Reviewing the above comments, I wonder about the single heavyweight field, or even 35 heavy CCK fields. I really question how deeply that will integrate with CCK fields and Views.