Prestashop: Search Filter by Availability

[omar2886]

Hi,
Seems like the "availability" criteria on PS means that product is active and available for sale (not related to actual stock level).

What I need is simple I think, when someone uses the "availability" filter on "search filter" block, it should filter the products depending on the level of stock:
Stock level > 0 = in stock
Stock level =< 0 = unavailable

I don't know if it makes sense to the rest of the community, but for me this is how it should actually work the filter, otherwise makes no sense. Thanks for the help!

[freeman78ita]

I agree 100%, and this is one of the reason i purchased an addon like Advanced search, but i think that should be a stock option into any ecommerce store that provides filtered layers search

[khouloudbelguith]

Hi @omar2886,

Seems like the "availability" criteria on PS means that product is active and available for sale.

In fact, I created a product Product A with a quantity > 0 but not available for sale.

I created another product Product B with quantity =0 available for order
I created a product Product C with quantity > 0 & available for the order
In the FO,
I have two products In stock & one product Not available.


I attached a screen record.
https://drive.google.com/file/d/1b_OCqWBd5_eTXNSXAnR3qFKZjDfzh_eh/view
Thanks to check & feedback.
PS: I used the ps_facetedsearch v3.1.0.

[omar2886]

After your explanation I tried something. In fact I am still getting filtered many products as available when their stock is 0 or bellow.
Experiment: Took a product which stock was 0 and then in the Quantity tab changed the default option I have for the store (allow orders when products not in stock) and turned it to refuse. After doing so, this particular product was not filtered anymore as available in stock in the FO.
So there we are! when having this option active for the store, the availability filter is senseless. I have products in stock and many many others on order, so people can still order them and we can provide in a longer delay, this is something common for eCommerce stores. It would be good if this could be adapted somehow in Prestashop, for my understanding as an eCommerce owner the availability filter should be directly related to the actual units in stock (as well as to the "available for order" option).
Regards,

[khouloudbelguith]

@omar2886, thanks for your feedback.
Yes, you are right.
If we allow orders when out of stock, we try to filter with the Availability filter, products which have quantity =<0 are in stock.
ping @marionf @colinegin what do you think of his suggestion?

What I need is simple I think, when someone uses the "availability" filter on "search filter" block, it should filter the products depending on the level of stock:
Stock level > 0 = in stock
Stock level =< 0 = unavailable

Thanks!

[marionf]

Hello @omar2886

If you have a product with quantity <= 0 but you allow order of out of stock product, we can say that your product is "in stock" because you sell it.
If we only take into account the quantity and not the behavior chosen when the product is out of stock, a product with a quantity <= 0 will not be displayed when your customers will check "in stock", while they can order it. That means they can miss a product on your website.

Furthermore, you can display the delivery time of out-of-stock products with allowed orders and also display the availability date. So, your customers know when the product will be available and when it will be delivered.

Please, take a look at this issue: https://github.com/PrestaShop/PrestaShop/issues/13139

[omar2886]

When you have a catalog of +10k produtcs and only a few percentage is actually available in stock (because we are not Amazon) then this feature is important.
That's why there are different labels for this cases (In stock, no stock but can order & no stock can't order). These labels help define the type of availability of products in 3 possible scenarios. But when it comes to filtering, what really matters is to distinguish from those products that are allowed for purchase, which ones are actually in stock, that's why it makes sense the filtering by in stock availability, so customers can actually know what are the products that are physically in stock with immediate availability for the shortest shipping delay (independent from the fact that for each product details where you can see the delay, we're talking here about the filtering, our aim is to simplify things for customers, they don't have to understand us, it's us who have to read and understand their behavior and understanding of our websites so we can adapt accordingly, I give this feedback and request this feature as merchant, not programmer, which I'm not).
Thanks for the help

[marionf]

Thank you for your feedback @omar2886
What do you think if we add a filter, so we will have:

• In stock: Product with quantity > 0
• Out of stock but available for order: Product with quantity <= 0 and allow order of out of stock checked
• Not available: Product with quantity <= 0 and deny order of out of stock product checked

[omar2886]

I can't talk in the name of all merchants but at least I may say that a filter option to see products out of stock and that can't be purchased won't make any sense.

• One feature for sure would be that "In Stock" should stand for products with stock > 0
• The other filter can just be "out of stock" for the rest of the cases

[marionf]

