Prestashop: No carrier available in checkout with free shipping cart rule

[e-perrodon]

EDIT: to get the reproductible scenario, jump to https://github.com/PrestaShop/PrestaShop/issues/11172#issuecomment-502165356 ◀️

Describe the bug
When I apply a free shipping cart rule whith a code on a specific product, no carriers are available in check out, only on my production environment

To Reproduce
Steps to reproduce the behavior:

1. Update Prestashop from 1.7.4.1 to 1.7.4.2 and 1.7.4.3 with 1 click upgrade module on DEV environment.
2. Push new sources to PROD environment with git
3. Apply upgrade.php script to update database
4. Create cart rule with code and free shipping on specific country (France) and specific product
5. Order the specific product and choose a delivery address to France
6. A carrier is proposed. Apply code. Voucher is ok but no carrier are available after updating.

Steps to reproduce the issue [Khouloud]

1. Create a cart rule "Free shipping" with/without code
2. Create any cart rule without code & disable it
3. Go to the FO => add some product to the cart => complete the checkout process => in the SHIPPING METHOD step => add the code for the first cart rule (free shipping)
4. Go to BO => Enable the second cart rule
5. In step 3 => reload the page => "Unfortunately, there are no carriers available for your delivery address." is displayed

https://drive.google.com/file/d/1JWZ_iX-EpXKvwepfj9B4usDZYBBUQCBz/view
Additionnal information
PrestaShop version: 1.7.4.3
I haven't problem in DEV environment. If i get a dump from PROD and set in DEV, I reproduce problem.
Something must be wrong in database but I can't find what is it...

[e-perrodon]

I managed to work around the problem forcing flush when calling $this->context->cart->getDeliveryOptionList in getDeliveryOptions function in classes/checkout/DeliveryOptionsFinder.php
But it's not really a solution...

[khouloudbelguith]

Hi @e-perrodon,

I did not manage to reproduce the issue after upgrade from 1.7.4.2 to 1.7.4.3 using the 1-click upgrade 1.7.4.3.
I attached a video record.
https://drive.google.com/file/d/1mSCzwvkDUs7BBiXoPqzLkWDHMRhxPUwX/view


Thanks to check & feedback.

[e-perrodon]

Hello @khouloudbelguith,
I think it's not easy to reproduce this bug...
How i said, i put new sources, got by 1-click upgrade on DEV env, with my personnal git on my PROD env.
Then I execute upgrade.php to update database.

A normal upgrade with the module works as expected.

[khouloudbelguith]

Hi @e-perrodon,

We need to retrieve the PHP error log and the debug mode report in order to find out what's wrong.
Don't you know how to get this information? Please read the following article:
http://build.prestashop.com/howtos/misc/how-to-create-bug-report/

Thanks!

[e-perrodon]

@khouloudbelguith, sorry but i haven't any error in php error log and bug report.

[khouloudbelguith]

@e-perrodon, It seems that your issue is not a PrestaShop's core bug but most likely a server configuration or customization problem.
Thanks!

[khouloudbelguith]

Hi @e-perrodon,

Since we had no news from you for more than 30 days, I'll close this ticket. Feel free to open another one if you can give specific details.
Thanks!

[krystian-3c]

Same problem here.
Prestashop 1.7.4.3 when product triggers free delivery discount I get no available carriers message. No errors on dev mode nor in error log.
Problem is hard to reproduce.
On my development instance after upgrade everything works great (even on production database copy).
I tried cleaning cache in backoffice, reloading vendor folder and manually removing var/cache folder.
I'm using GIT on production, there are no changes outside ignored folders.
What else can i try?

[khouloudbelguith]

@krystian-3c, have you the same issue with this ticket: https://github.com/PrestaShop/PrestaShop/issues/10903#issuecomment-438233641?
Thanks!

[krystian-3c]

I'm afraid not. I tried the discount configuration shown in your video in the comment. It works fine on my instance.
But I get the same symptoms when I change discount action to free shipping.
Dont know if that helps, but I've done some debbuging on my side, and I've learned that if I comment out line 771:

$gifts = $this->getCartRules(CartRule::FILTER_ACTION_GIFT);

delivery methods starts to show up. I wend one step further, and I only commented out the part of getCartRules - line 512-513:

$row['value_real'] = $row['obj']->getContextualValue(true, $virtual_context, $filter); $row['value_tax_exc'] = $row['obj']->getContextualValue(false, $virtual_context, $filter);

I stoped there when I saw that the method has been called several times on one request.

[khouloudbelguith]

@krystian-3c, if you enable the debug mode, are there any exceptions displayed on your FO, in the shipping step.
Thanks!

[krystian-3c]

@khouloudbelguith Unfortunately nothing.

[khouloudbelguith]

@krystian-3c, the same issue reported here: #10903 with free shipping

