FIX Magento Search Please!

[gfxguru]

The more I think about the unwillingness to repair a major flaw in Magento the more I think about migrating to another platform. I've worked with so many ecommerce platforms that have zero problems with one of the most important storefront features "SEARCH". I've also watch so many customers search a site and leave the site because a search never presented the actually product the customer was looking for but the store possessed.... That is called a flaw!
Now I understand it's quite an undertaking, but putting it off or relying of someone else to provide such capabilities is not the solution either. I say we fix the issue and make it a top priority. NOW before 2.0 is released.
This is a major issue with magento and if you haven't noticed it yet then you haven't run a store... Period

[ghost]

100% on target - should be top priority.

[JosephMaxwell]

I agree that the search is very poor at best. We have been using Google SiteSearch, which has been an acceptable alternative, although we do not have the control that we would like. I think most of that can be overcome with more code. It would be very nice to have a free solution to this basic problem.

+1 for this being top priority. Please give the best shopping cart out there the best search.

[kuafucode]

I think solr and the php solr extension should be introduced to magento
core and disabled by default, so people who don't need it do not have to
worry about setting up additional search server.

On Thu, Jul 24, 2014 at 9:55 AM, Joseph Maxwell notifications@github.com
wrote:

I agree that the search is very poor at best. We have been using Google
SiteSearch, which has been an acceptable alternative, although we do not
have the control that we would like. I think most of that can be overcome
with more code. It would be very nice to have a free solution to this basic
problem.

+1 for this being top priority. Please give the best shopping cart out
there the best search.

—
Reply to this email directly or view it on GitHub
#622 (comment).

[choukalos]

For Magento 2.0 we're planning on modularizing search and making it easier to customize. For search improvement it's already a high priority ( with a lot of items I'm pushing for ) but there's still debate on when and how those improvements will release. Please keep commenting and specifically state what you want as highest search priority. That'll help us refine prioritization and how we could release in light of other priorities.

So far I see ( 1 for better search results; 1 for more search control ); please get others to comment/weigh in and provide specifics on their top search item to address.

@ryansun currently we're planning on mysql search for CE and SOLR for EE; with hooks for the community to easily support other search engines like sphinx, etc.

@gfxguru when you say more accurate search results do you have something in mind specifically ( based on my research/understanding it's 2 things - weighting control & search reports to identify search terms with no results; i.e. identify the case you're describing with weighting control to address/fix ).

Thanks!
Chuck ( I own the Search domain for Magento / Product Management; Any suggestions/ideas to improve please feel free to ping me directly )

[gfxguru]

Why does search work so well on the backend but terrible on the frontend? I don't get it?

[gfxguru]

Does enterprise suffer from such capabilities? no.. neither does prestashop, shopkart, woocommerce, bvcommerce, bigcommerce, shopify or volusion... ok, some better than other true but magento's inability to fetch even something similar to the users search, one must get strategic in creating products.
I could talk all day about functionality and capabilities, I think if we just get the better results would be the key. Lets get that right and then an addon's that posses the reporting and weighted results could be an awesome extension I would think.

[gfxguru]

Ok i was a bit harsh, I apologize..To explain, I've been with Magento since it's infancy and this has been my arch nemesis in more way's then I care to explain.

[CodeMonkey90]

@choukalos IMO the top priority (apart from making the default search return reasonable results, which is kind of obvious) should be making both the search process (e.g. weighting of product attributes, filtering out certain products) and the search result page (visual representation, e.g. grouping results by product type/category/etc) as easy to customize as possible. There is no one-size-fits-all solution, so ideally developers should be able to customize Magento's search module without having to rewrite it completely.

[kbariotis]

+1 for making this a top priority and for a more customisable and extensible search module.

[choukalos]

@Landkeks - in our upcoming December ( platform beta ) release we'll introduce search modularity to Magento 2 that should address the communities desire to customize all aspects of search (which I've gotten lots of feedback on this need).

Unfortunately I haven't gotten as much feedback on technical suggestions to fix the search algorithm ( mysql/default out of the box). Lots of suggestions on configurations/merchandizing features. Are there any agreed upon technical suggestions on how to improve search accuracy? I have a few but not necessarily correlate. We'd appreciate any suggestions you or the community have to improve the algorithm.