In fact, I don't think adding an option "Out of stock but available for order" is usefull for customers.
When I search a product what matters is to know if the product is available (can be ordered) or not.
We can just change the wording and replace "in stock" by "available"

[omar2886]

I'm not sure if I follow you but, the thing here is not a matter of wording rather than proper filtering. Main thing is that it should be an option to filter available products with positive stock ("In stock" products).
Then if you think that other filtering won't be necessary I can't tell, in my case it would be enough to just have a filter for my customers to be able to only see the available products in stock. But other merchants for whatever reason may like to see a second filter to see the products that have no positive stock but can be purchased ("produits sur commande" in french). If it's possible to implement all at once, as it's already offering "available" and "not available" options, why not doing so?
The whole thing on this Github Issue was to correct the way this module interprets the "availability" feature, that's it.

[marionf]

@omar2886

There have been different returns on this subject before: https://github.com/PrestaShop/PrestaShop/issues/13139
This is why we decided to include in the "in stock" filter not only products that have a quantity > 0 but also products qith a quantity <= 0 but that are available for orders.

The only way to satisfy everyone would be to add an option in the module to choose if "in stock" takes into account only the quantity of the product or also the behavior when the product is out of stock.

[omar2886]

@marionf
Then I don't see where is the problem, both filters can be implemented together to satisfy all demands, despite I don't see the point of having those 2 filters when there are usually just those 2 possibilities to be filtered. I try to explain it from my point of view.
In most of the cases a customer may only want to filter to see the immediate available stock, "In stock" products (qty > 0), and the only alternative would be "out of stock" products (qty=< =). So if we only have these 2 possibilities, a unique filter that can let you know the "In stock" items would be required, as for those customers who want to see the "out of stock" items won't bother them seeing all products together (in stock and out of stock).
Also in a second scenario, don't know who may interest this one, you'll have in addition of these 2 stock possibilities also the items that are not available for order. Maybe this case is what you're talking about, so a customer may have 2 filters for 3 possible stock criteria, being "in stock" products and "out of stock" with available order, then you don't need a 3rd filter for products not available for order as it won't make sense.
What do you think? in my case our customers know that there are 2 possible scenarios for the products in our website, either available in stock with 24h shipping or not available in stock (sur commande) with a much longer delay.

[Hlavtox]

@marionf

@omar2886 is definitly right. You want the availability filter to filter out products, you can order right now and the store has them in stock.

Your proposed solution is correct and should be implemented.
In stock: Product with quantity > 0
Out of stock but available for order: Product with quantity <= 0 and allow order of out of stock checked
Not available: Product with quantity <= 0 and deny order of out of stock product checked

Personally, I don't understand what's the point of filtering product's that are not available for order. What's even the point of having them in store when you know the customer can't order them? :-D

One checkbox with "Show only items in stock" could be enough.

---

In most of stores, there are three cases:

• In stock - We have the items in OUR warehouse and we have quantities listed in the store. We can ship the product the same day.
• Available - The items should be available at our supplier's warehouse. We have 0 quantity in our store. We can ship the product usually in 2-3 days after ordering.
• Not available - The product was dropped out of the catalog and cannot be ordered anymore from our supplier. In this case, I make the product inactive and possibly redirect it to a replacement product.

[omar2886]

Dear @khouloudbelguith & @marionf,
I've seen that there has been an upgrade to this module, I've just tested it but this hasn't been yet fixed, I'd like to know if this feedback is going to be taken into account for future upgrades or maybe it does actually affect a core feature of Prestashop that would need to be changed in a major upgrade that may take longer and would require us to upgrade the entire system.
Regards

[marionf]

Hello @omar2886

This issue will be fixed in the next version of facetedsearch.

FYI here is what we will do:
Add 3 options in facetedsearch when the filter by stock is enabled:

• Display in stock products: Yes / No
  If the option is set to Yes, display in FO an “In stock” checkbox: Product quantity > 0
  Should be on Yes by default
• Display available products: Yes / No
  If the option is set to Yes, display in FO an “Available” checkbox: Product quantity <= 0 but available for order
  Should be on Yes by default
• Display out of stock products: Yes / No
  If the option is set to Yes, display in FO an “Out of stock” checkbox: Product quantity <= 0 but not available for order
  Should be on No by default

[marionf]

@Hlavtox

Edit:
These 3 options should also be displayed when the filter by stock is disabled:

• Display in stock products: Yes / No
  If the option is set to Yes, display in FO products with quantity > 0
  Should be on Yes by default
