Recommendations for PHP based Ecommerce platform

Requirements

1. Dev Friendly (So Magento/Magento2 is NO NO NO)
2. Isn't built to be a place to "buy features" that should be included by default
3. Limited or NO SaaS models, we want to own it and have full control. Not pay every month for something that should be a one time purchase.
4. Active and supported module/plugin system
5. Get free upgrades
6. Non SaaS integrations with eBay and Amazon

From my reviews so far this has left me with WooCommerce and CSCart and possibly XCart but it's upgrades are charged.

I prefer procedural code very much to convoluted design patterns and over-engineered object inheritances like M2 has. I want a simple and easy to edit template system that is straight forward, does not feature layout xml files or complex relationships for layouts represented in some database or stored objects it should be template files in php or smarty and layout should be freely editable.

Zen commerce/open commerce imo are a disaster house of spaghetti code on the other side, but I haven't checked up on them in a very long time.

Drupal codebase and Wordpress codebase are things I like, but just wanted to see what is out there and get recommendations.

I looked up prestashop and it seems it isn't nearly as bad as M2 as far as all the things I don't like about coding trends these days go, but it still subscribes to some of them and as a result isn't as dev friendly as other solutions. Thanks.

---

 

Thanks for the replies, I had my eyes on Woo so seems like that's backed up here.

Shopify / BigCommerce - I think this is SaaS and definitely don't want to get into that. Thanks tho.

 

I researched the speed of woocommerce vs magento2. Magento2 is garbage in comparison on everything but like one page. Magento2 also makes you compile things for dependency injection to make production changes, and has so many layers of caching, and even with all that on you get TTFB of like 1.5 seconds on a lot of servers, or longer, depending on the size of your database. So then you have to add even more caching.

Hooks and actions are smart coding and a good thing that have been around forever.

Magento2 decided to use inheritance, dependency injection, and just tracing where the actual code is means opening about 10-20 files a lot of the time and it's just horribly written. Classes are much more expensive than hooks too, programmatically. See some other posts here for how bad Magento2 is speed wise: https://community.centminmod.com/th...eded-ecommerce-platform-for-centminmod.14707/

That you are never supposed to run magento2 on a shared server but woocommerce can have extremely high traffic loads on one should be an indication too.

I haven't used Woo a lot but I have used Wordpress a lot.

I appreciate the advice, just saying, in comparison to some stuff out there, Woocommerce is a speed demon. And if I did half the stuff I did to "fix" magento2 speed issues having 2 nginx servers, with a varnish cache server and redis and a separate database server, rewriting 4 core "indexers", disabling things that break the site, adjusting mysql settings etc, then I'm sure from what else I know woocommerce would still be faster than m2 cuz it's junk.

I put "fix" in quotes because there is no fixing a stupid slow system like magento2. When you clear cache, when you develop, when changes are made, when people have to do tasks to lots of items/orders, when you look away for 10 seconds and it breaks b/c of some issue which it has a plethora of... well. It's not really fixed is it, it's always there and always an issue and always will be.

 

I think you misunderstand, I wasn't saying you were recommending Magento2. I was simply explaining why I think Woo speed isn't bad in comparison to what else I have experienced out there, and that hooks are actually cheap in terms of impact on speed vs inheritance and DI. So even if woo takes work out of the box to make extremely fast, it's still miles ahead of a lot of competition. Most of the speed in terms of user exp comes from how good your caching system is, and how slow the php side is has no bearing on it. Though if you read the last paragraph of my prior post, a very slow system still has a ton of downsides.

I appreciate your input, just giving my perspective. I just figured any system isn't going to come premade with full page caching and varnish you know? I also think it's not really hooks slowing it down. Hooks add overhead for sure, but the only way to get rid of some way to inject code into a part of the execution is write it exactly how you want start to finish. Modular design doesn't allow for it unfortunately. When I look at how other system modularize code, Wordpress is smart. Drupal is smart. Magneto2 is a dumpster heap. And there's not really other ways to do it. You either go hooks/events or you get a spaghetti pile of objects that are over-engineered for their purpose and just make developing and maintenance harder. You have to also understand my frustration with magento2 has nothing to do with you so wanting to compare what I want to get off of (magento2) to something that has been recommended is entirely the point of this thread. Thanks for the info tho it's as I said appreciated.

Opcode caching from php, properly configured database, nginx and varnish setup with a full page caching system, redis or memcache for storing some objects in memory and you have a pretty full package. There's several caching engines for wordpress that can utilize all of them. Not sure about woo tho I assume there's at least a few that support it. I'd weight the redis/memcache part the least important, but there's def a speedup to be had storing full data structures or variables in memory, rather than having to query the database and recreate them with php. PHP opcode cache helps speed that part up but you never have to run anything to fetch/create it if the result is in memory and the code knows to use it.

It's kind of weird, like, magento2 you have to do all this. Must be nice to be on a system that doesn't need all of it to just "function" (again in quotes).

I'd like to add for the server side centminmod makes most of it pretty easy btw.

 

I am not experienced enough in Woo to agree or disagree. I can say though that my preferred caching method for wordpress only uses wp fastest cache for full page caching, and auto optimize for making some of the loading order stuff better so you get better content paint times. I'd say it's very good advice to not add more than you need and since WP isn't so ungodly slow like M2, it would take a lot more to "need" it.

Varnish can suit any website tho, it has it's own rules, and there's many rulesets for wordpress out there available by default. It essentially tho boils down to not caching requests that have certain cookies tied to them. You can further it more by making any unique content ajax'd in and have your base page full page cached, then you can leverage the best of both worlds (stupidly fast main page fully cached, and then fetching in unique data for that user via ajax).

Whether you need that is def a question to ask. It's pretty slick when it works tho, I'd have to do a lot more research and trench time to know how it works if at all with woocommerce's existing systems. I know that there's things like W3 Total Cache that have varnish support, varnish cache purging, opcode cache storage and purging, and redis/memcache support all ready to go and free. But I just stopped using it cuz most the time I can get the same speed output with far less configuration overhead on the smallish wordpress sites I need maintain.

Not doing more than you need is definitely a valuable thing most devs don't appreciate. It's good to know Woo is often running great without the extra complexity introduced. And you always have that there if you do need it.

WP Fastest cache just stores the resulting page as an html file and uses nginx/apache rules to load that if it's cached instead of everything else. Then that is cached in memory by unix. So it's pretty fast. It also smartly turns off if there's any user logged in. So it's only good for anon users but that's most users on some websites. It's pretty easy to setup. Sometimes it has issues with things like headway tho.

If you introduced varnish in front of that, with proper rules, you could have varnish serve the html file generated by the full page cache and then not get any of the nginx overhead either and since varnish is built to do exactly that it does it faster and can handle more requests of it.

The other side tho is varnish rules are very customizable. So if you want to have fine control over what is cached and what isn't then varnish is very useful. Such as a system that has full page loaded in but ajax requests with cookies are not cached. I'd def say don't use it if you don't need it though as varnish is hard to edit rules in.

I guess I'll have to see how it all works out for our size of store when we eventually get to doing it. Thanks for the info!

 

I haven't but this looks promising in conjunction with W3 Total Cache Varnish v4 VCL for WooCommerce Stores - Beta

Cart will still work due to them being excluded altogether.

Full cached pages you should be able to get under 60ms TTFB reliably with this method and using centminmod tho.