7 ms·

Show HN: Thirty Bees – A PrestaShop 1.6 fork

58 points by themaveness 10y ago

gingerling 10y ago
FSFE legal network may help you with licencing questions - I have a good contact there, email me and I will connect you.
JaggedJax 10y ago
I had high hopes for PrestaShop and hope this leads to the improvements the platform needs. It's so close to being great but it was not particularly stable and their API is a terrible mess of an afterthought. 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).
- aritali 10y ago
  I have been helping with the fork, that is the plan. First thing we have to stabilize it and fix the bugs. We are refactoring a paypal module right now that has buttons that are not connecting to anything. It calls methods that do not exist. It was something that someone made to essentially try to get over on people. 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.
  - sandGorgon 10y ago
    please please use an ORM. if yoy dont build database abstraction today... you will never be able to build it once the plugins take off. Just the fact that you can run postgresql will be a killer feature. 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. http://www.doctrine-project.org http://www.doctrine-project.org http://propelorm.org http://propelorm.org
    - aritali 10y ago
      To be totally honest these are the kind of decisions that kill a platform like this. Postgres is great and everything, but the low number of hosts that adopt it would sink something like this. You really have to look at the market. The main installation user will be using softaculous or a similar installer on cpanel. Which does not support Postgres out of the box. Sure, if you have root you can add it, but that will effectively kill our US shared hosting / managed VPS market. The goal is to make it where merchants can use the software easily and it has features they want. Picking a Postgres design effectively limits us in using compatible modules out of the box and it effectively limits our hosting choices. I don't think its anything we are going to do at the start, but I would not rule out a version of it in the future.
    - themaveness 10y ago
      I get it, but honestly it is not in the immediate roadmap. Its really not something that people in the scale we are in are worried with.
      - sandGorgon 10y ago
        an ORM will help you write more maintainable code in general. Every framework right from rails to symfony uses an ORM for the abstraction it brings. 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.
        themaveness 10y ago
        I understand it, but look at it from this point of view. PrestaShop 1.7 requires everyone to purchase new themes and modules. The code base is extremely messed up. 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.
  - benmarks 10y ago
    I deal with the PayPal team regularly, and I'm sure they'd be interested in your success. Are you in/near Paris? We (Magento) have an event there in early February. Happy to meet up then or sometime / somewhere.
    - themaveness 10y ago
      We are not. We are actually spread out all around the world. Right now we are not a company, we are just agencies / developers that mad, sick and tired, and want something better. We just started this project this week and we are pulling more and more agencies on board, it is exploding under us. 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.
      - benmarks 10y ago
        Okay, I've emailed their team so that they can look into the situation.
- deleted 10y ago
  [deleted]
- jonah 10y ago
  If you're not tied to PHP, check out Spree[1] or its fork Solidus[2]. [1] https://spreecommerce.com/ https://spreecommerce.com/ [2] http://solidus.io/ http://solidus.io/
  - deleted 10y ago
    [deleted]
  - hardwaresofton 10y ago
    Why are they both built on rails? 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.
- rmccue 10y ago
  Curious: what do you find missing from WooCommerce?
  - themaveness 10y ago
    I find it missing a lot of things personally. Its just a mash of plugins from different sources that have not been evaluated or secured. The package itself is pretty light, because it does not have the features of other actual ecommerce packages. You have to use plugins that were not made for ecommerce packages to extend it. 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.
  - Implicated 10y ago
    I don't have the time or energy to list all of my issues with WooCommerce, but as a PHP contractor that has worked on a handful of client projects utilizing it... I could never recommend it to people trying to run a real business. The fact that it will turn off webhook delivery after 5 un-expected responses, without sending notifications of any sort, is mind boggling.
- Twirrim 10y ago
  Urgh. It has been several years now since I last had to deal with Magento, and nothing I've seen over the years suggests it has got any better. 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.
  - ehnto 10y ago
    There is a completely re-written Magento 2 out now, in case you were curious. 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.
    - Intermernet 10y ago
      Magento have had a bug in 2.1 Since September last year which they still don't seem to have fixed which basically breaks any 3rd party import / export / sync[1]. 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.