• Display available products: Yes / No
  If the option is set to Yes, display in FO products with quantity <= 0 but available for order
  Should be on Yes by default
• Display out of stock products: Yes / No
  If the option is set to Yes, display in FO products with quantity <= 0 but not available for order
  Should be on No by default

[omar2886]

dear @marionf, I was said that this would be applied to the new version. I upgraded couple days ago to v3.2.1 but filter in FO offers only 2 options:

• Available for order products (no matter the stock level)
• Products not available for order.

[marionf]

@omar2886 yes, this improvement has not been implemented yet

[guigplt]

Hi,
Do you know when this issue will be fixed ?

Regards.

[guigplt]

Hi,
Do you know when this issue will be fixed ?

Regards.

Any idea ?

[marionf]

Hello guys,

A lot of work has been done to improve faceted search these last months.
We are currently focused on the 1.7.7
So this improvement will not be integrated right now, I hope we could rework on facetedsearch after the 1.7.7

[Hlavtox]

@PierreRambaud @marionf Do I understand correctly that this will be implemented after 1.7.7? :(

Guys, I know there are other important issues, but it's a crucial feature to filter out in stock products... I don't know about other merchants, but at least for us, there is no way of moving to 1.7 without this.

[lutek]

I agree. I would also add filtering according to e.g. shipping time.

[omar2886]

@Hlavtox indeed, it's a key module that has gone through a lot of trouble and I think never worked 100%, at least not the way professional merchants expect. Many had to purchase really expensive modules just to get this key filter working properly.
What I don't get is why it has to be implemented for the newest release of PS when it can just be a module update, there is no need to upgrade, PS is so much fragmented that most of merchants just can't do it, or can't do it more than once. Me personally, I went through 3 PS developer partners the last year trying to upgrade from 1.6 to 1.7, and still not finished, last company I'm working with has been already working on it 19 months and counting, and the PS team itself can't do it either unless you agree to give up on any changes or non native modules you may have implemented.

[marionf]

@PierreRambaud @marionf Do I understand correctly that this will be implemented after 1.7.7? :(

Yes, we need to be focused on 1.7.7 right now as we are already late
If this feature is so important for you, feel free to contribute by submiting a PR, it will be usefull for everyone ;)

[Hlavtox]

@marionf

Bear in mind, that general public (talking 80% of population) is just stupid. Think I contempt for people, but it's just true. Customers will not try to add a product to cart again if there is a bug, they won't flush their cookies, reload the page. Slightest problem? Other stores has the stuff sorted better? They will just go and buy the product on 50 different stores, which have it for the same price and do actually work. The same goes for page speed, loads too slow? They just close tab and don't give a single F.

Imagine you are a customer, it's 10:00 in the morning and you need something tommorow. So, you need to order something the store has in their stock, right? So, you select a category and your selection is limited to stuff that the store actually has in stock.
Now, what's the purpose of the filter in it's current state when it will show you 99 or 100% of the products? You want to tick the products they have in stock and can ship them immediately, or you can pickup personally in that store.

Check the biggest ecommerce store in Czech republic, Alza.cz had a turnover of 1 billion EUR last year. How they IN STOCK filter looks like? Just a single checkbox 'Show only products in stock', which hides products 'on the way', 'on backorder' and 'not available' and keeps only the ones with quantity>0.

EDITED by @matks : please dont use rude statements and follow Github community guidelines in order to _promote a respectful and friendly atmosphere where people feel comfortable asking questions, participating in discussions, and making contributions_

[Hlavtox]

@matks Sorry for the words from the heart, but you have to imagine my frustration.

PS 1.6 was left abandoned with (major) bugs unresolved, with technology and libraries getting obsolete. I reported a bug which prevents users from adding products to cart, you just closed it. #14751 I think it should be worth announcing, at least. 💁🏽‍♂️

But, 1.7, at least until 1.7.7 is not production ready, and even after, it will still be undone.

So we are stuck on old unsupported software and unable to move to new one, because it lacks features and is buggy.

I wanted to migrate to 1.7 since May and still postpone it more and more. My boss is asking me every second day, when we will finally change to new version, all I can say that we just can't, for example because of a missing instock filter.

[Hlavtox]

@omar2886 @lutek @guigplt @freeman78ita Guys, I managed to do the filter myself. It was 15 minutes of work.
https://drive.google.com/file/d/1qQuoWBUiNsmOxBAJhip5ySWLaPgCZm1V/view?usp=sharing

Only thing needed is to modify/replace two files in the module.

• Update the module to latest version v3.3.0
• Update the files from the ZIP in the link
• Enable stock filter in the filter template
• Flush cache by clicking the button in the module and rebuild your indexes.
  Download: https://drive.google.com/file/d/1pxVnSooaONB6OAdaLGLDZWnkttQXSUcE/view?usp=sharing

[omar2886]

@Hlavtox great job! if it was something that simple for you, I don't know why they didn't do it when this thread was opened 4 months ago, it takes much more time discussing here that implementing the solution

[Hlavtox]

@omar2886 Ask PS dev team, but expect something like "there are more important issues". Do you know the situation with the order note being messy with escaped characters? They fixed the bug after 2 years.

When I asked them:

What the fix was? 1 line of code.

[marionf]

PS 1.6 was left abandoned with (major) bugs unresolved

As you can see here : we don't maintain 1.6 version anymore but the maintenance of PrestaShop 1.6 is now being performed exclusively by volunteers to fix critical issues.
If you think your issue is critical, you can open an issue on the dedicated repository

But, 1.7, at least until 1.7.7 is not production ready, and even after, it will still be undone.

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.

This is why we are now focused on 1.7.7 and try to put in every minor version:

• Bug fixes (because fixing bugs is important)
• Improvements
• Refactoring
• A few new features, that merchants are waiting for
• BO pages being migrated to Symfony

This way, we'll ensure that PS 1.7.7 will be better than PS 1.7.6 and previous versions.

In addition to minor versions, we have more than 80 built-in modules to maintain

I don't know why they didn't do it when this thread was opened 4 months ago
They fixed the bug after 2 years.

For the reasons explained above, we have a LOOOOT of things to do (fixing bugs, adding improvements & new features, migrate pages to Symfony, maintaining / improving modules ...) with only 6 developers in the team. So, obviously we can't do everything !

But the good news is that PrestaShop is open source. If something is important for you, it's probably important also for other persons. And you can submit a pull request (instead of a google drive link) to share your solution and make it available faster for everyone.

[ttoine]

+1,
Please open a pull request. The repository of the module is here:
https://github.com/PrestaShop/ps_facetedsearch

[Hlavtox]

@marionf @ttoine I don't know how to do it and I don't to mess anything up. I use github only to spam your repo 😅 🚀 (joke)

The thing is, I don't know if _what I think is correct_ is _correct for all the merchants_. Let me know what you think.

3 different product conditions/groups - (src/Product/Search.php)
A) products - quantity > 1 - _Only products in Stock_

