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

Ben Wilson dausha at gmail.com
Wed Sep 20 11:28:12 CDT 2006


On 9/19/06, Crisses <crisses at kinhost.org> wrote:
> 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.

It's all data storage. Most users have learned to ignore pagenames in
an ecommerce context, as long as the title is more descriptive. Look
at the typical Amazon product. The difference between mySQL and a wiki
page is essentially moot since beyond the interface level a mySQL
record is in a file. Scalability does present a concern, but there
would have to be a significant hit to impact a simple directory
lookup. By the time you get into the scalability issue, you would
(IMO) be in a situation where you're using dedicated server(s) with
load balancing, etc. I'm thinking daily transactions in the tens and
hundreds are equally well-served via a page system or a mySQL system.
The advantage of a page system is you have hooks already available for
your use, while you have to code SQL strings for a database. Perhaps
this is really just an apples/oranges issue.

> 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.

The advantage of the wiki page approach is the ease of integrating a
client's web site theme with the data. My biggest complaint with most
CMS-type products is the impossible to manage theme. This is usually
because the design either calls for too many templates or CSS markup.
For example, I've tinkered with Vanilla Forum, but just changing the
colors can be a royal pain. Contrast those with PmWiki's Incredibly
Friendly Skin Format (IFSF).

> > 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
> yesterday ;)
>
> > 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.
>
> I'm almost done with my mysql authentication extension for PmWiki.

As opposed to my mySQL authentication extension? Hmm, that was one of
the Mini Summer of Code projects that didn't get finished. That is,
there is something out there, but not entirely user friendly.

> 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.

I put my wiki.d outside the web directory. So, while the directory
permissions are wide open, they are harder to access. Additionally, I
have a cron that keeps files 666. In an ecommerce context, I would
think security demands moving wiki.d out of the web directory.
Anything less in this day-and-age is tantamount to reckless behavior
(i.e. knew the risk but ignored it).

> 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 ;)

Worse, I'm a law student with BS in Comp Sci. I was pretty siked when
one of my "read me" books that I bought last Fall ended up being
required reading in one of my Summer courses. But, on top of software
projects that limp along, I have three book shelves of "read me." The
pain ends in December.

> If the variable is stored IN the page text see note above about 777
> permissions.

Agreed, which is why I recommend moving wiki.d out and croning page
permissions to 666. For what it's worth, I had a PmWiki running with a
named PHP calendar program on a web server that had a non-hardened
kernel. That site was hacked---because of the calendar program. Pm is
pretty hard-core about fixing security issues as he becomes aware of
them.

> 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...)

I'm not saying _don't_ go mySQL, but as PmWiki is file-based, it would
be nice to have an ecommerce recipe that fit in with file-base. You
may consider tying in the mySQL listing of products with a variation
on (:pagelist:). For example, (:productlist:) could retrieve the
products ala mySQL and use a pagelist template for presentation. But,
that depends on how tightly you want to couple your project with
PmWiki. In this thread I advocate a rather tight coupling, but I
realize this is your project.

> 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.)

When talking plaintext/cyphertext, we're talking a function of the web
server, right? Again, I assume any ecommerce project would imploy SSL.
The recipe needs merely to check if it's being used in a plaintext
context and carp when it is.

When talking user pages, isn't that also a matter of security? I mean,
anybody could code an ecommerce mySQL project that allows customer
87623 to view customer 8675309 by changing the query string. It's when
you add a checksum that says that only customer 8675309 (or an
administrator) can view that customer's information that security is
added.[1] We reach the same degree of security via PmWiki by setting
the read, edit and admin variables of a page, and moving wiki.d out of
the web directory. (Also, mySQL AuthUser to better manage hundreds of
users.)

I once queried how to set it up so that group permissions are based on
the user's name. Thus, user BenWilson could have a group BenWilson
were page default permissions are restricted to him. Then, I could
open up the wiki to my school's student body. It should be no small
feat to do the same for a user.

Regards,
Ben Wilson

[1]: Why is the ID 8675309? Think of the song . . . "Jenny, Jenny, who
should I turn to? 8-6-7-5-3-0-nai-e-ain." Okay, maybe you only get it
if you were in your teens or tweens in the early 80s.




More information about the pmwiki-users mailing list