PrestaShop bad business, bad decisions

I am going to dive a bit more into bad decisions today to try to explain some of the things I said yesterday while at the same time being more clear on how management is the problem. How they have tied the hands of a software product and forced it to be a poor product by their bad decisions and inaction.

The PrestaShop Cloud

Ok. Its time to close this money costing thing down. The cloud itself was not a bad idea, it was a poor idea. It was an idea aimed to get money. The PrestaShop Cloud was an idea that was used during a venture capital funding round. It got them a lot of money too. Almost 10 million dollars it did. At the same time it missed every release schedule. It was basically forced to market because the investors were pissed. The launch was delayed for about a year, that is why they were pissed.

Still, it was not a good idea. Before the cloud PrestaShop had a wildly unsuccessful service called PrestaBox. It was pretty much the same thing as the cloud, but it had a monthly fee. It didn’t do well, it had a few holdout users that used it though.

The reason that PrestaShop tried to launch the cloud was simple. They wanted to stem Shopify’s efforts. They wanted to stem Shopify by offering a stripped down inferior product. It flopped. It flopped hard. If you haven’t noticed the cloud has been pulled in most countries now, only a few countries can sign up for it still. There was writing on the wall though, but they did not heed it. Magento offered a similar product as the PrestaShop cloud. It closed around the same time the cloud launched. It could not make money either. The PrestaShop cloud was a bad idea, it is a money suck, it needs to be closed. Let me leave you with a quote about the cloud from a PrestaShop employee last week.

‘PrestaShop Cloud is mostly for testing, and the way it was built doesn’t make for an easy upgrade. If you invested so much on Cloud, I guess this shows that your test is conclusive. I suggest you move to your own hosting, where you will be free to upgrade to the latest version too.’

The integration fund

PrestaShop started a thing called the Integration Fund. It sounded like a reasonable idea to someone I guess. The idea of the integration fund was pretty simple, they would front the cost for developers to build localized modules. Then when the modules sold on the addons store they would recoup their money and once it was recouped the developer could have a split again. This has been another failure by design. One huge reason it is a failure is price. Think about it this way, if you have one developer that wants to make a payment module for a company in Sweden and it takes 50 hours to make and he charges 50 euro an hour; what is the investment in the module? 2500 euro. If you have developer in Senegal that wants to make a module for a local payment provider that will take 50 hours and he charges 15 dollars an hour you have a different cost. The incomes in the two places are far different. PrestaShop would sell the two modules for the same price though. This effectively priced the modules in the lower labor cost countries out of the market.

The integration fund to be honest sounded like a nifty idea at first. It was poorly set in motion. It was poorly managed. It was managed in a PrestaShop way. It had potential though. Things could have been changed to produce better results and could have made the system awesome. They were not though. Its just one more stone around the PrestaShop neck.

Symfony

This is one of the issues I have that if you are a not developer it might be hard to understand. Let me simplify it. Your shop will run slower. It will use more RAM and it will take more CPU processing. This has a twofold meaning to merchants. The first is you will spend more on hosting. The second is you will realize a lower conversion rate because of the slower shop. Currently 1.7 is considered a ‘hybrid’ since it uses two template engines. It uses both Smarty and Twig. Twig is the new template engine that Symfony uses. Its slow. It slower than Smarty and less stable.

Take a lot at this article. Besides one test that used 10,000 variables Smarty wins hands down. But let me explain the columns, they might be confusing. The first column is the initial compiling of the file; this is creating the cache file. Once the cache file is created you will be seeing the values of the second column on your site. The rendering of Smarty templates as compared with twig are anywhere from 50% faster to 500% faster. This is ecommerce, speed matters.

The big underlying issue with Symfony is the code base. Its huge. PrestaShop has grown to over 1 million lines of code because of it. Being huge is one thing, but it is dumbed down which makes it even worse. See Symphony is a framework, this means parts don’t have to be developed by the core developers anymore. What this also means is a part of PrestaShop that might have been 200 lines of code is now bloated to 2000 lines of code to do the same operation. PrestaShop did recently write an article about the performance of 1.7 versus 1.6, it looked good actually. Unless you knew what to look at. If you look at the 1.7 theme you might notice something. It is stripped down. Especially compared to the 1.6 PrestaShop default theme. Less images, less modules, less functionality. So it almost won. That is pretty depressive if you ask me. They basically rigged a test to make it look better than it is. This is a shame.

One thing I would like to make a note of is a comment I received yesterday. It was from a PrestaShop user lauding the new template inheritance. This is something that could have been done in 1.6 just fine. The user dismissed every bad thing about 1.7 for one feature. One feature that would work fine in 1.6. This one feature will be problematic though. When multiple modules start using it, problems will happen. It’s sad he is thinking about his own pocketbook and not the user base. I assume he has taken a cue from PrestaShop in his thought process.