$operationsFilter[] = [
   ['quantity', [0], '>'],
];

B) products - quantity <= 0, but available for order - _Only available products_

$operationsFilter[] = [
   ['quantity', [0], '<='],
   ['out_of_stock', [1], $this->psOrderOutOfStock ? '>=' : '='],
];
$operationsFilter[] = [
   ['quantity', [0], '>'],
];

(MAYBE) C) products - quantity <= 0, but not available for order - _Not available now_

$operationsFilter[] = [
   ['quantity', [0], '<='],
   ['out_of_stock', !$this->psOrderOutOfStock ? [0, 2] : [0], '='],
];

Resulting filters
_Scenario 1:_ I think we need to display only cases A) and B), because you come to the category and you already see all products. What is the point of displaying of C) checkbox? Why would anybody want to check it?

_Scenario 2:_ And in case of our stores, we display only products which available for order, so, one checkbox with A) is enough.

What if do it this way:
If any products are in C) category, it shows option A) and option B)
If there are no products in C) category, it shows only option A)

And I would also force checkbox or selectbox type for this filter, hm?

[matks]

OK, I dont like doing that but it seems a few important points need to be stated here.

---

Guys, I know there are other important issues, but it's a crucial feature to filter out in stock products... I don't know about other merchants, but at least for us, there is no way of moving to 1.7 without this.

This feature has been analyzed, explored and queue accordingly. It will be done after the other features / bugfixes that are more important and before the other features / bugfixes that are less important. Sorry but this is how it works, and it is logical. There are lot of issues and features to address, we have to sort and queue them, we cannot do everything at once.

Everybody works this way. If tomorrow your boss comes and gives you 2,000 assignments, you're going to ask him "OK, which one should I pick first ?" . He's going to sort them and tell you the order. We do the same, but we control the sorting process.

