Search not showing all products in v1.6.0.13

[Pedro Lima]

Hi,

 

And here's me again with another problem on Prestashop.

 

My search isn't showing results correctly, because not all products are showing and this is SERIOUSLY affecting my sales, because search is used very often by my customers...

 

For instance, this search result doesn't return all products: http://goo.gl/b065J8

 

And, at least, it should return these: http://goo.gl/Fv4qjC

 

Please I have already searched for a lot suggestions, cleared cache like "a bazilion times", reindexed index some 5 times, tried this change in search.php as explained by Nemo1 ( https://www.prestashop.com/forums/topic/322995-search-box-not-working-good/?p=1634700 ), ...

 

Nothing worked so far!

 

Please, please guys, this is a really big thing for me and I just noticed now that it's not working correclty but I don't know if this is for some time now.

 

I've spent MONTHS upgrading my old 1.5.4 to 1.6.0.9 and while in 1.5.4, search worked flawless. I've then upgraded to 1.6.0.11 and now to 1.6.0.13

 

I have tested SO many things but I think I just forgot to test search. I was finding weird that I had, with a new adwords campaign we are running, almost as double visitors as before but a really poor convertion ratio. I've just realised the problem two days ago and I've been trying really hard to solve it but so far, nothing...

 

Once again, please help me here.

 

Thank you guys very much in advance.

 

Best regards,

Pedro Lima

Edited March 12, 2015 by Pedro Lima (see edit history)

[erouvier29]

Hi Pedro,

Something completely stupid first: did you check that your products are visible for search or both search and catalog?

After that, did you activate debug mode to check if there is any error reported during the search request?

Regards

--

Eric

[Pedro Lima]

Yup, actually, debug is right now activated and nothing.

 

All items have visibility everywhere so all should appear.

 

Man, this is really anoying me and it's making me lose customers.

 

EDIT: Thank you so much for taking your time to help. Really appreciated.

Edited March 12, 2015 by Pedro Lima (see edit history)

[erouvier29]

I'm sorry for you Pedro but I have no idea except fully rebuilding the search index one more time.

 

Nevertheless you can analyse the current search index (and then the rebuilt one) to understand why your products are not correctly found. The following request will show you for each product what are the search words that will make it displayed (assuming that your language and shop are both #1). You can execute it from BO > Advanced parameters > SQL Manager > Add new SQL query, or directly in phpMyAdmin.

SELECT pl.name AS product, GROUP_CONCAT(sw.word SEPARATOR ", ") AS words
FROM ps_product p
LEFT JOIN ps_product_lang pl ON pl.id_product = p.id_product AND pl.id_lang = 1
LEFT JOIN ps_search_index si ON si.id_product = p.id_product
LEFT JOIN ps_search_word sw ON sw.id_word = si.id_word AND sw.id_lang = 1 AND sw.id_shop = 1
GROUP BY p.id_product

You're welcome

--

Eric

Edited March 13, 2015 by erouvier29 (see edit history)

[skinnybloke]

I've just noticed this problem today on one of my sites https://www.luxurygardengazebos.com using v1.6.0.11 - putting 'gazebo' in the search box should return at least 10 products.

 

I recently converted the installation to be multisite which in itself gave me quite a few problems.

 

I have also rebuilt the search index and checked the visibility.

 

Database tables/records look correct as far as I can tell.

 

Tried running erouvier29's query and this shows the products with what looks like the correct search terms.

 

The products that are not displaying for me all exist in the same category

Edited March 13, 2015 by skinnybloke (see edit history)

[erouvier29]

@skinnybloke: Looking at your site, I think that searching 'gazebo' should even return all your products, as it's part of every category name.

Interested in the result of your database investigation.

Cheers

[Pedro Lima]

Hi Eric,

 

First let me thank you once again your kind help.

 

Well, this is very, very, very weird... just look at this! I used your query, which was very helpful indeed and then I did this:

 

TRUNCATE table x_search_index

TRUNCATE table x_search_word

 

So I could be REALLY sure they were EMPTY!

 

Then I re-indexed once again through Prestashop. And this is where the weird part starts... Some products were actually inserted BUT with id_lang = 1 (and in my case, id_lang I am using is 6), others have correct language id.

 

I have manually updated my table x_search_word on column id_lang = 6 and now it works flawless!

So my suggestion: take a look at your x_search_word table and search for id_lang = 1, because if you have more than one language, that might be the problem.

 

Thank you to all you guys who helped me reaching this conclusion.

[skinnybloke]

Cant see anything obviously wrong so I have raised a bug report

 

http://forge.prestashop.com/browse/PSCSX-5028

[selectshop.at]

Perhaps the search engine is not interacting with your theme correctly, from what I can see it is not the default Prestashop search ? Besides that the time for showing any result is too high (most of the cases this problem is due to a bad configured server)

 

Did you tried to switch to default theme ? Do you have the same bad results ?

 

When you go to re-index products, are there some missing products showing ? missing xxx form xxx ? If yes than your server breaks the execution of the script before all your products are re-indexed completely.

 

Did you changed something in the default settings of search engine ? Put here a screen for us to take a look.

[selectshop.at]

Oh yes, themes which are only adapted from PS 1.5. or lower to PS 1.6. could be have a ID-language problem, this means, that they are not multi-language. ID 1 is mainly English. Switch to default theme and check if search is working. Your theme is using an own search script.

Edited March 13, 2015 by selectshop.at (see edit history)

[selectshop.at]

Another problem I'm seeing on your site is the change URL-architecture. You eliminated the ID from category, no it is running several 404 errors. Take a look with Chrome developer tool (F12). Network -> add a search name and open one of the products.

 

The change of the architecture could be indeed a problem for not finding products correctly and showing wrong results.

 

Correct URL achritecture: dev.lentesoculos.pt/4-oculos-graudados/463-oculos-cpp173-d-laranja.... (4 is an example only!!)

YOUR URL architecture: dev.lentesoculos.pt/oculos-graudados/463-oculos-cpp173-d-laranja.... here the ID of category is missing and driving to several errors.

 

You should inspect also the error_logs or your server from time to time !

[skinnybloke]

Good stuff guys. 

 

I remember changing my language from 'English' to 'English GB' which has a lang-id =7 about 3 months ago part way through setting up my site.

 

When I look at my 'ps_search_word' I see the attached for the word 'gazebo'

 

 

 

What do I do to correct this? Change everything to be 7, or delete everything that is not 7?

[selectshop.at]

I suggest you to undo all your core changes, especially the one omitting the category-ID's on URL, switch to default template, test the search engine if it is working without any problems, and than switch to your bought theme. Only by this way you can locate the problem.

 

Omit ID's does not take any SEO effects besides it drives to problems, cause Prestashop needs these ID's for to work.

[selectshop.at]

Good stuff guys. 

 

I remember changing my language from 'English' to 'English GB' which has a lang-id =7 about 3 months ago part way through setting up my site.

 

When I look at my 'ps_search_word' I see the attached for the word 'gazebo'

 

 

 

What do I do to correct this? Change everything to be 7, or delete everything that is not 7?

Please don't make changes directly into Database, if you don't know the exact dependencies. If you change some basic like language ID, you have to change it everywhere on database. (products, search, categories, customers, already added orders, and, and, and). This could be a fatal problem, if you don't know all dependencies Prestashop is writing and it could make your database useless.

Edited March 13, 2015 by selectshop.at (see edit history)

[erouvier29]

I think that changing everything to 7 (as Pedro did to 6) will temporarly solve your issue (search will be correctly complete/completely correct).

Nevertheless, when you will edit/create products afterward, the index may become wrong again.

It seems anyway that there is actually a bug in search indexing relative to multi-language, which you already reported.

[erouvier29]

@selectshop.at: Aren't you shy too much? It's true that PrestaShop has some (one could say a lot) bugs, but it's not rubbish everywhere.

 

Scanning the code (1.6.0.13) shows that ps_search_word and ps_search_index tables are read only by class Search.php. They are also used by classes Language.php, Product.php and module pscleaner.php for deletion purpose.

So we can expect that modifying manually will not lead to a disaster. The worst of it is that you may have to truncate them again and re-index (incorrectly in that case).

 

Well, now you can say that I'm confident too much...

Regards

[Pedro Lima]

I think that changing everything to 7 (as Pedro did to 6) will temporarly solve your issue (search will be correctly complete/completely correct).

Nevertheless, when you will edit/create products afterward, the index may become wrong again.

It seems anyway that there is actually a bug in search indexing relative to multi-language, which you already reported.

 

I don't have multi-language site and what I did notice was that this only happened on "old" products that were on my old Prestashop v1.5.4

 

All new products that we are adding in the last days, are perfect.

[erouvier29]

Not even a bug? Disappointed ;-)

[Pedro Lima]

Not even a bug? Disappointed ;-)

 

