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

I am in the middle of creating a new product_type book for ZC 1.5. with the working title "bookx", so from here on "bookx" refers to my yet to be created new product type book. It will be for ZC version 1.5. only – I do not intend to adapt it to any lower ZC versions.

To get started I have downloaded the last version of the add-on which this thread was created for (the "moku" product type book, from here on "moku book") and since I didn't understand very well how it worked, I decided to start from scratch. This is the old plugin I looked at:

sammirah:

Do be forwarned it doesn't work too well with 1.5.0 but I have been able to use it seemlessly with 1.3.9h and earlier. 1.5.0 has it's own version of product book but it is seriously lacking. Maybe the developers can take this and figure out what is missing with the new version of zen cart.
http://www.atmospherebooks.com/test/ML_ZC1_3_8_EXTENDED_BOOK_TYPE_V_4_LANGS_ISS2.zip

Sammirah mentions a product_type book already provided for ZC 1.5. on which one could build, but I have been searching all over and I couldn't find anything.

Furthermore this ZC wiki post mentions a product_type book, but I couldn't find anything about that either. Seeing that the documentation says it's for ZC 1.2 it would probably too old anyway.

Even though I do not plan to build onto "moku book", I may try to provide an import function, so that data already entered for "moku book" doesn't have to be completely re-entered for use with "bookx". That way orders and other references to existing products wouldn't have to change. That's the theory, I don't know how well it will work :-)
However, since I do not currently use "moku book", it would be great if someone interested in this conversion feature could provide some Mysql data containing the tables added by "moku book". It really just needs one or two actual entries per table, so that I can see the table structure and the kind of data stored there.

Here's what I am planning for "bookx":

– the "product model" field will be used for ISBN / EAN

Additional data fields provided by "bookx":
– subtitle
– no. of pages
– printing (color)
– binding type
– size
– volume no. (for series)
– publishing date
– publisher
– imprint / sublabel
– series
– authors (multiple possible)
– genre (multiple possible)
– book condition

Of those, the following data items will be managed in a separate table and can be assigned to a product through a drop-down.
They will have the fields listed in (parentheses). "Language_specific" fields can be entered separately for as many languages as are installed in the shop.
– printing (language_specific_description, sort_order_for_dropdown)
– binding type (language_specific_description, sort_order_for_dropdown)
– book condition (language_specific_description, sort_order_for_dropdown)
– imprint / sublabel (language_specific_name, sort_order_for_dropdown, sublabel_image_for_shop)
– series (language_specific_name, sort_order_for_dropdown, sublabel_image_for_shop)
– genre (language_specific_description, sort_order_for_dropdown, genre_image_for_shop)
– publisher (language_specific_name, sort_order_for_dropdown, publisher_image_for_shop, language_specific_url, language_specific_description_text)
– authors (name, sort_order_for_dropdown, author_image_for_shop, language_specific_url, language_specific_description_text)

In the code of "moku book" I saw a field called "book type", but I don't understand what it is used for. I therefore do not plan to implement a "type" field for the "bookx" add-on. Furthermore, "moku book" uses a good number of "misc" fields and quite some "drop-down" fields, for which I also do not quite see what they are used for. Possibly they have something to do with searching, but whatever they do, there must be a more elegant way to achieve the same result :-)
If someone wants to comment on these extra data fields, please do.

I myself will be using this add-on for a single publisher with an online shop, so a bookstore may have different needs. For example there is no plan for a data field "book language". Let me know if this is needed for someone.

All data items can be set in the admin backend to appear in the product_listing and product_info view.

It would be great if there are volunteers for a (short!) beta-testing stage, so that the add-on has been tested by a few people before it is installed in online shops.

philou

Philou, I have been combing the internet for someone working on a book product type module for 1.5 for the past 2 hours. What a strange coincidence that you made this post just a few moments ago. I have a great need for this plugin, and would happily volunteer for some beta testing.

The site I'm building is a wholesale book site, and the primary requirements I need to meet are these:

-To be able to sort books by author (or select the letter that the author begins with & it display everything that matches)
-To be able to import all of the inventory from stone-edge(an inventory management software compatible with zen-cart) so that each field from stone-edge goes into the correct book product type field.

Do you think those two things would be achievable with the module you're working on?

Hi nealt900,

the search should be possible as I plan to implement search / filtering by genre / author / publisher etc.
The import should be doable as well, however I would first have to get an idea of how much work is needed to develop this before I can commit to implementing that, as an import from your inventory management add-on is a bit beyond what I would personally for my setup here :)
If you can upload an snippet of SQL somewhere with a table structure and 2-3 lines of data, I will have a look once I get to that part of the job. You can send me a message with an URL for the data.

Let's see how the whole thing progresses.
I am expect development to be a matter of weeks.

philou I am working on a bookstore web site for ebook reading and downloads. I will be a beta tester for your plugin.

Ok, work has progressed nicely but over the last three weeks I have been diverted to other projects. I hope to have something to test soon :)

Hi jkcollect,

do you need to covert existing products into "book type" or will you be entering everything as new products?
if you need them converted, will they be converted from "product type general" or are you using anoethr product type already?

thx,
p.

Hi all, I am a publisher and very interested in this thread. Please IM me if you need help or testers. I am using 1.5 Zen Cart and currently working on a new design.

Hi D4F,

development has progressed well, but it's lacking some work on the "catalog" side, i.e. filtering for "authors" or some other attributes. The display of product info for the "book" type is still very ugly at present, but that may be the smallest problem, since most users may customize the product info display anyway? It's also missing an instruction manual which covers at least the basics.

Hopefully in February it will be in a state where I could pass it on for some testing.

There is some very basic conversion of "normal" ZC products to the "book" type and back. I don't know if there are other "book" plugins currently in use, for which it would be nice to convert to this new book product type. That may be something for a future version.

philou,

I'm a bookseller looking at different cart solutions. If you're near a testing phase I'd love to take a look! If zen cart winds up being our best solution then I'd be happy to help out some too.

Hi Booker,

I hope to get back onto this project within the next two weeks – unfortunately (for this project :-) I have been submerged in another project over the past two months...
As I said above, the development on product type "book x" is actually quite advanced, but it needs some pulling together. For someone who is a developer and quite familiar with ZenCart it should be useable soon, for someone who needs to mainly interact with the module through the backend, it still needs more polishing.
I will make a post here as soon as I have something that can be beta tested by those who are currently developing a shop.

Best regards,
p.

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).