themaveness 10y ago
I for one welcome this change. Hopefully they are successful and can fix the issues that have plagued the software for so long.
TonaldDrump 10y ago
This is great news. I don't know if anyone has been keeping up, but PrestaShop is being run into the ground. Check out the glassdoor reviews lately, https://www.glassdoor.com/Reviews/PrestaShop-Reviews-E884065.htm?sort.sortType=RD&sort.ascending=false&filter.employmentStatus=REGULAR&filter.employmentStatus=PART_TIME&filter.employmentStatus=UNKNOWN https://www.glassdoor.com/Reviews/PrestaShop-Reviews-E884065... The management seems like world class screw ups. Hopefully this will get off the ground, I signed up.
zebra9978 10y ago
where is the github repo ... the github organization ? there is no link to any source code anywhere. It may be an oversight, or a hesitation to open it too early. But here at HN, it gives me an uncomfortable feeling for a cabal that may bait-and-switch. For example, I have zero idea of whether you are going to use a MIT license or Apache or whatever. Why is this so secretive ? We have been looking to throw our weight behind an open community platform that can compete with magento. Im hoping you guys can be that... but you need to be open right from day zero. P.S. oh and I second the ORM comment. Like seriously. It will be a horrible mistake not to use one.
- aritali 10y ago
  I can speak to the GitHub repo and source. Basically a lot of the companies that are forking are agencies that are affiliated with PrestaShop. We are bound under certain contracts (not ones that deal with the OSL though). We basically decided this move this week. The reason the GH repo is not public yet is because we are changing the licensing (the copyright attribution not the type) and the branding. Also we are going over the code and commenting what is PrestaShop's and ours. On a basic level we are trying to do everything right with the code to cover our asses and not get sued. As for the license we are not experts in licensing, we are developers. It seems easiest for us to keep the same license that is on the code than to try to transfer it to another system. It is going to stay under the OSL 3.0. That being said, that is why we have the mailing list sign up. We are shooting to have everything cleaned by early in the week where we can release the public repo and a road map of what needs to be worked on. This is going to be a totally open source project, we are just trying to do it in a way that will not end up in us getting sued for some minor violation of the license. As for a community platform, that is what I am going for. I own an agency that manages around 800 PrestaShop websites. I see my clients leaving. I see them leaving for stupid reasons (not on their part, stupid reason on PrestaShop's part). I am trying to stop the bloodletting in my company and give my clients what I hear them asking for. Transparency is what we are going for. I want users to suggest features. I look at other platforms often and say things like 'damn that would make a nice core feature'. Its part of the reason we are breaking off. There is nothing more demoralizing than spending a day or two working on a feature for an open source platform then they reject it. Not only do they reject it, the company (PrestaShop) takes the idea and sells it as a paid module. This happened to one of our developers. tldr: We are going to be totally open source under the same OSL 3.0 license we just need to properly deal with and attribute the code before we release it to try to prevent a lawsuit.
hardwaresofton 10y ago
Can anyone suggest a good writeup on the problems with magento and the existing solutions? I honestly thought storefronts were basically a solved problem, with options like Shopify, WooCommerce+Wordpress, existing.
- Walf 10y ago
  Have you ever worked with Magento? With 1.8+ I found customisation very tedious and unpleasant, documentation virtually non-existent, 3rd party code unreliable, and CMS functionality lacking. Perhaps it's come a long way since then but I wouldn't bet on it.
  - navs 10y ago
    Good bet. Magento 2 isn't any easier to develop for. As for the CMS, Magento has recently purchased Bluefoot CMS which I take to mean they are looking at improving the CMS experience, maybe just for enterprise sigh
    - benmarks 10y ago
      Stay tuned regarding that.
  - hardwaresofton 10y ago
    Respose is a little late, but I've worked with shopify and seen a little bit of how woocommerce worked so I was just very surprised anyone would need much more for a storefront
