TreasureChest: MODx eCommerce solution.

I’m afraid ram is correct.
Without some major modifications Treasure Chest works with a single shipping charge by product.
Paypal offer some scope for customising, but it doesn’t offer multiple rates options.
It is possible to hack TC and add an extra step in the order process to vary shipping charges, I did so for a shop that hasn’t gone live yet, otherwise I’d post a link.

Thanks for confirming that info Ram and Bunk58.
FoxyCart is out too unfortunately as they don’t interact with paypal websites standard ("Currently we don’t support PayPal Standard")

The search continues...

Any ideas on a shopping cart that integrates well with a MODx site that will allow for a selection of flat rate freight options:
Adelaide metro (free delivery) and SA Country& Interstate $12)?

I have restarted work on TC2. I ran into some pretty significant roadblocks that I was able to overcome. There are a lot of good suggestions in this forum, and I am open to every suggestion.

Some key features of what I am working on right now:
There will be no separate module for product administration.
each item is a MODx document. Product attributes (price, quantity, shipping options, etc...) are set in TVs.
"ViewCart" contents will be customizable via chunk. Default functionality will be to open a new page to view the cart with an easy option to use an included javascript modal window or to roll your own javascript view.

Focus for TC2 will be on the API.
Payment options (PayPal, Google Checkout, Authorize.net, 2Checkout, etc...) will be a modular extension. Any developer can add a new payment method by extending the TreasureChestPayment framework class:

<?php

class GoogleCheckout extends TreasureChestPayment

{

    public static function init()

    {

        //class code here...

    }

}

?>

I am (as usual) working on this in my spare time. As soon as I get a workable public alpha, I will subversion it to encourage collaboration from the community.

-sD-
Dr. Scotty Delicious, DFPA

Great news Scotty.
TC definitely has the potential to meet most peoples need with a bit more flexibility on shipping and payments.

Scotty,

How do you see the product options working? A CSV list or ajax table? a TV for each option?

Quote from: ProWebscape at Jun 18, 2008, 10:42 AM

Scotty,

How do you see the product options working? A CSV list or ajax table? a TV for each option?

Right now, the plan is for a TV for each option. I really just want to keep it as clean, and as MODx native as possible.
CSV is not on my list right now because on a product with 10+ options (name, price, SKU, shipping ground, shipping next day, etc...) and considering each option would probably have 2 or 3 entries (option, display text, value), that is a long, ugly, CSV. If this is being put in a text TV, after about 4 options, it is going to be really hard to edit.

Ajax table sounds cool. It would certainly be nice to sort columns on the fly. I can’t think of a way to do this without hacking the manager because the module has been ditched in favor of managing all the data on the MODx document rather than the item data in the module and the snippet call, parameters, placeholders, and such in the document.

Looking back, it was a solution to a problem, but a very convoluted one. I really want to streamline this, and at this point, the way that interferes least with the usual way to do things in the manager is setting up 6-12 TreasureChest TVs and giving Template Access to TC specific templates.

I am a reasonable man, and a fan of compelling arguments for/against. If you got ’em, I’d love to hear (read, I guess?).

-sD-
Dr. Scotty Delicious, DFPA.

Well I’ve got a sortable, editable jquery table. Trying to figure out how to show it in the manager. Thinking of using ManagerManager cause it would be ohh sooo sweeet for clients to have a multiple column/multiple row input option (and sortable too).

If it’s just TV’s it could be whatever. Text for each one, a simple csv converted to the list via phx, it’s all open.

For one foxycart store, I’ve created a text field where the options are filled in via:
LabelName1=Option1,Option2,Option3||LabelName2,Option2a,Option2b

I’ve created a little phx snippet to convert that. The label acts as the select name and label. But anythings really possible. It just needs to output the form correctly. I think the multi-row/multi-column table would be very piratey though!

Chuck

I’ve got a module with a sortable editable AJAX table (using Prototype). The tutorial might help you get your jquery table plugged into a module.

http://www.sottwell.com/database-module-2.html

That was my starting point Susan. What I want to do now is have it show up in the document edit interface.

My thinking is to:
* Create textbox TV (it’ll be a big array possibly)
* use ManagerManager
- to hide that textbox
- show the editable table ??

So I think the editable table would be best as a modal, so they know to save it. When saved:
- the form values are base64_encoded (http://davidwalsh.name/php-serialize-unserialize-issues)
- serialized
- inserted into the hidden textbox

Then we can take the array, and do whatever we want with it. I’ve got the table working here http://modxcms.com/forums/index.php/topic,20802.msg159720.html#msg159720. I just dont want to fiddle with the jquery/manager stuff right now. My head’s about to explode.

BTW, I got this idea from SilverStripe and ExpressionEngine. It’s a godsend in EE. EE doesnt do it this way- but we’ve got to work with what we got. Which is really really good.

Quote from: ProWebscape at Jun 19, 2008, 01:27 AM

For one foxycart store, I’ve created a text field where the options are filled in via:
LabelName1=Option1,Option2,Option3||LabelName2,Option2a,Option2b

I’ve been experimenting too with what would be the best way to store product options in the Modx native documents table. And I came across this same solution.
Yet, a lot of e-commerce sites now offer comparing functionality and I want to keep track of inventory for each product. Therefore I still create a document per product and fill one tv with all product properties:
Size=Small||Color=Blue

What I still don’t like about this approach is how to do a good search, like query all products where color=blue, but it can be done. And when you want comparing functionality and display all properties in a table layout, you need an array of all properties of all chosen products since certain properties could be missing in the tv of a particular product. It means having to go through the arrays a couple of times, while in the old days a good old sql statement simply returned all relative data.

I hear a lot of users say that storing a lot of products in the documents table would make the site slow, but why is that? Is it because of how the manager is built? It’s still the same amount of data when storing in another table no?