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.
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.