[pmwiki-users] [pmwiki-devel] ZAP shopping cart question

Crisses crisses at kinhost.org
Wed Nov 8 13:05:51 CST 2006


On Nov 8, 2006, at 1:14 PM, The Editor wrote:

> Thanks Crisses for the input.  I hadn't noticed the info you had put
> up on a shopping cart proposal, but read it just now and found it
> quite helpful.  It generated some great ideas for me on how to make
> the ZAPcart module far more flexible.  I wrote up a response on the
> talk page but thought I would post it here as that page seems to have
> been active for going on two months now, and see if it generates and
> response.  Thanks again!

You're rather welcome!

I didn't get very much helpful input on that proposal.  I'm not even  
certain how feasible it is -- it was a method that occurred to me and  
woke me up one morning, and I ran over to a huge whiteboard in my  
home office and started scribbling. :)

> Posting to this a bit late, but had a few comments, in relation to ZAP
> and the ZAPcart module...
>
> 1) While I wasn't thinking Mall, I do believe a way could be
> configured for multiple merchants to set up separate shopping carts.
> It would require you to have a configurable Order.Items page (where
> item info is stored), or better yet a configurable Order group which
> would make each store fully independent.

It needs to generate separate carts for each merchant, since the  
payments would be separate.  Amazon.com is somewhat similar -- when  
you buy used books, they generate your order as one, but your card/ 
payment is charged separately for each of the merchants.  That's  
where some of the inspiration comes from.

> 2) Sounds like the proposal you are suggesting is a bit complex, but
> it may be necessary for complex needs.  The ZAPcart module is really
> designed for small shops with simple needs.  But there may be other
> ways to solve the flexibility needs.  Namely:

It is certainly complex.  I'll agree with that.  But there's more  
complexity for the programmer -- on the user end it only gets complex  
when setting up a complicated store.

Here I'm selling one product, with 2 size options:

	(:cart XES1 seller=XES pmt=PayPal;info at example.com tax:)
		(:item XyZ name="Product Name" desc="Product description"  
pic=http://example.com/products/pic.gif:)
			(:pic http://example.com/products/pic2.gif:)
			(:options QHI name="Size" select=1:)
				(:option 8oz name="Small" default amt=123.45:)(:optionend:)
				(:option 20oz name="Large" amt=10.50:)(:optionend:)
			(:optionsend:)
		(:itemend:)
	(:cartend:)

"cart" sets basic cart defaults -> a code for the cart (XES1), who  
the seller is (XES -- which could tie back to the Profile page I  
guess), what method(s) of payment are accepted (PayPal & its email  
for payment), and that the default for all of the XES1 cart items is  
that they're taxable.  I could leave "tax" out and put it into the  
item instead.  Because it's modular, I can specify the picture for  
the item, or a picture for each item's size options.  Of course, if I  
weren't putting in pictures of the item(s), and the item had no  
options, it would be pretty simple:

	(:cart XES1 seller=XES pmt=PayPal;info at example.com tax:)
		(:item XyZ name="Product Name" desc="Product description"  
pic=http://example.com/products/pic.gif:)(:itemend:)
	(:cartend:)

I've considered whether to use explicit open/close tags or a  
different method, but until I get even close to proof-of-concept,  
this is simply a "concept" for how to set up a store.  The store is  
product-driven, rather than trying to cram one's products into the  
available features of the cart.  The only requirement in each item,  
option, coupon/discount, or cart as given is that the item have a code.

Then there's issues about how to display something so flexible.  I  
was considering that in the (:options:) tag I would allow people to  
specify whether they want a drop-down, checkbox, radio button, etc.

So my idea has issues. :)  I was hoping that people would catch on to  
the concept behind it, and help move along the problem-solving phase  
of the concept brainstorming.

I've used ZenCart, and it's also complicated, but part of the problem  
is that there are SO MANY menus for setting up the store -- it's  
complicated for the USER.  Much too much back-end administration  
complexity.  Usable? yes.  Better than oscommerce?  By a long shot.   
But OSCommerce's back-end was easier to administer; ZenCart merged  
several oscommerce plug-ins into the core, which complicated the  
administration.

> 3) The javascript function can be modified by any programmer fairly
> easy to calculate shipping and taxes any way desired. You could also
> specify the javascript file in a SDV (or perhaps in the markup), so
> different checkouts could use different approaches.  Defined in a
> local config file.

I personally find this absolutely unacceptable, especially where  
membership or downloads may be concerned.  If someone is not hand- 
calculating the order, people can mess with the functionality of the  
JavaScript, and perhaps send through orders with lower prices --  
maybe even $0.00 or $0.01.  It's one of the big failings of browser- 
scripting.  I had put encrypted Buy Now button code in the cookbook.   
Someone else came up with a more flexible and easier method that  
could be done by any wiki author to create buttons -- and it's a  
great solution -- but the reason for the encrypted buttons is so  
people can't change the prices on the order.

> 4) The format of the ZAPcart order and checkout sections could be
> defined in a separate PmWiki page (like ZAP's email templates), to
> make them quite easy to configure.  To allow multiple kinds of forms,
> I could change the markup to allow an optional pagename into the
> zaporder directive. Otherwise the current default would be used.  This
> *should be* easy enough to do.
>
> 5) I think, without looking closely, additional parameters could be
> stored for items fairly easy and made accessible to the order and
> checkout sections, and to the javascript functions the same way it is
> currently done.  Basically it explodes the item info by pipes--so
> other fields in that array should be just as available as the price
> and name.