Hehehe. Totally get what you mean... so many days losing my mind over Prestashop!

[selectshop.at]

I think that changing everything to 7 (as Pedro did to 6) will temporarly solve your issue (search will be correctly complete/completely correct).

Nevertheless, when you will edit/create products afterward, the index may become wrong again.

It seems anyway that there is actually a bug in search indexing relative to multi-language, which you already reported.

I've investigated this, and cannot confirm that there is a bug on search with multi-languages. I've tried on Shop EN/PT, another EN/DE and a third one with EN/PT/ES. No one shows any problems on search engine. Not for products already added to database before upgrade to PS 1.6.0.13 and also not the one added this days. All search words available and indexed (BTW by adding new products the search engine should refresh automatically). If this not occur, so it is a server problem and you have the possibility to add the words manually on search engine configuration tab.

 

4 years ago I had the same problem with language ID's and I changed 4 to 2 for all on all tables, so I know from what I'm talking about. BTW I migrated my Database from a German Prestashop Fork to original software with original database architecture.

[selectshop.at]

Good stuff guys. 

 

I remember changing my language from 'English' to 'English GB' which has a lang-id =7 about 3 months ago part way through setting up my site.

 

When I look at my 'ps_search_word' I see the attached for the word 'gazebo'

 

 

 

What do I do to correct this? Change everything to be 7, or delete everything that is not 7?

