PHP 8.0 - Search function not working properly following upgrade to 1.5.8

[mikeel100]

Hmmm...not sure what's happening.

I will try your scenario on my unmodified installs after breakfast.

The search mechanism could use some improvements like checkboxes for sale price, regular price, free shipping, in stock,, and anything else that would limit the customers ability to get the product. It would help store owners too.

I may try to work on improvements after I finish updating my cart.

[mikeel100]

I have tried that. Updating the sanitize makes it better, but it doesn't work 100%.

As per my examples above, if I do 48 to 48 it only shows products with a '+' in the title (why?)
Same for 46 to 48, and 47 to 48.

However if I do 45 to 48 it works as it should! And also 0 to 48.

In my unmodified 1.5.8a install...except for the init_sanitize.php modification.

I typed in 45 to 50 in just the price range text boxes to see what items show up in that price range...and to verify if I have a $48 item in my cart.

I had four $50s (one sale priced), two $49.99 items, and one $45.00 item.

Next, I searched $50 to $50, $49 to $50, $45 to $45, and $49.99 to $49.99 and all yielded the expected results.

I took it one step further and compared all of these results against the prices in the database price and sale price information.

The catalog search mechanism is picking up everything it is supposed to in my case.

Sale prices are the determining / overriding factor with regards to showing them in the search results...which is good. So, If you are expecting to see a $48 normally priced item with a sale price that is out of your search range, then you are not going to see it in the results.

Make sure you have a $48 non-sale item and a $48 sale item in your cart (thanks Capt Obvious...LOL). Then, repeat the test I just did.

If you are still having issues, report it here and someone will hopefully help you. I don't see a problem with the search engine.

[royaldave]

You're right.

I did a fresh install and it works (with the init_sanitise amendment of course).

I think multisite is interfering with the search. And it's probably been a problem for a long time because my live 157 install is showing the same!

Damn! Have I never tested this before???

[royaldave]

You're right.

I did a fresh install and it works (with the init_sanitise amendment of course).

I think multisite is interfering with the search. And it's probably been a problem for a long time because my live 157 install is showing the same!

Damn! Have I never tested this before???

Actually I take back what I just said. I've gone back to the fresh install and am getting inconsistent results. Some queries work better than others, but I still feel there's something not right about searching in a price range.

[mikeel100]

What is multisite and is your fresh install on it?

I am out of ideas...can anyone else shead any light on this?

[royaldave]

Multisite is a plugin that allows multiple domain names/templates to point to one zencart install - and it allows you to choose which categories are listed on each domain.
The "cat_filter" in this plugin immediately jumps out as the likely culprit - however when I say fresh install I do mean unzipping the zencart.zip and not making any amendments.

I really tied myself in knots with this the other night and need a fresh pair of eyes to go over it again in case my thinking was not correct - so will come back to this.

I think previously I've removed the price from/to from the search page (and always the dates) and re-introduced them to my 157 install. I'm quite happy to remove them again to get my 158 install live and I will come back to this.

[mikeel100]

Good plan.

I have been upgrading since Jan 21...I finally resolved all of my log errors and issues yesterday!

Next...file taxes.

Good luck.

[royaldave]

OK, my 158 upgrade has worked fine so I'm back to investigating this.

I have freshly unzipped the 158 onto my server at home and am getting the same results.

Without updating the init_sanitize file, doing a price range without the .00 added to the price values causes the search to basically ignore that criteria and display all matching products at any price.

However even with the .00 added, doing my from:48.00 to:48.00 or from:47.00 to:48.00 will display nothing that should match - except products that have a '+' in the title will show up!

When I update the init_sanitize file as recommended all it means I can get the same results by entering from:48 to:48 - ie I don't need the .00 anymore.

It's a strange one.

Maybe it's an issue with my DB - but everything else works!

[royaldave]

OK, I have kind of worked out the problem here.

This section of code in header_php.php in modules/search_result



if (DISPLAY_PRICE_WITH_TAX == 'true') {
if ($pfrom) {
$where_str .= " AND (p.products_price_sorter * IF(gz.geo_zone_id IS null, 1, 1 + (tr.tax_rate / 100)) >= :price)";
$where_str = $db->bindVars($where_str, ':price', $pfrom, 'float');
}
if ($pto) {
$where_str .= " AND (p.products_price_sorter * IF(gz.geo_zone_id IS null, 1, 1 + (tr.tax_rate / 100)) <= :price)";
$where_str = $db->bindVars($where_str, ':price', $pto, 'float');
}
} else {
if ($pfrom) {
$where_str .= " and (p.products_price_sorter >= :price)";
$where_str = $db->bindVars($where_str, ':price', $pfrom, 'float');
}
if ($pto) {
$where_str .= " and (p.products_price_sorter <= :price)";
$where_str = $db->bindVars($where_str, ':price', $pto, 'float');
}
}



What is P.products_price_sorter all about?

If I replace that with p.products_price I get the desired result!

Actually now i know what the issue is - not too long ago I decided to increase all products with a $45 price tag to $48 and I did a quick and dirty sql query in admin to change the price. I didn't realise there was this price_sorter field so my sql query didn't take care of it. What's it for anyway?

[mikeel100]

Price sorter is the sale price...