The themes

I say themes, because there are actually two themes that PrestaShop developed. There is the classic theme that is enabled when you install PrestaShop 1.7, but there is another theme as well called the starter theme. The starter theme is a theme for developers that is void of pretty much all CSS and structure to let developers do what they want. Sounds reasonable. I guess someone in management thought that and made it happen. In reality it’s not. Its as huge problem.

If you are a merchant you more than likely do not know what is going on behind the scenes. What is happening behind the scenes is standardization. PrestaShop 1.6 included a library called Font Awesome. If you are not familiar with this library, it is pretty cool. It is a font of icons on a basic level. If your theme has a cart icon, a Facebook icon, a Twitter icon, it is more than likely using this library. It helps with standardization. It is no longer included in PrestaShop. Let us say you buy a module that adds another row of sale products on your home page. The developer has to include the cart icon now for the add to cart button. If there is a wishlist, he will need to include that icon as well. How can be ensure they match what your theme uses? We cannot really. What is going to happen is most developers will more than likely include Font Awesome with their front end modules. Sounds pretty reasonable. Until you have 5 modules loading the same 250kb file. Then it becomes a headache that slows your site down. Because in reality PrestaShop does not care about the speed of your shop.

Another thing you might notice about the new theme is that the images are all scalable vector graphics (svg) with weird names. This is thanks to a program they use called Webpack. It seems nice, it packs everything into little files so your theme can use them. Its not though. Instead of loading one file you now have the overhead of loading several small files with randomly generated names that modules will never be able to access. This kills standardization. This makes it harder to buy a module and it work correctly. That is what we all dream of isn’t it? Buy a module, install it, and it works perfectly with our shops. This is a monkey wrench in that. This also means that to make simple changes to your shop’s template you will need even more programming knowledge. Because that is what shop owners want, right? They want to secretly be programmers. No, it is to open more revenue streams for PrestaShop and their network of developers.

The last major omission was a complete CSS framework. PrestaShop 1.6 had this. It was not the best, it worked though. When Template Monster wrote it (yes, they wrote the PrestaShop 1.6 theme) they butchered a lot of the underlying framework called Bootstrap. This did not mean Bootstrap was bad, it meant bad developers implemented it. Never fear though. 1.7 has removed most all functionality associated with it save the grid and a few other items. Now module developers can write their modules and hope they work with your theme.

Finger pointing

Now I am going to start getting personal and pointing fingers. I am going to point out some things you might not know or might have never heard of. But they all matter.

Sebastian Levaillant

He was one of the PrestaShop employees that responded to my post yesterday. You can read his response here. My main take away from his response was this. PrestaShop has around 125,000 active shops (this was not in his response but it helps us math things) they only consulted 50 shops about features for PrestaShop 1.7. Did they consult you? Do you know anyone they consulted? If you are in France you actually might. Because they really did not consult with anyone outside of France. 50 merchants. Look, I am not unreasonable, 1250,000 shops is a lot. But they only consulted .04% of all the active shops. Not even a half of one tenth of one percent. This is something that should have been handled better. Use polls. Use wide reaching surveys. Something better than reaching .04% of your user base.

Julien Martin

My exposure to him, like Sebastian is very limited. Once actually. I read a chat log between him and a couple of other community members regarding the saving bug in the 1.6 versions. If you are not familiar with this bug, here is a link to it. The bug, which I call very loosely, because its not actually a bug. Its lazy code. Lazy code that Julien as the lead core developer owned. What the issue was is Google Chrome said they are changing how Javascript is handled. They announced that a year and a half ago. They even announced round about when the browser would stop supporting this way of handling Javascript. He led a lazy team and did not change the way it was handled. So lots of shops broke. Onward to me pointing a finger at him though. What I saw in the chat logs really kind of shocked me. When one of the community members asked why the fix was taking so long (the was on day 6–7 of things being broken) he responded ‘Sorry to have a life… I will not sacrifice my life for it’ The user then pointed out all of the merchants that were affected and how they were bothered by it. He left saying ‘I remember why I’m never on Gitter …’ which Gitter is the chat that the development community uses to talk to the PrestaShop developers. He does not care about you or your shop. He cares about Julien.

Mickael Andrieu

You get an honorable mention for your replies yesterday. You tried to defend Symfony here, and then you tried to act like it was a Chrome bug and not bad coding. Both are wrong, you are wrong.

I used to find joy in PrestaShop and the community. I used to love working with it. I used to..