I've been working on creating a Drupal 7 port of the library module for the past week, and I've run into a wall that I can't seem to cross. I would like to get some collective eyeballs looking at this. The library module installs alright. The main library settings page works (note: the library actions settings page does not work at this point, but I'll work on that), triggers and action configuration appears to work, and you can add content types to the library.

However, after adding a content type to the library, a segmentation fault is generated if a user tries to add a new node of that type. No errors in the Drupal logs - just white screen of death. Cannot create a node - so no library items, and I can't test past that.

So - I need some fresh eyes looking at the code. Specifically as to why there's a segmentation fault on the node create form.

A couple of mentions. I have spent over 20 hours just to get the Drupal 7 version to this point. In an effort to simplify a bit, I've removed some functionality:
All CCK-dependent functionality has been removed. This means you may not select certain CCK fields to add to the library items list. Consider using a view instead of the library-provided list.
No "unique title check" functionality. If you would like this functionality, please look at the Unique Field module http://drupal.org/project/unique_field
No library-specific search. The search API changed in Drupal 7, and the added functionality of the existing library module-specific search is not that great since limiting a search to specific content types is something that can be done in another module or by using the views module with an exposed search field.
No upgrade from Patron module included, so please make sure to upgrade to the latest Drupal 6 version of library before upgrading to Drupal 7.

I'd like to include more extensive views integration than in the Drupal 6 version, but that's waiting on an official release of the Views module for Drupal 7.

The Drupal 7 version of library (as it is) is attached. grahl - I admit I'm really hoping you can help out on this one.

CommentFileSizeAuthor
#13 973574-patchset.zip37.48 KBgrahl
library.zip28.36 KBjastraat

Comments

jastraat’s picture

jastraat commented

Let me emphasize that the attached module DOES NOT actually work. I'm posting it to get some other folks involved in debugging.

Some more hints for developers out there - the code executed at least through line 170 in the form_alter function for the node edit form. And through at least to the return statement of the sub-form of library items: _library_item_form

(I know this because I found and corrected PHP bugs in those 2 places.)

So - the error causing the seg fault has to be after that.

tutumlum’s picture

tutumlum commented

Subscribing..

grahl’s picture

grahl
he/him
Location Zürich
commented

After getting my thesis work out of the way I'm now trying to familiarize myself with the D7 API changes. I'm not as familiar with FormAPI as I'd like to be (either 6 or 7), so the things I discovered until now might be stating the obvious a bit:

The primary error seems to occur when calling drupal_render($form) in the theming function library_items_field. When commenting out that theming function the form gets displayed. Also, when one leaves it in place commenting out drupal_render($form), as mentioned above, the page loads.

I have not yet been able to isolate which particular component is structured in such a way as to break drupal_render this badly, though it does not seem any specific element that is added to the fieldset structure ($key for all form elements should probably not return "form" either). I'm still poking at this, but I probably need to read up on form processing first.

This is possibly related: http://drupal.org/node/1067612

jastraat’s picture

jastraat commented

Hey grahl,
I did eventually figure out that the seg fault was related to the theme function. Since that was primarily just for display, I commented it out to try to get the form working otherwise. Another 8 hours and no luck. Before the git migration, I committed what I had of the Drupal 7 (totally not working in any way, shape, or form) to a new branch.

krazykellie’s picture

krazykellie commented

Hey All,

Is there any update of the Drupal 7 integration?

jastraat’s picture

jastraat commented

I'm afraid I don't have more time to spend on continuing to work on an upgrade - especially since the last client I had who was using it is moving to a different solution. A few months ago, I posted that I was seeking a new maintainer. With the new modules available since this one was originally released, you can accomplish the same functionality using a combination of other modules although it wouldn't be a self-contained, packaged solution.

krazykellie’s picture

krazykellie commented

Do you have any suggestions for the checkin/checkout? I know I can use CCK to define the fields and feeds to import the records, but I am still not sure on the checkin/checkout. I've tried several other modules such as MERCI and aggreatvations(?) but don't serve the purpose I needed. I'm opening to any suggestions.

jastraat’s picture

jastraat commented

So - CCK in Drupal 6. If you were going to do this in Drupal 7 though, you could just use the core fields. (That move is part of what made the upgrade of this module challenging.)

A couple of ideas for how to manage the availability of resources:

Simplest: Flag module
The flag module in Drupal 7 allows administrators to separate "flag" permissions from "unflag" permissions and you can have global flags. Flag integrates nicely with views and even allows for ajax flag links within views. AND it offers the flag actions module, so if you want trigger an e-mail when a user checks out an item, you don't even need to install a module like rules.

So - create a global flag for availability. Apply it to content types that may be checked out.
Flag link text = "Check out"
Unflag link text = "Check in"

You can then set it so that general users may flag items as checked out, but only library administrators can unflag them to check the items back in.

Create the appropriate views - maybe a filter based on whether or not an item is "flagged" (e.g. checked out)

