Robert Heller

Ok, you mean in the ‘brief’ item detail. The subject is listed in the ‘long’ form. Normally, the item_list short code lists the current page worth of items using a ‘brief’ level of detail: the item thumb, the title, the author, the call number, and the checkout/hold status, with a request button (if a user with a parton id is logged in). The title is a link to a page with just that item, displayed with a ‘long’ level of detail — basically everything about the item.

To change what is displayed as ‘brief’ you would have to change the item_detail short code.

If the search string was empty (effectivly wildcarded), then the ‘search’ results would be all items by category. You would just need to replace the generated search form with a manualy crafted one that used a ‘hidden’ input tag instead of the search string input tag.

OTOH, most decent shopping cart / e-commerce systems include a ‘product database’ that would be structured by category, and probably other criteria (eg something like author, year, publisher, etc.). Which would make the web librarian plugin redundant.

I don’t think the web librarian really makes sense in an E-Commerce context.

Don’t suppose you have some of that clever stylesheet code around??? 🙂

Nope. I barely understand stylesheets myself. Misquoting Dr. “Bones” McCoy: “Damit Jim, I’m a programmer, not a web designer!”.

This could probably be handled with clever stylesheet code, much in the same way the WP backend dashboard is handled.

*Normally* the Call Number would imply a ‘location’, but if you really have multiple branch locations, you might do better with a more full-featured ILS, like Evergreen/Open ILS.

Adding more columns means changing the low-level database structure. This is non-trivial. It is doable, but you are on your own. OTOH, you could create psudeo ‘columns’ with keyword value pairs in the Description column.

Adding more ‘fields’ for the author is also tricky. Nothing is stopping you from joining multiple authors with ‘and’ though.

It *sounds* like you might do better with something like Evergreen/Open ILS — Web Librarian is a *simple* system, meant for small libraries with *simple* needs.

Well, you have somewhat gone off the deep end here. *Normally* each patron has their own login / username and places holds under their own patron ID. When they check out the item, the hold is ‘converted’ to a ‘checkout’ — the hold record is deleted and a checkout record is created. When the patron returns the item, the librarian checks the item in and the checkout record is deleted. There isn’t really a way for the librarian to clear holds, only a way for patrons to cancel holds. (I guess there probably should be a way for the librarian to clear holds as part of admistrative clean up procedures.) Question: when the librarian hands out items at your meetings, does the librarian do a checkout? Do your club members actually have their own patron records?

It seems like you have added *unecessary* complications with this single generic “subscriber” user — *I* think you would be far better off simply providing a way for each club member to create their own ‘user’ and associate it with their patron id. They don’t *have* to ever deal with the back end (since the *librarian* can make the WP user <=> patron id association). This has the *added* advantage that the librarian will know who requested which book.

Since the Web Librarian is written to use WP localization, it *should* be possible for it to use different localizations. The *database* itself is not going to be localized though. I am not sure what you mean by having the site available in more than one language — do you mean having the prompts and labels in more than one language *at the same time* or just using one language at a time, but switching between them? The latter is what I think is possible (just a matter of switching the ‘locale’). The Web Librarian has already be localized for Italian, in addition to American English.

This something I would need to look at. There are possible secutity issues (I think). I don’t know if there is an existing plugins to allow access to a user’s profile on the front end. If there is such a plugin it could be a starting point.