1

I've been playing with the catalogsearch for a while, and I'm almost done, but there is one odd thing happening to me. The only "usable in search" attributes are name, child_skus and synonyme. In child_skus, I'm storing the skus of the associated products of my grouped products, as I'm working with grouped products only on the frontend. synonyme contains a list of coma-separated words which related to the said product.

What I'm using for the fulltext search is the following code :

$query = Mage::getModel('catalogsearch/query')->setQueryText($searchText)->prepare();
$fulltextResource = Mage::getResourceModel('catalogsearch/fulltext')->prepareResult(
            Mage::getModel('catalogsearch/fulltext'), 
            $searchText, 
            $query
        );
$products->getSelect()->joinInner(
            array('search_result' => $products->getTable('catalogsearch/result')),
            $products->getConnection()->quoteInto(
                'search_result.product_id=e.entity_id AND search_result.query_id=?',
                $query->getId()
            ),
            array('relevance' => 'relevance')
        );
$products->getSelect()->order('relevance DESC');  

All works fine for now, except that somehow, it also indexes the associated product's name in the fulltext table, which ends up jamming my search because it yields biased results.

Does anyone have any idea on how to change that behaviour, or control it through admin?

  • Why the downvote? This is a very good question. – Marius Sep 25 '14 at 8:00
3

Take a look at the method Mage_CatalogSearch_Model_Resource_Fulltext::_rebuildStoreIndex. That's the one that actually rebuilds the fultext search index.
Somewhere inside it you will find this:

$productChildren = $this->_getProductChildIds($productData['entity_id'], $productData['type_id']);
$productRelations[$productData['entity_id']] = $productChildren;

and later

if ($productChildren = $productRelations[$productData['entity_id']]) {
   foreach ($productChildren as $productChildId) {
       if (isset($productAttributes[$productChildId])) {
           $productIndex[$productChildId] = $productAttributes[$productChildId];
       }
   }
}

This means that for configurable, grouped and bundle products the child product attributes are indexed also.
You can rewrite the model and remove this parts, or leave it like it is and simply rewrite the method _getProductChildIds in the same class and make it return null so it will be like there are no child products for any other product.
this way the child products will not be indexed in the parent product data.

| improve this answer | |
  • looks brilliant, let me check that ;) – Julien Lachal Sep 25 '14 at 8:11
  • @JulienLachal. I forgot to mention that I didn't test that. Just took my shovel and dug up the code. But it seams like the way to go. – Marius Sep 25 '14 at 8:12
  • it works, but I'm having a hard time overriding the file for some reason, it'll do for now but I'll have to clean this :p thanks for your help. – Julien Lachal Sep 25 '14 at 8:55
1

You can already set the synonyms in the back-office with "search term" in the catalog menu. To do that the search term as to have been already used in front-office and then you can redirect to the product, category or cms page you like. For products, you can set visibility accordingly to what you want to display in search results so you don't really need to bother about the child_skus.

I would suggest you to install elasticsearch or solr with an appropriate module to really improve search results. Moreover, you can really manage better with fuzzy queries, wild cards and so on.

| improve this answer | |
  • synonyme isn't quite like search terms, and it's easier to manage for my clients than having to set each individual search terms. Visibility didn't quite make it in terms of associated product sku's, so I had to find another trick. I really don't want to bother with another module, my site already has plenty. – Julien Lachal Sep 25 '14 at 8:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.