- DCoder 10y ago
  I have been working with Magento CE 1.x for several years now. I have spent at least a hundred hours inside the debugger carefully stepping through the seventy layers of its core code to make sense of it. I can list a lot of problems I have seen in it. However, I cannot recommend any alternatives: I refuse to touch WordPress because it's WordPress, I have no intention of using OpenCart because I have already tried it once and its author is a crazy man, and I have no experience with Shopify or Prestashop. Business issues: * Magento is in control of your price structure. You will structure your prices in the way that Magento allows, or you will suffer. Our client was not happy with the price calculation, so we spent hundreds of hours changing it thoroughly. Do you want tier prices for product options? Too bad. Do you want customer group prices for product options? Too bad. Do you want to set discount values as "discount this much after applying all taxes" (e.g. because your shop displays only prices after tax)? Too bad, all you can do is "discount this value on the untaxed price, plus whatever reduction that makes on taxes" or "calculate the discount amount off the taxed price, then discount that much off the untaxed price". And once you have made some price customizations, the customer will find an extension that does something to the prices and breaks your changes in a creative, subtle, and unexpected way. * The CMS part of Community Edition is a joke without a punchline. It doesn't even have any menu module, only the ability to manage pages with content dumped in an RTE. * Our clients were originally in love with Magento because "we can just add all these existing modules and get all sorts of awesome functionality without having to pay you for it!" We warned them that that was a pipe dream, but they didn't listen. Now they have several thousand hours worth of custom development on top of Magento 1.x (95% of it written solely by me, no bus factor problems with that) and they're still asking for more. Last I checked, the end-of-life for M1.x is planned in December 2018, and the client has no plan for what to do then. Technical issues: * The database API has an "you want it, you got it!" mentality - if you tell it to add a unique index and MySQL refuses to because existing data is not unique, the API will parse the MySQL error message to identify the duplicated fields/values and delete the duplicate rows silently. You will get your index, but you might no longer have all your data. [0] * The model classes store nearly all the in-memory data in an untyped dictionary. You can call $model->setFoobar('12345') and later $model->getFoobar() to get it back - all unknown method calls get forwarded to a "catch-all" method which treats the method name as a key into this dictionary, and gets/sets a value of that key [1]. Most of the time, these calls are unannotated, so IDEs can't make any sense of them (see the "Undefined method" part in [2]). This magic is also a performance issue, so they make optimizations like [3] by inlining pieces of the catch-all handler code for commonly-used data. * EAV models. In theory, a workable idea, and you can even make your own EAV models if needed. In practice, you need to spend a lot of time in the debugger stepping through the code to figure out what code in the Product or Customer classes needs to be copied into your custom EAV model to make it work right, because the core EAV model doesn't have half the needed functionality. * Misleading code comments and annotations. Nothing like finding a method whose phpdoc says it returns a class that does not exist in the codebase. * XML configuration jungle: * Module configuration and theming configuration is based on heaps of XML that has no schema. Module configuration combines XML documents in the "there can be only one" manner (if two documents have XML nodes with the same path, the second one's value overwrites the first one), specifically so modules can change each other's configuration. * Theming layer operates on "blocks", which are basically a PHP class with a corresponding .phtml template file. These blocks are defined, managed, and composed through XML files. You can even encode instructions like "after creating this block, call its method foo()" in the XML. If your theming doesn't seem to take effect, you get to step through the loader to figure it if it's not loading your file, if some file loaded later is giving different instructions, or if you placed your code in the wrong place in the XML structure. Or if there's some extra XML configuration in the database specifically for this category/product/CMS page. Happy hunting! * Using third-party modules and themes is a russian roulette: * Magento includes a "Developer Mode" where php notices and warnings are turned into exceptions like in sane languages. However, lots of modules and themes have never been tested with this setting on and they cause faults on every page load - either you have to disable the Developer Mode, or fix this third-party code. * Some modules are well written, some do crazy things completely at odds with Magento workflow (e.g. an extension to set custom tier prices that calculates them when you load the product from the DB and ignores the precomputed price index in the DB), some are downright broken. And some of them contain gaping security holes – are you going to audit all the third-party code you include [4]? * Magento core JavaScript is based on Prototype.js, not jQuery, so half the modules and themes bundle their own copies of jQuery and drop them in different locations. Some of them provide a configuration setting so you can disable their jQuery and use your own, some don't. I have seen a page that loaded Prototype, ExtJS, jQuery, and Angular side by side. * As with every extendable system, some extensions don't work well together. Every module has the ability to override a Magento core class. Fun happens when two different modules want to override the same core class. * Other * Performance is demanding. You need powerful hardware and good caching to get good performance. And then you'll get that one extension that tanks your performance, like the Analytics plugin that loads each product in a category individually to send its data to Analytics when you view the category page. * Security updates are fun. When you log into the admin panel, you will see a notification about a new security update. This notification shows up because a scheduled task periodically fetches a news feed, which contains security alerts, new version announcements, marketing spam, and whatever else Magento wants to show you. You read the notification, and follow a link to the Magento downloads page. There, after logging in, you can find and download a .sh file which contains both the patcher and the patch content itself. Run it to apply the patch. If the security issue is critical enough, Magento will publish a repeated reminder to apply it a few days later. Which your news feed will again pick up and dutifully display to you, despite the fact that you've already applied that patch. You will also get a panicked call from the client because he logged into the backend and saw that message too. * Some things are just silly: * Translation manager cannot cache the translations correctly, you get different translations for the same input with caching enabled and disabled. * One class has both escapeUrl() and urlEncode() methods, and neither of them actually does URL encoding. [0]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/lib/Varien/Db/Adapter/Pdo/Mysql.php#L2739 https://github.com/OpenMage/magento-mirror/blob/magento-1.9/... [1]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/lib/Varien/Object.php#L616 https://github.com/OpenMage/magento-mirror/blob/magento-1.9/... [2]: https://imgur.com/RMxWEgR https://imgur.com/RMxWEgR [3]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/app/code/core/Mage/Catalog/Model/Product.php#L684 https://github.com/OpenMage/magento-mirror/blob/magento-1.9/... [4]: https://news.ycombinator.com/item?id=13100162 https://news.ycombinator.com/item?id=13100162
pitaa 10y ago
I wish them luck. I remember several years ago OpenCart was similarly forked to get away from the project owner's shenanigans, but that fork has had very little activity in the time since.
chrismorgan 10y ago
Argh! You’ve hijacked the Space key (which is supposed to be for scrolling) to open your weird, well-hidden navigation! … admittedly, I wouldn’t have even found the navigation if I hadn’t pressed Space.
- themaveness 10y ago
  I can own that, it was me. We decided to launch this on Wednesday and I am a poor designer. I needed something to quickly get up as a page to explain to people what is going on. So I grabbed a Jekyll theme and went to town. Sorry about that, I am kind of at fault. Here is the theme I used though, http://jekyllthemes.org/themes/space-jekyll-template/ http://jekyllthemes.org/themes/space-jekyll-template/
  - chrismorgan 10y ago
    Remember mystery meat navigation? This is even worse: invisible navigation. Hiding the navigation behind a hamburger is OK on mobile because it’s an established pattern there and the screen is smaller so you perceive the entire screen readily; but on desktop computers? I didn’t even see the hamburger.
philtar 10y ago
What's the difference between an official fork and an unofficial fork? Watch this project fail in X months because the project owners care more about publicity than work.
- themaveness 10y ago
  That is a bad thing to say. We need help, its a huge project. Its not just rewriting a few lines of code, there is a whole infrastructure behind the software we need help in setting up.
  - philtar 10y ago
    Then why say you guys are official and remove credibility from all the other forks? I know that's not your intention but you used the word official because "these idiots on the Internet will pay more attention to us"
ebbv 10y ago
Seems premature to announce like this before you even have a new version to show. I would think you would make the fork version and say "Here is our alternative. We have done X, Y and Z. Join us." when you announce. Anyway best of luck to you.
francoisfeugeas 10y ago
This is an excellent initiative. Can you shoot me an email to discuss how we can work together (it's on my profile) ? My company used to work with Prestashop a lot.

58 points by themaveness 10y ago

FSFE legal network may help you with licencing questions - I have a good contact there, email me and I will connect you.

JaggedJax 10y ago

I had high hopes for PrestaShop and hope this leads to the improvements the platform needs. It's so close to being great but it was not particularly stable and their API is a terrible mess of an afterthought. 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).

aritali 10y ago
I have been helping with the fork, that is the plan. First thing we have to stabilize it and fix the bugs. We are refactoring a paypal module right now that has buttons that are not connecting to anything. It calls methods that do not exist. It was something that someone made to essentially try to get over on people. 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.
- sandGorgon 10y ago
  please please use an ORM. if yoy dont build database abstraction today... you will never be able to build it once the plugins take off. Just the fact that you can run postgresql will be a killer feature. 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. http://www.doctrine-project.org http://www.doctrine-project.org http://propelorm.org http://propelorm.org
  - aritali 10y ago
    To be totally honest these are the kind of decisions that kill a platform like this. Postgres is great and everything, but the low number of hosts that adopt it would sink something like this. You really have to look at the market. The main installation user will be using softaculous or a similar installer on cpanel. Which does not support Postgres out of the box. Sure, if you have root you can add it, but that will effectively kill our US shared hosting / managed VPS market. The goal is to make it where merchants can use the software easily and it has features they want. Picking a Postgres design effectively limits us in using compatible modules out of the box and it effectively limits our hosting choices. I don't think its anything we are going to do at the start, but I would not rule out a version of it in the future.
  - themaveness 10y ago
    I get it, but honestly it is not in the immediate roadmap. Its really not something that people in the scale we are in are worried with.
    - sandGorgon 10y ago
      an ORM will help you write more maintainable code in general. Every framework right from rails to symfony uses an ORM for the abstraction it brings. 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.
      - themaveness 10y ago
        I understand it, but look at it from this point of view. PrestaShop 1.7 requires everyone to purchase new themes and modules. The code base is extremely messed up. 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.
- benmarks 10y ago
  I deal with the PayPal team regularly, and I'm sure they'd be interested in your success. Are you in/near Paris? We (Magento) have an event there in early February. Happy to meet up then or sometime / somewhere.
  - themaveness 10y ago
    We are not. We are actually spread out all around the world. Right now we are not a company, we are just agencies / developers that mad, sick and tired, and want something better. We just started this project this week and we are pulling more and more agencies on board, it is exploding under us. 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.
    - benmarks 10y ago
      Okay, I've emailed their team so that they can look into the situation.
deleted 10y ago
[deleted]
jonah 10y ago
If you're not tied to PHP, check out Spree[1] or its fork Solidus[2]. [1] https://spreecommerce.com/ https://spreecommerce.com/ [2] http://solidus.io/ http://solidus.io/
- deleted 10y ago
  [deleted]
- hardwaresofton 10y ago
  Why are they both built on rails? 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.
rmccue 10y ago
Curious: what do you find missing from WooCommerce?
- themaveness 10y ago
  I find it missing a lot of things personally. Its just a mash of plugins from different sources that have not been evaluated or secured. The package itself is pretty light, because it does not have the features of other actual ecommerce packages. You have to use plugins that were not made for ecommerce packages to extend it. 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.
- Implicated 10y ago
  I don't have the time or energy to list all of my issues with WooCommerce, but as a PHP contractor that has worked on a handful of client projects utilizing it... I could never recommend it to people trying to run a real business. The fact that it will turn off webhook delivery after 5 un-expected responses, without sending notifications of any sort, is mind boggling.
Twirrim 10y ago
Urgh. It has been several years now since I last had to deal with Magento, and nothing I've seen over the years suggests it has got any better. 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.
- ehnto 10y ago
  There is a completely re-written Magento 2 out now, in case you were curious. 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.
  - Intermernet 10y ago
    Magento have had a bug in 2.1 Since September last year which they still don't seem to have fixed which basically breaks any 3rd party import / export / sync[1]. 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.

themaveness 10y ago

I for one welcome this change. Hopefully they are successful and can fix the issues that have plagued the software for so long.

TonaldDrump 10y ago

This is great news. I don't know if anyone has been keeping up, but PrestaShop is being run into the ground. Check out the glassdoor reviews lately, https://www.glassdoor.com/Reviews/PrestaShop-Reviews-E884065.htm?sort.sortType=RD&sort.ascending=false&filter.employmentStatus=REGULAR&filter.employmentStatus=PART_TIME&filter.employmentStatus=UNKNOWN https://www.glassdoor.com/Reviews/PrestaShop-Reviews-E884065... The management seems like world class screw ups. Hopefully this will get off the ground, I signed up.

zebra9978 10y ago

where is the github repo ... the github organization ? there is no link to any source code anywhere. It may be an oversight, or a hesitation to open it too early. But here at HN, it gives me an uncomfortable feeling for a cabal that may bait-and-switch. For example, I have zero idea of whether you are going to use a MIT license or Apache or whatever. Why is this so secretive ? We have been looking to throw our weight behind an open community platform that can compete with magento. Im hoping you guys can be that... but you need to be open right from day zero. P.S. oh and I second the ORM comment. Like seriously. It will be a horrible mistake not to use one.

aritali 10y ago
I can speak to the GitHub repo and source. Basically a lot of the companies that are forking are agencies that are affiliated with PrestaShop. We are bound under certain contracts (not ones that deal with the OSL though). We basically decided this move this week. The reason the GH repo is not public yet is because we are changing the licensing (the copyright attribution not the type) and the branding. Also we are going over the code and commenting what is PrestaShop's and ours. On a basic level we are trying to do everything right with the code to cover our asses and not get sued. As for the license we are not experts in licensing, we are developers. It seems easiest for us to keep the same license that is on the code than to try to transfer it to another system. It is going to stay under the OSL 3.0. That being said, that is why we have the mailing list sign up. We are shooting to have everything cleaned by early in the week where we can release the public repo and a road map of what needs to be worked on. This is going to be a totally open source project, we are just trying to do it in a way that will not end up in us getting sued for some minor violation of the license. As for a community platform, that is what I am going for. I own an agency that manages around 800 PrestaShop websites. I see my clients leaving. I see them leaving for stupid reasons (not on their part, stupid reason on PrestaShop's part). I am trying to stop the bloodletting in my company and give my clients what I hear them asking for. Transparency is what we are going for. I want users to suggest features. I look at other platforms often and say things like 'damn that would make a nice core feature'. Its part of the reason we are breaking off. There is nothing more demoralizing than spending a day or two working on a feature for an open source platform then they reject it. Not only do they reject it, the company (PrestaShop) takes the idea and sells it as a paid module. This happened to one of our developers. tldr: We are going to be totally open source under the same OSL 3.0 license we just need to properly deal with and attribute the code before we release it to try to prevent a lawsuit.

hardwaresofton 10y ago

Can anyone suggest a good writeup on the problems with magento and the existing solutions? I honestly thought storefronts were basically a solved problem, with options like Shopify, WooCommerce+Wordpress, existing.

Walf 10y ago
Have you ever worked with Magento? With 1.8+ I found customisation very tedious and unpleasant, documentation virtually non-existent, 3rd party code unreliable, and CMS functionality lacking. Perhaps it's come a long way since then but I wouldn't bet on it.
- navs 10y ago
  Good bet. Magento 2 isn't any easier to develop for. As for the CMS, Magento has recently purchased Bluefoot CMS which I take to mean they are looking at improving the CMS experience, maybe just for enterprise sigh
  - benmarks 10y ago
    Stay tuned regarding that.
- hardwaresofton 10y ago
  Respose is a little late, but I've worked with shopify and seen a little bit of how woocommerce worked so I was just very surprised anyone would need much more for a storefront
DCoder 10y ago
I have been working with Magento CE 1.x for several years now. I have spent at least a hundred hours inside the debugger carefully stepping through the seventy layers of its core code to make sense of it. I can list a lot of problems I have seen in it. However, I cannot recommend any alternatives: I refuse to touch WordPress because it's WordPress, I have no intention of using OpenCart because I have already tried it once and its author is a crazy man, and I have no experience with Shopify or Prestashop. Business issues: * Magento is in control of your price structure. You will structure your prices in the way that Magento allows, or you will suffer. Our client was not happy with the price calculation, so we spent hundreds of hours changing it thoroughly. Do you want tier prices for product options? Too bad. Do you want customer group prices for product options? Too bad. Do you want to set discount values as "discount this much after applying all taxes" (e.g. because your shop displays only prices after tax)? Too bad, all you can do is "discount this value on the untaxed price, plus whatever reduction that makes on taxes" or "calculate the discount amount off the taxed price, then discount that much off the untaxed price". And once you have made some price customizations, the customer will find an extension that does something to the prices and breaks your changes in a creative, subtle, and unexpected way. * The CMS part of Community Edition is a joke without a punchline. It doesn't even have any menu module, only the ability to manage pages with content dumped in an RTE. * Our clients were originally in love with Magento because "we can just add all these existing modules and get all sorts of awesome functionality without having to pay you for it!" We warned them that that was a pipe dream, but they didn't listen. Now they have several thousand hours worth of custom development on top of Magento 1.x (95% of it written solely by me, no bus factor problems with that) and they're still asking for more. Last I checked, the end-of-life for M1.x is planned in December 2018, and the client has no plan for what to do then. Technical issues: * The database API has an "you want it, you got it!" mentality - if you tell it to add a unique index and MySQL refuses to because existing data is not unique, the API will parse the MySQL error message to identify the duplicated fields/values and delete the duplicate rows silently. You will get your index, but you might no longer have all your data. [0] * The model classes store nearly all the in-memory data in an untyped dictionary. You can call $model->setFoobar('12345') and later $model->getFoobar() to get it back - all unknown method calls get forwarded to a "catch-all" method which treats the method name as a key into this dictionary, and gets/sets a value of that key [1]. Most of the time, these calls are unannotated, so IDEs can't make any sense of them (see the "Undefined method" part in [2]). This magic is also a performance issue, so they make optimizations like [3] by inlining pieces of the catch-all handler code for commonly-used data. * EAV models. In theory, a workable idea, and you can even make your own EAV models if needed. In practice, you need to spend a lot of time in the debugger stepping through the code to figure out what code in the Product or Customer classes needs to be copied into your custom EAV model to make it work right, because the core EAV model doesn't have half the needed functionality. * Misleading code comments and annotations. Nothing like finding a method whose phpdoc says it returns a class that does not exist in the codebase. * XML configuration jungle: * Module configuration and theming configuration is based on heaps of XML that has no schema. Module configuration combines XML documents in the "there can be only one" manner (if two documents have XML nodes with the same path, the second one's value overwrites the first one), specifically so modules can change each other's configuration. * Theming layer operates on "blocks", which are basically a PHP class with a corresponding .phtml template file. These blocks are defined, managed, and composed through XML files. You can even encode instructions like "after creating this block, call its method foo()" in the XML. If your theming doesn't seem to take effect, you get to step through the loader to figure it if it's not loading your file, if some file loaded later is giving different instructions, or if you placed your code in the wrong place in the XML structure. Or if there's some extra XML configuration in the database specifically for this category/product/CMS page. Happy hunting! * Using third-party modules and themes is a russian roulette: * Magento includes a "Developer Mode" where php notices and warnings are turned into exceptions like in sane languages. However, lots of modules and themes have never been tested with this setting on and they cause faults on every page load - either you have to disable the Developer Mode, or fix this third-party code. * Some modules are well written, some do crazy things completely at odds with Magento workflow (e.g. an extension to set custom tier prices that calculates them when you load the product from the DB and ignores the precomputed price index in the DB), some are downright broken. And some of them contain gaping security holes – are you going to audit all the third-party code you include [4]? * Magento core JavaScript is based on Prototype.js, not jQuery, so half the modules and themes bundle their own copies of jQuery and drop them in different locations. Some of them provide a configuration setting so you can disable their jQuery and use your own, some don't. I have seen a page that loaded Prototype, ExtJS, jQuery, and Angular side by side. * As with every extendable system, some extensions don't work well together. Every module has the ability to override a Magento core class. Fun happens when two different modules want to override the same core class. * Other * Performance is demanding. You need powerful hardware and good caching to get good performance. And then you'll get that one extension that tanks your performance, like the Analytics plugin that loads each product in a category individually to send its data to Analytics when you view the category page. * Security updates are fun. When you log into the admin panel, you will see a notification about a new security update. This notification shows up because a scheduled task periodically fetches a news feed, which contains security alerts, new version announcements, marketing spam, and whatever else Magento wants to show you. You read the notification, and follow a link to the Magento downloads page. There, after logging in, you can find and download a .sh file which contains both the patcher and the patch content itself. Run it to apply the patch. If the security issue is critical enough, Magento will publish a repeated reminder to apply it a few days later. Which your news feed will again pick up and dutifully display to you, despite the fact that you've already applied that patch. You will also get a panicked call from the client because he logged into the backend and saw that message too. * Some things are just silly: * Translation manager cannot cache the translations correctly, you get different translations for the same input with caching enabled and disabled. * One class has both escapeUrl() and urlEncode() methods, and neither of them actually does URL encoding. [0]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/lib/Varien/Db/Adapter/Pdo/Mysql.php#L2739 https://github.com/OpenMage/magento-mirror/blob/magento-1.9/... [1]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/lib/Varien/Object.php#L616 https://github.com/OpenMage/magento-mirror/blob/magento-1.9/... [2]: https://imgur.com/RMxWEgR https://imgur.com/RMxWEgR [3]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/app/code/core/Mage/Catalog/Model/Product.php#L684 https://github.com/OpenMage/magento-mirror/blob/magento-1.9/... [4]: https://news.ycombinator.com/item?id=13100162 https://news.ycombinator.com/item?id=13100162

pitaa 10y ago

I wish them luck. I remember several years ago OpenCart was similarly forked to get away from the project owner's shenanigans, but that fork has had very little activity in the time since.

chrismorgan 10y ago

Argh! You’ve hijacked the Space key (which is supposed to be for scrolling) to open your weird, well-hidden navigation! … admittedly, I wouldn’t have even found the navigation if I hadn’t pressed Space.

themaveness 10y ago
I can own that, it was me. We decided to launch this on Wednesday and I am a poor designer. I needed something to quickly get up as a page to explain to people what is going on. So I grabbed a Jekyll theme and went to town. Sorry about that, I am kind of at fault. Here is the theme I used though, http://jekyllthemes.org/themes/space-jekyll-template/ http://jekyllthemes.org/themes/space-jekyll-template/
- chrismorgan 10y ago
  Remember mystery meat navigation? This is even worse: invisible navigation. Hiding the navigation behind a hamburger is OK on mobile because it’s an established pattern there and the screen is smaller so you perceive the entire screen readily; but on desktop computers? I didn’t even see the hamburger.

philtar 10y ago

What's the difference between an official fork and an unofficial fork? Watch this project fail in X months because the project owners care more about publicity than work.

themaveness 10y ago
That is a bad thing to say. We need help, its a huge project. Its not just rewriting a few lines of code, there is a whole infrastructure behind the software we need help in setting up.
- philtar 10y ago
  Then why say you guys are official and remove credibility from all the other forks? I know that's not your intention but you used the word official because "these idiots on the Internet will pay more attention to us"

ebbv 10y ago

Seems premature to announce like this before you even have a new version to show. I would think you would make the fork version and say "Here is our alternative. We have done X, Y and Z. Join us." when you announce. Anyway best of luck to you.

francoisfeugeas 10y ago

This is an excellent initiative. Can you shoot me an email to discuss how we can work together (it's on my profile) ? My company used to work with Prestashop a lot.