another search issue

[keat]

We have 25 products with a product_code starting BPN.

If I search BPN only 12 products appear in the results (2 of which contain BPN in the description).

The web site would indicate that there are 3 pages of BPN's, which if there are 25+ this would be about right.

But if I click to the next page, then nothing happens. Also 'View All' does nothing.

 

This probalem appears to be when searching product codes and not so much when searching words.

If I search 'brake pipe nuts' which are BPN's then the search works and will move on to the next page.

 

Any pointers please.

[bsmither]

When you "click to the next page", do you actually get a new page, with the CubeCart header, sidebars, footer, but an empty main content area? Or is it a just a completely blank white screen? Or when you say "nothing happens" and "does nothing", are you saying that when clicking on the link, there was no effort by the browser to issue a request for a new page?

Please remind us of the web address for the site.

 

[keat]

Click the next page, the page flashes (assume a refresh), but nothing changes.

web site is www.beal.org.uk

 

Search for BPN (a product code) and see what happens.

But search for 'Brake Pipe Nut' and see how the page actually does refresh.

[bsmither]

Searching BPM.

I see that the web address indicates that page=2 has been requested, but yes, the twelve results are the same as shown on page 1.

Clearing CubeCart's internal cache had no effect.

Asking for a sorted list (Price Low-High) got the twelve lowest priced products. Page=2 got the same products.

I had a suspicion that the database is resisting in some fashion having to search on a three or less letter search term. The term UNF seems to work, but GRN has only one row returned in the resultset. GRN1 has 12 in the predicted search popover but shows only the two products where "GRN1" is the actual product code.

So, I cannot see that there is a fault in the building of the query - specifically calculating the solution to 'per-page' multiplied by 'page-1'. (That is, for page=2: 12x1=starting at the 12th row in the resultset for 12 rows.)

There must be a fault in the construction of the wildcards used in the REGEX query sent to the database.

Examining the queries that CubeCart sends to the database would be helpful. In admin, Store Settings, Advanced tab, enable Debug Mode. Enter your local IP address in the following text field (www.showmyip.com). Save.

Search for BPM.  Go to page=2. At the bottom of the screen will be some diagnostic info. Specifically, all the queries sent to the database. Copy and Paste that list of queries into a Private Message to me.

Edited September 26, 2022 by bsmither

[keat]

We don't have a product code 'UNF', so this phase appears in either the prodct name or description.

The issue seems to be around product codes.

 

PM sent

Edited September 26, 2022 by keat

[bsmither]

Please try this edit. In /classes/catalogue.class.php:

The line numbers may be slightly different...

Lines 1941-1943, find:

                    } elseif ($search_mode == 'fulltext') {
                        return $this->searchCatalogue($original_search_data, 1, $per_page, 'rlike');
                    }

Change to:

                    } elseif ($search_mode == 'fulltext') {
                        return $this->searchCatalogue($original_search_data, $page, $per_page, 'rlike');
                    }

Lines 1998-2000, find:

                    } elseif ($search_mode=="rlike") {
                        return $this->searchCatalogue($original_search_data, 1, $per_page, 'like');
                    }

Change to:

                    } elseif ($search_mode=="rlike") {
                        return $this->searchCatalogue($original_search_data, $page, $per_page, 'like');
                    }

 

[keat]

my line numbers were massively out compared to the ones you quoted.

I found the lines way higher up in the 3-4000's.

I made the edits but it killed the site.. just a white screen

[bsmither]

Literally, the change involves replacing a digit (1) with the name of a variable ($page). This edit cannot have caused a white screen.

 

Depending on the text editor used, the editor may be doubling the line endings, making the file double spaced.

Thus, line 1941 becomes 3882.

Do you recall seeing double spacing in the editor you used?

 

[keat]

Yes on the double spacing...

Quite clearly I did something wrong with the edit, but what ever I did...... I did it wrong twice

So I remade the edit, and now the search seems to work for that phrase.

But if I search GRN (Grease nipples), it says only 1 product found, yet there are probably 30 or more.

 

Also, If I search TAR (which is a range of tarpaulins) it only bring up T-Cut (which removes tar spots)

I'm guessing that it's only searching the descriptions maye, only I've no idea why BPN's show a full range.

.................................................

 

I figured something out.

 

If I search GRN, the results come back with only one product found.

This product contains the phrase 'GRN in the description'

If I remove this phrase from the product and try again, the search comes back with about 30 results.

 

I can only conclude that the search looks at the description first, and if it finds an answer, doesn't look elsewhere for any other occurances.

It's done it's job and stops.

 

...........................................

 

And then it's even more wierd.

I removed the TAR phrase from t-cut.

Performed a fresh search for TAR and the results come back with 49 pages.

 

Edited September 27, 2022 by keat

[bsmither]

CubeCart has three methods to ask the database on how to formulate a query:

1. Fulltext Relevance - if nothing found, then
2. REGEX on word boundaries - if nothing found, then
3. REGEX anywhere - if nothing found, then say "No products found."

Fulltext Relevance is a somewhat complicated method to explain. Basically, if too few results are returned, the term(s) must not be all that important. If too many results, then the term(s) must not be all that unique. There are nuances.

Word boundaries will find whole words. 'TAR' will find "TAR 735" but not "TAR735".

Anywhere will find the sequence of characters in "TAR", "TAR367", "STAR-BRIGHT", etc.

By looking at the list of SQL queries in the debug section, it can be determined which method CubeCart finally used: whether there are one, two, or three search queries.

Several store owners have edited the searchCatalogue() function definition so that the default method is $search_mode = 'rlike', skipping the 'fulltext' method.

[keat]

 

T-CUT cleans tar from paintwork, if i remove the phase 'tar' from the product description, and perform a new search the cart then comes back with 490+ products.

I'd suggest that 480 of them probably don't contain this phrase anywhere.

For instance, search tar and the first result (out of 490) is a cable tie.

https://www.beal.org.uk/stock-clearance/stock-clearance/cable-ties-bases/cable-ties-762mm-x-9.0mm

No mention of TAR anywhere, maybe if it contained the phrase 'guitar' i could understand why it pulled this product. ??

[bsmither]

By looking at the list of SQL queries in the debug section, it can be determined which method CubeCart finally used: whether there are one, two, or three search queries.

The first will be a query, if present, will have the word RELEVANCE in it, the second, if present, will have the word RLIKE in it, and the third, if present, will have the word LIKE in it.

(There will also be several queries that have LIKE in them but searching against the CubeCart_manufacturers table. Ignore these.)

There is a preliminary test that asks the database what is the minimum number of letters that the shortest search term must have. It will be this query:

SHOW VARIABLES LIKE 'ft_min_word_len'

The answer is usually 4. So, because at least one of the search terms is less than 4 characters, the RELEVANCE query won't be executed and you won't see it in the list of queries. Instead, CubeCart will skip that and go to RLIKE.

Since TAR is a whole word, the search using RLIKE succeeds.

Then, you remove the whole word TAR from the description, and now CubeCart uses LIKE which will find 'tar' as part of any word.

I cannot explain why the results include obvious non-matches.

However, the LIKE query is permitted to use the query cache. So, if there was a recent instance where the data for product_id 7817 (aka TR21-W) did include a word containing 'tar', then maybe we see this because of a cached recordset from an earlier search on 'tar'.

We would have to explore your database directly.

 

[keat]

As from last week, I'm semi retired, i'm only working 1 day per week, hence the delay in responding.

Any suggestions how you'd explore the database ?