[pmwiki-users] shopping cart cookbook - oscommerce vs PmWiki

Marc Cooper gmane at auxbuss.com
Wed Sep 20 06:52:37 CDT 2006

Crisses said...
> On Sep 19, 2006, at 5:35 PM, Marc Cooper wrote:
> > Crisses said...
> >> (oscommerce vs PmWiki)
> >> Round 1: Fight!
> >>
> >> I had my first experience with oscommerce and MAN am I pissed.  I
> >> ranted about it in my blog if anyone is interested (and YES, it
> >> mentions PmWiki) at http://www.eclectictech.net/etblog/ (right now
> >> it's the 2nd entry since I put a delicious (food!) recipe in last
> >> night).
> >
> > Shopping baskets - I deign to call them carts - are fairly easy in
> > PmWiki. I based one on the freely available wfcart class and it only
> > took a couple of hours, including checkout and sidebar "module".
> >
> > Here's my checkout page.
> >
> >   (:DisplayCheckout updatelabel='Update' :)
> >   (:if ! equal {$CartItemCount} "0" :) (:ClearCart:)
> >
> > I do things this way:
> >
> >   (:AddProduct prodcode=BLA price=45.67 desc='Blah product' label='Buy
> > BLA':)
> >   (:RemoveProduct prodcode=BLA label='Remove BLA' :)
> >   (:EditQuantity prodcode=BLA :)
> >
> >   (:DisplayCart:)
> >
> > Cart total: £{$CartTotal}
> > Cart items: {$CartItemCount}
> > Cart quantity: {$CartQuantity}
> >
> > Kinda makes the equivalent in OScommerce, Joommla!, etc, look a little
> > over engineered :-o
> I'm more than willing to consider something such as WebForce Cart
> (http://www.webforcecart.com/ for anyone who can't find it in
> Google), but I'm pretty sure your example is leaving things out.  I
> don't see how you're plugging WFCart into PmWiki in your snippets.


:-) I started with wfcart because it meant not having to write it 
myself. It's also a class, with all the advantages of encapsulation - 
not enough OO in PmWiki recipes, imo.

In this case, OO is useful, because extending any base recipe is going 
to be the norm in most cases. In addition, bloating a recipe with "all 
things for all men" is not a very good direction for the recipe to take, 
again, imo.

BTW, you immediately have to consider whether wfcart meets your 
requirements, because it uses sessions for state info. Some folk will 
want this info to persist, so it's design time. As it happens, for folk 
logged in, I do persist this info, but I would never force it.

Similarly, I don't force the "create account" process on folk 
immediately prior to ordering - I get them on the way back :-) When 
designing a "cart", you need to provide for these requirements. It's 
really hard to retrofit this kind of process change - if that's what it 
is - on a monolithic monster.

> If you could write up a full explanation of blending WFCart into
> PmWiki as a Cookbook recipe, I'd greatly appreciate it (as would
> others, I'm sure).

Yup, I started out with good intentions, but - like most businesses - 
the pricing, discounts, stock levels, blah are driven from a database, 
and this is not the PmWiki way.

My design comprises many blobs - so replacement is easy, say, when not 
using a db - but any base recipe is unlikely to work out of the box for 

> How do you handle coupons or discounts

That's a simple checkout function. In my case, in addition to these, I 
automatically apply discounts on the displayed page to "members" that 
have made previous purchases, so discounting is fairly complex.

Note that - in the code in the OP - I use something like

  (:AddProduct prodcode=BLA price=45.67 desc='Blah product' label='Buy 

Most of the values are dynamically generated from the (in my case) 
database (accessed by the recipe). That way prices only need to be 
changed in one location. Once you start dealing in multiple currencies 
and the vagaries of VAT, you don't want to be embedding these on every 

However, my view is that everyone will want different discount rules - 
anyone that has worked with a "marketing" department will know that 
these change on an hourly basis - so trying to configure a "one size 
fits all" discount matrix will never work and be more of a headache than 
a benefit. With PmWiki, this is so far from being a problem it can't but 
fail to make you smile.

> product options, etc?  How well does it handle various payment processors or
> PayPal?

PayPal? It's not on my map. Payment processes need to be "pluggable", 
since they all behave differently. This isn't a problem, even for folk 
using more than one payment route.

Slightly trickier, is handling the banks' callbacks.

> How do you deal with shipping info, customer names, shipping
> prices, etc?

All that info is usually collected before transferring to the bank. If 
not - and I do this with one-click ordering [dear Amazon, we've been 
doing this long before your (US-only) patent] - then the info will be 
provided by the bank's transaction confirmation email/logs.

You also get this info in the bank's callback. What I do is to format 
address labels, invoices and so on based on the callback info. In that 
way, the whole order process and the accounts are done automatically.

> Or do you allow PayPal to handle something like that?

I wouldn't touch PayPal with a bargepole, even with gloves on and a peg 
on my nose.

> Maybe it makes OSC etc. seem over-engineered, but there are options
> that people take for granted in shopping carts and I don't see an
> example of it in WFCart's example or in yours.

What I was trying to convey in my OP is how simple it is to build 
additional functionality behind the scenes and yet provide a very 
simple, yet flexible presentation via PmWiki.

The OSCs, VirtueMart - what an awful name! - and so on, are monolithic 
jungles that are monsters to mould into what you are likely to require. 
I have used both and I'm glad to be out of there.

What Patrick's superb design permits is building the whole "cart thing" 
in discrete chunks that are easy to maintain and easy to make do your 
bidding. The central problem with the uber-carts is lack of flexibility.

I've spent days, in the past, trying to add little bits of this and that 
to VirtueMart in Joomla. For the most part, it's pretty trivial using 
PmWiki - and I really don't know PmWiki very well.
> I also see from the 1 page documentation that WFCart out of the box
> requires you to write extensions to it for volume discounts and for
> item options.  That doesn't mean we can't consider it, since it's GPL
> and obviously simple to use from your example.



More information about the pmwiki-users mailing list