Jump to content

another search issue


keat
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by bsmither
Link to comment
Share on other sites

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');
                    }

 

Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

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 by keat
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

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. ??

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...