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

Ben Wilson dausha at gmail.com
Tue Sep 19 19:14:54 CDT 2006

On 9/19/06, Crisses <crisses at kinhost.org> wrote:
> 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.
> 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).  How do you handle coupons or discounts, product
> options, etc?  How well does it handle various payment processors or
> PayPal?  How do you deal with shipping info, customer names, shipping
> prices, etc?  Or do you allow PayPal to handle something like that?
> 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.
> 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.

It looks like wfCart is the middle part. The "first" part is the
product (page). The "last" part is the payment. I'm probably stating
the obvious. But, the key variables that class needs aren't hard to
produce.[1] For example, the $code variable could be the $pagename.
The $info variable is that page's title. The price is an additional
page variable.[2] Quantity is user defined. It appears that wfCart
stores all cart data in a session variable.[3]

I believe having price as a page variable allows you to create a
pagelist template that includes the price, although that goes a bit
beyond my recollection. With pagelists and searchlists, you have the
ability to list multiple products and allow the customer to view the
product from that list.

You'll need a function to verify the items and prices, handle any
discounts, total the order and feed to the final page. I assume FAST
Data is working on that. I think you'll also want an order page to
track the placed order; as opposed to just sending an email to both
customer and site-admin. Perhaps Customer/JuanDoe-000001, or
Orders/JuanDoe-000001 (or even
Order/0a3a4ce1f7045fc716d3e8243683d772)?[4] With this, you could use
TellAFriend to send the email to both customer and customer service
(TellAFriend validates email addresses before sending). Of course, you
may want to embed more information on your customers (e.g. their email
address) as a page variable on their page as I suggest for price in a
previous paragraph.

The read permission would be restricted to customer Juan Doe and set
at time of page creation. The edit permission would be the customer
service group. Perhaps before you process the order, the permission
would be id:JuanDoe, @CustomerService, and when the order has been
processed, you'd set the permission to @CustomerService. This allows
the customer to change his order before processing. Naturally, he is
not editing the page the same as we would a wiki page; he is given
access to form controls via auth.[5]

The order would be a list of items:

(:order-item id=Computer/Commodore64 price=1500.00 quant=2:)
(:order-item id=Computer/Eniac price=1.50 quant=50:)

In the page header/footer you might have (:order-list:), which
processes the items. In GoogleMapAPI, I have the order-item
(specifically gma-point) built into an array of objects. The
order-list is processed after order-item, and pulls from the populated
item array.[6]

You've got me wishing I weren't in school. I would much rather try to
code some of this rather than write a paper.

Ben Wilson
"All this worldly wisdom was once the unamiable heresy of some wise man." HDT

[1]: http://www.webforcecart.com/manual.html
[2]: By page variable, I mean a key in the associative array generated
when you read a wiki page. For example, page text is $page['text'].
So, price would be $page['price'];
[3]: I'm used to storing the cart on the server and using a cart ID in
the session.
[4]: The last is an md5sum of Order/JuanDoe-000001 with a secret word.
This would help avoid somebody trying to slip into somebody else's
order. Obscurity on top of authorization control.
[5]: (:if auth edit:)Blah, blah, blah(:ifend:)
[6]: I am only comparing how I handle a similar problem in GMA---I
don't actually have what I'm describing, only a similar solution.

More information about the pmwiki-users mailing list