next »

[OpenGeek]

I've got four installations on my localhost, as well as my personal site which I use as a remote testbed so others can play with my toys too. Gets interesting when I forget which installation I'm working on at the moment!

Indeed Susan; I'm looking at 17 MODx (and 2 Etomite) projects in my Eclipse navigator right now and that's only the ones I've worked on since last week when I got a new computer.  Now, what was I working on???!!! 

[mandrl]

Sounds really cool! Thanks.

I have to try this some day. For my purposes this could be better than the "complete" e-commerce systems out there. I'd create my own shopping cart, but lately have had no time for such projects...

[Djamoer]

This is cool... Keep it simple and flexible Susan.

I'm here supporting you. Hope I can do something later on.

C ya...
and Good JOb!!!


Wendy Novianto

[sottwell]

The catalog is simple enough, just a creative use of the MODx document tree structure, menu snippets and NewsListing snippet calls. 

The plugin keeps track of the user's activity by loading the POST returns into the SESSION.

The mini-cart snippet uses these SESSION values to generate the display of purchases with a running total.

The checkout cart snippet does the same, with the addition of a bunch of TVs that can be edited from the checkout document.

The checkout page has two TVs to contain the option blocks, one for shipping options and one for payment options.  The payment options block won't show until a shipping option has been selected.

Each shipping option requires a TV to provide the radio button option and do any other processing to determine shipping costs, setting the result as a hidden input field, then on postback if its button was set the plugin adds that to the SESSION.  The checkout snippet then adds the shipping costs and generates the second part of the order.

Each payment option requires two TVs, one to provide the option radio button, and the other to handle the payment function if its option button was selected.  This will make it easy to add payment options by creating two new TVs, one for the button and one for the actual payment processing. This version does not require registration, nor does it permanently store any user information.

So while it contains a number of various parts, it's designed to be modular in the extreme, and to use as many MODx features to advantage as possible. And most of the parts can be omitted if you like; for example if you only have one payment method, just stick it in the Checkout document and skip the payment button and processing TVs; likewise with the shipping options.  If you want to skip the mini-cart, you'll need to add a link somewhere to the Checkout document, and a link or button on the checkout document so the user can clear his cart. Eventually that checkout cart will have form capabilities to change the quantity, or remove individual items.

[davidm]

What can I say Susan : not only do you created this great thing from scratch, but here you are writing the doc at the same time... do you sleep sometime ??

[rthrash]

Ninjas do not sleep.

[davidm]

lol... yeah apparently they don't !

I didn't know this was a no-sleep-bug-squashing-code-writing-team of ninjas

Ninjas do not sleep.

[Djamoer]

Just wanna thanks for all the hard work.

Keep it up guys...


Sincerely,
Wendy Novianto

[rthrash]

Susan... got that PayPal thing much more cleaned up and almost done now, if you want to toss in IPN and webuser account creation into the mix.

[sottwell]

Well, I've manage to get a rather crude email order form working.  Has some rudimentary input validation.  Needs a lot of work, but it gives an idea of how a Payment Module TV should work.  Just call it at the end of your Checkout document, and put the corresponding PayCODOption TV in the Payment Options TV like this:

Code:

@EVAL
if(isset($_SESSION['order'])) {
return '
<form action="[~[*id*]~]" method="post">
<fieldset id="scPaymethods">
[*PayCODOption*][*PayCreditCardOption*]
<input type="submit" class="button" name="paymethod" value="Select Payment Method" />
</fieldset>
</form>
';
}

(yes, I know the names are a bit different than the package below, I will be updating it shortly)

[sottwell]

Susan... got that PayPal thing much more cleaned up and almost done now, if you want to toss in IPN and webuser account creation into the mix.

User registration and validation will be included in the next major package release, as well as a user editable cart display (remove items, edit quantity).  Probably not for a couple of weeks though, I'll be housepainting.  Maybe.

Um...IPN? 

[rthrash]

IPN = paypal posting back to your site with a success code and amount.

[jlarson]

