[Project] shopX 2.1

Quote from: nos at Dec 03, 2007, 06:14 PM

"Well, gee, Buddha ZAP - that wasn’t very helpful ..." (but understandable)

what I wanted is: to get working the cart and the checkout "for now", not even paypal and such things …

Why does it run for you? I did see a page some time ago that runs shopX too (but forgot its url). :-( so I dived into this.

Heh. Basically it works for me because I’ve written a lot of custom code to make it work. I’ve been trying to package it up as a resource to share with others, but I’ve just had way too heavy a workload.

The page you mentioned was one that Ryan had set up (with Susan’s help), but he’s now using FoxyCart instead.

I think the payment processing is tricky because there are multiple payment gateways with different requirements. For example to use PayPal a developer has to work out the API and then handle the IPN and tie that back into the shopping cart database. This is something that an end-user wouldn’t need to customize so it only needs to be written once.

Regarding the shopping cart: Personally I’m not sure how to persist session data across any page within MODx, and again, this is a problem that only needs to be solved once then people can reuse it without modification. Probably easier to save to a database instead of using session data, and use the web user ID to track the user.

So I think if a standard database table is chosen along with PayPal payment gateway and shopping cart modules that work with it, I think it would be a good start for a modular system, like I have advocated in the past.

I think that shipping calculation should be left up to the end user as there are far too many ways of doing it. Too many requirements. For example, in Calif. the sales tax depends on counties, and zip codes sometimes cross county boundaries.

Andy

Payment processing comes in various shapes and sizes, that’s for sure. Some systems take you away from your site to do all the processing on theirs and then return you, whereas others are just done via a connection from your site to the processor. And there are other ways of accepting payments, such as storing credit card info and processing it offline, printing out a form to send with a check or by fax, etc.

So yes there are a multitude of methods and that complicates things somewhat. But none of these is all that complicated on its own, which is more what I meant. I’ve set up SHOPx to process cards using Authorize.Net and also to store the credit card data to be processed offline, and neither of these was all that difficult.

For example, all I do to process cards via Authorize.Net is prepare the transaction info the way they want it, send it to them via curl, store it all in the database and then continue checkout depending upon the response code that they send back. It’s basically all in one eForm function and is probably less than 100 lines of code. This is the kind of thing that I think might be useful as part of an eCommerce toolkit, since for people who use Authorize.Net it’s essential but for those who don’t it would just be useless bloat to include it in their system.

I am still just using SESSION vars to store cart and order info, although lots of people have recommended that I use a database table instead. This is one of the things that I’d like to change, although it’s not really one of the most urgent. I’ve actually never had a problem with storing the info this way.

I agree that shipping and tax are complex and vary greatly among stores and locations, but if the system is going to be modular it needs to have hooks in the right places to be able to plug these in. I’ve always used rate tables for shipping in the past, for example, and they worked fine. But now a client wants live UPS calculation instead, which means that I need to rework that logic quite a bit (since UPS doesn’t always respond, doesn’t ship to all addresses, etc.).

I’ve also dealt with the California tax issues as well, and every time I’ve just created custom code (which is very efficient if you’re comfortable coding, but not an option for a lot of people).

I’ve been looking at Treasure Chest with some admiration in this respect. Not only because it’s a very elegant and useful system, but also because it’s got a clear and limited scope and doesn’t get bogged down in all of the zillions of possible eCommerce configurations. For people who want what it offers, it will be the porridge that Goldilocks chose.

Look at the principal issues at first. That is (at least): to (only) share a system
- to provide a cart and a checkout
- a (plugin?) to handle the cart values for the checkout
any other requirements have to succeed …

Here’s what I do:

• I use a module with parameter sharing to set some standard store configurations
• I create a template for products with TVs for different attributes and options
• I use Ditto to create catalog pages (and tvExplorer for product search pages)
• The product page template is the Add to Cart form
• I use a plugin for intercepting and processing posted values and managing the basket and order SESSION vars
• I use eForm with some Ajax inserts for the checkout form (multi-tabbed). These inserted divs recalculate order totals and other values based on what people enter into the checkout form. So tax and shipping can be determined by location, quantities can be changed, coupons applied, etc.
• I use eForm functions to sanitize data, process the payment, insert to the database, send emails, etc.
• And I use some snippets with a front-end manager login for displaying the orders to admins, sending follow-up emails, etc.

Some things I don’t do that others might want:

• Store temporary info in a database table
• Create user accounts for reviewing orders, etc. (I do allow for setting cookies for repeat orders)
• Deal with downloadable products
• Any sort of non-SSL gateway (where you are forwarded to their site for the actual purchase)
• Store products in a separate database table (much faster for large stores)
• Complex inventory management (other than in stock or out-of-stock)
• A whole lot of other things...

And much of what I do is hacked into the code. For example, if an option affects the price and weight of an item I don’t currently have a system in place to deal with that. What I’ve been doing is just coding that specific function into the plugin, which is just a dirty hack.