SKU live search resutls not working

[Anonymous]

I have your ajax search pro plugin installed on my client’s site and it works well except that it can’t seem to find the right woocommerce SKUs. I’m using indexed search and have the _sku custom field included (though the behavior is the same if I switch to regular engine as well).

As far as possible plugin conflicts go, I do have the SKU Search for Woocommerce plugin installed but disabling it didn’t seem to make any difference.

Here’s some screen shots: http://imgur.com/a/DJctk

If I type “116” then it will start to search and show me a product with the sku “116-M10176”. If I pass the dash and type “116-S” then it gives me the no results found message. However, if I click the search button then the correct product appears on the search results page.

Any idea how I can fix this?

Thanks,
Chris Patrick

[Ernest MarcinkoKeymaster]

Hi Patrick,

Before the recent update (4.8.4) there was a known issue with index table and custom field search.

Let’s try the following steps:
1. Make sure that the Remove dash like characters? option is turned OFF on the index table options page: https://i.imgur.com/GF2iibS.png
2. If the _sku custom field is selected on the index table page, save the options once again, so everything is refreshed.
3. Delete the current index and create a new one: https://i.imgur.com/9IHjvTN.png
4. Make sure that the index table engine is selected on the search instance options page.

Once the new index is ready, try searching again for the SKUs again. If the problem was related to the bug with the previous version, it should start working.

Best,
Ernest Marcinko
If you like my products, don't forget to rate them on codecanyon :)

[Anonymous]

Hi Ernest. Thank you for helping me look into this.

First I disabled my w3total cache database/object caching to make sure it wasn’t related to that and purged all the rest. Then I followed your instructions and verified all the settings were correct. Remove dash like characters is off, search is set to indexed including custom field _sku, deleted the index and recreated it, then cleared my cache one more time for good measure. Unfortunately this didn’t seem to change anything.

It doesn’t appear to be related to the previous index table issue, since it seems to happen with either indexed or regular engine searches. I’ve tried looking at the database to see if there is anything funky about the saved SKU entries but they appear to be correct (e.g. I don’t see any formatting differences between the SKUs that it can find and the ones it cant’).

Here are some examples of the data… really not sure what it could be since it i can find some dashes and some not.

Working Examples:
LATCHSLAM
NOZZLEFOG1.5
LATCH T-HANDLE
181-2.5VF7302210 (if pasted into search, but fails with just 181-2.5 typed in)
252-800

Not Working Examples:
252-500
NOZZLEFJ3/4HH-4.0
3332-10NC
1771-NCIV-KIT
181-B5-RWG10

Searching for 252- gets me 252-300×200 and 252-800 but not 252-500.

The only difference I see in those is that 252-500 is a variant SKU and the parent product doesn’t have it’s own SKU… though adding one didn’t seem to make a difference either. 3332-10NC is also a simple product so idk if the variable/simple thing has anything to do with it.

[Anonymous]

You cannot access this content.

[Ernest MarcinkoKeymaster]

I have found out why! It was strange to me that the numbers were correct in terms of the indexed documents and the SKUs, so I suspected that it might be some kind of exclusion.

The problem is that you have a post date inclusion rule configured to include results from date 2014-08-01 to 2034-08-01. I’ve checked, and all of the not working SKUs are before the given date range. I have disabled this option on the Advanced Options -> Exlude results panel, now it search through all the results.

However one thing will not work for sure yet with the index table engine, and it’s the product SKUs with the forward and backslash “/”, “\” characters. So “NOZZLEFJ3/4HH-4.0” might not return anything. The good news is that it will work with the regular engine, and I’m going to add support for more special characters including the slashes for the upcoming version.
It’s a security related concern, and I want to carefully test it to make sure that it’s not something that could be used for hacking the database of my customers.

Best,
Ernest Marcinko
If you like my products, don't forget to rate them on codecanyon :)

[Anonymous]

You cannot access this content.

[Author]

Posts