next »

[sottwell]

All ShopX is is a plugin/snippet combination for the sidebar cart, and another snippet with a bunch of TVs for the checkout.  Items are just documents in a folder, categories would be folders.  Display is done with NewsListing and DropMenu. The whole purpose was to enable the shop to mix and match however you like.

[bugaev]

All ShopX is is a plugin/snippet combination for the sidebar cart, and another snippet with a bunch of TVs for the checkout.  Items are just documents in a folder, categories would be folders.  Display is done with NewsListing and DropMenu. The whole purpose was to enable the shop to mix and match however you like.

Hi, Susan! Is it possible to see finished checkout module in close future?

[Dimmy]

HI susan found this paypall class maybe somthing you could use?
http://www.phpclasses.org/browse/package/2989.html
greets Dimmy

[Colin]

Hi,

I'm completely new to Modx, and need some kind of e-commerce solution. I don't need something very complicated, but I do require that downloads are automatic upon purchase. Would I be able to adapt shopx to do this, if it cannot do it already?

Thanks.

[sottwell]

It could be done, but the entire checkout process needs more work. If you're a php programmer it shouldn't pose any problems, once you understand the snippet/plugin/TV system that ShopX is based on.

[Colin]

Alas, I'm not a coder at all. What I need is code that I can just slot into place. I'd try some tweaking, but it would have to be very basic; something like this would be way beyond anything I could hope to do.

What are the chances that you will be adding this functionality? After all, it must be something that many would find useful. - I guess it would be a fair amount of work though.

[bugaev]

it must be something that many would find useful. - I guess it would be a fair amount of work though.

I suggest  to make a work group to finished a checkout module. Susan could be the boss 

[sottwell]

It's something I just need to do. I know exactly how I intend to go about it. I deliberately made the core snippets as simple as possible, so a simple inserting of TVs to the checkout page would add whatever functionality is desired. It's just a matter of making up the TVs, and tweaking the plugin to allow for different levels of user data retention to finish it off.

I'll try to move it up a bit in my list of priorities; I thought a few other people were working on their own solutions and at least one would have been released before now. I still want to finish this though, since I'm rather fond of its simplicity for smaller catalogs that don't need a lot of different management options.

[bugaev]

I still want to finish this though, since I'm rather fond of its simplicity for smaller catalogs that don't need a lot of different management options.

Because you can 

[Colin]

Hi Susan,

It would be great if you could enhance this feature. As I said, automatic downloads, and I'm sure many would find that an automated subscription system through your Shop module would be of great benefit.

Go on Susan, do it. - You know you want to!

[bugaev]

It's something I just need to do. I know exactly how I intend to go about it.

Susan, I could help you with any stupid work such as html-coding the form or something else.
Hey, gues! Who can help Susan?!

[Colin]

I'll help test. I'll look at simple stuff like HTML and CSS too, if that helps.

[sottwell]

No, it's just that I have to take the time to concentrate and get my head back into the code. Right now I've got a lot of different things coming at me from a lot of different directions, and I don't multitask well.

Ok. For the rest of this week, I work on this. No more home page modifications for my partner, the newsletter registration feature for the local php user's group website will have to wait. And no Ajax until the basic functionality of this is finished, although Ajax is sure a lot more fun!

[Colin]

Great Susan!

[bugaev]

Ok. For the rest of this week, I work on this.

[sottwell]

I've run into a nasty problem that I don't know how to solve. Under certain circumstances, if the user clicks the "back" button on his browser, or refreshes the page, the plugin repeats the latest form submission (such as adding items to the cart if returning to the shopping catalog), adding the items again. I need to be able to tell the plugin to ignore the POST if it's a page refresh or the back button. Do any of you smart people have a suggestion or a link to information on how to deal with this? I'm researching the issue, but finding far more questions than answers!

[Colin]

Hi Susan,

This page relates to ASP, but thought that some of the ideas might still be relevant.

http://aspalliance.com/687

[omnivore]

I had to deal with this a few times, and IIRC, I did it by associating a unique string based on the time&date (plus optionally the user's ip) with each transaction. You need a field in the database to store this with each added item. Just check for existing identifiers, and reject the ones that exist. It means a trip to the server: these days, a bit of AJAXness would be helpful.

your change on a dollar: 0.98.

[sottwell]

I've already examined and considered most of these methods. The first problem is that the data are not being stored in a database as this point, they are maintained in the SESSION because the user may or may not be logged in at this point; in fact for some applications the shop master may not want users to have to be logged in. For example, PayPal has its own forms that can be linked to as a checkout option, so the online shop does not need to handle user processing at all, merely pass the items and costs. The shop's records are not created until a successful PayPal transaction is returned, and these may consist of email notification that is input into a local database.

The second reason is that a customer may wish to repeat the order intentionally. His cart will show how many of a given item he has ordered, the item's individual cost, and a running subtotal. If the customer decides to order another of a given item, then the quantity of that item is incremented and the running total recalculated.

This sounds like the hidden field and a timestamp, with the timestamp being stored in the session for later comparison might be made to work. Since the data are only stored in the session to begin with, losing a session will cause the customer to lose his cart completely anyway. I willl have to ponder the logic of this, though, I'm kind of hazy on exactly how it would work. Looks like good ol' trial-and-error time again!

[omnivore]

I've already examined and considered most of these methods. The first problem is that the data are not being stored in a database as this point, they are maintained in the SESSION because the user may or may not be logged in at this point; in fact for some applications the shop master may not want users to have to be logged in. For example, PayPal has its own forms that can be linked to as a checkout option, so the online shop does not need to handle user processing at all, merely pass the items and costs. The shop's records are not created until a successful PayPal transaction is returned, and these may consist of email notification that is input into a local database.

in principle, this is no different from logging, and doesn't require a login by the user: why not have a separate table, or even a text file, or a flat berkely db separate from the main db that simply records the on-the -fly generated timestamp&ip ids, separate from any cart issues. The records can expire after a certain time, so the maximum size of the table/file would be as many cart transactions take place in the expiry period, probably a small number, ie avg 10 users, x 1 transaction a minute x 24 hour expiry = 14,400 lines/records.

The second reason is that a customer may wish to repeat the order intentionally. His cart will show how many of a given item he has ordered, the item's individual cost, and a running subtotal. If the customer decides to order another of a given item, then the quantity of that item is incremented and the running total recalculated.

Sure, but since the detection would only happen when someone backs into something that has already been processed, do you think that anyone is going to repeat orders by using the back button**? What's being detected is a duplicate timestamp & ip, nothing to do with the contents of the order. If a repeated identifier is found, then a mechanism like a popup or a div that you make visible could ask if that is the user's intended action.

(** to clarify: I understand that someone might back up to a previous page to increase an order, or reduce it or whatever. By putting a confirmation page after the user says 'add to cart', with a 'continue shopping' button, it will usually be that page that they hit first, and that's where the action you are flagging takes place. If they use the Back menu to go directly to where they can specify the type and quantity, then there is no problem, no?)