---

If this feature is critical for you, then you have the option of making it happen faster by using either your time or money.
If you work on this feature (so you build it for yourself), you use your time.
If you hire someone else to work on this feature, you use your money.
If you pay for a module that provides this feature, you use your money.

That's it. Period. Either you wait for your feature request to reach the top of the queue to be done, or you use money and/or time to speed it up. Complaining, ranting and saying harsh words will have no effects other than making us less and less happy to help you.

This is how all big projects work. I have already shared it, but I'll share it again: Software has bugs. This is normal.

"Software organizations that stay in business triage their backlog of bugs like that. They do not drop everything to deal with any damn bug. As the economies of scale kick in, so does the magnitude of consequences from such triaging. Large software packages and organizations will have hundreds if not thousands if not TENS OF THOUSANDS of open bugs of various criticality. THIS IS NORMAL. THIS IS EXPECTED."

---

What I don't get is why it has to be implemented for the newest release of PS when it can just be a module update

It will be a module update, it's just that the people working on the release of PS and the people working on this module are the same, so we scope modules updates together with PS updates, it's a way to make our time management easier.

---

and the PS team itself can't do it either unless you agree to give up on any changes or non native modules you may have implemented.

Yes, that makes sense. When adding custom changes or non native modules, you actually build your own shop system on top of PrestaShop. That is why it requires time to adapt to a new version of PS. It works the same with other CMS like Magento, it works the same with OS updates (ask a developer how painful it can be to adapt a WindowsXP application to Windows10).

My advice: when building things on the top of PrestaShop, it is important to build them in a modular way (meaning: you make the link to PS as flexible as possible) to make it easier to adapt for an earlier version. It's additional work when building the custom module, but it pays long-term for updates.

---

@matks Sorry for the words from the heart, but you have to imagine my frustration.

I can imagine it, but it does not mean you can just shout at us. You can shout at people you pay (although it does not help to maintain an healthy relationship with them) because you have given money in exchange for services. So you can be frustrated, angry, sad, it does not mean you can direct this aggressiveness towards us.

---

@Hlavtox great job! if it was something that simple for you, I don't know why they didn't do it when this thread was opened 4 months ago, it takes much more time discussing here that implementing the solution

Because the solution that works for him would not work in multiple other usecases. We build PrestaShop for the whole world, with hundred of different usecases, dozen of different languages, currencies, constraints. When we fix a bug, we have to make sure we cover all of the possible usecases where PrestaShop is used. You can have a look at this part of the review process to have an idea of how many things we must check before being able to say if a piece of code is valid or not.

---

@omar2886 Ask PS dev team, but expect something like "there are more important issues". Do you know the situation with the order note being messy with escaped characters? They fixed the bug after 2 years.

And there are still more important issues, check by yourself: https://github.com/PrestaShop/PrestaShop/issues

When I asked them:

What the fix was? 1 line of code.

You seem to believe that the number of lines of code is a good measure of how long some work can take. Then I'm afraid I have to tell you that sometimes, people will write 2000 lines of code in 1 hour and sometimes they will write 1 line of code in 3 weeks. The changes in the code are only the visible result of a long and complex process of analysis, exploration, rumination, discussion and choosing the right solution. Lines of code is a very bad measure of how much energy has been spent on a topic.

For the reasons explained above, we have a LOOOOT of things to do (fixing bugs, adding improvements & new features, migrate pages to Symfony, maintaining / improving modules ...) with only 6 developers in the team. So, obviously we can't do everything !

We are now 7 developers thanks to @atomiix 😄 and soon 9 !

[Hlavtox]

@matks Thank you for giving me your point of view. I don't think I shouted, but I understand it and I am sorry to you and to @marionf. There is just a neverending discussion what is important and what is not. I just wanted to give you some insight from a store that makes a living for X people and an example from other BIG stores, so you don't think I am making stuff up...

Every coin has two side. Looking on it your point of view:
At your place, and in the number of people there is in your team, personally, I would just give up on it. HUGE thumbs up for running it and pushing Prestashop forward. The whole team just took a huge bite and for many merchants, these times are difficult. And for example with my "explosive" personality, sometimes it's too much.

Merchants point of view
We choose Prestashop as a stable, opensource ecommerce platform back in 1.6 and through years, we invested insane amount of time/money into modules and customization. But even then, 1.6 was filled with some pretty serious bugs, but it was somehow livable. But even then, the amount was approaching the limit, when we would choose to go a different way. In 1.6, you can't properly edit an order, products are getting doubled, can't properly remove a discount from order and so on.