Forgive me for not sharing sooner, but I've been frantically working on getting a Modx-based storefront of my own released.  Just turned it loose on Monday, with probably a bug or two, but we were already late on the Christmas season. Take a look at http://girl33.com/shop.  Pleare help me and report any bugs and ideas, ok?  If people are interested, I could now possibly set up a demo site and provide manager login info to some folks.  I am not the most thorough or knowledgeable out there esp. when it comes to security and error checking, not good for e-commerce, so would be most happy to share with the brilliant Mod-xers around here.

Features:
All TV-based (10 TV's so far I think).
Expanded registration table and signup form, with user account editing.  User id is email address.
Categories based on page tree, with no theoretical limit to subcategories
Discount by product or category, based on quantity or total value ordered
Product options (uses a child page, with a simple boulean checkbox TV to mark it as an option)
Maintains stock levels
Most content, including product listing pages, is template-based using chunks. 
Real-time U.S. Postal Service rate lookup
Paypal IPN based on class found on phpclasses.net.  Not working perfectly, but getting the job done for now.

Limitations: English, U.S. currency, Paypal and U.S. Postal only at this time.  Of course no reason more options can't be added--something I see Susan is already on top of.

Misc. notes:
Adds new tables for orders, ordered products and paypal ipn (at this time they're in a separate database, but will probably just integrate them.

One minor core hack, a simple function to set a TV.  Otherwise all snippets and modules (for backend reports). Still creating some of the backend tools.

Product pages are currently added via manager, not a frontend tool like News Publisher--counting on the upcoming manager rewrite.

I like Susan's ideas and will be taking a look at incorporating at least some of them.

Because of the combination of snippets, TV's, chunks and modules, if this were to be publically released it would need an installer, something I would probably never get around to, if for no other reason than I'd never think it was good enough with my sloppy coding.

Modx is fun.

[sottwell]

One minor core hack, a simple function to set a TV

Maybe you could use a plugin? I've gone the route of core hacks, and it's a real pain when upgrade time comes.  Unless, of course, it's a really useful feature and gets put into the core distribution!

[jlarson]

Maybe you could use a plugin?

Because I've never really understood plugins very well.    Actually I first set it up as a snippet that got I called via runSnippet, but it seemed to really slow things down when I first used it to decrement the stock level.  I assumed the speed hit came from multiple calls when iterating through a list of products ordered.  But to be honest it's such a small function it's probably easiest just to repeat it in snippets whenever needed.   

Parenthetically, I've been wondering why the Modx core couldn't include a class extender called user or something, for cases where for efficiency you want to avoid the overhead of a snippet, but I guess that's another post.

[OpenGeek]

Parenthetically, I've been wondering why the Modx core couldn't include a class extender called user or something, for cases where for efficiency you want to avoid the overhead of a snippet, but I guess that's another post.

That's exactly where we are headed in the not so distant future.  Probably even allowing user-defined extension objects to be loaded as well, on demand.

[sottwell]

OK, the shopX pages work in IE now. What a pain. 

[sottwell]

Fixes to ShopCart.snippet and StartCartSession.plugin.

Fixed URL issue in creating the 'clear cart' link (thanks, Mark!)

Changed SESSION storage of the items in cart from serialized to array to facilitate...

Simply increase the quanitity of a line item added to the cart more than once, rather than show the item multiple times.

Will still need to serialize or implode the array for cookie or database storage.

[sottwell]

shopX version 2 firmed up to the point of the payment module selection. Whole enchilada (hm...sounds good, too bad I can't get good Mexican ingredients here!) attached to the first post. Read the accompanying text file.

Payment option selection still a bit fuzzy, but I'm sick as a dog with my winter bronchitis and this is the best I can do right now. Maybe somebody else can see where I'm going with this; if not I'll get to it eventually. For now, it's a hot shower, hot tea with brandy, and some sleep.

[jlarson]

My Modx-based shopping cart is working fine at http://girl33.com/shop.  This is a completely separate project from what Susan is working on, but hopefully there will be some synthesis as her project develops.  Since I don't have time to develop this project into a distributable package nor support it as such, I've set up a demo site at http://storie.com/shop.  I still need to add some technical info, mostly about dbase additions, changes, but will send a manager login/password to anyone who would like to take a look.  Send request via PM.