Layered Navigation: price range with specific prices

[medred]

Hello everyone.

 

How is it possible to get price range filter to work with specific prices (special discounts) on ps1.5.2?

 

As i have seen so far price range work only with base price and not Final price value.

 

Thanks in advance.

[Sonick]

Hi med,

 

I am having the same question, where are the variables pointing out the sale price (discounted) to filter price range on block layered navigation, 

 

i am trying to find a topic related to this but nothing comes out,

 

I am wondering nobody filters the products on sale price? only on base price?

 

thanks in advance

[avionicom]

Hi guys, I've the same problem.

It seems nobody found a solution. I'm on PS 1.5.5

Do you have solved?

[medred]

Nop. I have no replies on any of my topics about it. We had to buy a search-filter module to solve the issue. If you solve this by the way let us know.

[avionicom]

Yes, of course I'll keep you informed. Thank you.

[Emzed]

EDITED:

 

Sorry, ignore my previous post. 

 

I believe most of your problems are caused by the "from quantity" in the ps_specific_price table being 1 by default when your apply discounts via the product CSV import. Downstream functions require this value be set to 0 with the way the module has been configured. However, if you change this value to 0 you may have other issues (I lost all the discounted products from the Prices Drop page and related functions).

 

See a possible solution below.

Edited September 23, 2013 by Emzed (see edit history)

[Emzed]

I can repost my previous hack if anyone wants it since technically we should be able to search for specific prices where from (quantity) >= 1, right?

 

I just edited blocklayered.php and modified all 3 variations of

 

$price = Product::priceCalculation(param, param, param, etc) 

 

by adding null, null, null, 1 as the last 4 parameters (i.e. add, not replace), where 1 is the required quantity. So I suppose this means if your specific price only comes into effect at 3 items, for example, that price won't show up in the search, which is technically expected.

Edited September 23, 2013 by Emzed (see edit history)

[avionicom]

Hi Emzed and thank you for your help. I tryed to do what have you said by modifying the 3 variations of $price...

but the price filter seems to ignore these changes.

[Emzed]

Hi!

 

Did you re-index all the prices in the module's settings? Also, which version are you using? I can post the modified file for 1.5.4.1.

 

Cheers

[avionicom]

If I try to re-index all the prices, it is still loading... and seems blocked.

I'm using 1.5.5.0 but this module should be the same version 1.8.9

Please post your modified version and I test it, thanks ;-)

[Emzed]

Latest Working Version: 

v3-155-blocklayered.php - Rename to blocklayered.php (PS1.5.5)

155-blocklayered.tpl.txt - Rename to blocklayered.tpl (PS1.5.5)

 

New Fixes:

Version 3 works with or without tax

Correctly subtracts reductions without tax to calculate min_price

Previous fixes maintained:

min_price is rounded down to nearest integer

max_price is rounded up to nearest integer

tpl file's javascript makes minimum currency unit 1 to maintain accuracy

Price reductions are subtracted manually from price since specific prices can't work without a country assigned

 

 

Original Message

 

Hi,

 

I checked the 1.5.5 version of blocklayered against the 1.5.4.1 version with a code difference checker and there were surprisingly a lot of small changes made so I'll upload the 1.55 version with my changes as well. The 3 functions in question were not changed in the 1.55 version so I just changed them in the same way. I haven't checked if the expected parameters have been changed in the core classes but I'm guessing/hoping they weren't too extreme.

 

DOES NOT WORK -  blocklayered.php for 1.5.2

 

DOES NOT WORK -  blocklayered.php for 1.5.4.1

 

DOES NOT WORK -  blocklayered.php for 1.5.5

 

 

Cheers

Edited October 19, 2013 by Emzed (see edit history)

[avionicom]

Emzed, I downloaded and tested the version for 1.5.5.

It seems to work very well! I don't kwon if your hacks to the code will interfere to something else, but the price filter now is very good!!

Thank you for sharing the code and please keep us informed if you discover something wrong.

Edited September 23, 2013 by avionicom (see edit history)

[Emzed]

My pleasure

[medred]

Hello and thank you for this great solution. Do you know if this works on 1.5.2 as well?