Steps to reproduce the issue

1. Create cart rule
   1.1 without code
   1.2 In the condition Tab "Minimum amount 100 EUR & Shipping included
   1.3 In the actions tab, apply any action => Free shipping
2. Go to FO, add to cart a product which price = 70 EUR < 100 EUR (must be < 100 EUR) => so the cart rule is not applied
3. Complete your order => in step 3: SHIPPING METHOD => Unfortunately, there are no carriers available for your delivery address.

Thanks!

[krystian-3c]

In my case there is no cart value restriction (it is set to 0). Only restriction is date and manufacturer.

[khouloudbelguith]

@krystian-3c, in my case, I did not manage to reproduce your issue.

What to Check If PrestaShop Carriers Are Not Available At Checkout?

1. Carrier Is Inactive: PrestaShop carrier status is the first thing you should consider
2. Incorrect Zone Assign or Country Disabled: Zone association is among the first things to check if a created carrier does not show for a specific shopper. When configuring PrestaShop carrier you are supposed to assign it to zones, this very carrier can deliver parcels within. If a carrier is not assigned to the zone, customer address belongs to, then it will not show as a delivery method at the checkout.
3. Carrier Is Not Allowed for Customer Group: This detail might easily be skipped, since you can have hundreds and thousands of customers, belonging to various customer groups. If some customer belongs to the group that is not served by current shipper, it will not be offered as delivery method for this customer
4. Weight or Price Ranges Are Not Specified: Creating PrestaShop carrier you usually define billing cost for each by one of criteria: order price or weight. Having selected a suitable method, you need to create ranges and set prices for them. In case ranges are not created, “The product selection can not be delivered by the available carrier(s). Please amend your cart” message will display at shipping step for a customer.
   5- Package Dimensions Are Out of Range: If all above listed settings are configured properly but still PrestaShop carrier does not display at the checkout, you have to compare package dimensions with maximum dimensions PrestaShop carrier can handle. If package goes beyond these limits, the carrier can’t ship it and, respectively will not display as a delivery method.

Thanks to check & feedback.

[krystian-3c]

I'm afraid it's not about configuration data, how I said before, the problem doesn't exist on my dev instance witch is working on a copy of production database. There are no difference in code outside ignored files from:
https://github.com/PrestaShop/PrestaShop/blob/develop/.gitignore

The problem first accured after shop upgrade.

I assumed that its some kind of problem with cache. But I cleared cache using BO. Additionally I reloaded vendors folder and I removed Symfony cache folder.

Still problem exists. I hoped that there is some other solution I can try before reinstalation.

[khouloudbelguith]

@krystian-3c, in your case there are no errors in your log file, no exception.
The only issue that we can reproduce https://github.com/PrestaShop/PrestaShop/issues/10903 & it is added to our bug roamp.
Despite our several trials, we could not reproduce your issue with the provided information.
It seems that your issue is not a PrestaShop's core bug but most likely a server configuration or customization problem.
I invite you to contact our support team: http://addons.prestashop.com/en/388-support to help you solve your issue.
Thanks!

[sulwen]

I can reproduce this 100% of cases through this:

Create a basket rule with code, and set rules as follows:

Then apply your code at checkout.

[khouloudbelguith]

Hi @sulwen,

Sorry, but I did not manage to reproduce the issue with PS1.7.5.0 & PS1.7.4.4 when applying the same configuration described by you.
Thanks!

[thbl]

I got the samme problem

[khouloudbelguith]

Hi @thbl,

Did you use a minimal amount in the condition tab of your cart rule created?
Thanks!

[crishnakh]

In 1.7.5 the problem persist. This solution works, temporally, but if you filter by carrier in the discount, this solution is not working.

I managed to work around the problem forcing flush when calling $this->context->cart->getDeliveryOptionList in getDeliveryOptions function in classes/checkout/DeliveryOptionsFinder.php
But it's not really a solution...

[crishnakh]

Sometimes I still have this problem. I commented this line, and force flush on getDeliveryOptionList function. Not the best option...

$gifts = $this->getCartRules(CartRule::FILTER_ACTION_GIFT);

[tomlev]

@khouloudbelguith could you please check if this issue occurs in 1.7.3.x versions ?
Just to know if this is a regression in the 1.7.4.0 cart refact or not

[khouloudbelguith]

HI @tomlev,

No, I did not manage to reproduce the issue with PS1.7.3.4.
I attached a video record.
https://drive.google.com/file/d/1Yn4ho6X2wzTTxzUs-ghzK3xoj5fc5c_s/view
Thanks!

[sulwen]

Still present in 1.7.5.0

seems like this is broken.

too late for me to dig more, but seems like
new CartRule wipes the $results table in:

foreach ($result as &$row) { $row['obj'] = new CartRule($row['id_cart_rule'], (int) $this->id_lang); $row['value_real'] = $row['obj']->getContextualValue(true, $virtual_context, $filter); $row['value_tax_exc'] = $row['obj']->getContextualValue(false, $virtual_context, $filter); // Retro compatibility < 1.5.0.2 $row['id_discount'] = $row['id_cart_rule']; $row['description'] = $row['name']; }
line 512 in classes/checkout/Cart.php

[crishnakh]

HI @tomlev,

No, I did not manage to reproduce the issue with PS1.7.3.4.
I attached a video record.
https://drive.google.com/file/d/1Yn4ho6X2wzTTxzUs-ghzK3xoj5fc5c_s/view
Thanks!

But I have the problem with carrier filters. It's like when you add filters on discount for carriers and for products, yo got empty delivery method.

[pulsationseutrr]

Same problem here. When i apply a voucher for Free Shipping, i have this error "There is unfortunately no carrier that can deliver to your address."

But if i remove voucher its okay...

For view the error juste create a Free Shiping Voucher and dont forget to hit F5 after applying it

[ftardio]

HI @tomlev,

No, I did not manage to reproduce the issue with PS1.7.3.4.
I attached a video record.
https://drive.google.com/file/d/1Yn4ho6X2wzTTxzUs-ghzK3xoj5fc5c_s/view
Thanks!

I also have the same problem in Prestashop 1.7.5.0.

A tip to reproduce: If you only have an active voucher (configured to get free shipping), it works and lets you choose a carrier. But if you have several vouchers in your shop, and one of them is for free shipping, then you get "no carrier available" at checkout when using this voucher, no matters if the others vouchers are not appling to your order. If you deactivate the others, and let only the "free shipping" voucher, you get again your carrier available.

I'm using Prestashop 1.5.0, and only one carrier in my shop (and obviously, is configured to be available for my country). The only difference for getting the carrier available or not is to have several vouchers active or only one for free shipping.

[khouloudbelguith]

Hi @ftardio,

I tried to create several discounts & it is OK with PS1.7.5.2.
I attached a video record.
https://drive.google.com/file/d/1m5hmHLpJVizbd_GaOg2GZGXMrbx9IRKR/view
Thanks!

[ftardio]

Hi @ftardio,

I tried to create several discounts & it is OK with PS1.7.5.2.
I attached a video record.
https://drive.google.com/file/d/1m5hmHLpJVizbd_GaOg2GZGXMrbx9IRKR/view
Thanks!

Hi!

Thanks for your response. But I tried in two different stores, with different themes, different products, and different carriers and I get the same problem!

I also recorded a video to explain the problem: The first voucher (VOUCHER_TEST) is for free shipping. The second one is for getting some discount if you spend enough money (no related to shipping, and not applied to the cart in this case). You can see what happens when I activated only the first (free shipping), and both:

https://drive.google.com/open?id=1GBAqXV-YLTx_fiiQTsYJz_NQgK5v0BsY

More info: The problem is not related to the second voucher, I can create any other and the same happens, but it MUST NOT HAVE A CODE (for automatic checking its application to all clients).

Update: I made more tests: If BOTH vouchers applies to my cart, then it works (I get free shipping and carrier to choose), but if only the first one applies (free shipping), and the second doesn't, I get no carriers.

[khouloudbelguith]

@ftardio, thanks for your feedback.
Your link is not available: Oops!
We couldn't find your video.
Thanks to check & feedback.

[ftardio]

@ftardio, thanks for your feedback.
Your link is not available: Oops!
We couldn't find your video.
Thanks to check & feedback.

Thanks for your reply. I made a mistake uploading the video, it's online again using this link:
https://drive.google.com/open?id=1GBAqXV-YLTx_fiiQTsYJz_NQgK5v0BsY

[khouloudbelguith]

@ftardio, thanks a lot for your feedback.
I manage to reproduce the issue with PS1.7.6.0beta1 & PS1.7.5.2.
Steps to reproduce the issue:

1. Create a cart rule "Free shipping" with/without code
2. Create any cart rule without code & disable it
3. Go to the FO => add some product to the cart => complete the checkout process => in the SHIPPING METHOD step => add the code for the first cart rule (free shipping)
4. Go to BO => Enable the second cart rule
5. In step 3 => reload the page => "Unfortunately, there are no carriers available for your delivery address." is displayed

https://drive.google.com/file/d/1JWZ_iX-EpXKvwepfj9B4usDZYBBUQCBz/view
I tried to disable/enable with one cart rule => OK.
I’ll add this to the debug roadmap so that it’s fixed. If you have already fixed it on your end or if you think you can do it, please do send us a pull request!
Thanks!

[frihauge]

I allso see the issue on 1.7.5
I have 3 discount rules with prio 1,2,3 which add a free produkt at a given amount.
If i enable all tree and it reach the number 2 discount it view "Unfortunately, there are no carriers available for your delivery address"

[jf-viguier]

I'm facing this issue in 1.7.6

[khouloudbelguith]

@jf-viguier, here's the PR: https://github.com/PrestaShop/PrestaShop/pull/14381 to fix the issue, but it is still in progress.

Thanks!

[jf-viguier]

@khouloudbelguith the PR: #14381 only add some tests, I can't see any fix. Is the PR #12878 evaluated by the ore team ? It fix my bug too but I can't evaluate if this code has side effect.

[olecorre]

I am also facing this problem in 1.7.6

[prestamodule]

It should be tagged as Major and integrated into a patch release

[khouloudbelguith]

@jf-viguier, yes you are right.
This issue is targeted as the TopWatcher issue.

Thanks!

[marionf]

@prestamodule

It should be tagged as Major and integrated into a patch release

No, it shouldn't be included in a patch release as it's not a regression.
We fix in a patch release only regression of the last minor version

Furthermore this issue is realy hard to fix, any help is welcome :)

