Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

E-Commerce Modules

Discuss about the various e-commerce modules available:
Ecommerce, SS Shop, SilverCart and SwipeStripe
Alternatively, have a look the shared mailinglist.

Moderators: martimiz, Nicolaas, Sean, frankmullenger, biapar, Willr, Ingo, Jedateach, swaiba, simon_w

Working on e-commerce for SS 2.4


Reply

121 Posts   13490 Views

Avatar
TotalNet

2 June 2010 at 11:05am (Last edited: 2 June 2010 11:07am), Community Member, 181 Posts

No, the code isn't bad at all. It's actually a very good example of what is possible with SilverStripe.

There is a good deal of missing functionality IMHO though, particularly when it comes to order management and product management. If your primary requirement is an online shop, as opposed to a flexible CMS with integrated modules, then there are better options available. I think SilverStripe recognise this, hence the direction away from the (current) ecommerce module.

So, the option is to patch up the current ecommerce module to work with SS2.4.0 or build some basic catalogue & order management and using the Payment module. This is where the willing participants come in, it's easy enough to patch something up with a bit of help from time-to-time but it takes a coordinated and commited effort to build something new.

I'm more than happy to look at what Jeremy has done and to help test and patch it if necessary, as for extending it - I'm leaning towards the "Payables" example when I don't need a cart/order-management and using an alternative for a more complete ecommerce solution ... unless we have enough willing participants ;)

Rich

P.S. I really would prefer it if we could get the willing participants!

Avatar
Jedateach

2 June 2010 at 11:43am Forum Moderator, 227 Posts

@HansR WillR gave the example of DataObjectManager - it is much endorsed by SS, but maintained (and stored) externally. http://dataobjectmanager.carlinowebdesign.com

I'm in favor of keeping this project going, as it has a lot of functionality already. I wouldn't consider a rewrite until we actually hit that wall and find that we can't implement something without a major rewrite. I think we do have the skills to see this turn into a quality solution, its just a matter of collaborating effectively/efficiently.

I've been treating the eCommerce system as a catalog / cart system that integrates with the payments module.

@scip I've noticed over time that people (including myself) are willing, but the willingness diminishes when their work is not actively merged into the site code. It's great when you don't have to rely on patching core code to have things work the way you want.

@DsX I have kept the product in multiple groups functionality, but I've (temporarily) removed the ability to custom choose which groups can show child group products also. Its either the all show their children, or none do.

...setting up google code project.

Avatar
HansR

2 June 2010 at 11:58am Community Member, 140 Posts

@scip

In your opinion, what kind of functionality is missing?

My needs are fairly simple as I won't be running a retail store with thousands of products. I'd prefer a Silverstripe module over using one of the many e-commerce packages out there is due to several things:
- I'm familiar with Silverstripe, and prefer its template system to that of other packages (more flexible)
- I would want my customers to use one unified system via one account (e.g., including support forums, knowledge databases, or whatever else). I don't like the fragmented nature of many online websites. With Vodafone website, for example, you have to create separate accounts for their main site and their technical support sites. It's rather messy.
- I'd also prefer to use a unified system myself, instead of having multiple sets of templates to maintain, multiple incompatible systems, etc.

I'd be willing to help where I can. I have my hands full with other projects, am primarily a C++ developer and haven't done much with PHP or e-commerce systems; hence why I can't contribute much code-wise.

Maybe we could start with building a list of what people here actually need, and go from there. My preference would be to strip down the existing module, make it easily extendable, and turn the removed functionality into extensions. That's not so much a patch-up, as a major rewrite. Since I'm not using the module at present, I have no problem with breaking compatibility with the old module.

@Jedateach

Great. Post the link to the Google code project once it's up.

Hans

Avatar
TotalNet

2 June 2010 at 12:52pm Community Member, 181 Posts

@Jedateach
True, having to reapply our own fixes to each new trunk is a pain and I'm sure is the main thing holding back any community development effort.

Right now I'm not fond of the underlying model - for me, it's not so much about reaching a point where we can't implement something but whether patching the functionality we have to work the way we want is more costly than working with a clean slate. It's a hard call to make. To complicate things, different people will want different things and assign different priorities to them!

As I said, I'm more than happy to contribute to making ecommerce module work on SS2.4.0, Google Code sounds good to me.

@HansR
If you already have other customer logins and uncomplicated requirements for an ecommerce system then yes, SilverStripe + ecommerce module is the way to go. I am in complete agreement that multiple logins for one website/company is rediculous.

The main weaknesses of the ecommerce model for me are around order/customer/product management (the front-end is fine) and these issues go to the core of the underlying model, not in a hugely fundamental sense but as I said above, it may be easier to strip the module back to basics rather than try to patch up the order-flow management or add product types to allow sets of common product attributes for example.

I'll resist the temptation to start a functionality wish-list here but open to discussing that separately.

I think it's great that we're getting some momentum behind this module again, here's to keeping it going!

Rich

Avatar
DsX

2 June 2010 at 1:41pm Community Member, 178 Posts

@Jedateach

eagerly awaiting the google code link :)

Avatar
Jedateach

2 June 2010 at 1:42pm Forum Moderator, 227 Posts

Ok, the moment you've all been waiting for...
https://code.google.com/p/silverstripe-ecommerce/

I first committed the SS ecommerce 0.6 beta 1 code, then all the work I've been doing.

Things people can do on this project moving foward:

  • - Test the current trunk code, and submit bugs to the [url=https://code.google.com/p/silverstripe-ecommerce/issues/list]issues section of the google project[/url].
  • - Go through all the [url=http://open.silverstripe.org/query?status=inprogress&status=new&status=replyneeded&status=reviewed&group=component&component=Modules+-+ecommerce&order=summary&col=id&col=summary&col=status&col=priority&col=milestone&report=37#no1]current trac tickets[/url], and replicate the ones that are still valid on the google project.

I'll be updating the project wiki in future with things like guidelines for contributing to the project, configuration, customisation instructions etc. Anyone that wants to help with these is more than welcome.

Avatar
HansR

2 June 2010 at 5:38pm (Last edited: 2 June 2010 5:39pm), Community Member, 140 Posts

@Jedateach

I just checked out the code into a fresh Silverstripe 2.4.0 install with the payments module, and I get the following error:

Fatal error: Class 'Database' not found in /Development/Test-Website/ecommerce/code/AccountPage.php on line 80

According to [url=http://silverstripe.org/e-commerce-module-forum/show/284804]this thread[/url], that error is caused by an old version of e-commerce module which the trunk version was supposed to fix. However, I definitely am using the code from the Google project (double-checked with "svn info").

Hans

Avatar
HansR

2 June 2010 at 5:42pm Community Member, 140 Posts

Okay, line 80 is:

Database::alteration_message('Account page \'Account\' created', 'created');

whereas it should be:

[DB::alteration_message('Account page \'Account\' created', 'created');

So please change all of the instances of "Database" to "DB".

Hans