[pmwiki-users] shopping cart cookbook - oscommerce vs PmWiki
crisses at kinhost.org
Tue Sep 19 20:10:09 CDT 2006
On Sep 19, 2006, at 8:14 PM, Ben Wilson wrote:
> 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. For example, the $code variable could be the $pagename.
> The $info variable is that page's title. The price is an additional
> page variable. Quantity is user defined. It appears that wfCart
> stores all cart data in a session variable.
I have a problem with having to make a business fit the wiki (or
cart), rather than the wiki (or cart) fit a business. Who wants a
page name like ORC839729? But a business could very well have a very
large product offering with item numbers like that.
My initial idea was using extensible markup very similar to what the
wiki already uses, so that stores can be set up that fit the business
rather than a business having to "make do" with their cart features.
That's my argument against requiring a product per page in the wiki,
but it is quite possible to do that since the majority of businesses,
product catalogs and shopping cart sites require businesses to model
themselves along the lines of a single "product detail" scenario.
> 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.
Not yet -- I think that's functionality Patrick said he'd have done
> 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)? 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.
I'm almost done with my mysql authentication extension for PmWiki.
It stores email addresses but doesn't have any feature for pulling
the address from the database. Regardless, one could extend the
database to include shipping info, have a recipe that calls up
customer info for shipping, etc. While you CAN store this info in a
pagevariable, how secure is the information from other users on the
same server if people have to give their wiki.d directory 777
permissions? I think MySQL is at least more secure in that way.
> 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.
> 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.
I've had similar issues when studying Psych -- I had a pile of psych
books I wanted to read for personal research reasons that easily took
up two shelves, but I was stuck reading the required school texts --
I couldn't wait to finish class so I could read more psych books ;)
I hope you're not a Computer Science student ;)
> : http://www.webforcecart.com/manual.html
> : 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'];
> : I'm used to storing the cart on the server and using a cart ID in
> the session.
> : 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.
If the variable is stored IN the page text see note above about 777
While not everyone has MySQL or other databases, there is a good
reason for them, especially in these contexts. On a shared hosting
server you can't have files in the directory that are readable/
writable ONLY by the webserver or you can't clean your own webfiles.
You can't add yourself to the webserver group (which I do on my own
servers so I can 770 or 660...)
> : (:if auth edit:)Blah, blah, blah(:ifend:)
> : 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.
The logic of what you've done before applies for the cart, but the
point at which I see this as not-similar is when other people's
privacy and security are involved. There are concerns for price
hacking if you use plaintext to place PayPal orders (cf my PayPal
"buy it now" button recipe -- someone made a "simpler" recipe using
plaintext instead of encrypted buttons. I absolutely agree that the
recipe is simpler, but it becomes hackable. Not a big deal if a
human checks the orders-- a very big deal if the person is gaining
access to something immediate like music, movies, software...without
human verification of the order.)
More information about the pmwiki-users