threeopus3

I have a client who is looking for help for help customizing his Prestashop store. This would be a contract for ongoing support including managing web hosting. You must be expert in Prestashop and must be able to provide some samples of past work. Ideally, you live in Toronto. Please contact if you would like to learn more. Thanks!

Here is one of those BIG issues with little documentation. As we know, the layered navigation module requires a hash tag (#) before the filter names. As such, google does not track any product views in the store. Does anyone have insight into how to deal with this? Thank you in advance. Note: In blocklayered.tpl, I can change this code: <script type="text/javascript"> {if $nbr_filterBlocks != 0} current_friendly_url = '#{$current_friendly_url}'; {if version_compare($smarty.const._PS_VERSION_,'1.5','>')} param_product_url = '#{$param_product_url}'; {else} param_product_url = ''; {/if} </script> to <script type="text/javascript"> {if $nbr_filterBlocks != 0} current_friendly_url = '=?{$current_friendly_url}'; {if version_compare($smarty.const._PS_VERSION_,'1.5','>')} param_product_url = '?{$param_product_url}'; {else} param_product_url = ''; {/if} </script> While this (substituting # for ?) works, and google can now track product views, there is an extra page load whenever I elect a filter. I have tried editing blocklayered.js to deal with this extra page load, but have not had any luck.

Bump

Bump

Hi Meredith, No, I never figured out how to do this. I've realized that I don't have the skill set to customize Prestashop in any real way. Wordpress? No problem? Prestashop? Not so much. Sorry. Kent

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

Hi Emzed, Thanks for this. I will give it a try. However, I was able to get the previous version to work when I turned of taxes at the module indexing stage. With this update to the pho file, taxes appear. '.(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).')'; Thanks again for your hard work on this. This code that you have provided is a huge update to Prestashop, as far as I'm concerned. Thanks again, Kent

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

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

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.

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

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

I can confirm that works. Oh man, I am way too excited about this. Thank you!

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.

Emzed, I would be so grateful if you could post that. I actually hired some developers to help me with this and they are breaking the store in the process. So, I would be so thankful it if you could post a working version. I promise, in the name of karma, that I will give back. Cheers!!!