@ttoine

[kpodemski]

@marionf

i really don't understand this "it's not a regression"... guys, it's a bug which prevents people from completing an order - in e-commerce software... shouldn't be this major issue?

[jf-viguier]

@marionf it's a regression from Prestashop 1.6
@kpodemski I totally agree.

[marionf]

@marionf it's a regression from Prestashop 1.6

Yes, but it's not a regression of the last minor version (1.7.6.0), so it will not be fixed in a patch version even if it was defined as major

[kpodemski]

@marionf @eternoendless

you guys really need to rethink this strategy, because i completely understand angry people, if you can't complete checkout it's not something what you can just postpone to next version, especially that it's very common to just move major issues from version to version, first label 1.7.4, no time, second label 1.7.5, no time, third label 1.7.6 no time and this way we have Issues reported over a year ago, important ones, still not fixed...

[Anidatte]

@kpodemski Indeed. I'm facing this issue for some time, still waiting for fix. Placing orders is mandatory functionality, if it's not working correctly, what is the purpose of using ecommerce software like this?

[eternoendless]

In our day-to-day terminology, a regression is a _new_ bug introduced in the last _minor_ release. Admittedly, it's "language abuse" that we use to tell new bugs from old bugs apart.

In patch releases, we only accept fixes for "regressions" created in the last minor version and security fixes. We do this in order to limit the number of releases we make. Other bugs are fixed in subsequent minor releases, according to prioritization and ratio of difficulty over value provided by fixing them. Remember that we have 600+ open bugs right now.

I think that fixing old bugs while ensuring no new bugs are created is how we progressively increase the overall software quality.

Let's face it: one of the main problems with PrestaShop is that some parts of it are extremely complex and very fragile due to bad design. Any change in those parts usually leads to new bugs (aka regressions). To properly fix bugs in those subsystems, we need to do two things:

1. Write integration tests that verify the system works as expected. A bug fix should start with writing a test that fails because of the bug.
2. Fix the bug, and apply refactoring as needed.

We started doing that for cart calculation, and thanks to it it's improving. However, we still have some problems that prevent us from moving forward:

• Test coverage is very much insufficient right now
• Refactoring options are limited due to backwards compatibility constraints (I'm actually writing an article about this problem because it's a major headache).

Regarding this particular bug, I haven't looked at it myself, but it seems that it's very hard to fix without incurring in a high risk of introducing new bugs, and it requires a large amount of work. It doesn't mean it _won't_ be fixed.

Regarding the proposed PR, and specially in these delicate cases, providing a fix that includes a detailed technical description of the problem and the solution (random example) as well as automated tests will help for having it accepted. We're not being strict because we're living in fairlyland, or because we're into "code beauty". It's because we wan't to avoid regressions as much as possible.

We are well aware that this bug is problematic. As for minor/major, remember that it's about the _severity_, not the _priority_, and this value has a limited impact on prioritization.

[ttoine]

fixing old bugs while ensuring no new bugs are created is how we progressively increase the overall software quality.

This is the key, even if it might take time to find the right way to do it.
What you guys prefer: a quick and dirty fix like it has been done in the past too many times?

[ftardio]

The main problem here is that this bug is not evident, so anyone can be having this in his store and doesn't know until a client claims because it. And when this happens (if it happens), you can have lost a lot of sales and even clients, because they can't finish their orders at your store. So, in my opinion, any bug that prevents finishing an order should be important enough to priorize it.

The bug was informed some months ago, and several new PrestaShop versions have been released, while it remains unsolved. As already said, I don't agree this strategy.

[kpodemski]

@ttoine @eternoendless

