I hope they can turn this into a stable and powerful platform that I can recommend as a self-hosted solution over Magento (too bloated) and WooCommerce (easy to use, but tied to Wordpress and missing some important features).
I hope they can turn this into a stable and powerful platform that I can recommend as a self-hosted solution over Magento (too bloated) and WooCommerce (easy to use, but tied to Wordpress and missing some important features).
At the time, the final product was arguably a case of code that is far too split up, resulting in quite some system penalties. I get the advantage of developing that way, but I wonder if they'd have been served better by somehow writing stuff to combine libraries together for the final releases product.
Even loading the landing page on a default website used to require loading hundreds of PHP scripts. I was absolutely gobsmacked the metrics I was getting out of APC.
One of their biggest vendors, WebShopApps, happened to write a pretty scathing open letter to Magento yesterday if you're interested:
http://webshopapps.com/blog/2017/01/what-magento-should-spen...
This is a company that just a year ago was making almost all of its revenue off of the Magento platform, and they are one of the most-respected brands in that community. Not a good sign for Magento.
Karen raises some valid points. Others have raised some additional points as well as counterpoints:
* Kalen Jordan (Co-host of MageTalk podcast, MageMail.co creator, CommerceHero.io founder): https://blog.commercehero.io/response-1ee004f6d3c7
* Joshua Warren (CEO of Creatuity, a Magento partner agency): http://www.joshuawarren.com/blog/2017/1/5/magento-2-in-2017-...
* Paul Byrne (President of Razoyo, a non-partner Magento agency): https://www.razoyo.com/blog/2017/01/07/2017-starts-rage-apol...
If anyone reading this thread is curious about Magento in 2017, I recommend to check them out as well.
I work with Magento everyday and what she says of a disparity between community and the enterprise agenda is ever so apparent.
Promises can only take you so far.
I have high hopes for it's future as it has some great minds behind it, but unfortunately at the moment it has some very key usability issues for developers and they are still making grand architectural changes to some components in a not so friendly fashion, so it is hard to iron those issues out yourself.
It is still an incredibly complex and cumbersome beast, and I suspect that will never change. But for complex and cumbersome business requirements it's strict structure and modularity make it a good fit.
It also has the benefit of being one of the few module/plugin ecosystems where it isn't a race to the bottom, as good idiomatic plugins are hard enough to build that it keeps lowballers uninterested and bad modules will fail a sniff test pretty quickly.
Source: Full time Magento dev.
Not only that, but it was assigned an "internal jira ticket" near the end of October and there hasn't been any further notification since.
This isn't an isolated incident. They spend a lot of money on marketing and conferences, yet the developer community seem to get less feedback than a one-person open-source labor-of-love provides. It's obvious (and has been for years) that Magento are really about the Enterprise version, and the Open Source version is really just a tip of the hat to their original legacy.
I still do consultation for it, but I no longer recommend it. I actually now actively suggest that people looking for ecommerce solutions look elsewhere.
As for us (Magento): Our velocity in handling GitHub issues and PRs for M2 has been really, really slow. This is partly due to the volume of reports, and partly due to some inefficiency in our own house. We're fortunate that we have a huge, engaged community who have continued to be patient with us - however, we know that patience has worn thin. People have work to do! Merchants have customers to please!
Starting a couple of months ago, the factors around this have started to change for the better. We've dedicated a large portion of our team to working on issue support, and I've been having calls & conversations this week which indicate further shifts for the better.
In the next week or so, I (@benmarks) and/or our new SVP of Product & Technology (Jason Woosley - @jasonwoosley_mg) will post more about the current state as well as upcoming changes.
Hopefully in the future you will be able to recommend Magento 2 when appropriate. Of course, it is on us to demonstrate real improvement.
In the meantime, my inbox is always open: ben@magento.com
Regarding your question, I hate to say it, but out of my recommendations most of my clients are tending towards either Woo or Shopify. I actually personally prefer Magento for most reasons, and still have clients who are happily trading with M1, both OS and Enterprise, but the customers on M2 feel that they've been burnt by the constant show-stopper bugs (mostly in regards to integration with other systems).
I really hope that I'll be able to start recommending M2 to clients again, as I've worked with Magento for many years and I know the system well. I feel it gets a lot of things right, but the M2 bugs have been frankly embarrassing, and have led to uncomfortable conversations with clients where I have to explain that yes, the old M1 site worked perfectly, but the new site that they're spending money on still has 3 month old bugs that I can't provide an update on, or even an ETA for resolution.
I look forward to Magento hopefully fixing the major issues with M2 in the near future.
P.S. I realised that I didn't actually post the URL to the bug I mentioned in my previous post. It's https://github.com/magento/magento2/issues/6683 ("Products updated_at field is not updating on save") which seems related to a couple of other bugs pertaining to "updated_at" fields not being modified.
I'm a little intimidated by the fact that if I have a problem with my store front, and start to look under the covers to fix things, I'd be hit with the full complexity of entering a new rails codebase.
A good case in point is most dedicated ecommerce platforms have one thing in common. User login and admin login is handled by a totally different system. This is a security feature. At the same time, most platforms support multiple sites or shops out of the box. Woo supports it with a plugin that was never made for ecommerce.
The lack of an MVC ... I digress. Wordpress is awesome for blogs. For something that takes money and has liability I don't want to have to read 0-day lists every day and see if I need to comment out something or update. Its counter productive to business.
The fact that it will turn off webhook delivery after 5 un-expected responses, without sending notifications of any sort, is mind boggling.
Once we get things stabilized we are going to figure out the best way to rewrite things. That is why we are trying to be very community focused. We need to see the pain points of merchants, what they want, what would make them succeed.
We are scrubbing the whole platform for legacy code and updating what we can while maintaining compatibility with the current modules and themes. Then we are really going to break this down and develop something more awesome than awesome.
i think the golden usecase would be running thirtybees on heroku (postgresql, composer, php 7)
EDIT: there was a dead comment about how postgresql is not good. what im asking is different - im requesting for an ORM like Doctrine or Propel. This will let the end user choose the database that they want to use. But you have to take this stand pretty early in a project's life cycle or you will not be able to do it later. Exactly the issue with WordPress.
So far, I've moved a lot of people, including my own online auction company, off of your platform because getting AJAX code to work reliably with it is near impossible due to lack of object-relational mapping.
I could go on and on, but quite frankly, you need to start from scratch. Right now you're just trying to slap a lot of icing on a poorly-made cake.
Some of the security issues in wordpress - unescaped queries, SQL injection and everything - which plagued it for decades could have been avoided by using a well tested ORM.
I would urge you to make this one of the highest priorities in your code cleanup. It is not going to take you a lot of effort, but the long term advantages are too many to enumerate here.
For example, for your own development sake - I dont know how you plan to manage schema changes. If you use Propel, you will use "database migrations" - something that every framework from Rails to Django, etc mandates as best practice.
We are taking the PrestaShop 1.6 codebase that has 10k modules and 2k themes as a fork. If we go changing the database handling off the bat we are going to lose the compatibility that might make us successful. We aren't a project starting from scratch with unencumbered code. We need to maintain compatibility to be successful in the beginning. We are springboarding basically. You are wanting us to take the springboard away and just jump.
since 1.7 is already breaking backward compatibility.. maybe it was an opportunity to do it right.
After that we are going to pool our knowledge, resources, and community to figure out the path forward. I will be totally honest with you, I am half developer half CSR person. I hear what my clients want and I try to make it happen. I am not the only person in on this though. I am one of many and very flexible. We are going to do a rewrite after we have stabilized things and we are going to do it right. We are going to look at the options out there and figure out where to go.
At this point it looks like I am leading things. I am the reluctant leader. I am the guy that realizes that my ideas might not be the best ideas and I want to hear yours. I just feel in the beginning it is about stabilizing what is there. I think if we spent 6 months rewriting everything we would lose an important window.
Tonight I am actually setting up the feature voting for our site. This is how I think things with a community need to be handled. There are going to be nay-sayers that stifle things because they are new and unfamiliar. This is always going to happen. But if we are transparent and add features by simple voting then no one can really argue with the logic. I have my ideas, but I am not the arbitrator of what will be included. I really want this to be a community project. I want the merchants and the developers to speak what they want and I want to make something that reflects the ideas of both.
About the Paypal. For me personally that is a reason we are forking. Last year the company that develops the Paypal module for PrestaShop got into an affiliate fee dispute with Paypal. They released an "update" of the Paypal module that basically made every UK shop's module disappear on the checkout for customer. People in the UK had a shit fit. I mean who releases an updated module that is meant to punish users to prove a point to Paypal? Totally unacceptable.