I am about to start a project to create a simple e-commerce site for selling tangible items via Paypal. My current plan is to do this with Zenphoto - root albums as product categories, sub-albums as items for sale, and images in those sub-albums as a half dozen product images, and a paypal button (with an option for "buy it now" or "add to cart" buttons, dynamically generated based on the product price stored in the database)
Why ZenPhoto? Mainly because it gets me 95% of the way there out of the box. Simple admin interface, a very narrow feature set that makes it easy for a non-geek to use, all of the pagination, themeing, search, image manipulation etc built in.
I already have the seed of a strategy for how to do this, but I am curious -- would this be useful to anybody else? If there is interest, I would welcome feature requests now (before I start), rather than building this site, releasing it, and then rolling requests back into it.
It will obviously be somewhat hacky - I need to add a "price" field for albums (=products), but not TOO hacky. I was debating whether to wait for a localization-ready version, so that I could just rename a field I don't need (say, "location") to "price".
If you are interested, reply with input, feature requests, etc. in this thread.
Thanks!
Zenphoto
Comments
Anyway, I think the best solution would be indeed a new field instead of using one of the metadata field. To avoid any possible conflicts it's better to keep it separate. Good would be if one could set a specific album (and its subalbums) to "shop" so that you could run a normal site and a shop in one installation.
PS: Do you know that your site is broken?
I do like the idea of limiting the shop to a single album (and its sub-albums). Any thoughts on the best way to indicate this to the theme? I suppose the shop's config file could just have a spot for "shop album ID", but that ID isn't exposed in the admin album page. I could modify the album schema to allow for a "is_shop" value I guess...
PS: thanks for the reminder and gentle social pressure.
You mentioned a cart, I don't have experience with that, but I guess that would be db independed sesssion or cookie based.
The more I looked at how I would actually implement it, it seemed like it would be a pretty significant hack, and I wasn't really excited about maintaining a hack through future ZP releases. I would definitely be up for it if there were a plugin API. For my immediate needs, I am actually looking at doing my store as a plugin to the Chyrp blog engine, which has a framework that allows you to add plugins as well as create new post types. It is not perfect, but at least it carries forward better than hacking the ZP core files.