ps_search_word is not the table of search_engine, but the statistic table for the word searched by somebody. In this case the search had ID 346, on Shop ID 1, with ID language 3, and the searched word was gazebo.

 

The table responsible for search index is only ps_search_index. And as you can see there are no words added, but ID's.

 

ps_sekeyword is the table responsible for to register the keywords searched on Search Engine (Google for ex.) and on where the user clicked to the Google Link and got to your page. So it's a statistic table too.

 

ps_search_engine is the table on which all possible search engines are registered. Also for statistic purposes.

[erouvier29]

Hi guys,

 

@selectshop.at: Thank you for your further investigation. Generally speaking, I agree with you, it's somehow dangerous to change directly ids into the database. But in this specific case I'm afraid you're not totally right.

 

ps_engine_search and ps_engine_word are both tables for indexed searching. Search::indexation (starting at Search.php line 476) truncates or partially deletes them (lines 483 to 511), and then repopulates them according to indexation scope (lines 553 to 654). Looks correct.

 

The story of Pedro and skinnybloke is that they first created some products, then changed or added a shop language, and afterward continued to create products. The result is that the products created before language setup are not correctly indexed even in case of full re-index.

 

I just did exactly the same on a 1.6.0.13 install:

 

1/ Shop was created in French with the sample catalog

2/ Add language English

3/ Add language Spanish

 

=> After that, ps_category_lang and ps_product_lang look correct: all initial category and product entries have been duplicated for additional languages (not translated but we cannot ask PrestaShop to do the impossible, can we?).

 

4/ Rebuild the full index

 

=> At that point searching for "robe" (dress) gives 7 results for FR, 6 for EN and 5 only for ES.

 

5/ Edit (change ref.) the product which is missing in both EN and ES

 

=> As auto-indexation is on, re-indexation of that product should occur. And it is the case. Searching for "robe" gives now 7 results for both FR and EN, and 6 for ES.

 

6/ Full re-index again

 

=> Back to status after 4/ i.e. FR 7, EN 6 and ES 5

 

So I really think there is a bug in the indexation. Unfortunately I will not have the time to investigate further right now. Maybe in the coming days, except if someone else do it before...

Edited March 14, 2015 by erouvier29 (see edit history)

[selectshop.at]

There is no bug on indexations, trust me. The problem are more than only changing the ID of the language. Did you see that the screen of skinnybloke is showing several ID languages and ID-Shops ? For me it is clear that:

 

