tomtotalsurf

Was a fix ever implemented for this or is it still in the pipeline?

Hi

So I’ve been looking at it further and I’ve found a solution, at least for my use case and a couple of test cases I looked at. Unfortunately I haven’t really been able to fully test it and not sure if I will get the chance. Part of that means I have made some changes but not 100% certain if it actually mattered to the end result as I haven’t had a chance to revert those changes.

Basically all I did was looked at any instance where you’re rounding a number and increased the precision on it, or removed rounding altogether (removing intval function calls). Whether those actions were needed, I’m not sure. The final action which actually showed a result was in /public/assets/js/pp-handler.min.js and making vars.data.amount=Math.floor(PHP_round(tAmount,2)) in the calcTotal function.

To be honest there’s still probably some inaccuracy in the calculation as the value is 1299.6 when it should just be 1299, but it seems to work in this instance and could potentially be a more robust solution? Again, more testing would be needed to see if it’s worth it.

Thanks

Hi

Yes we’re trying to get 12.99 with 20% tax.

I understand rounding the price to 2 decimal places, but it seems strange that this is done before the final value is calculated. Doing it this way means there are values which people just can’t sell an item for. If I look at Germany’s 16% VAT as another example, they can’t sell an item for 15.99 as the base price would (accurately) need to be 13.7844827586.

I’ll probably just see if I can tweak it easily enough for my purposes or just push for a slight change in price, but hopefully you understand where I am coming from.

Thanks

Hi

Just as another test, I set the product to 10.825 and then included shipping of 2.49 and I still get a similar issue:
Invalid payment amount received. Expected ￡15.48, got ￡15.49.

The same happens if the shipping becomes 2.50:
Expected ￡15.49, got ￡15.50.

Thanks

Hi

Sorry for the delay in replying.

Bringing it down to 10.82 makes the total 12.98 after tax. I’ve tried playing around by increasing/decreasing the value to see if something like 10.8249 would resolve it but it doesn’t, it’s either 12.98 or 13.

Thanks

Hi

Was there any further update on this?

Thanks

That actually makes complete sense and actually filtering the “Captured URLs” would be sufficient for what I actually need. Basically what’s sort of happening is that someone will see 100s of these URLs (a lot of which are just bots trying to brute force a link) and think it’s a bigger issue than it really is, so it’s just me trying to mitigate that and also it would hopefully help show more “legitimate” URLs which have been caught with no redirect.

Sorting by last used kind of does the job, and makes me wonder if hiding anything not used in X days would probably do the job and similarly in the “pop up”/header where it says “404 Solution: There are N captured 404 URLs to be processed.”, just limiting it by time. Maybe couple this by checking it against existing filters. Though, this is probably out of the scope of the plugin and would be something I would have to look into myself.

Thanks for all the help, if nothing else I’ve realised my problem may have a reasonably easy solution to it. Much appreciated!

Thanks for the quick reply! I have given this a go but does not seem to work. Perhaps this is because it requires some kind of folder reference/file extension but I am trying to block a URL from logging?

For reference, I went to the URL /adminpageWILLTHISWORK which I believe would match /adminpage*