[UPHPU] I need shopping cart advice

[Mac Newbold]

Today at 3:08pm, David Boucha said:

>> A custom cart may not be as hard as you think, and may not be a bad idea
>> since you've pretty much got custom products. That way you'd also be able
>> to make a step-by-step Candle Configurator (tm) that walks them through
>> the ordering process, explaining the wax and wick/no wick options perhaps.
>> Then it would only drop fully configured candles in the cart, and they
>> could manage things like quantity from there.
>> 
>> It sounds like a fun project. Good luck with it, and if you happen to find
>> a good cart system that works out really well, let us know what it is.
>> Most I've found are so hard to customize that it takes longer to make them
>> look the way you want and do what you want than it would have to build
>> your own. So we generally end up building our own... :)

> Do you keep some code around that you share between shopping cart
> projects? Or do you code them up from scratch every time?

We reuse code from other projects as a starting point. We'll pick our most 
similar one to what the new one needs, copy it's files, and customize it 
to what they need. Some we've set up to be more self-contained than 
others, but the overhead of making one, great, really general-purpose, 
shopping cart system that we can just drop in is way bigger than the 
savings in time on each one we set up. Almost every cart we do needs 
something new that we haven't done before, and they at least need some 
different combination of things.

By the time you factor in all the variables, there are a ton of things 
that change from one cart to another. To take some examples from a variety 
of carts we've done, here are some things that change:

- Shipping/Handling pricing structures (percentage, flat, per-item, 
weight-based, free, multi-option, freight, special case (AK/HI extra) or a 
mixture of several)

- Sales tax structure (most are utah only, but some have to charge tax 
everywhere, and change rates by individual zip codes across USA, but not 
at all internationally)

- Product options (none, same-priced options, different-priced options - 
multiple options allowed, or mutually exclusive options - same options on 
many products, or different options on each)

- Discount plans (coupon codes, bulk discounts, package discounts, 
shipping discounts, percent discounts, flat dollar amount discounts, 
limits on discounts, multiple discounts allowed and how to apply them)

- Product list (some have a limited and enumerated product list, others 
have custom products and a practically unlimited product set with new 
things being created on the fly. Configuring custom products, etc. Some 
products are really services, and have different magic about them.)

- Sales Rep/Expert/Advanced mode (some carts need to let insiders enter 
orders using a "pro" mode that gives them choices or options or other 
entry methods (like direct by SKU) that aren't avaiable to customers)

- Payment (paypal, credit card, authorize.net, some other processor, 
live/online processing or delayed/manual/offline processing)

- Order processing (usually send an email or two, often save in a database 
and provide order administration area, sometimes integrate with internal 
systems, sometimes deliver automatically, sometimes put order in a queue 
for handling, sometimes generate printable receipts/invoices or other 
paperwork, etc.)

- Shipping/Delivery/Pickup (some send it ASAP, some need estimates of ship 
dates, some need to let the user schedule a delivery/pickup date and/or 
time with a calendar. Some have time-sensitive ordering, like a cafe that 
takes online lunch orders but has deadlines for ordering same-day meals.)

I don't think we've yet had two carts out of probably at least 20 or 30 
that have the same answers to all those questions, even on the simplest 
ones. So if you can imaging trying to build one reusable cart system that 
handles all of that, it would be a huge mess and nearly impossible to 
build and maintain. So we reuse where we can, but make each one custom to 
what is required.

The last time I recall building one almost entirely from scratch was a 
moderately complicated one that needed paypal, an enumerated product list 
with some different-priced options and some same-priced options, and a 
mini-gallery of product photos for each product. The whole project from 
start to finish took 25-30 hours, including implementing a simple graphic 
design and a dynamic php-generated CSS style sheet so they could change 
the entire color scheme with the seasons, and loading and processing 
hundreds of product photos. I don't know how that compares, but to me it 
felt pretty reasonable considering all the functionality and stuff. The 
cart itself was probably close to half of the total time, 12-15 hours.

If someone wants a cart that works almost exactly like an out-of-the-box 
cart system, then it's probably a savings to go that way, especially if 
the parts of the cart that you need are pretty complex (in other words, 
hard to duplicate/reimplment).

If you need to depart very far from the normal default configuration, it 
varies how difficult and time consuming that is, but some carts take a ton 
of work even to put a new face on them that matches the rest of your web 
site, even with a relatively simple design.

It's crazy, but over the years we haven't once found a way to make it a 
win to use a ready-made shopping cart.

Mac

--
Mac Newbold		MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com	http://www.macnewbold.com/