[Emzed]

In blocklayered,php itself there doesn't seem to be a great difference between 1.5.2 and 1.5.4.1's modules (the only major difference appears to be a change of the assignment name to the home image). I've uploaded an updated version for v1.5.2 above. Unfortunately I don't run any old versions for testing purposes so I'm not 100% sure of any issues.

[medred]

Thank you Emzed. I will try to test it as soon as possible.

[Emzed]

Hi,

 

As I was working on my own version of a slightly modified blocklayered.php I found that the module would in most default circumstances (where the specific price's country is set to all countries, or 0 in the specific_prices table) fail to remove the tax from the "amount" reduction, leading to lower index values.

 

I understand this is because the tax calculator explicitly requires the country_id that appears in the tax table for your specific price (in my case, 24, for Australia).

 

In my version, I've reused the $max_tax_rate already calculated in the module instead to reduce the reduction according to this calculated tax, making the module changes a little more tedious now. As I only use 1 country I don't know the impact this change will have, and I'm interested to explore once I get some sleep if the layered navigation price lists would be indexed accurately in other circumstances with the way the max_tax_rate is calculated anyway. Beyond this I've been wondering if it's better to have a ceiling value rather than a rounded value for the max price since it looks a little strange to have a $24.16 item appearing for a max price of $24.

 

I'll prepare a modified version tomorrow as it's very late here. In the meantime you can check if your indexed values are off as well (might not be obvious with low tax rates or prices).

 

Cheers

Edited September 25, 2013 by Emzed (see edit history)

[Emzed]

Hi,

 

I've made quite a few changes to both the blocklayered.php file and the blocklayered.tpl template to have the module work as I expected. Whether the approach I took is robust is another matter.

 

Firstly, in blocklayered.tpl the script calculates the slider's step amounts by dividing the filterRange by 100. Only if the step amounts are above 1 were they converted to an integer and I decided that for my purposes I can make any steps below or equal to 1 default to 1 when the slider filter is "price". Considering that other parts of the blocklayered script intentionally avoided "cents accuracy" this accuracy appeared irrelevant anyway.

I edited line 158 in blocklayered.tpl thus:

if (step <= 1 && {/literal}{$filter.type == price}{literal})
    step = 1;

In blocklayered.php I made many changes:

 

(1) There was a function that loosened the range of the slider by casting the so-called "out" product prices to an integer. This group of functions allows integer indexed prices that fail the range on one side to be included if the actual prices fall within range, which is of course a desirable feature. I removed the (int) cast (in concert with another important change elsewhere) since I like my range to be as well-defined as possible and this (int) ruined a useful function.

$price = Product::getPriceStatic($product['id_product'], Configuration::get('PS_LAYERED_FILTER_PRICE_USETAX')); //(int) casting removed

(2) The max price stored in the database as an integer was rounded with the following function:

(int)Tools::ps_round($max_price[$currency['id_currency']] * (100 + $max_tax_rate) / 100, 0).')';

If the price with taxes was say 7.20, this would be round down to 7 and would be incorrectly seen in a range of, say, 6 - 7. In combination with my change in (1) above, I changed this to always give a ceiling value instead, such that 7.20 would become 8 and fail the range.

'.(int)Tools::ceilf($max_price[$currency['id_currency']] * (100 + $max_tax_rate) / 100, 0).')';

(3) This is where it gets messy and I don't know if such drastic action was necessary or I'm missing some shortcuts or oversaw something simple. Since it appeared the reduction was being subtracted with tax from the price without tax due to the absence of an absolute country setting I created two separate functions to calculate final price. One to find the $price without reduction and a second that extracts only the reduction. I then use the pre-calculated max-tax rate in blocklayered.php to "de-tax" the reduction.

 

For example, here's one of my 3 original modifications that were operating undesirably (with the extra 4 parameters already added) :

$price = Product::priceCalculation($id_shop, (int)$id_product, null, null, null, null,
$currency['id_currency'], null, null, false, 6, false, true, true,$specific_price_output, true, null, null, null, 1);

Now was changed to this:

$price_before_reduction = Product::priceCalculation($id_shop, (int)$id_product, null, null, null, null, $currency['id_currency'], null, null, false, 6, false, false, true, $specific_price_output, true, null, null, null, 1);
				
$only_reduction = Product::priceCalculation($id_shop, (int)$id_product, null, null, null, true,$currency['id_currency'], null, null, false, 6, true, true, true, $specific_price_output, true, null, null, null, 1);
					
if (isset($price_before_reduction, $only_reduction))
    $price = (float) $price_before_reduction - (float) $only_reduction * 100/(100 + $max_tax_rate);
			
unset($price_before_reduction, $only_reduction);

I also set $price = null before the first currencies foreach loop to avoid potential errors where price could not be initially set.

 

I haven't had a chance to proof-read or test these changes (shown for 1.5.5) yet as my files from 1.5.4.1 have other custom changes I'm actively working on, but hopefully they work. I hope to upload other versions soon if you need it.

 

155-blocklayered.php for PS1.5.5 (remove '155-' prefix)

155-blocklayered.tpl.txt for PS1.5.5 (remove '155-' prefix and .txt extension) 

EDIT: Try latest version

Edited October 19, 2013 by Emzed (see edit history)

[threeopus3]

Emzed,

 

Really nice of you to take the time to document your solution. I hope to give this a try tonight, and will report back what I find. Again, I really appreciate you sharing this. Very nice of you. You are a rockstar!

 

Cheers.

[thoreking]

works great now on a 1.5.5

thanks so much

well done !

[threeopus3]

Emzed,

 

I have been reading through the explanations of the logic behind the code that you've provided and am baffled at what a smart/complicated fix this is - I must admit that a lot of the logic is over my head. 

 

I am using 1.5.4 and notice the price rounding issues that you've described. I have looked through your updated 1.5.5 version and see that it is quite a bit different from 1.5.4. Is there anything that I can add to the 1.5.4 version to address the price rounding issues?

 

I have looked through your code and tried playing around with the update that you described in your last post in this thread - can't get that to work.

 

I realize that this is not a full Prestashop update, but if you can recommend anything or if you have a 1.5.4 version that would be super awesome and hugely appreciated.

 

Thanks for any thoughts.

 

Kent

[Emzed]

Hi Kent,

 

Don't worry, I've probably forgotten most of the changes myself Since I haven't developed a site using much of v1.5's advanced features (multiple shops, or complex "combinations" etc) my work arounds may not even be robust in all cases (even in the unmodified versions of the layered navigation module there have been reports of issues with multishops).

 

The "by unit price" version I posted on http://www.prestashop.com/forums/topic/276126-block-layered-price-slider-use-unit-price/ used v1.5.4.1 of Prestashop. If you need the original modified version posted here you can also copy the v1.5.5 module's directory to your v1.5.4 setup and update with the modified files posted here (you'd think the newer versions would have less bugs but note there are known, potentially fixable issues selecting filters in the back office of v1.5.5/1.5.6 - e.g. http://www.prestashop.com/forums/topic/282258-156-layered-navigation-filters-continuously-loading/).

 

I normally use a tool like http://www.quickdiff.com/ to look for changes between files. If you wish to update an older version and have trouble I can give it a go when I get a chance. Just to be sure are you using 1.5.4.0 or 1.5.4.1? I'm not sure if there are differences between them.

 

Regarding the changes, I was also surprised at how complicated the layered filtering was in Prestashop. I haven't built a similar system from scratch yet but originally imagined something much simpler using specific database calls. It would probably be much slower due to many more joins but the current module seems to use a combination of direct and indexed calls anyway.

 

