Summary:A proposal for how to develop a shopping-cart add-on for PmWiki.
Version: 0.0.0
Prerequisites: reading
Status: pre-alpha
Maintainer: XES
Categories: Payment

Questions answered by this recipe

This section is optional; use it to indicate the types of questions (if any) this recipe is intended to answer.

How can we build a shopping cart into PmWiki.


Discussing a shopping cart -- from philosophy to features.


I've looked at shopping carts. I see some issues to bring up about HOW people think about shopping carts.

Some programs view carts and items strictly as data. You need to have data fields available for every item and every option, the fields are filled up or null (empty) as appropriate, but if you can't conceptualize how you want your data stored, you can't have an inventory. Thus it requires a database-planning mentality to create the shopping cart. This is very useful for professionals trained to view attributes as categorizable data, across a wide spread of objects. It's also very useful for very large merchants with custom inventory programs that are tied in to their custom website ordering systems written by a team of 50 programmers.

I feel it's not as helpful for small merchants or people with a wide variety of very different products or services. I propose reconsidering this from a non-programmers' point of view for a moment.


In all cases "product" can be interchanged with "service".

A merchant sometimes groups like items into broad product categories (Clothes vs Jewelry.).

These categories may or may not contain sub-categories (Clothes->Shirts, Jewelry->Bracelets).

A merchant often groups similar items into a single "product" with different "features" (skirts of the same design, but different colors).

In addition to single products having different features or attributes, each feature or attribute of the product may alter its price, shipping weight, availability/stock, discount/coupon eligibility, etc.


I want to address whether anyone would find a "Mall" mentality helpful. Since Wikis are collaborative platforms, would it be helpful to allow multiple merchants on a single site? Should each merchant have their own "field" in the wiki? Separated by groups? Or allowed to add items for different merchants on a single page?

Information Storage/Retrieval

ZAP can be used to store data on pages. It can certainly work with a database-oriented shopping cart philosophy, and at that point only needs demonstration of usability and bugs worked out.

One thing that would be helpful is a customized ZAP textarea that you can cut/paste an encrypted PayPal buy now button code into, and easily create a database of buttons for a variety of items. ZAP would have to change the quotes on the button and add it to a product button markup for the site?

If I understand what you are saying, ZAP can already do this using field replacements and hidden fields. Use {Field} in the paypal button code and the value of that "Field" will be automatically inserted into the button code field. The button can then be retrieved into the page as a page variable and it will display as desired.

Programming philosophy

I'm proposing that extensible classes be built (yes, object-oriented -- yes, I'm willing to do that) for dealing with items and behavior of items in the shopping carts. The core shopping cart module will have to be extended with payment processing modules, which should plug in in a: ShoppingCart$PaymentModule class manner. The same could go for shipping (ShoppingCart$ShippingModule class). For example a shipping module would receive address data, number of items & weight if applicable ($shipping_cost = ShoppingCart$ShippingModule->ShippingPrice($address,$postalcode, $numitems, $weight); ). There could be many shipping modules or only one -- using the variable in the class call would allow flexibility and the admin can choose whether to allow one or more shipping modules. The shipping class(es) would then deal with whatever shipping processor handing over the data for calculation -- or internally determine that 8 items at a flat rate per-item = amount and return shipping amount to the core package.

ShoppingCart$PaymentModule() same type of deal -- the form of payment can be defined in config.php or chosen from a list (array $PaymentModulesAvailable ? defined in config.php or a drop-down of available payment options defined by a merchant when they set up their store? ) by the user.

Markup proposal

I'm proposing a markup philosophy that blends in with the philosophy of item-centered logic rather than data-centered logic. I'm much more than willing to hear arguments for/against this idea. My proposal can be seen at cart-0.2.phpΔ -- feel free to just browse it or to download it. It's actual PHP just to set up a mockup of the resulting array right now, with the markup in the comments.

The idea is this allows the cart to call up a number of class methods (i.e. functions) to act on the data, and allows working through the items in an order recursively through the array. If ZAP can store the arrays, I'd be interested in hearing about it.


What types of hooks would the program require? How should they be programmed.


I have some minimum requirements, and I want to hear what features other people want

  • discounts
  • coupons
  • gift certificates
  • shipping options
  • payment options
  • I prefer software download features be included -- but security needs to be addressed
  • would we want optional inventory handling? This may be handled by ZAP, but should tie in to the cart so it reports "out of stock" or "in stock"


I want a store that can handle building and processing a one-shot form that builds a preliminary estimate for things from creating a website through building a house -- with the ability to add tons of features to the one cart item, have everything added up, and if I have a "special offer" discount in place, handle the discount. In this case it would never send it to a shopping cart -> spit out the answer as an estimated cost for the customer.

I want the ability to do the same thing with a custom jewelry order, allowing the customer to specify the types of beads they want, the type of clasp, the pendant, etc. and then to accept the payment for the order.

I want it to handle "regular" inventory products such as static items like a tee-shirt or jeans.


Release Notes

27 September 2006

If the recipe has multiple releases, then release notes can be placed here. Note that it's often easier for people to work with "release dates" instead of "version numbers".

See Discussion at ShoppingCartProposal-Talk

See Also



User notes? : If you use, used or reviewed this recipe, you can add your name. These statistics appear in the Cookbook listings and will help newcomers browsing through the wiki.