[Project] shopX 2.1

Quote from: ajayre at Nov 20, 2006, 11:12 AM

So which part of that should be in a ShopX framework, which part is already in MODx/other snippets and which part should be user customization? I.e. where is the line drawn?

I think the nice part about MODx is you don’t have to "draw a line". If there is an existing snippet out there that would add functionality to shopX, it will undoubtedly become part of shopX. On the other side of that coin, we may develop a very useful addon to shopX that may miraculously have a very useful life in another aspect of MODx. The customization of it will be limited (initially anyway) by lack of imagination and/or initiative. Neither of which seem to be an issue looking at the posts here in the last 24 hours. I for one am very exited about this. Now I have to think of something to sell!

-sD-
Dr. Scotty Delicious, Scientist.

What I meant was, regarding the products download aspect, what needs to be part of ShopX? For example, if the download is only available for a limited, time, does the ShopX system use a plugin to remove access to a specific page for a specific user, or is that left up to the developer to write their own plugin, etc?

Andy

Ah, there lies the beauty of using the MODx documents for your products! Simply set the publish/upublish dates for your document, and it will automatically be removed from your catalog on the date set for unpublish! You only want the item visible to a logged-in user? Put it in a document group attached to the web user group in question.

Sorry, I didn’t explain what I meant clearly.

Suppose you have a product that is downloadable, i.e. software. But you only want to allow the user to download for the next year so they can get updates. At the end of the year they need to purchase the product again for another year of updates. Or suppose that you only want download links to work for 30 minutes to stop people sharing username/password info with others.

These are just a couple of situations that I’ve already had to handle in stores that I have built in the past.

Andy

Some other random thoughts:

The system should store the total number ever sold of each product. Then developers can build snippets to show the top n products.

It would be nice if the system can connect products together via a sale. For example, know that frequently product x was bought at the same time as product y. Then people can build snippets to show "Customers who purchased this product also bought ..." ala Amazon.com. Although probably not a feature for the first version, any design shouldn’t stop features like this from being easily implemented later.

Andy

As long as the sales are stored in the db with an ID that can still be cross-referenced to the actual product, then such things are possible. Yes, storing some information (total sales) against the product itself can be a useful timesaver.

Back on the digital download thing:
Of course, sharing the file itself is as much a danger as people sharing the username/link. I think digital downloads are outside the scope of ShopX, but things need to be in the core to enable them. Basically what we’re talking about is an extra privilege that a user has gained through payment - I’m going to call this a user token for the sake of argument.

ShopX:
* Saving of user token upon successful sale with start date and expiry date with ID specified by product purchased
* Triggering of external routine upon successful sale (activate product URL)
* Inclusion of instructions in confirmation page / email based on products purchased

Other System:
* Creates link for dynamic instructions
* Checks user has token and valid credentials before serving file.

Other Uses
That user token might even be a store membership that entitles them to 10% off future orders.
Or it might be checked elsewhere in MODx - Gold Membership might disable all ads on a community site, for instance.

Lots more good ideas. It’s amazing how much easier it seems to be to build a complex system like this when the assorted parts are modular and not all jumbled together. So far I’m not doing anything but display sales info for order fulfillment purposes, but now that you’ve started me thinking about that info it’s certainly true that upselling and sales reports would just be a matter of query and output.

Quote from: sottwell at Nov 19, 2006, 12:57 PM

Then I’m going to rework the whole thing to use a couple of database tables instead. I’ll only store a key and a tag for preventing re-submissions in the SESSION.

Susan, let’s chat about this before you decide to do that, if you don’t mind. IMO, session data needs to be handled by the registered session handler in the standard way provided by PHP, and trying to maintain what is session-related data in other forms is not really the most efficient approach to solving this problem of shopping cart "state". What is the real motivation for doing this?

Quote from: OpenGeek at Nov 20, 2006, 12:57 PM

Quote from: sottwell at Nov 19, 2006, 12:57 PM

Then I’m going to rework the whole thing to use a couple of database tables instead. I’ll only store a key and a tag for preventing re-submissions in the SESSION.

Susan, let’s chat about this before you decide to do that, if you don’t mind. IMO, session data needs to be handled by the registered session handler in the standard way provided by PHP, and trying to maintain what is session-related data in other forms is not really the most efficient approach to solving this problem of shopping cart "state". What is the real motivation for doing this?

I think that the motivation was the intransigence of PHP sessions (24 minutes by default), combined with occasional flakiness and possible security issues on shared servers. But I’m not sure that storing everything in dedicated db tables is the best solution either. Personally I was going to use a cookie for basket contents and either PHP or MODx-native user sessions for checkout info (excepting the credit card info, which I’m not storing in anything except a post variable).

But I actually haven’t made this leap yet, and I’d definitely be interested in alternative ideas before I do. Especially from someone who knows the future path of MODx so intimately. And if we are going to set up a collaborative effort on this then we should all be on the same page, so I don’t want to go off on my own tangent if it’s not what most people think is the best course of action.

Speaking of collaboration, how shall we get that rolling? I’d be happy to set up a test installation (0.95? 0.97?) on a server and give access to folks who are working on this. Susan already has one set up as well, but maybe we should have one stable test site and one for development purposes?

The ideal is to have cart data stored on the server (in db or whatever), with a cookie so that the cart can be picked up again later. It’s much easier for all concerned, is more secure and is more flexible. When a user logs in, the cart is stored against the user, and they can log in anywhere and see the same cart. Having a cart purely as session data works, but it is limiting. Also, abandoned carts are useful to study.