Ignoring the bugs which fail it anyway, all the problems with the price filtering seem to stem from the fact it's not intended to be accurate in the first place and is creating a single static table to set the product price ranges for a user that might have specific tax requirements (country or state specific, with or without tax)? Assuming the indexing process improves speed, why are price ranges based on one end without tax and on the other with tax? The apparent answer was to provide as broad a range as possible to cover all tax scenarios but even this intent was failed with the upper range rounding down due to integer casting and I may be wrong but aren't there some states/countries with additive taxes (I believe the module only uses mySQL's MAX operation to estimate the maximum tax). On another note, in Australia when a person visits a retail website he/she doesn't care about filtering for the price without tax and I don't recall any websites that work that way (note that I haven't changed this even in the modified version for now). Without my already dramatic changes - unless I'm wrong - the indexing simply couldn't work since there's no user - hence no country context - for the in-built pricing functions to work as is, to even create an accurate price table index to begin with. And what's the point in having currency filtering below integer values (e.g. 37 cent divisions) if the index doesn't even provide for that level of precision and would only cause further inaccuracies?

 

Cheers

 

P.S. I don't seem to be getting e-mail notifications for this topic (but I saw this updated on the first page of the forum by chance) so excuse me if I don't notice an update.

[threeopus3]

Hi Emzed,

 

Thanks for the response. Were you ever able to get the unit price slider working with accuracy? In the 1.5.4 version which I am using (on Prestashop v 1.5.4.1) , the slider prices often differ from the product prices by a significant enough number (i.e. $1.50) that it is a problem.

 

I noticed that you posted a 1.5.5 version a couple of weeks after the originally posted 1.5.4 version. Were you able to tackle to rounding issues in the 1.5.5 version? I got the sense from your comments that you were. I compared files using Quick Diff (thanks for that) and see that there are a number of changes, so I haven't tried to fully merge the two files yet....

 

If I can't get this working, I am thinking that I could potentially turn tax off in the layered nav module (before indexing prices), and then do some math (in Canada, tax is 13%) so that I multiple the slider prices by 1.13. But even this has been tricky so far.

 

I can keep playing around with it, but am curious to know whether you were ever able to, or if it is even possible to, get the unit price filter display to have any accuracy.

 

My store sells wine, which is a bit unique - prices always include tax in this country when the product is alcohol.

 

Thanks,

Kent

[threeopus3]

Hi Emzed,

 

One more thought on a way to get this to work - I'm hoping that you might know how to easily make this approach work.

 

If I use your excellent 1.5.4 version with tax turned off in the layered nav module, it works perfectly and with full accuracy. In the .tpl file, I can then multiply $filter.min and $filter.max by 1.13. This would, in theory allow site users to see prices on the slider that match the prices in the store which include 13% tax.

 

If I could then multiple the numbers/integers that go into the URL by .88, the prices in the URL would pull up the correct products.

 

So, for example, if the most expensive product in my store has a pre-tax unit price of $100, it will show up in my store at $113.

 

If I turn off taxes in my layered nav module, it will show up in the slider at $100.

 

If I multiply the $100 $filter.min/$filter.max by 1.13, I would see a top range of $113 in my slider.

 

A slider value of $113 will not pull up any products, because the price in the URL will show as $113. And this does not exist.

 

Do you know where the function is that puts prices into the url? If I could modify that function so that prices = prices x .88, everything will work.

 

The prices in the URL will not match the prices displayed in the slider, but at this point I am okay with that.

 

I hope that makes sense.

 

Kent

 

Argh, Sorry, This Won't Work.

Edited October 18, 2013 by threeopus3 (see edit history)

[Emzed]

Hi Kent,

 

That's interesting. The unit price module and the latest module here are based off the same modifications. I've only tested the unit price module with 10% tax added for Australia and it works as expected. From a quick check now the module might not even function if I attempt to filter without tax and re-build the index (but I haven't investigated why).

 

Could you toggle back to using tax and ensure you re-build the entire price index?

 

If this doesn't work and you're certain you're getting the right tax-free filtered products then you could try a dirty hack of the following 2 lines at the bottom of the indexProductPrices function in the blocklayered.php file to prop up the indexed values by 13% before the integer rounding. But since my hacks were designed with taxes in mind this shouldn't work?!

'.(int)$min_price[$currency['id_currency']].',
'.(int)Tools::ceilf($max_price[$currency['id_currency']] * (100 + $max_tax_rate) / 100, 0).')';

//change to

'.(int)(1.13 * $min_price[$currency['id_currency']]).',
'.(int)Tools::ceilf(1.13 * $max_price[$currency['id_currency']] * (100 + $max_tax_rate) / 100, 0).')';