If your case is slightly more complex => Rules and possibly Rules link
With rules, you can schedule a rule set to execute and send overdue notices based on a date field. (Might even be able to get the flagged datetime, but I haven't tried this in Drupal 7.) Since rules allows for if/else kinda statements, the overdue date could even be different by role. If you want to have a log of "check-outs", then you may want to have a content type called something like "record" with nodereference/userreference fields (http://drupal.org/project/references) and a rule that triggers when someone flags a node to create a new "record" node with information about who flagged what and when.

Need to allow people to checkout items for other people? Reverse the order. Use something like http://drupal.org/project/nodereference_url and have a rule that flags the library item node as unavailable when a checkout record associated with that item is created. Add another rule to unflag the node when a new check-in record is created.

If you need to allow users to check back in anything that they have checked out, you'll probably need to use something other than flag, but it turns out there may be another module for that: http://drupal.org/project/rules_link

No PHP required.

Want to be able to check out in bulk? http://drupal.org/project/views_bulk_operations (also works with rules)

krazykellie’s picture

krazykellie commented

Thanks!

I'll work on this!

Anonymous’s picture

Anonymous (not verified) commented

I was so close to that solution, I never thought to just remove the flag and have it as a separate record. I had the flag attached right to the content-item. Then I was stuck with no record once the item was flagged. I suppose you could also do this with a reservation system, and have another content-item as a 'reserved-record'.

Would that work?

I really liked this particular module, because it was an all in one solution. It also integrated really well, I didn't have to write hooks etc.

jastraat’s picture

jastraat commented

If you go that route, I'd suggest keeping a flag for available/unavailable on the checkout items and just use a separate content type for maintaining a record of transactions. You could use rules to create a new record node each time someone flags or unflags. You'd need some type of access control module to restrict view access to records if they are nodes, but you could let each user see their own history with http://drupal.org/project/nodeaccess_userreference + views. (The advantage to using a node for storing these records is that all the views plugins will already exist. Ideally a record would be it's own entity type with it's own view plugins, but then you get into writing a new library module.)

Another module you might consider for logging activity is heartbeat. I haven't used it myself, but it apparently logs user activity and can tie in with both rules and flag.

daengo’s picture

daengo commented

One thing that I hope you all consider for a Drupal 7 port is some sort of 'shopping cart' style workflow. That way when a user/patron shows up to the circulation desk with 10-20 items, they can be scanned one by one and checked out in one transaction with a final submit button. Correct me if I'm wrong but I could see anyway to set up the existing system without going to each item's node and clicking the button to check it in or out.

grahl’s picture

grahl
he/him
Location Zürich
commented
StatusFileSize
new 973574-patchset.zip37.48 KB

Attached is a set of patches that get the 7.x-1.x branch into a usable state. I'm working towards finalizing this in the coming weeks, any feedback on those patches would be much appreciated. With these patches it's possible to add/edit library items, check in and out (w/ patron autocomplete) see the history and use the administration pages. In depth testing has not been done.

Adding more than one library item to a node still needs work, though adding is possible, also I'm not certain if the unique barcode value is respected properly.

Minor issues I know about are:
* $action is undefined in library_transaction_form_validate, see line 212-129 in library.pages
* Notice: Array to string conversion in theme_library_admin_new_action() (line 35 of library.theme.inc).
* Warning: array_merge(): Argument #1 is not an array in _form_set_class() admin/config/workflow/library/duedates
* library_node_form_submit is still commented out
* Notice: Undefined index: patron_uid_set in library_transaction_form_validate() (line 145 of library.pages.inc).

I haven't tested profile support yet since my test site did not have migrated profile fields.

I've also pushed the repo here: https://github.com/grahl/library

jastraat’s picture

jastraat commented

grahl,
I just gave you commit access to the library project. (At least I hope that worked.) In case you'd like to commit your D7 patches here :)

grahl’s picture

grahl
he/him
Location Zürich
commented
Assigned: Unassigned » grahl
Priority: Normal » Major

Hi jastraat

Thank you for granting me access to the project! I was able to successfully push the branch. Hopefully I'll have the rest done by next weekend, so I'm taking ownership of the issue and will document my progress here.

grahl’s picture

grahl
he/him
Location Zürich
commented
Status: Needs work » Needs review

Taking care of the remaining issues took longer than expected, however, things work now. I have fixed numerous smaller issues and have tested all general functions apart from overdue mailings and the behaviour is as expected. Any feedback regarding this state would be very helpful.

There is one remaining problem I know of which is that the add new action form does not submit correctly, though the forms and form theming could probably be improved upon.

@Jastraat: Do you think it would be acceptable to create a 7.x-alpha1 release now? Also, could you please enable a 7.x release in the issue tracker so I can file the issue mentioned above there? Thanks for your help!

Greetings from DrupalCon

nimzie’s picture

nimzie commented

what ever happened to this project? is there an alpha release around?

grahl’s picture

grahl
he/him
Location Zürich
commented
Version: 6.x-2.x-dev » 7.x-1.x-dev
Status: Needs review » Closed (fixed)

I have fixed the remaining issue and created an alpha1 to simplify use, I will continue to work on patches for this branch since I'm finally able to use it in a production setting.

I hope to add new features, too, but cannot promise that.

jastraat’s picture

jastraat commented

@grahl - Awesome!

daengo’s picture

daengo commented

cool!
Are there still plans to have cart checkouts?

grahl’s picture

grahl
he/him
Location Zürich
commented

@jastraat Thanks :-)

@daengo I hope to get that done, too, in a reasonable time-frame now. I will update #1286518 as soon as I have something minimally viable to get feedback if the process solves the problem for most users (the interaction is a bit counter-intuitive in terms of choosing actions for items and vice versa).