Forum OpenACS Q&A: Who has Ecommerce 4.6.1 working? On what platform?

Berklee Music is also using it;  we did that work sometime in 2002, so I'm not sure what version that was, but it was working ok at that time.

I too, have setup several ecommerce sites. Most of them on OpenACS 4.6. but I don't think that ecommerce is incompatible with OpenACS 5.0. Yes, there are a number of noquote issues in the user interface but the code under the hood should work well.

Maybe you can provide us with some more information about your setup. OS version, DB version, OpenACS version, AOLserver version, openssl version and nsopenssl version.

I do know that AOLserver 4.x requires nsopenssl 3.x which does NOT support outgoing HTTPS connections. That is ns_httpsget and ns_httpspost are not supported at the moment in nsopenssl 3.x.

For ecommerce w/ the authorize-gateway that means that you'll have to use AOLserver 3.x + nsopenssl 2.1.

/Bart

Torben, I haven't used the current ecommerce setup either, but have hacked much on the original port. What are the issues you are having a problem with? Are there features missing which your boss expects? Or does it just not install?

Ecommerce itself is a very broad area. This module is good for a retail shop, but the backend is more important than the sucky front end, as you can easily create a new frontend. You should also note that every retailer has an infinite desire to customize their site with features, so you constantly have to hack in these features. So even if the package (OpenACS Ecommerce or other) you choose does everything you want when you install it, soon you will discover it's weaknesses.

Can you elaborate on the reasons why your company is prepared to drop the ecommerce module? Was it mainly due this error message or some other reasons?

Nagita Karunaratne, the boss' concern was mainly due to a series of errors, incomplete features, and undocumented steps, which pushed the project significantly passed the original deadline we set and others' expectations (that we had built up). We should have set up a working test site beforehand, but didn't think it was necessary since others were successfully using it. My mistake.

Hi, Tom. Gladly the backend issues have since been resolved.

For the record, the issues consisted of:

1. issues recorded in the bug tracker. Most are now fixed thanks to help from Bart and a growing number from the community.

2. poor documentation with a different payment gateway that seemed to claim compatibility to authorize.net. Turned out it was *not* compatible for direct access. We've created an ezic.com gateway thanks to help from Bart and EZIC. However, the site uses the authorize.net gateway. note: Ecommerce is limited to using one gateway.

Advantages of each? Authorize.net is the mature, sophisticated choice. EZIC gateway is a simpler, recent implementation. EZIC offers a feature to change the billing message that appears on customer statements, which is useful when setting up vendors with multiple domains. (The refund function has not been tested yet).

You should also note that every retailer has an infinite desire to customize their site with features, so you constantly have to hack in these features.

Customize? Actually, we just wanted to start with a generic running setup and modify later. The generic features are reason enough to choose openacs' ecommerce package. However, it became clear to us that not all ecommerce features ported from aD have been used. Or, if they were, bug fixes did not make it back to openacs.org.

Weaknesses? There's one feature needed before officially announcing the implementation. We're working on a single checkout form that integrates with the existing multipage ordering checkout format, so that the one page form is used for first timers, and the multipage format is used when more than one address already exists for the user. This should reduce end-user usability issues we've encountered. The code will be worked in to 5.x.