[Emzed]

The other question I had was whether you are setting unit prices for everything? And in that case, have you entered all the unit prices without tax. And have you just used my default tpl template directly or made modifcations to it?

[threeopus3]

Hi Emzed,

 

Thanks for taking the time to respond.

 

Here is what I just tried:

 

I downloaded the .php and the .tpl files from post 18 of this thread. I downloaded the PS version 1.5.6  blocklayered module, and swapped in the two files modified by yourself. I then uploaded this new blocklayered module package to my server, reindexed the store, and the unit price was not registering in the store at all. Strange. Don't know what I did wrong.

 

What I have been trying up until now:

 

- I replaced the blocklayered.php file in my PS 1.5.4.1 store with the version 1.5.4.1 blocklayered.php file that I downloaded from post # 11 in this thread.

- I have made some changes to the .tpl file, but tried reverting back the original 1.5.4.1 .tpl file and edited it as per your instructions in post # 18, by adding:

(if (step <= 1 && {/literal}{$filter.type == price}{literal})    step = 1;)

- Some of my products have unit prices, and some do not. The products without unit prices register correctly in the slider. The products that do have unit prices seem to suffer from the issues that you've written about in this thread:

 

Beyond this I've been wondering if it's better to have a ceiling value rather than a rounded value for the max price since it looks a little strange to have a $24.16 item appearing for a max price of $24.

 

 

My unit priced products seem to fall outside of the lower end of the slider. For example, a $52 product won't show up until the slider is lowered until about $47. If the low end of the slider is $48, for example, that $52 product won't show up.

 

The unit price was not calculated using tax. The unit price in the back office for the product just described is $46.01. So, 46.01 * 1.13 = 52.00.

 

If the price with taxes was say 7.20, this would be round down to 7 and would be incorrectly seen in a range of, say, 6 - 7. In combination with my change in (1) above, I changed this to always give a ceiling value instead, such that 7.20 would become 8 and fail the range

 

 

 

This seems to be the sort of thing that is happening, though it sounds like you fixed it?

 

Note that the slider handles tax correctly when unit price is not involved. So, for example, a product with a back office price of $12.17 will show up on the slider as $13.75 (12.17 * 1.13 = 13.75).

 

 

 

This is where it gets messy and I don't know if such drastic action was necessary or I'm missing some shortcuts or oversaw something simple. Since it appeared the reduction was being subtracted with tax from the price without tax due to the absence of an absolute country setting I created two separate functions to calculate final price. One to find the $price without reduction and a second that extracts only the reduction. I then use the pre-calculated max-tax rate in blocklayered.php to "de-tax" the reduction.

 

 

 

 

I feel like you are describing and dealt with the issue that I'm having, and that I'm either a) not using the right files I don't know what.

 

I did also try the no tax approach using 

'.(int)(1.13 * $min_price[$currency['id_currency']]).',
'.(int)Tools::ceilf(1.13 * $max_price[$currency['id_currency']] * (100 + $max_tax_rate) / 100, 0).')';

As you suspected, that didn't work.

 

Do you think it might be the case that this just doesn't work for Prestahop 1.5.4.1?

 

Kent

Edited October 18, 2013 by threeopus3 (see edit history)

[Emzed]

Hi Kent,

 

I'm not home right now but I just wanted to make sure you're not using any files from this thread, which isn't designed to work with unit prices. Please modify the files attached in the other thread you started.

[Emzed]

I think I should delete the mods at the top of this thread since people keep downloading it. I left it for historical reference only.

[threeopus3]

Thanks again, Emzed. Confirming that I used the files posted in this thread, I continued to experience the same price rounding issues.

 

However I was able to turn off taxes in my slider index, and then calculate them in my .php file using the solution that you provided:

--

'.(int)$min_price[$currency['id_currency']].',
'.(int)Tools::ceilf($max_price[$currency['id_currency']] * (100 + $max_tax_rate) / 100, 0).')';

//change to

