Sloth, I think you're missing the point. Obviously anyone who runs a full-fledged online store selling hundreds of units a day is just going to use a straight up Magento install (or whatever other ecomm platform), and on top of that, they're probably going to invest thousands in optimizing it for high traffic, hardening it for security, etc.

Ecomm in Silverstripe is, and has always been, about satisfying an ancillary need of a content managed web site. We're not talking about creating the next NewEgg.com, here. It just needs to be significantly better than the singular ecomm solution that is currently offered for Silverstripe, which is extremely limited and approaching extinction. If you want to punch holes in an ecomm module, look no further than that one.

What we would love to see are simply more options for someone who wants to take advantage of the Silverstripe CMS, but also add an small ecomm component to their site. Let Magento, Shopify, ZenCart, and all the others handle the heavy-hitters. That's simply not the intended audience for the Silverstripe product.

@jam13 Well I definitely understand the attraction of avoiding anything in Magento ;)

[begin maniacal rant]
Seriously, my biggest complaint about Magento is that it's slow as molasses in February... and by the time you learn the API and EAV database structure, and how to properly override methods, and properly cache stuff .... you could have built your own ecommerce platform that doesn't need a cache ... or have all the limitations / crazy code / insane database architecture of Magento.

If Magento is so good why don't large companies like Amazon, or even medium-sized companies migrate to it? No. It's always small startups with less than $100,00 to spend on their website which go the Magento route. Everyone smiles and congratulates themselves on making such a smart decision not to build a custom app. Why re-invent the wheel? They say. Then after they see the performance of the finished app they end up paying Varien for the 'real version' of the program anyway for a yearly fee of 10,000 per server.

I may sound like a lunatic... but I am sick of people trying to write these generic, overly complicated apps in php ( maybe SS should be listening here as well ) and then having them run like molasses and not scaling. BTW... caching does not equal scaling! Caching is what you're supposed to do right before you're about to get Dugg. Scaling is running a live website with medium traffic and live data without things crashing.

I find that when I write custom apps for custom purposes things work much smoother than using so-called generic 'Wonder apps' that look real good on paper and crash when five people visit the live site at the same time. But maybe that's just me.

If you want to build a skyscraper out of OO matchsticks… go ahead… but I won't rent a room in it. And I'll only help build it if I need the work ;)
[ end maniacal rant]

I'm not a Magento evangelist, and whilst I do agree with some of your points you're wrong that it's just small startups who are using it. Many established ecommerce sites have migrated from bespoke or other off the shelf solutions to Magento, and there are probably many more are planning to follow them. As I said before, it is starting to get brand recognition amongst the people who make the decisions, which means that whatever it's flaws (and I know there are many) it's hard to discount it.

You suggest that writing custom apps is a better solution, but whilst you might end up with a faster and more efficient end product, your customer is then tied in to you for the lifetime of the site. With a framework like Magento or Silverstripe, one of the attractions to the customer is that if you ever part company then the foundations of the site are still maintained, and they can probably get another company in who will understand how it works. You might argue that if it's written in PHP (or any other popular language) then another developer can come in and maintain it, but in practice this just doesn't happen due to lack of documentation, poor coding standards and politics.

I would love to have a feature complete ecommerce module for SilverStripe but I don't, and even if I did it would be a much harder sell than Magento, so for now I hold my nose and live with it.

Jamie

Magento is slow, no doubt. That's it's biggest criticism, and like Jamie said, neither of us are shills for Magento or any other ecomm platform for that matter. We just want Silverstripe users to have some viable options for ecomm modules. Ithink it's misguided to say that just because something is bundled as an all-in-one solution, that makes it a skyscraper of matchsticks. If that's the case, why use Silverstripe? Why reinvent the wheel? Just build your own proprietary CMS. As most of us know, that usually results in failure.

Plus, I'm no Magento expert, but I believe a lot of the things you're complaining about with Magento are not relevant in the SS/Magento integration because all of the configuration is done on the Silverstripe side. Ideally, the user is only using Magento for its backend. And in terms of the speed, I don't think Magento loads anything near its full stack for SOAP requests. It shouldn't anyway..

Actually SOAP calls appear to be even slower than normal page requests with Magento, hence the requirement for the caching, so if you are suggesting using silverstripe as the frontend for magento via it's API then I'd give up now :)

This would be something I'd be VERY interested in seeing.

I've currently got a few sites running SS, one of them has a small e-commerce requirement which the existing e-commerce module might fulfill if it worked properly.

I also have, on the other hand, a fully fledged e-commerce site which is currently running Zencart, and another site which is due for launch later this year which would be equal content/e-commerce.

For these projects, where I'm building it so me less technical partners can operate it, being able to operate a complete CMS/e-commerce solution from the SS interface (Which we all like) would be a fantastic solution and put SS way ahead of many other offerings.

My PHP is rustier than the Titanic, but I can certainly help with MySQL stuff, as there's some options I think we could improve on in there, not least moving to InnoDB for the tables (moreso with an e-commerce module)

Jamie, I'm interested in knowing more about how you have integrated SS and Magento as we are assessing whether to go down this route, for example how you shared sessions to show the magento basket and login status on SS.

We have successfully used the magento api to pull through the store categories to SS but so far have been unable to include the mage classes into SS in order to access the store basket and login status etc, which is how we have achieved this with wordpress in the past.

Any suggestions, code examples or resources that you or anyone else could recommend would be most appreciated.

We avoided the route of loading both stacks for two reasons: it's so slow, and as both Magento and SilverStripe use autoloading, there seemed to be be no straightforward way of loading the Mage classes alongside the SilverStripe ones.

Instead we integrated at two points:

1) Static content (stuff that is probably not going to change during the user's session) was shared through SOAP calls from SilverStripe to Magento (to get categories and product info), and for calls from Magento to SilverStripe we wrote a simple SilverStripe controller that returned json encoded data to Magento. In order for this to perform at an acceptable speed we added a layer of caching to both sides, which as the data is relatively static is fairly easy to do.

2) Dynamic content (session related stuff like the basket count) was shared by getting Magento and SilverStripe to share a common session. We then stuffed in anything that we needed that wasn't already in there and retrieved it using each platforms standard session handling code.

The main problems we encountered were getting the two systems to share a session nicely. Things to be aware of:

- Magento stores it's sessions in MAGE_ROOT/var/session, whilst SilverStripe uses the default PHP session path. We fixed this by adding a static method to the SilverStripe Session class that allowed us to make it use the same path as Magento.

- Both systems need to use the same cookie path. By default, Magento uses /shop/ (assuming you have installed it in a subfolder called shop), but you can change this in the config.

- Both systems need to use the same cookie lifetime or you will experience weird behaviour.

- Both systems need to use the same cookie domain. This is a subtle one, as assuming your domain is "www.example.com", SilverStripe uses the cookie domain "www.example.com" whilst Magento uses ".www.example.com". We originally patched the Session code in SilverStripe again to fix this, but in 2.4.2 there is now a static call that you can use to do it from the config.

There may have been other things that I've forgotten, but those are the important ones I think.

We have modules for both silverstripe and magento which provide most of the required connectivity, but they are still quite inflexible and generally need customising for each site. If anyone is interested in taking a look and/or helping to polish them, then I'd be happy to publish the code.