Also, we choose Prestashop base, because it could do some basic features merchants would need. One of them is, for example, the stock filter, ability to set up discounts, payment and delivery method options and limitations, vouchers, etc. Just the basic stuff that modern shop shoud have.

This year, 1.6 was getting really old and I started to make a new shop on 1.7 platform. We are forced to upgrade to something that doesn't reach 1.6 version's knees and doesn't have the features that Prestashop had when we choose it. That why I and many merchants are upset... 😞

1.7 current state
Now, with 1.7.7 it will be finally somehow usable, but before it? You will argue, that it was production ready, but I think it was million miles from it.

I know everything has it's order by importance. I know that the software needs to be pushed forward to keep track and have new features. But, for example, is migrating order administration to Symfony so important? We could live with it for X years and I think we could live with it for one more... :-)

Think I came from Mars, but isn't there a stuff that is more important?

• That people can't track their orders?
• That people see nonsense delete icons next to cart rules, that they can't see a gift in cart properly?
• That merchants are loosing money because people can see and USE vouchers that they should not?

Just to sum it up
I have read the bug classification, but I think generally, everything the customer sees, should be put top priority, right after money. We want to make money and the ordering and product selection process is the most important thing of them all.

Everything that is relating to BO and "underground stuff" is just not that important I think. When we have the order and the customer in our DB, who cares? Employees can always shout: _"Dan, this is not working, come check it out."_ Something doesn't work? I can open DB admin anytime and fix it manually.

But customers don't have these options and don't want to deal with your bugs. When something will not work, they will just leave the store.

[ttoine]

Hello everybody,

I think it is time to calm down and maybe also to close this discussion before it reaches the "Godwin point".

Sometimes, it's better to accept that we don't agree and don't share the same vision, than to try to convince the other is wrong in an infinite way. In general, experience proves that ending discussions this way makes them interesting too: each one involved learned from the different point of views.

TL,DR:

• PrestaShop is obviously an e-commerce solution, and it is built for different people of the ecosystem, including module vendors, agencies and freelancers, host providers (and many other personas). It is not only for merchants and their customers, even if, at the end, they are of course the target users that the devs and PM have that in mind. It's a B2B2B solution.
• When you use any open source software, you are free to use it to build your own solution to your problem. If the basic features that are suitable for most people don't fit your needs, it is possible to customize it.

[marionf]

I am sorry to you and to @marionf

Thank you for your apologize, I appreciate :)

We are forced to upgrade to something that doesn't reach 1.6 version's knees and doesn't have the features that Prestashop had when we choose it.

We know that PrestaShop 1.7 was released too soon and we are trying to make it better everyday, but it takes time

But, for example, is migrating order administration to Symfony so important?

Merchants don't care about PrestaShop being powered by legacy system or Symfony system. However, if we stop the migration, we simply kill PrestaShop.

Why ? Because in 2019 modern and robust software relies on either Symfony or Laravel.
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.
If we want to hire, if we want to attract new developers, we have to use modern tools and technologies.

Everything that is relating to BO and "underground stuff" is just not that important I think.

You are wrong, it's a question of survival. If PrestaShop doesn't implement new techno, nobody will be willing to work on it in a few years.

Finally, I hope that with these explanations you will understand that migration is as important as this improvement request about facetedsearch

[Hlavtox]

You are wrong, it's a question of survival. If PrestaShop doesn't implement new techno, nobody will be willing to work on it in a few years.

Finally, I hope that with these explanations you will understand that migration is as important as this improvement request about facetedsearch

@marionf Thank you for a deeper insight into the problem. I understand it.

I am sorry to you all guys and I owe you a beer 🍻.

Let's somehow put it together. I will try to help as much as I can (and to keep nerves down 😄).

[freeman78ita]

Hi Guys, been following the Thread quietly and have to say i love PS and decided to move from 1.6 to 1.7. Bugs always exists, it's normal, and most will be fixed, you are doing a great OPEN SOURCE job. I need this feature too, in the meanwhile i bought a paid addon and it works perfectly, when this one will be tuned and fixed i will maybe drop that module and use the native one. Keep up the good work! My 2 cents ---> update to ps 1.7 the disadvantages are far less compared to the added value in terms of SEO, speed and a lot more features. Plan carefully, do test and migrate.