Thanks!

[barbazul]

@choukalos From a technical view,

• Change "OR" for "AND" when concateating "Like" conditions because more search tearms should mean more accurate (meaning: less) results
• Configurable query modes, as suggested on the original thread: Better Search Please!! NOW #198 (comment)

[barbazul]

Also less technical, more functional requests:

• Automatic Suggested Terms: Search terms should not be automatically added as suggested search terms. There should be some kind of logic to define when should a S.T be suggested (EG: more than 100 searches, more than 50 results) or should be handled by an admin. The default of sending every term used to the list, leads to bad searches being reused over and over
• More terms should bring less results (explained): If some one searches for a single word term, it should bring more results than someone searching for two, and it is not working like that right now. If currently search for "A" and you get 5 results, then you search for "B" and you get 4 results, when you search for "A B" you will get 9 results, while it should only show the results in both searches separated.
• Configurable Stopwords: Stopwords should be configurable. This would be very handy for other languages (other than English), and for specific industries.
• Automatic Search synonyms: When no results are shown, it would be very usefull to obtain suggestions that are "similar" but do have some results.
• Search Terms Configuration Scope: When you configure a Search Term, you are currently forced to do it within a Website Scope. For sites with many websites and big catalogs (shared in different websites) it would be useful to configure search terms (synonyms and redirects) globally.

[kilianyp]

Just another suggestion - the way how synonyms work:
Right now, when I add a synonym for a search term, magento finds only results, when the customer searches exactly for the term I set an synonymy up. It would be much more useful if every occurrence of that word would be replaced even in search terms with additional words.

This would obviously need more work from the shop administrator but would definitely lead to better results, as you could use it to smooth out common spelling mistakes as well.

[barbazul]

@choukalos did you have a chance to look at my technical suggestions? What
do you think of them?
I think they're small enough they can be thrown in regardless of other
bigger search improvements.
El 26/09/2014 21:07, "kilsen512" notifications@github.com escribió:

Just another suggestion - the way how synonyms work:
Right now, when I add a synonym for a search term, magento finds only
results, when the customer searches exactly for the term I set an synomy
up. It would be much more useful if every occurence of that word would be
replaced even in search terms with additional words.

—
Reply to this email directly or view it on GitHub
#622 (comment).

[rtull]

+1 for global word-based synonyms, AND matching, and stopwords.

[choukalos]

@barbazul Thanks for the insights! Stopwords I believe require a mysql compile to change or a SOLR config not sure we can wrap a Gui around that - I'll check with our architects.

[barbazul]

Way back I remember using a tool called PHPDig which was a PHP based
crawler and search. It did fulltext search but based on its own algorithm
instead of mysql native fulltext.

I recon its probably very outdated and underperformant but it supported
multi language stopwords.

Since Magento supports multilanguage natively it makes sense it should
support multilanguage search.

It shouldn't be to difficult to preprocess the query based on a dictionary
regardless of mysql compiled language.

Also, most hosting providers have mysql compiled in english regardless of
the target audience so we should work around that limitation
El 30/09/2014 11:31, "Charles Choukalos" notifications@github.com
escribió:

@barbazul https://github.com/barbazul Thanks for the insights!
Stopwords I believe require a mysql compile to change or a SOLR config not
sure we can wrap a Gui around that - I'll check with our architects.

—
Reply to this email directly or view it on GitHub
#622 (comment).

[choukalos]