to be honest i don't recall many situations (if any) where fixing something introduced more problems, path versions were very common and people trust them, because upgrade process was WAY easier than for example from 1.7.2 to 1.7.6, and i'm with PrestaShop for over 10 years, it's more likely that newly migrated pages will introduce new problems, and because of your strategy, we will not have this fixed (this problem with shipping cart rule) in 1.7.7 but in 1.7.8, 9, 10 or later, simply because migrated pages have higher priority.

Sorry, but this is not a first problem with checkout process, many people are aware of the issue where if you edit your billing address you cannot complete order, still, first report was on forge many months ago and fix has been pushed between versions.

Merchants don't really care about excuses you're writing, or your day to day terminology, for them it's simple, if people cannot complete checkout in PrestaShop, you need to do anything in your power to prevent this from happening. This is e-commerce software, every time someone cannot complete checkout people lose money.

My idea: stop migrating new pages, no merchant really cares about this anyway (sorry but that's true), focus on https://github.com/PrestaShop/PrestaShop/issues?q=is%3Aopen+is%3Aissue+label%3AMajor

Cool example: https://github.com/PrestaShop/PrestaShop/issues/10766 - issue reported year ago, moved from version to version, now there's an idea to fix this... on migrated page :D and you really think that it's more safe than simply change this behavior on existing page?

Oh, and for the tests, the thing is that tests are written to match fresh installation of PrestaShop, you know that people migrating from 1.6, right? Many of this issues are related to migrated versions of PrestaShop or just custom theme (like translations). Because of that people don't trust new versions, they are willing to update from 1.7.6.0 to 1.7.6.1, but it's way harder for them to trust that going from 1.7.6 to 1.7.7 will go smooth.

Guys, i'm developer, i'm happy that we have Symfony, implementation of CQRS, behat tests, really, that's great! But real users of PrestaShop don't really care... and they don't trust you, autoupgrade module is still too problematic for many of them. The truth is that you cannot even update between 1.7.2 to 1.7.6 without loosing informations about employee access to BO tabs etc.

I really hope that one day we'll have quicker releases, stable autoupgrade, and people who will finally trust that upgrade != problems.

[kpodemski]

The bug was informed some months ago, and several new PrestaShop versions have been released, while it remains unsolved. As already said, I don't agree this strategy.

This is exactly what i'm thinking... guys look at the labels, 1.7.4, 1.7.5, 1.7.6, now 1.7.7. People are going here, creating issues, and they're simply ignored, even tho @khouloudbelguith is doing her job great with reproducing these issues.

Like i said, this is because bugs are not that important for you, it's better for you to have 2 more pages migrated to SF instead of -2 major issues. That's a way i see this, and it's sad and annoying.

@eternoendless don't get me wrong, i'm really a fan of current progress of the software, new dev team and things we have as developers, but my day job is to bring this software to merchants, which are annoyed and angry every time i say: "sorry, it's a PrestaShop problem, but we'll handle this, tho we need more budget"

[ttoine]

Like Henri Ford told, if he would have listen strictly to people needs, they would have asked for faster horses, not for cars. You have to fix customer problems, but also to think about the best way to do it and sometimes, it means new ways. Cars also introduced new problems: horses don't leak oil and cars don't start with hay.

Migrating pages on Symfony, or supporting PHP 7.3/7.4, improving the overall quality of the software with a long term vision is mandatory for the success of the PrestaShop software. And it's already the case on many topics, there are a lot of good feedback already even from you.

About this very issue, a lot of man time has been spent already, so it's not like if nobody worked on it at all.

About the test on new installation versus migration, you are right. The good news is that it's in the pipe now, as discussed yesterday during the demo/retro.

Unfortunately, for tests, we rely also on the community: this is impossible to discover and describe all the testing scenarios all by ourselves. Instead of just complaining, I guess that you have the skills to do it, show us a good example of a pull request described by @eternoendless with description, tests and problem resolution. I am sure everybody will be pleased to follow the example then.

[matks]

My idea: stop migrating new pages, no merchant really cares about this anyway (sorry but that's true), focus on https://github.com/PrestaShop/PrestaShop/issues?q=is%3Aopen+is%3Aissue+label%3AMajor

Hi, @kpodemski you are right: merchants do not care about PrestaShop being powered by legacy system or Symfony system. However, if we stop the migration, we simply kill PrestaShop.

Why ? Because this is 2019 (soon 2020), and in 2019 modern and robust software relies on either Symfony or Laravel (like the wonderful https://sylius.com/ for example, a e-commerce framework powered by Symfony).
In order to be able to keep living, PrestaShop needs to motivate developers to use and contribute to it. And it needs skilled developers who can ship documented, tested and high-quality reliable code. We seek these people, but they refuse to work on PS 1.6 (and the legacy part of PS 1.7) because, in their opinion, it's a technology from the past.

It's a question of survival. If PrestaShop cant migrate to Symfony, nobody will be willing to work on it in a few years.

Very often we have a developer saying "hi, I want to develop a module for PS, but seriously what is this project ? it looks like code from the year 2000 ! I heard you guys are migrating to Symfony, do it faster because there is no way I will do modules for this CMS right now, I'll go use Sylius or Magento else". This is a dev who did not use PS for 10 years. So the 1st time starts he uses it, he compares it with his other current projects, all either Symfony or Laravel projects, and he just does not understand how far behind PrestaShop looks like ... There was not even a composer.json in PS 1.6 ! Modern php software uses Composer.

Look at Drupal, Magento, Joomla, eZ Platform ... they all did the migration we are doing now. For the same reason: Symfony is a powerful framework that will bring in many benefits and not using it means no modern php developer will be willing to contribute/develop on PrestaShop.

By the way this is the same reason why we'll have, in the future to stop using jQuery and use a modern JS framework, likely Vue.js . Right now it is impossible to hire a senior JS developer and ask him to work with jQuery. It has to be Angular, React or Vue. We have been trying to hire a JS senior developer for 1 year now and we could never find one because for them, using jQuery is just like using PHP3.

Young developers in developers school now think that server-side rendering is forgotten and think that echoing some html, be it with php, smarty or twig, is stupid and against logic. They think backend development means building APIs, and rendering must be done on browser side. It's sad but this is what we hear from the developers who teach in such schools.

Same for Twig versus Smarty. Please compare https://github.com/smarty-php/smarty project activity versus https://github.com/twigphp/Twig activity. If PrestaShop stays on Smary, it will become a technology from the past, unable to motivate modern php developers to start writing it.

This is why, in every minor version upcoming there will be:

• bug fixes (because fixing bugs is important)
• improvements
• refactoring
• a few new features, that merchants are waiting for
• and BO pages being migrated to Symfony

This way, we'll ensure that PS 1.7.7 will be better than PS 1.7.6 that was better than PS 1.7.5 that was better than PS 1.7.4 . This is what we mean by "no regressions": we cant fix all bugs at once, but each version we release, if we break something, this is a regression and this one we fix it. So for every incoming version we allow ourselves to only enhance the software, we refuse to add issues. We refuse to lower the level of quality of each minor version, we only allow ourselves to increase it.

So the "no regression" rule means: every thing that is working in PS 1.7.5 will be working in PS 1.7.6 and will be working in PS 1.7.7 and will be working in PS 1.7.8 . We cannot promise every thing that we know are broken in PS 1.7.5 will be fixed soon, but we can promise we do not add any issues to the stack. We only make things better, not worse.

By the way there is already a bunch of "major" bug fixes delivered for PS 1.7.7: https://github.com/PrestaShop/PrestaShop/pull/14558, https://github.com/PrestaShop/ps_shoppingcart/pull/41, https://github.com/PrestaShop/PrestaShop/pull/14263, https://github.com/PrestaShop/PrestaShop/pull/14263, https://github.com/PrestaShop/PrestaShop/pull/14452 and there will be more but we cannot focus only on it. Shipping only bug fixes means not to make any progress. And in the meantime, Woocommerce, Magento, Sylius, Shopify are moving forward. They are not waiting for us.

Look at those design issues that @eternoendless listed: https://github.com/PrestaShop/PrestaShop/issues/14994 this is pure technical debt and this is why we need to continuously refactor, improve, add more tests and be very strict in pull request reviews. Fixing the bugs will not fix these design issues. PrestaShop needs change because its very core is flawed. And this is why we upgrade CLDR (causing the currency issue for 1.7.6 that required 1.7.6.1 patch version) and this is why we migrate to Symfony.

[jf-viguier]

Thanks @matks for this explanation, but can you explain to me why, with a modern framework like symfony, so much bugs are added when legacy part are migrated by "modern developers" ? The symfony framework should make things simplier and easier to debug ?
The cart and cart rules proccess is very complexe : so much bugs with this. Maybe this part should be redesined and rewrited from scratch and break compatibility ?

[ttoine]

@jf-viguier please read again @matks long comment, there are most of the answers already to your questions.

Using technologies like Composer, Symfony, and other top component is the way modern softwares are developed and the way good developers are working (there are equivalent in other languages). It is an investment in the future. And, of course, I bet that when it will be finished, new ways will have emerged, and it will be time to start to move to something else.

30 years ago, building apps with VisualAge and Smaltalk was the top. 10 years ago, Eclipse IDE and Java was the top for cross-platform apps. And now, VScodeis is based Electron + NodeJs and apps are rendered in browsers with cloud based backends. Who knows what will be the future?

The only thing that we can be sure, is that if PrestaShop wants to be there in 10 years, it must embrace the move to continuous improvement and use the popular technologies to attract contributors.

As for redesigning and rewriting such a big part, yes maybe you are right. But who will make it and how much time will it cost? You are already blaming the team for not fixing it as fast as you would like it...

[jf-viguier]

Thanks @ttoine for your answer but merchants and agencies are in ecommerce course, not in technology course, that's the main divergence. The balance has to be found between bug fix and technology improvement, it's not an easy one and thanks to all prestashop core team to do they best for this.

[matks]

Thanks @matks for this explanation, but can you explain to me why, with a modern framework like symfony, so much bugs are added when legacy part are migrated by "modern developers" ?

Because we are developers, and every developer makes mistakes, especially when working on a complex codebase like PrestaShop with very few docs (neither technical nor functional), no tests.
But when we create bugs when migrating a page to Symfony, this is a regression: this means it gets fixed in a patch version. This is what we promise with the "no regression" rule, this is why we say it enhances the quality of PrestaShop. We try to break nothing, and when we do, we fix it immediately 😉.

Of course we make mistakes when migrating pages. Nobody can migrate a page from one framework to another without making any mistakes. We try as hard as possible to not make any regressions but we miss some.

Please look at this: https://github.com/PrestaShop/PrestaShop/issues/13989 this is the check-list we use to try to make sure we forget nothing. On top of that, new pages get new integration tests and go through a full round of QA. We can definitely do better, but please trust me when I say we are doing everything we can to migrate things as smoothly as possible.

Also, no matter the framework, bugs are everywhere. Using a modern framework or an old one will change nothing. You can make awesome code and applications with old tools and crappy code and applications with shiny new frameworks. But if you want to hire, if you want to attract new developers, you have to use modern tools and technologies.

I actually dislike this trend which targets "always the latest tech" and I am not convinced at all about, for example, modern JS frameworks 😢(I think they are over-used in a lot of usecases where plain jQuery would be a lot more relevant) but this is how the development world works now. This is what we see when we try to hire new developers and they choose another job offer because in the other job offer they get, they say they are using PHP7.3, Symfony, the frontend is fully powered by React and database is PostgreSQL.

The symfony framework should make things simplier and easier to debug ?

Depends on the part. Symfony indeed provides a nice stack trace tooling and the Service Container is very useful to track dependencies, which is better than the legacy system which uses singletons.

But there will be no magic change. Symfony will enable new capabilities, but PrestaShop will stay a big, complex software because it's e-commerce and e-commerce world is complex. Look at Sylius. It's powered by Symfony but it's still complex.

For example Symfony CLI is something powerful that is new to PrestaShop. Symfony authentication system has a wide range of features that, once login page will be migrated, will be available to you. You will discover that modifying how someone gets authenticated on the BO can be modified/configured in a lot of different ways, very easily. Symfony is a framework, this means it is a platform on top of which you build things. Want to connect on a ElasticSearch database ? There's a Symfony bundle for that. Want to send messages into a RabbitMQ broker ? There's a Symfony bundle for that. Want to define a complex URL like /send/me/there/{productId}/another/path_{combinationId} ? You had to modify htaccess with PS 1.6, Symfony will allow you to do it in 1 line.

Symfony is good at what it does, which means if we integrate it within PrestaShop, we'll benefit from the quality of the framework. They care a lot about performance, extensibility, security (! important topic !) so we'll benefit from all the work they have put in it.

Also, what will make PrestaShop easier to debug and easier to develop is the work we bring in while migrating the pages. Symfony is just the background, we move old code, add validation, add checks, add Exceptions, remove carry-everything-arrays and replace them with objects with identified getters and setters, we add integration tests (and unit tests when eligible). We also upgrade the UI of the page.

Please compare:

• legacy AdminCurrencyController https://github.com/PrestaShop/PrestaShop/blob/1.7.5.x/controllers/admin/AdminCurrenciesController.php
• migrated CurrencyController https://github.com/PrestaShop/PrestaShop/blob/develop/src/PrestaShopBundle/Controller/Admin/Improve/International/CurrencyController.php

And tell me which one looks cleaner 😉

The cart and cart rules proccess is very complexe : so much bugs with this. Maybe this part should be redesined and rewrited from scratch

200% agree and this is the only reliable solution for the future
When it's being rebuilt, it'll need documentation and extensive testing. If we have that, we'll be able to bring in new changes without the fear of breaking something else.

and break compatibility ?

We cannot do that in a minor version. People have built modules and shops on top of this system. Following SemVer we guarantee that the public API of the code (= all public functions) will remain functional until next major version. We do not have the right to break it now.
But we will be more than happy to delete it in one major version and replace it with something a lot more maintainable.

[eternoendless]

I think there's a misunderstanding here. We all want the same: a better, faster, _bugless_ PrestaShop. Thing is, we are paying un _years_ of unhandled technical debt while providing as much backwards compatibility as possible. It's like rebuilding a house having the inhabitants still living inside it. Keeping people safe from the falling walls is tricky, and doubles the workload.

The migration is a _refactoring_ meaning that it helps paying up debt, having a better understanding of what happens, and maybe fixing a bug or three at while we're at it. But keep this in mind:

• The migration mainly affects controllers, and only in the BO
• Most of the buggy logic resides within legacy files that we cannot fully refactor until next version because of backwards compatibility
• We're introducing CQRS to isolate those legacy files so that we can fully refactor them later

So the migration is part improving, part laying the groundwork for some major improvements to come later.

[kpodemski]

It's not that i don't want a migration, i just dream about 1-2 month period of focusing to have major issues fixed, that's all.

[ttoine]

this is your priority and devs would love that.
and on the other side, more people are waiting for other priorities...
difficult to handle all needs.

[ftardio]

I don't know if it's already solved (I don't think so, because it's still marked as "open"), but I insists: It's a important bug and should be fixed as soon as possible.

For example, I have a client using Prestashop 1.6. As support for this version has been finished, we have been working to migrate his store to 1.7 version. But we can't do, because he's using a lot of vouchers for free shipping, coupons and article discounts, and there can be a very big problem if we migrate the store and then we start having problems when using vouchers that prevent customers finishing their orders.

If you aim people to migrate to new version, things like that can't happen, and leaved opened for months, because it can be a very big problem for store owners and even bigger for technical teams.

[matks]

I don't know if it's already solved (I don't think so, because it's still marked as "open"), but I insists: It's a important bug and should be fixed as soon as possible.

For example, I have a client using Prestashop 1.6. As support for this version has been finished, we have been working to migrate his store to 1.7 version. But we can't do, because he's using a lot of vouchers for free shipping, coupons and article discounts, and there can be a very big problem if we migrate the store and then we start having problems when using vouchers that prevent customers finishing their orders.

If you aim people to migrate to new version, things like that can't happen, because it can be a very big problem for store owners and even bigger for technical teams.

Hi, we have taken this into account (it even got assigned to me 😄) but if this can reassure you: the bug seems to only happen if you create/enable vouchers while someone is shopping right now and has a open cart. It's not systematic.

[ftardio]

Hi, we have taken this into account (it even got assigned to me 😄) but if this can reassure you: the bug seems to only happen if you create/enable vouchers while someone is shopping right now and has a open cart. It's not systematic.

Thanks for your response, but your explanation doesn't solve things in our case: In a store with more than 100 orders every day, most of the time there are carts opened. And if you are also selling gift cards generating voucher codes at any moment, you'll have always this kind of problems.

[matks]

most of the time there are carts opened.

Also the customer has to be on the checkout page at the moment the cart rule is enabled. Additionally, because the issue is (according to my first analyzis) due to bad data caching, if the customer refreshes he can see the carriers again.

So in order to see this crazy bug you need the exact https://github.com/PrestaShop/PrestaShop/issues/11172#issuecomment-502165356 scenario:

• customer enters the checkout
• at this moment the cart rule is enabled
• customer refreshes the checkout page => he has no carriers available
• customer refreshes again the checkout page => everything is fine

[ftardio]

Thanks again for your response, matks.

But I was one of the people who informed about the bug. And, at least in my tests, the scenario was not the same you present to get the bug. Maybe the customer must be at checkout when enabling rule (I'm not sure about this), but I'm sure I refreshed it several times at checkout and the problem persisted (no carriers available). The only way to solve this was to end the session or to delete the carrier.

I was testing it some months ago at 1.7.5.0 version. I don't know if things have changed in new versions, but anyway, even if the scenario is the one you present, you will have an average percent of customers having problems if you use several vouchers and even more if you have some modules that generate its own vouchers (like gif cards does).

[matks]

Maybe the customer must be at checkout when enabling rule (I'm not sure about this), but I'm sure I refreshed it several times at checkout and the problem persisted (no carriers available)

I think there is more than 1 bug, because other people have reported this behavior. It seems there's one usecase where it's due to bad data caching, so the refresh does clear the cache and fixes the carriers display, and another usecase where it's due to a bad carriers / cart rules availability computation

[colinegin]

Unfortunately, after review of the available PR, we consider it does not fix the bug, so we put back the issue in to do.

[matks]

Hi everybody,

We changed our mind. Although we do not feel 100% safe by merging #12878 because we think it might create unwanted side-effects, we added several checks in order to find them all:

• one behat test to validate this PR works as intended
• current test coverage which guarantees there is no known regression (what we are afraid of are unknown regressions)
• PR QA analysis should spot the most obvious ones
• in the end, we think that full testing campaign that will be used for 1.7.7 release should spot the remaining issues