'.(int)(1.13 * $min_price[$currency['id_currency']]).',
'.(int)Tools::ceilf(1.13 * $max_price[$currency['id_currency']] * (100 + $max_tax_rate) / 100, 0).')';

--

In short, I now have a slider that displays unit price with accuracy. MUCH appreciated....As you may be able to tell, I really struggled with this one. Thanks for your help.

 

Kent

Edited October 18, 2013 by threeopus3 (see edit history)

[Emzed]

It's great you found a workaround.

 

Could you elaborate which files from this thread you used exactly? The original ones I now labelled "DO NOT WORK" or the later one for 1.5.5? The whole reason for me creating a new version in the first place was based on this one line I wrote:

" Since it appeared the reduction was being subtracted with tax from the price without tax due to the absence of an absolute country setting... ".

Are you using discounts or specific prices at all? If you don't now and everything works, I worry you may have headaches down the road.

 

Also, did you ever try the files in the other thread like I mentioned. They were custom made for your needs -i.e. unit pricing slider - and if you notice the dates they were actually posted after I noticed all those issues and made the major changes in this thread. If you haven't, for your own future sanity, PLEASE TRY THOSE FILES    after backing up your current solution since I have a feeling your issue is not solved if you plan to filter by unit prices (or plan on using price reductions).

 

I haven't had a chance to go through it yet, but from the top of my head, I'd say that you can't accurately index reduced prices without tax in even my latest modified files since when Configuration::get('PS_LAYERED_FILTER_PRICE_USETAX')=0 the max_tax_rate defaults to 0 and there's no tax to remove from the reductions that include tax. Thus all index prices can be potentially low after integer casting rounds them down. I can fix this by creating a separate max_tax_rate_for_reduction variable that never defaults to 0 (by ignoring PS_LAYERED_FILTER_PRICE_USETAX) and using this value to remove tax from all the price reduction values.

 

If this works, I'll post the latest revisions here and in the other thread for your unit-pricing version.

[Emzed]

I have modified the php file once again so that the index works correctly without the addition of taxes.

 