On this shop more than one language is activated. If it is not, so than there are several improper changes on the language ID's. On the screen you can see ID 1,2,3,4,5,6 and 7.

 

The problem of Pedro Lima for me is the changed core omitting the ID's. This drives to several search errors.

[erouvier29]

Sorry to contradict you again but there was a bug: some couples of product attribute / language were not processed during full indexation.

I tried to make a patch and proposed it (https://github.com/PrestaShop/PrestaShop/pull/2651)

Be careful with it, because Search.php base version was neither 1.6.0.13 nor 1.6.0.14

Regards

--

Eric

Edited March 15, 2015 by erouvier29 (see edit history)

[selectshop.at]

Yes, this "bug" applies only to shops with product combinations (not my case).

Product features more important as combinations for example are not indexed. Besides that the search engine of Prestashop is not a full-text search eingine, What it means that only some keywords are index (the one you have added to your URL, to short description and some keywords added as combinations). I've never seen that you can search by size for example unless this is not added explicit to URL-name. Great deficit. 

Prestashop's search engine is not really the golden egg solution.

 

 

AND NO: ps_search_engine is a statistic table and not a table for the indexation process. Check SearchEngine.php, and ps_search_engine table content and you will give me right.

 

The ID's are a central must have, cause it drives to results, if you omit id category on the URL you will have troubles, like Pedro is having (s. screen attached). Check SearchController.php

		$searchResults = Search::find((int)(Tools::getValue('id_lang')), $query, 1, 10, 'position', 'desc', true);
			foreach ($searchResults as &$product)
				$product['product_link'] = $this->context->link->getProductLink($product['id_product'], $product['prewrite'], $product['crewrite']);
			die(Tools::jsonEncode($searchResults));
		}

