Success! The WikiSh shop code is working. The redirects both work now. Forms and order page are correct. Thanks Peter, great work. WikiSh achieves a lot with a small amount of code.
I still have to solve my "auth admin" write access problem. We can track that issue in a separate post, it may be my set up or a pmwiki/WikiSh security thing. One minor gotcha. Make sure there is no blank line in Shop.Items or you get a blank extra field which duplicates the last actual field, and could cause a miscalculation of the total in Shop.Order. Maybe we should use a termination line such as "%%", just to prevent this going unnoticed by an admin, and causing price over-calculation and abandoned orders? Back to the design. I will work on shipping and payment gateways once we have the basics figured out. There are two things still needed for a basic order page. - Sessions for each order, as we began discussing. However, that is linked to another design feature...saving orders. - Order storage, editing, status tracking, invoices I've been wrestling with whether it is necessary to store each order because after all you could just use the data the payment processor provides. You could scrape by with that if you only sell single fixed price items without variables or accessories. However, that doesn't allow for editing orders, which happens when customers change an order. (Say they upgrade from 512MB to 1GB when purchasing RAM, or an item is not in stock.) You cannot create custom invoices, and the data format (CSV records) is different for each payment processor. AND, you cannot offer bank transfers which are becoming more popular and cost less. So I think any but the simplest and smallest shop needs to record orders. That requires. The easy part: - Storing order info - Storing customer delivery info (The two are linked by a customer number or email address) The tricky part: - Needs to be unique per order and customer - Customer info should be encrypted > I could create capability of having all files in a certain group > (i.e., "Session.PageA") be created as virtual pages saved in your session. > Would either of those be of interest? I would think much better from a > security perspective... > I would say whatever is most secure. This is the only sensitive area. I think customer details should be encrypted. I would not store credit card details, since the payment processors (Paypal etc) take care of that, but we don't want addresses and phone numbers being cracked. I intend on making all pages write protected on the file system side, except for the orders section. So the orders should be encrypted. I experienced some nasty break-ins recently, on my hosting. They linked to an EXE file, so Google flagged my site as potentially harmful. It takes a week each time for them to review the site after you've cleaned it. Hence, site security is definitely top priority now. Marcus _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