pipes is ok too -- I wanted something human-readable, so you might  
want to allow spaces around the pipes

> 6) As for options for items, I don't know any *easy* way to do that.
> But without too much trouble, each variations of an item could be
> stored as a separate item, and a special code could be put in the
> zapcart markup that would create a pulldown menu with options.  A bit
> of coding but not much.

I'd like to see that.  Not every store needs to be as complicated as  
my proposal.

Also, if we work with similar mark-ups, if someone wanted to upgrade,  
it wouldn't be as hard.

> 7) Things like discounts, coupons, gift certificates, shipping
> options, payment options, would be more complex but could be added
> *perhaps* using ZAP's conditional capabilities and/or replacement
> fields.  The javascript would also have to be written to make the
> appropriate changes.

> 8) I suppose a way could be set up for ZAP to handle inventory control
> (in stock or out of stock) but I have no idea how, and would probably
> rather not tackle that within the ZAPcart module.  It seems it would
> be for a more industrial strength application with direct tie in's to
> a company's database.  Something way out of ZAP's limited scope.

That's out of scope for what I was thinking also -- at least for  
now.  Once you get into that, you might as well drag a database into  
it.  Once I try to cram my concept into a database, it becomes much  
more complicated.  That's one of the nice things about the wiki  
version -- nearly arbitrary data nesting.

> I really appreciate the conceptual work you did Crisses, but think
> starting with something very simple and building extensibility into it
> might be a better option.  I know the basic ZAP cart system works like
> a charm and it is extremely easy to set up.  Making the various parts
> of ZAP more configurable would make that same ease of use available to
> much more diverse applications with minimal editing, and without
> having to reinvent the entire framework.
>
> Any thoughts?

I'm very hesitant about the JavaScript portions.  For updating totals  
on a page, sure, but for anything critical before payment I would not  
be happy.  I would think any order needs to be checked before it's  
sent to the payment processor.

> Cheers
> Caveman
>
> PS.  What did you mean by "What I'm going to need VERY soon are things
> like tying in user access to PayPal subscription services, as an
> example".  Don't have a clue how this would work, but I'm interested.
> I wouldn't mind having a section of my site only available to those
> current on their subscriptions.  But can't see how PayPal and PmWiki
> can communicate sufficiently to automate this.  How were you thinking
> about going about it?

PayPal has a subscription service.  I don't fully understand how it  
works yet, but they will create recurring payments and send  
subscription info to your website (through a specific URL on your  
site).  I would want to tie in subscriptions to the authentication  
module I've (re)created.  Mine uses databases, but it should be able  
to be done without a database.  So I would do this by, for example,  
having a wiki url divert to a specific recipe function -- that  
function accepts the PayPal information and changes the user's  
privileges accordingly.

So it's similar to the PayPal Payments Pro, I think -- where you send  
an order to PayPal, and PayPal returns verification to your site that  
the customer has indeed paid.  I've looked at the documentation, and  
they have some code samples, but I have to go over it again more  
thoroughly at some point.

I'm not interested in pay-only sites, but I had a customer who is.   
What I need is like you said: elevated privileges for a price.  So  
someone pays and is added to a privileged group with additional  
access to other features.  When their subscription runs out, PayPal  
renews them or their access to the privileged group is removed.

I'd love to accept other methods of payment, but services such as  
PayPal are very cost effective compared to some credit card  
merchants.  So, one thing to be careful about in developing these  
modules is to indeed make them modular -- separate the payment method/ 
processor from the code, so that people can create other plug-ins for  
other merchant services.

I would be doing this as an add-on for the new AuthUserDBase that has  
stand-alone features.  It probably comes right after I add the  
ability for the module to control groups -- I was able to do it for  
vBulletin, so I'm sure I can do database-to-wiki group conversions.

Crisses




More information about the pmwiki-users mailing list