And Search.php

	$results = $db->executeS('
		SELECT cp.`id_product`
		FROM `'._DB_PREFIX_.'category_product` cp
		'.(Group::isFeatureActive() ? 'INNER JOIN `'._DB_PREFIX_.'category_group` cg ON cp.`id_category` = cg.`id_category`' : '').'
		INNER JOIN `'._DB_PREFIX_.'category` c ON cp.`id_category` = c.`id_category`
		INNER JOIN `'._DB_PREFIX_.'product` p ON cp.`id_product` = p.`id_product`
		'.Shop::addSqlAssociation('product', 'p', false).'
		WHERE c.`active` = 1
		AND product_shop.`active` = 1
		AND product_shop.`visibility` IN ("both", "search")
		AND product_shop.indexed = 1
		'.$sql_groups);

Last but not least and this is another problem: Using short description you have a bad SEO for the whole shop, cause you are distributing all keywords of all products to the whole shop instead to canalize them to the product. This problem is available since I'm using PS 1.3.1.1. Discussion about SEO architecture I had several with Prestashop CEO. With PS 1.5. they changed the architecture a little bit, you can now work with it, and are more flexible for to construct your keywording. But adding short descriptions is still technically worth.

Edited March 15, 2015 by selectshop.at (see edit history)

[erouvier29]

1/ My fault from the beggining about intention of tables: I was talking about "ps_search_index" and "ps_search_word" (cf. initial test query).

 

2/ Fully agree with you when saying that searching should address product attributes and features. But that would not be a simple bug fix...

 

3/ Trusting you about SEO, I'm really not a specialist.

 

Cheers

--

Eric

[skinnybloke]

Hi -

 

 

There is no bug on indexations, trust me. The problem are more than only changing the ID of the language. Did you see that the screen of skinnybloke is showing several ID languages and ID-Shops ? For me it is clear that:

 

On this shop more than one language is activated. If it is not, so than there are several improper changes on the language ID's. On the screen you can see ID 1,2,3,4,5,6 and 7.

 

Just to confirm I have only one language activated.

 

[selectshop.at]

Hi -

 

 

Just to confirm I have only one language activated.

 

For now, but it could be that you had activated languages ID 1,2,3,4,5,6 before and that is the reason why the searchword gazebo was searched on all ID-languages. The table is only a tracking of what was searched, for which shop, and displayed in which language. Perhaps you afterwards changed the languages.

 

ps_search_word is only a statistic table. The only table responsible for to index is ps_search_index.. And there you will not find any word, cause they are written in arrays and not in visible text.

Edited March 15, 2015 by selectshop.at (see edit history)

[skinnybloke]

 

 

For now, but it could be that you had activated languages ID 1,2,3,4,5,6 before and that is the reason why the searchword gazebo was searched on all ID-languages. The table is only a tracking of what was searched, for which shop, and displayed in which language. Perhaps you afterwards changed the languages.

 

Definitely not - only ever had id-1 English(English) which I changed to id-7 English (GB).

[selectshop.at]

Using own theme ? Link to your page ? Databases do not lie, the collect only data and write them.

Edited March 15, 2015 by selectshop.at (see edit history)

[Pedro Lima]

Since I supose this will probably help someone else, here's what I did after noticing that my DB was being updated back to 1 on id_lang inside ps_index_word, I have created a basic PHP file that I can call as a cron each and every day, with this code inside:

// configuration
$dbhost     = "localhost";
$dbname     = "databasename";
$dbuser     = "databaseuser";
$dbpass     = "databasepass";

// database connection
$conn = new PDO("mysql:host=$dbhost;dbname=$dbname",$dbuser,$dbpass);

// query
$sql = "UPDATE ps_search_word
        SET id_lang=6
        WHERE id_lang=1";
$q = $conn->prepare($sql);
$q->execute();

// closing connection
$conn = null;

I know this is not the correct way of doing it, but I don't have the time to try and figure out what's the problem with my code so this is a nice solution for me and I hope it helps someone else.

 

EDIT 1:

I actually just noticed an even bigger problem... there are products that are NOT being added to index AT ALL! :S I try to re-index, I try to add missing and they just never end up there.

And yes, once again, all products are visible on search. Something is definitely not right with Prestashop search...

 

EDIT 2:

Ok, just noticed something very weird... on ps_search_word it seems that system is actually indexing and putting there all words, but for some reason on some products it inserts them with id_lang = 1 (which is not correct because I deactivated lang id 1 and only have one lang activated with id 6). Only on those products, system isn't inserting record inside ps_search_index and that makes it impossible to work on frontend with search... Will keep looking at this for a little more, I think I'm close to some solution.

 

EDIT 3:

 

PROBLEM FOUND!!!

 

It seems index only grabs the id lang 1 products (at least that was my problem). What I did was:

 

1 - Edited a product that was not showing on search;
2 - Changed language to EN instead of my language PT (although it's the ONLY active language);

3 - Deleted produt name in EN;

4 - Saved item;

5 - Went to Preferences > Search and clicked "Add missing products to the index";

6 - Ran my code above (because new item was inserted in DB as id_lang = 1).

 

And that's it... now items are showing... now I will have to check each and every one of my items for this, but at least for me is FINALLY problem solved - although clearly something is wrong with Prestashop and this might be complex for people with multilanguage websites... luckly that's not my case!

Edited March 16, 2015 by Pedro Lima (see edit history)

[erouvier29]

Hi Pedro,

 

Did you try the patch I proposed? It was satisfying on my simple installation in multi-language configuration for both full re-index and single product edition. I cannot swear but I think the worst you may face is to go back to initial Search.php and re-index...

 

Current indexation doesn't take into account if languages are active or not, but process every product/language entry found into the dabase. If some of your products still have EN description, they will appear again when re-indexing even if EN is disabled or deleted (it seems that language deletion empties the related search index, but not the product descriptions). But this is not the issue I corrected.

 

The one I did is that some product/language entries were not processed because of combinations that were not counted before limiting the number of data read from db. Now, it's no more the case, so the new index should be complete after being re-built.

 

Hope it's clear enough, but I'm not sure...

[selectshop.at]

Another problem search index is not complete (although there is showing it is), is due to a low/restricted max_execution_time. Check the value settings on your server. I have a shop with about 10.000 products. The value for max_input_time and max_execution_time I changed to 900 for boths. This is the only way to reindex all products if needed. Also after this change I never had any problems with new products don't added automatically. I had constantly the problem with missing products not added automatically to the search.

 

You can try, if you have root privileges on your server, or your provider allows you to increase the values.

 

My own shop is also only one language. DE ID 4. From what I know ID-language 1 which is English = MASTER. Perhaps on your changes you deleted the master and now you are having these problems (and others I named you).

 

It is fact that it is not good to delete completely English language (I did this on my old PS 1.3. and database had a lot of wholes after on combinations and also on search) and the second sin is to make changes directly into database without knowledge of the dependencies Prestashop is creating.

Edited March 16, 2015 by selectshop.at (see edit history)

[skinnybloke]

Ok - this is what I have tried to solve my problem :

 

1. Truncated both search indexes and rebuild - doesn't work.

2. Updated search code as per this bugfix - https://github.com/PrestaShop/PrestaShop/commit/6ee1c4b607eb8b8b4b6c75ef80161e98ec357d5a - doesn't work

3. Reverted to the default-bootstrap theme - doesn't work

 

What has worked for me is erouvier29's patch - https://github.com/PrestaShop/PrestaShop/pull/2651/files

 

... except that there is a problem that the 'image not available' image is displaying,  and not the product image for the products that previously did not display. the product image displays correctly for the products that previously displayed.

 

What is even more weird is that this is the  'image not available' image for my other site in my multistore set-up, not the one for this site.

 

Go to https://www.luxurygardengazebos.com/ and search on 'gazebo'

[selectshop.at]

On back-office you see the pictures as thumb ? If yes, reindex your pictures. It could be the same problem I mentioned on topic #33. A low max_execution_time set on your server.

Normally the providers set the time to 30 as per default. You should increase the time to 300 if possible.

 

With firebug I have no errors, what for means that pictures are available, but script stopped before execution, so they are stored in a temporary folder.

[skinnybloke]

Hi selectshop.at - my max_execution_time is set to 300

 

Image problem resolved by this https://github.com/PrestaShop/PrestaShop/pull/2649/files

 

Thanks to everyone who took the time to reply to this - especially erouvier29

[lovemyseo]

I am also facing smae issue with multishop new product not displaying properly in search not with reference either

[Cas]

Hi everyone.

 

I also had this problem and tried the suggested patch https://github.com/P...pull/2649/files

 

After a full index, More keywords are found for language_id 7 but since then, search is not working anymore!!

Screen goes blank.

 

Also creating a new index is not working anymore.

 

I am running PS 1.6.14

 

Any suggestions how to solve this situation?

[mareksmareks]

Hi. I tried erouvier29's patch and it now finds missing products, but it doesn`t show products at all. It just tells - "Found xx products"

Check attached picture

 

Edit: forgot to mention, im on 1.6.011, have 3 languages (only 2 are used in front office (latvian and russian), 3rd is english that is kept because not everything is properly translated in our language for backoffice and sometimes I need to switch from latvian to english) that were set up at the creation of shop. Our prestashop version history is 1.4.8->1.4.9->1.6.011

 

Edited June 16, 2015 by mareksmareks (see edit history)

[mareksmareks]

p.s. right now reverted to original search.php (at least it shows majority of products)

[erouvier29]

Hi,

 

There are apparently some issues with the patch Jocel1 and I proposed some time ago. As I told before, the base version of Search.php  was neither 1.6.0.13 nor 1.6.0.14 but already on the way to 1.6.1. That might be the explanation of the empty search page...

 

Here is a Search.php override (simpler to install and especially to uninstall in case of issues) that includes only my changes (index all the products and do not forget some in multi-language context), and not the ones from jocel1 (indexation performance improvements).

 

Hoping it can be usefull for some of you.

 

Regards

 

Search.php

[mareksmareks]

Hi,

 

There are apparently some issues with the patch Jocel1 and I proposed some time ago. As I told before, the base version of Search.php  was neither 1.6.0.13 nor 1.6.0.14 but already on the way to 1.6.1. That might be the explanation of the empty search page...

 

Here is a Search.php override (simpler to install and especially to uninstall in case of issues) that includes only my changes (index all the products and do not forget some in multi-language context), and not the ones from jocel1 (indexation performance improvements).

 

Hoping it can be usefull for some of you.

 

Regards

 

Search.php

Thanks, mate!!!

It looks really good now. Not sure if it worked for all products (cant renember all that didn`t work, but it looks really good. Thanks a lot!!!

[Cas]

Thank you Erouvier for your effort!

 

 

I instlalled your latest update but however I  when performing a full index, only product references from languange 1 are indexed

 

 

Before the update I installed the github version in my 1.6.14 release and run against blank screens.

IN debug mode I noticed an error related to the file override/Search.php

Notification was something about not finding the SearchCore function in the override map.

I renamed the Search.php file in the override map to Search_org.php and everything seams to work since then.

 

So I reverted back to this situation for now and it works again.

I installed a clean, empty Search.php in the override map and seems to work also.

Cache is disabled, should not be a problem but unsure what it could have been.

 

 

Two other problems  found. Not sure if it is a bug but when a product is not related to a category, it won't be indexed either.

 

Also when a full index is performed on One store in a Multistore environment. Complete DB is first wiped and then ONLY an idex is build for the selected multistore. Other stores lost index.

 

rgds,

 

Cas

Edited June 16, 2015 by Cas (see edit history)

[erouvier29]

Hi Cas,

 

Interesting... I mean for a bug tracker, but not for you I guess!

 

To try to understand what happens in your shop, you can execute the following query (from phpMyAdmin or PS SQLManager) after having triggered a full indexation, on both official 1.6.0.14 and patched one (results may be large...)

SELECT ps.id_product, sw.id_shop, pl.id_lang, pl.name,
GROUP_CONCAT(word ORDER BY word)
FROM ps_product_shop ps
JOIN ps_product_lang pl ON pl.id_product = ps.id_product
JOIN ps_search_index si ON si.id_product = ps.id_product
JOIN ps_search_word sw ON sw.id_word = si.id_word AND sw.id_shop = ps.id_shop AND sw.id_lang = pl.id_lang
GROUP BY ps.id_product, sw.id_shop, pl.id_lang

Another thing: it seems there is a bug when indexing in multi-shop context. In order products are indexed for all the shops, you have to select "All shops" in the shop selector, otherwise only the main shop is addressed, whatever the active shop is (to be investigated).

 

Regards

 

[iAreku]

Hi there,

 

I'm coming from this other thread where someone pointed me to check this thread and see if it would help me with this issue im having.

 

Regarding the Search.php file someone just posted above.... is that a Class override I should place on my site? Because I just tried it on my 1.0.9 install with no luck...

Any other clues or solutions?

My current scenario is 2 languages, 1 store. english works fine, spanish wont find any results on the search FO.

[erouvier29]

Hi,

 

Here are the instructions:

1. Upload the file Search.php above in /override/classes if you don't have such a file yet (if you already have one, you will have to merge)
2. Remove the file /cache/class_index.php otherwise the new override will not be taken into account (the class_index.php will be automatically generated again at next access)
3. Reload your BO, go to PREFERENCES > Search, and rebuild the entire index

Hopefully, the spanish search from FO will succeed...

 

Regards

 

[iAreku]

Now this is weird....

 

I did upload and "merged" Search.php on override classes...

Removed class_index.php

Reloaded and rebuild the entire index...

 

Been more than 1h and for 75 products it still shows as 0 products out of 75 added!

 

I even clicked "manually add missing products" and still shows 0 products added.

 

Wth is going on here now!?

[iAreku]

3h later still at 0. Any clues how can I force or manually run the reindex query or something!?

 

Thanks!

[erouvier29]

1 store, 2 languages, 75 products should not require a long except if you have many many attributes.

What  other methods are overridden in your Search.php? Is it possible to have a look to it? 

There have been a lot of database performance improvments in 1.6.1. Did you try on such a release candidate?

 

[iAreku]

Im not using attributes at all.

 

This is my current Search.php override.

 

I havent upgraded to 1.6.1 yet, no.

 

Its on the TO DO list though.

[erouvier29]

Well, some little things differ from 1.6.0.9, 1.6.0.14 and your override...

I would suggest you replace /classes/Search.php by the 1.6.0.14 version and /override/classes/Search.php by my patch.

It should work properly on your 1.6.0.9 database.

Anyway you can have a try and go back to previous situation if it doesn't work...

 

Search_1.6.0.14.php

Search_override.php

[iAreku]

I did use the files you attached here, and if i go to regenerate or manually add the products I get a blank page so I guess an internal server error is being generated now

[erouvier29]

Strange...

Doing the same on a fresh 1.6.0.9 works.

Switch on debug mode (/config/defines.inc.php) to get the error, maybe due to some other overrides you made or modules you installed

Edited July 1, 2015 by erouvier29 (see edit history)

[erouvier29]

@iAreku: FYI, I don't know what's up with your searching issue, but doing something completely different, I just got an error with your previous Search.php override which was still installed: at lines 135 (method find) and 318 (method searchTag), you should replace ml.`name` by m.`name` (manufacturer names are not stored in the language dependent table)

[iAreku]

I will check those too, thanks for reporting back!

[cilecek]

Same problem and found solution.

 

I had 3 languages installed 1,2,3... Languages 1 and 2 were inactive, language 3 was active one i was using.

Not searchable products had filled in ProductName not only for language 3 but also for languages 1 and 2.

 

As a solution I deleted inactive languages and rebuilding search index.

(if you dont want to delete inactive languages, you have to delete each products ProductName for inactive languages)

[selectshop.at]

Indeed this is an old report. Solution is to update your Prestashop version to 1.6.1. (or PS 1.6.0.14). The problem is only on Prestashop 1.6.0.13. All other versions before and after don't have it.

[elPresta]

Well, some little things differ from 1.6.0.9, 1.6.0.14 and your override...

I would suggest you replace /classes/Search.php by the 1.6.0.14 version and /override/classes/Search.php by my patch.

It should work properly on your 1.6.0.9 database.

Anyway you can have a try and go back to previous situation if it doesn't work...

 

Could you share these files? I don`t know why but I can`t download it :/

[erouvier29]

Here it is again: https://www.dropbox.com/s/ma1wwobgxrmsr5j/Search_override_20150630.zip?dl=0

It may not work properly depending on the PS version you are using...

[PromoErik]

Hey Erouvier, just tried your override, when i tried to rebuild the index no products are added  (after a server timeout I just get 0/362) and without it not even half of the products shows up on a search. And I checked my db I have the language issue, PS 1.6.0.14. Any ideas?

Edited March 10, 2016 by PromoErik (see edit history)

[erouvier29]

What language issue do you have?

[PromoErik]

The issue where all of my products are indexed in English but my shop is in Swedish and only a few products are indexed in swedish, and only the few are shown. (like skinnybloke) And as I understod it your override was suppose to create an index where all products are indexed for all languages and therefore showing up?

[erouvier29]

I tested again the patch above as follows:

• install fresh 1.6.0.14, with demo catalog and language FR
• activate multishop and create and additional shop
• add language SE (but do not translate names and descriptions...)
• perform a full re-indexation => fails as some words are not bound to all (shop, language) groups
• install the Search class override
• perform a full re-indexation again => success

So it should work in "normal conditions".

 

I don't exactly remember what happened with skinnybloke, but I think it was a matter of upgrade from PS 1.5.

Is it your case as well?

 

What is the content of table ps_search_word after full re-indexation with and without the override?

(please try to summarize wrt shops and languages ;-)

[PromoErik]

Hey Erouvier,

 

Thanks for pointing me in the right direction. Turns out that my index contained way to few words. I did an override and replaced all functions that had to do with overrides with the ones from this: https://github.com/PrestaShop/PrestaShop/pull/2649 and now it works like a charm! Many thanks again.

 

Not sure if I had the same problem as the first poster but maybe it was both due to products having several languages and faulty indexing functions, anyways the answers were found in this topic!

 

Br.

 

Erik

[logan1ro]

Hello guys,

 

Same problem here, from PS 1.5 to the last one, PS 1.6.1.4. Not all the products show up in search results.

I had 897 products so far, in 26 languages (25 active + 1 inactive).

After months in searching for a solution, I finally find it here.

 

So, what I did:

1. Deleted the inactive language
2. Rebuild entire index
3. Search in front office

Everything works flawless now!

[Christiaan_01]

I had issues with building the search index from scratch.

Found a fix somewhere to add missing products to index, but had to switch between two search.php files all of the time.

 

After a few days products disappear out of the index. I can't do a cronjob since that is only for a complete rebuild.

 

Now I am using the patch from erouvier and can easily build the search index from scratch.

Enabled a cronjob which is working now, so search functionality is 100% in my store.

 

Thanks a lot!