I've never met anyone who uses Magento that actually likes it.
If you're running an ecommerce operation that is too small to justify building a custom CMS, and can't justify paying for Demandware/Salesforce Commerce Cloud, your options are really limited.
Shopify and Big Commerce offer good out of the box functionality, but you are then stuck with their feature sets and pricing tables. Each platform taxes you in various ways. Shopify imposes 0.5-2.0% fees on transactions processed with external credit card processors. Big Commerce forces you to upgrade your plan after your sales exceed a certain threshold.
For even ecommerce companies doing several million dollars a year in revenue, Magento community edition (open source) is sufficient. You pay up front for development or design work, pay annual server costs, and can scale your ecommerce technology spend on your schedule.
Magento has given me extreme headaches at times, but once we had our site up and running it was easy to maintain and administer. The non-technical people, i.e. the people who are actually packing and shipping orders, quickly picked up using the admin panel. So, yeah, I like Magento just fine.
My general issue with WooCommerce is being locked into Wordpress. I’m not a Wordpress expert, and it’s very difficult to determine when a security vulnerability (http://www.cvedetails.com/vulnerability-list.php?vendor_id=2...) is serious enough to justify upgrading my WP version, which may break compatibility with not-yet-updated plugins.
Small and medium is also in the eye of the beholder I guess. If you’re selling less than a dozen items, with no need for configurable products, advanced pricing rules, bulk discounts etc, then Magento is probably overkill.
I also don't see how you can be "locked into" Wordpress either, it's actually one of the easiest CMSs to migrate into and out of. It gets flack for being widely used and running on PHP (so does Magento,) but it's widely used for a reason.
Put yourself in the shoes of an ecommerce site operator. When a Wordpress minor release like 4.9 comes out, do I upgrade or not? How do I balance the security patches with the potential of breaking a critical part of my workflow?
EDIT: I meant WC 3.3. 4.1.19 was actually the plugin version
It seems like many developers prefer this newer Rails-based shop to Magento in terms of being able to customize. I've been contemplating moving a medium sized shop to it given that it seems relatively easy to customize, but nobody has mentioned it here.
Anybody have any experience or input on either of these?
I picked up Spree in 2015, and still build with it on a weekly basis.
The platform and its ecosystem both have ups and downs, for example the order system is quite complex[1]. For another I have yet to find a perfect way to architect complex extensions.
Most of Spree's power lies in its models. In hindsight my advice to myself would be: start with spree_core, modify the API (I like using cart api's on the frontend) and replace the backend/frontend entirely.
[1] https://github.com/spree/spree/blob/3-5-stable/core/app/mode...
I basically have custom frontend everywhere including some of checkout and account pages, so I mainly need to replace cart and payments and checkout and may try to integrate at the API level and handle all UI custom.
I have a bunch of requirements that may need plugins: - Volume pricing - Personalization such that some products can exist in the cart multiple times, but each item has a unique ID - Upsells / add-ons for personalized product. I currently handle this hierarchy outside the cart, but it's brittle. There are thousands of different options per product and they change all the time. Quantities of these have different syncing rules in terms of their quantity vs their parent combined with quantities from an external data source e.g. address book. - Social login, potentially adding login and payments with Amazon. Pondering if it'd be best to go with Auth0.
Promotions seem really powerful which is good, because I use them heavily and would want to add custom ones.
Any thoughts, insights, suggestions given these goals? Looking to support 100k products and millions of promotions.
Have done personalised line items in the past, when adding to cart there is a function that checks not just the variant being added but the options being added with. The comparison hooks for these options are designed to be extended, so that one should be relatively easy. Complex price changes on orders/line items can be handled via adjusters. These also hook into orders and are very flexible (although I haven't had to build any).
Have also build custom integrations to sync inventory with an external source using webhooks, since everything is fundamentally just Rails underneath it's as easy as you might expect.
No experience with changing the auth system, but since there is a separate plugin for the authentication (spree_devise) I think the intention was/is to make it easy to swap out if needed. I don't know how easy that would be though. There is no address book out of the box (just a save last used address feature), that's one of the features I am finally adding now.
I think you could go one of two ways with this, either a) keep your code light using decorators etc and try to do everything the 'Spree' way so that you can benefit from an easy upgrade path or b) fork spree entirely and manually bring in updates from upstream. I am slowly leaning towards b) because Spree has some design decisions that are incredibly powerful but also make everything much more complicated. Mostly I am referring to the ability to split shipments on checkout here.. I spent hours tracking down a specific line that was rejecting a shipment once. I gave up entirely and replaced spree_frontend early on, but I am mostly a frontend developer.
Are you developing/looking to develop this yourself internally as a retailer, or are you building this out on behalf of a retailer? Some of the other bits you've mentioned certainly sound complex (although this might be how you've approached these combinations of options and products), but not outside the realm of a Spree/Solidus or Workarea style implementation.
One thing to watch out for is Spree leaves cart level orders in the database, and deleting an order is not trivial. I have a cron job that deletes incomplete orders over a certain age, made after I realised ~90% of the database size was made up of abandoned cart data.
I mean the hardest thing, after the initial set up is on logistics and Services. What sets them apart in different level as you described?
At least I don't worry what breaks this time on a security update, which is a real PITA with magento. For updates to magento shops I schedule time, for updates to prestashop I press a button..
I'm not saying magento is better, but prestashop isn't in any way sane.
Prestashop is probably easier to administer than Magento, but that comes with tradeoffs because of its smaller developer ecosystem.
I guess that it wasn't so much that the add-on came at a cost, but more that it was:
a) a 3rd party developer
b) the only option
As you said it was just one of your issues.
On the other hand, MVMT Watches did $60 million in revenue in 2016, and is still on Shopify. Bombas socks did $50 million in 2017, and is still on Shopify. For many companies that sell a focused class of item, Shopify may well be the better solution for them.
Somewhat tautologically, the best ecommerce platform is the one that best suits your needs.
Two days later UPS knocked and I was the accidental owner of some 500 thread-count Egyptian cotton sheets I needed to mail back to my friend's client. The only time I've ever had a bug show up in real life at my house.
And don't look to closely at its chosen database schema...
1) Magento sites are normally full of plug-ins. The plug-in eco-system is much less mature for M2. We had to pay to fix a lot of bugs in plugins.
2) The new basket and checkout (for instance) relies much more on client side JavaScript (it saves as you write for instance). Our seasoned Magento devs were inexperienced with that kind of application, after years of working on php server side code only.
The rest has been actually a pretty good experience.
Also whoever wrote their JS needs to be shot. How it is acceptable to load your HTML buttons in one order and then, at the last second, suddenly switch to the opposite order. It was like all those Hawaii missile warning interface UI memes from a few months ago, except real life.