I got beta working when running dev mode

I tried last trunk version, but there aren't reports and there are some errors.
If you want, I've a SVN server...

@scip
To my mind, the current module is a little over-complicated and I would like to see it modularised so that functionality can be added through dataobject decorators. Right now you can't even add product attributes without changing "core" code. This extends (no pun intended) to things like testimonials, they've been added to the core code where they should really be decorators, I've had to write a decorator to remove them! This approach would make most people happy as you can swap in and out much of the wish list items described in this thread already.

That sounds like a good approach; let the e-commerce module focus on the core task of displaying and selling products, and leave stuff like product recommendations, etc., to the extensions. The extensions interface will have to be good though, but it should be easier to use and maintain overall.

Hans

Hi guys,

I'm almost ready to share what I've done on the e-commerce module (see my first post for an updated list of changes).

Regarding SVN / ownership for this project, I've talked to WillR about getting SVN comit access. He's spoken to Sam, the lead SS core developer who has made the call that they won't allow SVN access, as ecommerce is a retired project, which they will no longer maintain.

What do you guys think is the best place to store the code? My preference is to keep it svn-based, to keep in line with other SS code.

Anyone here with experience managing an open source project? I'm aware we'll need to start considering things like who gets write access to the code, how to manage merging in patches, and which new features are added to the core ....etc.

Jeremy

I'm a bit surprised that they won't allow SVN access, as I'm pretty sure that there are other modules that are not maintained by Silverstripe but are still hosted by them. However, it's their call. I personally prefer SVN, as it's what I'm most familiar with.

My suggestion would be to set up a sourceforge or Google code project for it. There's not much that you have to do initially. The module already has a BSD style license, so the licensing scheme is already set up. As the project creator you would automatically have write access to the repository and be able to add/remove developers to/from the source repository.

Hans

I'm both surprised and disappointed that SS won't open the SVN to you. I can only imagine that they want their new ecom (that we know almost nothing about, and have no timeline for) to be the only option... making some things easier I suppose..
In any case, I vote for google code. That would be easy.

@Jedateach I can't wait to see what you have done.

While trying to sleep last night another requirement of my current project came to mind.. I have 3 product groups, 1 for login in members, and 2 for public... 1 of these in english and one in french.... I am using the Child Group settings (don't show any, and show featured only) have these settings remained?
Can you tell me if there is a way to set the language on a per product group basis?

Well, I think it speaks volumes. I'm actually glad that SilverStripe have been upfront about the future of the ecommerce module and when you look at the Payment module it's easy to see why.

There's a lot of competition out there for ecommerce platforms, open source or otherwise, and the ecommerce module as it stands needs a lot of functionality and resilience improvements to bring it to a level that doesn't run the risk of making SilverStripe look bad.

That might sound harsh on the old ecommerce system but I'm not so keen to work on something that is more than likely going to get superceded (if it hasn't already). The Payment module actually provides most of the functionality required and the Payment Test module shows just how we can get 80% of the way. Perhaps it's time to start afresh?

I am open to taking part in an effort to develop a new ecommerce module(s) in an open source fashion, if done in a modular approach then it wouldn't take long to get the basics in place, especially if we can re-use some of the old code.

What do y'all think, do we have enough willing participants to make this work?

Rich

@scip

Is the code really that bad? If it is, then writing something from scratch would be a good idea. However, I do wonder if a major rewrite of the current one would be better. I'm not in a position to contribute code-wise, but I'm very interested in having a reliable and versatile e-commerce module.

Hans