I have changed this part...

			if (Configuration::get('PS_LAYERED_FILTER_PRICE_USETAX'))
				$max_tax_rate = Db::getInstance()->getValue('
					SELECT max(t.rate) max_rate
					FROM `'._DB_PREFIX_.'product_shop` p
					LEFT JOIN `'._DB_PREFIX_.'tax_rules_group` trg ON (trg.id_tax_rules_group = p.id_tax_rules_group AND p.id_shop = '.(int)$shop_list.')
					LEFT JOIN `'._DB_PREFIX_.'tax_rule` tr ON (tr.id_tax_rules_group = trg.id_tax_rules_group)
					LEFT JOIN `'._DB_PREFIX_.'tax` t ON (t.id_tax = tr.id_tax AND t.active = 1)
					WHERE id_product = '.(int)$id_product.'
					GROUP BY id_product');
			else
				$max_tax_rate = 0;

to this...

			$max_tax_rate = Db::getInstance()->getValue('
				SELECT max(t.rate) max_rate
				FROM `'._DB_PREFIX_.'product_shop` p
				LEFT JOIN `'._DB_PREFIX_.'tax_rules_group` trg ON (trg.id_tax_rules_group = p.id_tax_rules_group AND p.id_shop = '.(int)$shop_list.')
				LEFT JOIN `'._DB_PREFIX_.'tax_rule` tr ON (tr.id_tax_rules_group = trg.id_tax_rules_group)
				LEFT JOIN `'._DB_PREFIX_.'tax` t ON (t.id_tax = tr.id_tax AND t.active = 1)
				WHERE id_product = '.(int)$id_product.'
				GROUP BY id_product');
			
			$max_tax_rate_for_reduction = $max_tax_rate;
			
			if (!Configuration::get('PS_LAYERED_FILTER_PRICE_USETAX'))
				$max_tax_rate = 0;

Note that I maintained the assumption from the original file that if $max_tax_rate_for_reduction or $max_tax_rate are NULL, PHP will automatically cast them to zero when used in arithmetic.

 

I then use $max_tax_rate_for_reduction in place of $max_tax_rate to subtract the discounts properly from the prices in my previous modification (but I still use $max_tax_rate on the indexed min_price to form the max_price).

 

v3-155-blocklayered.php - Rename to blocklayered.php

155-blocklayered.tpl.txt - Rename to blocklayered.tpl

Edited November 15, 2013 by Emzed (see edit history)

[threeopus3]

Hi Emzed,

 

As I mentioned in the previous thread, I got your original version (posted in the thread: http://www.prestashop.com/forums/topic/276126-block-layered-price-slider-use-unit-price/) to work, when I turned off tax indexing in the module. 

 

This provided product unit prices without taxes to my slider. I then used this mod of yours:

'.(int)$min_price[$currency['id_currency']].',
'.(int)Tools::ceilf($max_price[$currency['id_currency']] * (100 + $max_tax_rate) / 100, 0).')';


//change to


'.(int)(1.13 * $min_price[$currency['id_currency']]).',
'.(int)Tools::ceilf(1.13 * $max_price[$currency['id_currency']] * (100 + $max_tax_rate) / 100, 0).')';

This successfully added taxes back to the slider prices and my site slider displayed perfectly as I needed it to. (As you know, the tax rate I am dealing with is 13%, hence the number 1.13).

 

-----

 

The 1.5.5 version never did work for me - the slider just never picked up unit prices. I am using PS v1.5.4, so that may have had something to do with it.

 

As you point out, price reductions won't be recognized by the slider. As such, I will explore your newest code, though I hesitate to mess around with the current set up because, thank to you, it works perfectly for my current needs.

 

Anyway, I will report back when I have tried the latest and greatest.

 

Thanks again VERY MUCH!

 

Kent

[strat813]

Hi,

 

I'm trying to modify my blocklayered.

 

On my store I have only products with specific prices (applied in percentage).

 

I would like to filter my products on the final price

 

You can see that my filter is related to the normal price (for example on the picture 6,00€ and not 3,45€).

 

Do you know how to do that please.

 

You would save my life

[tomerg3]

If you're looking for a working alternative, and cannot wait for the PS team to address this issue, check out http://www.prestashop.com/forums/topic/118467-module-ajax-filter-ajax-based-filter-using-price-supplier-man-category-feature-attribute/

[strat813]

Thank you tomerg3, I'll check that

[Emzed]

Hi strat813,

 

Have you not tried the modified files posted above or do they still not work?

[Emzed]

I might add taxes to the minimum indexed prices as well in an updated version (unless someone can justify otherwise). I was unsure whether this was an obvious bug or an intentional (yet unusual) feature so I previously left it as is.

[kingboy1027]

 Emzedasdf

[kingboy1027]

Emzed,hello. i use your blocklayered.php file,but i find it has an error, in the ps_layered_price_index datatable,the price_max is wrong.so ,can you fix it ?

price_min is 20,but price_max is  2091, how could ？

[Emzed]

Hi kingboy1027,

 

That's interesting. Is only one product affected? And has a specific price been set for the product, and if so, was a percentage or fixed discount used?

 

I'm a bit busy now with a medical emergency but I'll try help as much as I can.

 

Cheers

[Emzed]

Also, which tax was applied? I can try recreate your issue.

[kingboy1027]

Also, which tax was applied? I can try recreate your issue.

Thanks.

yeah,i set up  the specific price with amount or percentage discount,but i find max_price of all products with specific price are wrong,while with no specific price are right. so,i delete the code below,it gets the right results. Anyhow , thanks! in fact,max_price of specific should approximately equal with the min_price. aha .

 

/*

foreach ($product_min_prices as $specific_price)

foreach ($currency_list as $currency)

{

if ($specific_price['id_currency'] && $specific_price['id_currency'] != $currency['id_currency'])

continue;

 

$price_before_reduction = Product::priceCalculation((($specific_price['id_shop'] == 0) ? null : (int)$specific_price['id_shop']), (int)$id_product,

null, (($specific_price['id_country'] == 0) ? null : $specific_price['id_country']), null, null,

$currency['id_currency'], (($specific_price['id_group'] == 0) ? null : $specific_price['id_group']),

$specific_price['from_quantity'], false, 6, false, false, true, $specific_price_output, true, null, null, null, 1);

 

$only_reduction = Product::priceCalculation((($specific_price['id_shop'] == 0) ? null : (int)$specific_price['id_shop']), (int)$id_product,

null, (($specific_price['id_country'] == 0) ? null : $specific_price['id_country']), null, true,

$currency['id_currency'], (($specific_price['id_group'] == 0) ? null : $specific_price['id_group']),

$specific_price['from_quantity'], false, 6, true, true, true, $specific_price_output, true, null, null, null, 1);

 

if (isset($price_before_reduction, $only_reduction))

$price = (float) $price_before_reduction - (float) $only_reduction * 100/(100 + $max_tax_rate_for_reduction);

 

unset($price_before_reduction, $only_reduction);

 

if (!isset($max_price[$currency['id_currency']]))

$max_price[$currency['id_currency']] = 0;

if (!isset($min_price[$currency['id_currency']]))

$min_price[$currency['id_currency']] = null;

if ($price > $max_price[$currency['id_currency']])

$max_price[$currency['id_currency']] = $price;

if ($price == 0)

continue;

if (is_null($min_price[$currency['id_currency']]) || $price < $min_price[$currency['id_currency']])

$min_price[$currency['id_currency']] = $price;

}

*/

[Emzed]

Hi kingboy1027,

 

Thanks for the update. I was skeptical about that function working under all scenarios since I haven't tested it and don't have a test shop that is multi-shop, supports more than 1 country, supports more than 1 currency, uses group-specific pricing or uses various minimum quantity amounts per product. I'll need to check out the Product class's priceCalculation function again to investigate how it works with the parameters and what could cause such a high value.

 

If you have time it would be great if you could post from your ps_specific_price table the various lines for a particular id_product, that include id_shop, id_country, id_currency, id_group and from_quantity.

 

Cheers

[navid68]

Hi Emzed,

 

you clearly know the Layered Navigation module very well, so I would like to ask you this question.

 

The slider can be used for weight and price, how to use the slider for other features?

Other people are looking for a solution... see http://www.prestashop.com/forums/topic/273944-feature-slider-instead-of-checboxes-in-block-layered-navigation/

 

I am trying on PS 1.6.0.5 and can not find a way, any suggestion for a non-coder?

 

Thanks

Navid

[Emzed]

Hi navid68,

 

I don‘t have access to a computer and won‘t for a while but judging from memory it might not be straightforward to modify the module.

 

I haven‘t used Prestashop for a long time now since my projects have changed so I‘ve inactivated my Prestashop testing environment after updating my working environment. When I return home if I get the time I hope to check out the raw code.

 

Cheers

[navid68]

Thanks Emzed

 

Navid

[somits1]

Hello,

 

I am using prestashop 1.56 English version. But in my price range not available or not showing price filter. My Site is http://slmobileprice.com

 

Could you please help me to show price range in my website. or share any module as i don't know about php coding.

 

Thanks,

Somit

[Nicolas Lecloux]

Can someone post an updated version for the blocklayered.php / blocklayered.tpl please?

I want the final selling price of the products to be displayed.

 

Thanks in advance

[Medea Web Agency]

Do you know if these solutions work for 1.6 version too?

Layered navigation is a very useful module but it display the final price and not the special price (reduced or without taxes applied)

So we need to fix it, it will helps so many people

 

Thanks

[lcalin]

The min-price bug is still there, even in 1.6.1.1...

I solved it by changing the minprice the line 1295 from:

'.(int)$min_price[$currency['id_currency']].',

to

'.(int)Tools::ps_round($min_price[$currency['id_currency']] * (100 + $max_tax_rate) / 100, 0).',

 

Hope this helps!

[YiannisK]

somehow I cannot download the files

[nalini]

Hi Every one,

 

Can any one suggest me how to display  Price  range like 10$ -20$    ,21$-30$   and so on   in Left Nav ?

 

Thanks  in advance.

Edited November 24, 2016 by nalini (see edit history)

[Julen93]

Works on 1.6.1?