Creating an add-on "product type book" for ZC 1.5

Hi Philou,

I'm in the same position as Booker and interested as well. I'm not a developer but I have played around a bit with Zen Cart and I might help with localisation (to Dutch) and with testing.

The new product type is now working pretty well. I am still testing the installation /removal script and putting together a bit of sample data. I expect to have something to beta test within the next week.

p.

I know it sucks to document, but I need to know how to add in new filter variables and filter items that you seem to be working with so any insight you can give on these would be very helpful.

I have just submitted a first version of BookX(0.9 beta) for review by the ZC team here. Apparently new add-ons are reviewed every couple of days, so I will post here, if/when it is approved. In the meantime the files are also available on the sourceforge project page for BookX: http://sourceforge.net/p/zencartbookx

This module is already running pretty well on my development system, but surely there will be things to fix before making this a stable release. If you do decide to check out the beta version, just make backups of database and ZC shop files to be safe!

A typo in the install script prevents any changes to layout flags in Admin –> Webshop -> Product types -> Bookx -> Edit layout.
It will be fixed in the next update to the beta, but since it really restricts any testing of the plugin, there is an SQL patch you can download right now from sourceforge which will fix it. http://sourceforge.net/p/zencartbookx/files

Hi there. I noticed your first post in November when I was about to try getting moku book working on 1.5. Now that 0.9 has been released and I've had a little bit of time to play with it, here are some of my notes.

Bookx specific stuff in admin's preview_info page is missing. Also the meta tags stuff seems to be a work in progress? There could be some book specific stuff added there too.

The biggest complaint I had was the model number being used as the ISBN. My customer really needed them separate. So I've made all the necessary changes and included a git patch file for your review. It adds a new field to product_bookx_extra, adds the field to the product detail pages in the catalog and admin sides, and decouples the model number from the isbn. They are be independently used/displayed.

I'll keep you informed if there's anything else me or my customer find. If you need to contact me via email please use the address in the patch file.

Thanks.

Hi Noobish,

thanks for the suggestions. You are correct the Admin "preview_info" does not display the bookx specific fields yet, that will be resolved. So will be the meta tags.

Can you tell us a bit more about the model number issue, since I am trying to figure out if this should be something to be incorporated in the plugin or if this is too specific to your setup. The reason I used the model no. as ISBN is that it is in fact the "model no." of a book. The ZC model no. is used in other sections of the shop, so I thought this was the smartest way to do it.

I am guessing that your client has some kind of internal product id they use to identify a book? If this is the case, would it not be a more useable approach for a wide range of BookX users to keep the ISBN in the "model no." field and offer your additional field as some kind of "internal id"?

Thanks,
p.

Yes, they use a different internal ID number. As do many shops. Amazon, for example, has an internal model number for their inventory, etc. They also list 2 ISBN numbers, both a 10 digit and EAN-13 digit. They may even print a separate UPC number, I'm not sure. Point is, there's lots of numbers to assign to the model number field that are independent of the ISBN. The ISBN number is useless in the model number field in my customer's case, since the model number is printed on packing slips, receipts, etc. That's what they need to pull inventory with. The ISBN is there mainly for search engines to index.

I would think that the widest usability case would be to decouple the fields, and allow the user to type whatever they want in the model number field. If they want it to be the ISBN, they can put it in there, as well as in the separate ISBN field, or leave the ISBN blank and hidden. It can be up to them. But this way they have the choice.

Ok, an extra "custom field" can't hurt in any case. If such a field exists, then every admin can use it as they want. Admins like yourself could indeed use the custom field to hold the ISBN and use the model field for something else, if they like.

The big question for me is now, what the default behavior should be. The "model no." is used in the order class, the shopping cart class, in the default search and some other places as a superficial search in the code just revealed. Staying in the ZenCart logic and looking at it from a customer perspective, I still feel the use of "model no." in ZC matches the role of the ISBN. If customers are looking for or identifying books by anything else than the title, wouldn't they most likely use the ISBN and not some internal number of amazon or whomever? ISBN10 and ISBN13 can be derived from each other, so that should not be a factor.

It is my impression that by placing the ISBN in a different field, we are going against the internal ZC logic, which doesn't seem like a good idea.

Maybe some other (prospective) users of the BookX plugin want to comment on this?

I haven't had the time yet to take a look at the plugin, unfortunately. But about the ISBN:
- not all books have an ISBN!
- ISBN's may be printed wrong in the book
- some books have different cover-editions (but the same ISBN's)
So I think one needs an internal product or model number and a separate ISBN-field (useful extras: the handling of hyphens and a check on the number).