SEARCH in 1.2 still dosent work ! ?

[VIXUS]

i was searching for "book" and i did not get any result?
When clearly we have a macbook as product.

see immage...

[anafor]

I have the same problem(((. I have indexed the products in BO, but no result. What I'm doing wrong?

[Iamcaptain]

Works for me in 1.2.4.

Try searching for "Book", maybe it's case sensitive?

[fs_xyz]

Add a dummy product 1st. Just a simple description for name and empty description for the rest.
After that, just delete the dummy.
If you were using upgrade to get to 1.2.x , you need to use this way to make the search work.
Unless you are starting a fresh 1.2.4 install.

[anafor]

I've started a fresh 1.2.4 install and it's not case sensitive.
But I've found a solution.) I've installed the yasearch module and draw attention, that it's search_adv function works fine. So, I've just replaced the reference to "search" function with "search_adv" one in /search.php. Everything works fine!)) I have no time to look into this problem to find out, why does it has such behaviour, I just need a fast simple solution, but it'very interesting for me, so I'll engage in it later. If anybody find the solution earlier, please, tell me, I will be very appreciate for it!))

[TropischBruin]

I've just replaced the reference to "search" function with "search_adv" one in /search.php. Everything works fine.

Could you upload that change file to you reply please so others cab use it?

Thanks!

[anafor]

Yes, of course! But it's a "dirty" solution, and has to be fixed properly, due to unpredictible behaviour :smirk:
NB: the yasearch module is needed to be installed already to use it

search.zip

[codegrunt]

A quick look at "classes/Search.php" suggests to me that searching is left justified as the "%" wildcard appears afterwards. For MySQL performance reasons it is difficult to support both left and right justified wildcards (you cannot index right justified searches) so I bet if you seached for "macb" you would have got results.

Presumably the reason why yasearch is working for you is that they are doing this:

WHERE word LIKE "%book%"

You could change the logic in the stock search class to do that too but it will get slow if you have a lot of words in your table since it will not be able to use indexes to speed things up.

The only other option would be to use some sort of stemming function to break up words like macbook into parts. That's not a small task though there may be a PHP class out there somewhere already that does this.

Cheers

PS: for got to mention that by default MySQL string searching is *NOT* case sensitive so that is not the issue.

[anafor]

It seems to be a MySQL problem. I have a 5.0.67 version installed. The search returns correct results, but "SELECT FOUND_ROWS()" MySQL statement return 0 in any case. This problem was solved in yasearch module by repeating the MySQL search statement without the LIMIT. I've made the same thing with "search" function and it worked!

[codegrunt]

That's horribly inefficient though since all results need to be retrieved. It will also likely break paging.

Have you tried printing the generated queries out? If so, please post the originals as that should demonstrate what is happening.

Again, unless they are using a query with wildcards on both sides of the search word, "book" will not match "macbook".

FULLTEXT searches are a totally different bag of hammers but I do not believe that PrestaShop uses those (at least I did not notice it so far).

Cheers

[anafor]

Search query = "asus k50c".
$result =
Array ( [0] => Array ( [id_product] => 23 [id_supplier] => 0 [id_manufacturer] => 0 [id_tax] => 1 [id_category_default] => 11 [id_color_default] => 0 [on_sale] => 0 [ean13] => [ecotax] => 0.00 [quantity] => 10 [price] => 4209.700000 [wholesale_price] => 0.000000 [reduction_price] => 0.00 [reduction_percent] => 0 [reduction_from] => 1942-01-01 [reduction_to] => 1942-01-01 [reference] => 36047 [supplier_reference] => 36047 [location] => [weight] => 0 [out_of_stock] => 2 [quantity_discount] => 0 [customizable] => 0 [uploadable_files] => 0 [text_fields] => 0 [active] => 1 [indexed] => 1 [date_add] => 2009-09-29 04:17:15 [date_upd] => 2009-09-29 04:17:15 [description_short] => ноутбук Asus K50C [C220SCENWW](15.6" HD,Cel 220 (1.2GHz),2G,250G, IGMA,DVDRW,WiFi,WC,DOS) [available_now] => [available_later] => [link_rewrite] => p23 [name] => ноутбук Asus K50C [C220SCENWW](15.6" HD,Cel 220 (1.2GHz),2G,250G, IGMA,DVDRW,WiFi,WC,DOS) [rate] => 0 [id_image] => [legend] => [manufacturer_name] => [position] => 19 ) )

$total =
0

[codegrunt]

Sorry, that's not what I meant - I meant the generated MySQL query.

I think we may be talking about different issues here - the first poster's problem was that a search for "book" did not match "macbook". There is no reason why it would unless the search includes wildcards like this:

SELECT * FROM some_table WHERE word LIKE "%book%"

You are talking about search results not showing because the row counting logic is not working here. That could be due to the MySQL version or possibly the MySQL connection is getting reset. Instead of sending a complete query again, just ask for the total count back instead:

$result_tot = Db::getInstance()->ExecuteS('
SELECT COUNT(DISTINCT p.`id_product`) AS tot
               FROM '._DB_PREFIX_.'product p
               LEFT JOIN `'._DB_PREFIX_.'product_lang` pl ON (p.`id_product` = pl.`id_product` AND pl.`id_lang` = '.intval($id_lang).')
               LEFT OUTER JOIN `'._DB_PREFIX_.'image` i ON (i.`id_product` = p.`id_product` AND i.`cover` = 1)
               LEFT JOIN `'._DB_PREFIX_.'image_lang` il ON (i.`id_image` = il.`id_image` AND il.`id_lang` = '.intval($id_lang).')
               LEFT JOIN `'._DB_PREFIX_.'tax` t ON (p.`id_tax` = t.`id_tax`)
               LEFT JOIN `'._DB_PREFIX_.'manufacturer` m ON (m.`id_manufacturer` = p.`id_manufacturer`)
               WHERE '.implode(' AND ', $whereArray).'
               AND p.active = 1
               AND p.`id_product` IN (
                       SELECT cp.`id_product`
                       FROM `'._DB_PREFIX_.'category_group` cg
                       LEFT JOIN `'._DB_PREFIX_.'category_product` cp ON (cp.`id_category` = cg.`id_category`)
                       WHERE cg.`id_group` '.(!$cookie->id_customer ?  '= 1' : 'IN (SELECT id_group FROM '._DB_PREFIX_.'customer_group WHEREid_customer = '.intval($cookie->id_customer).')').'
               )';
$total=(int)$result_tot[0]['tot'];

So the result from that will be the total matches in the

$result[0]['tot']

.
Same logic as what MySQL should be doing but should not be affected by the MySQL version or connection resets.

[anafor]

Thanks a lot!) It is what I just wanted to do, but didn't know how.) And you're right, we were talking about different things. But, we had very similar problems with the first poster: I tried to find "as" and didn't found "asus", just like in the first poster's case. I found the reason why it was happening in my case. I hope it could help him or anybody else, but there's no guarantee, that it would.

[rylersbud]

I had some issues with the search not finding an exact part number what solved the issue was surounding the query with qoutes prior to sending it to the server. this seemed to work.
if ($query = trim(Tools::getValue('search_query')))
{

$temp_query = '"' . $query . '"' ;
$query = $temp_query;
if (!Validate::isValidSearch($query))
A bit dirty but it worked well enough.
the problem I am having is with version 1.1 the search engine must use seach query longer then 3 characters. with version 1.2 it has a selection in the BO but 1.1 does not and I cannot find where the code is to correct this. some of our products use a 3 character part number for dies and crimpers. Anyideas?