@barbazul - thanks for the insights on the PHPDig library ( http://www.phpdig.net/navigation.php?action=demo ); looks like the code hasn't been updated since late 2005. I'll ask our search architect to look into it and how we might further change our search indexer/search algorithm to be more accurate.

[mattisbusycom]

I have built an ElasticSearch indexer for a client site; It works amazing and I am currently creating the module (learning how to build Magento modules); but I am very experienced with ElasticSearch in general.

[alankent]

We would be very interested to hear how successful you are swapping out the default search engine. Have we go the APIs right to make it easy to drop in a different engine? Feedback and suggested changes appreciated. (We don't have much documentation done where the interfaces are, and this is relatively low priority to other documentation. If you are unsure from looking at code, feel free to ask questions.)

[choukalos]

Search features currently slated for inclusion in 2.0

• enhanced mysql search accuracy ( many points per comments above )
• APIs for search indexers
• [Enterprise] Support for SOLR 4.x

Search Epics likely in 2.1 - 2.3 release time frame

• MAGETWO-23112 : Search Autocomplete & Preview
• MAGETWO-11439 : Search CMS
• MAGETWO-10479 : Updated Search UX and Control
• MAGETWO-10478 : Manage relative weightings of search terms
• MAGETWO-10475 : [ EE ] Synonyms & Stop words GUI
• MAGETWO-10480 : [ EE ] Search - Promoted Products

[choukalos]

Sorry my bad; shouldn't have closed the issue.

[aoldoni]

For Enterprise, I would recommend probably to change the roadmap to move straight into Solr 5.3.0?
http://www.apache.org/dyn/closer.lua/lucene/solr/5.3.0

[choukalos]

@aoldoni we've decided to move to elastic search instead for enterprise. You'll see that happen in the Magento 2.1 release. Elastic search provides more functionality as a stack component than Solr does and gives us the potential to build out the platform on several interesting fronts.

[aoldoni]

@choukalos - Given the roadmap above, would you please be able to detail in which version (e.g.: 2.1, 2.2, etc..) these 2 tickets are planned to be released into?

MAGETWO-23112 : Search Autocomplete & Preview
MAGETWO-11439 : Search CMS

Thanks!

[choukalos]

Hi @aoldoni we're an agile company so we're constantly revising our roadmap and epics based on customer feedback and how we can maximize the value we deliver in each release as such there's no commitment to a specific release. All I can say is search is one of our higher priority items and likely to get some attention in 2016.

[southerncomputer]

https://github.com/Smile-SA/elasticsuite/tree/feature_magento-2.1-upgrade

https://github.com/Smile-SA/elasticsuite

Smile SA has always produced quality open-source Elasticsearch for magento1 and magento2 now along with their virtual categories and integrated search feedback system.

[choukalos]

@southerncomputer yes Smile's got some great Elasticsearch extensions for Magento. Really happy to see they've started porting their M1 extension to M2.

[s00071609]

I am not sure if this is off topic - i did not want to open a new thread. I am using magento 2.1 (upgraded from 2.0 to 2.1) recently. Just realised that the search term shows blank. Havent touched the default footer links and appear fine. But when the search term is clicked, no text - its blank.
Can check - https://jostechecig.com.au
Not sure if its a new bug, i also have a magento 2.0, search term shows all the search terms.

Is anyone having this issue? Any suggestions?

[Ctucker9233]

@s00071609 I had an issue after upgrading from 2.0.7 to 2.1.0 where the search bar was missing. I'm not sure if that's what you mean. I ended up deleting the vendor folder entirely and transferred in a clean 2.1.0 vender folder to replace it. It fixed the issue.

[s00071609]

No not the search bar. Looks like one issue ends and another pops up with magento. Somewhere something is always going wrong.

My html Head section is also missing. After upgrade the exisiting bundle products dont have bundle option. But the frontend works fine.

[piotrekkaminski]

Thank you for your submission.

We recently made some changes to the way we process GitHub submissions to more quickly identify and respond to core code issues.

Feature Requests and Improvements should now be submitted to the new Magento 2 Feature Requests and Improvements forum (see details here).

We are closing this GitHub ticket and have moved your request to the new forum.

[VladimirZaets]

Hi @gfxguru. Thank you for your report.
The issue has been fixed in #25556 by @engcom-Golf in 2.3-develop branch
Related commit(s):

• f22905662aeda6a0f2c073d650326dd6c2a6fd93
• a07627c9b0c8dcb600cc1109a65c5a08ab375a71
• 8e39f49b48692f2e820066815244e8532c247fde
• 3be5ac8e2e83415b8cafc340486b298038ed0421
• 76a866ec70987dfb0e1c778db472a06c6d738781
• 26dca1007e2458e29419ae5ecf7b77e0c1560658

The fix will be available with the upcoming 2.3.5 release.