NYCPHP Meetup

[inforequest]

Cliff Hirsch cliff-at-pinestream.com |nyphp dev/internal group use| wrote:

>Like many on here, the whole shopping cart thing is a mess to me.
>
>So...I just installed litecommerce, which was fairly painless. And changing
>the templates, which use Flexy, was fairly easy. But deciphering the PHP code
>is a nightmare. Who ever said OOP is easy? It just seems to obfuscate the
>meaning of things. Something as simple as tracking down the origin of
>order.details.error, which is in a template, becomes maddening.
>
>I’m on the verge of trying another cart, mainly because the ioncube-encoded
>files conflict with Zend Remote debugging. And without this, trying to trace
>the code using live interactions seems impossible. I’m sure this happens to
>everyone, but what seems like a simple feature list grows and grows... But the
>primary special requirements I have are the following:
>
>Single sign-on — means all authentication goes through the primary site. So
>far, I have hacked this by duplicating user info in the main site and the
>shopping cart user profiles. Not optimal, but functional. 
>Custom payment processor — just a call to a function on the main site. Again,
>nothing mind-shattering 
>Modified checkout to simply include shipping address fields — again, no biggie 
>egoods pin #s support (the reason I choose litecommerce — they offer a module
>that does this well) 
>Meaningful error messages — meaning modern validation used on my main site.
>
>None of these are overly complex. The challenging part is understanding
>someone else’s code and mindset. The devil is in the details... I have also
>discovered that integrating a shopping cart with anything other than simple
>static functions from a primary site can lead to all sorts of config
>conflicts, from phpini on upwards. Dated PHP4 code...can you say e-warning...
>
>So...a general call for help and recommendations.
>
>I am thinking of getting X-Cart because at least it is fully open source. But
>it’s developed by the same people, so the code may be equally confusing.
>OSCommerce and its derivatives are out — too many bad stories. Any other
>ideas? Is it too much to ask for a great, easy to modify cart? The cost of the
>cart is trivial compared to the cost of the custom code, time, maintenance,
>aggravation, etc.
>
>Happy holiday,
>Cliff
>
I think as far as shopping carts are concerned, we are in the era of 
charge by the hour programming. That is where the money is.

I also think it's time to redo the ecommerce platform. We have moved far 
beyong where we were when OSCommerce was built, and far beyond skinning 
(Zen cart). We don't need a new model for a shopping cart based *web 
site*, but a new model for ecommerce functions we can integrate into our 
modern web sites. To me that is *not* Shopify et al., because they 
charge too much without assuming much if any of the risk in a 
transaction. A few percentage points might seem like little at first, 
but if it is cream off the top and doesn't reduce liability, it's waste 
and waste needs to be eliminated. I think it is foolish to take on a 
recurring cost for design (eventhough that is a sweet deal for them).

Right now every successful store I see is hand coded from scratch, and 
severely platform dependent. I don't see a lot, but I've seen a dozen or 
so in 6 months.