Fournir une recherche à l'échelle du site pour l'édition communautaire

Au fil des ans, il y a eu de nombreuses tentatives pour améliorer les fonctionnalités de recherche de Magento. (Solr, Lucene, etc.) En 2013, existe-t-il un moyen préféré / dominant de fournir une recherche de catalogue dans Magento qui est disponible pour l'édition communautaire ? Qu'en est-il d'une recherche à l'échelle du site - quelque chose qui recherche des pages de contenu?

Est-ce que les gens s'en tiennent à la recherche immédiate ou y a-t-il quelque chose de mieux?

Je travaille beaucoup avec Solr et j'ai créé une extension pour cela ici http://solrgento.com . Vous pouvez rechercher des attributs et des pages CMS. J'ai eu la même idée qu'Ivan et j'ai implémenté toute la vue catalogue sur Solr. C'est vraiment très rapide ;-)

Ma recommandation personnelle -

http://php4u.co.uk/blast-search-lucene-magento-extension/

Utilisé des solutions de sphinx dans le passé, mais elles semblaient nécessiter une attention constante en tout temps.

L'utilisation de Sphinx est assez bonne de nos jours. Tout d'abord, il est directement connecté à mysql. Il crée un index basé sur la requête mysql que vous avez spécifiée pour la configuration de sphinx.

Nous mettons actuellement en œuvre une solution pour un client avec 2 millions de SKU et sphinx montrant d'excellents résultats. Nous prévoyons également de remplacer entièrement la version FLAT de Magento par Sphinx, dans ce cas, toutes les pages de la catégorie Magento seront très rapides.

Pour le moment, nous n'avons vu aucune bonne implémentation de Sphinx sur le marché qui répondrait à nos besoins et ne répéterait pas la logique de l'implémentation de Magento Solr qui a le plus gros goulot d'étranglement en utilisant la requête "entity_id IN (?)" À Magento DB .

J'ai également appris de nouveaux services qui fournissent des solutions de recherche SAAS axées sur les sites Web de commerce électronique. Ils ont de très bons outils pour organiser la navigation de recherche, les modifications de classement et même la possibilité d'ajuster les résultats de la recherche pour la vente incitative.

Un de ces services est Fredhopper. Cependant, ce n'est pas un logiciel Open Source.

jettes un coup d'oeil à http://www.magentocommerce.com/magento-connect/searchanise-connector-add-on-2652.html

son sphinx était basé et était principalement gratuit jusqu'au troisième trimestre 2013

j'ai testé https://code.google.com/p/magento-community-edition-solr/ mais cette recherche dans les attributs

Nous utilisons la recherche sphinx ultime par mirasvit, une excellente intégration de sphinx au magasin magento.

Pour l'édition communautaire, je vous conseillerais d'essayer notre module OpenSource ElasticSuite:

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

Il possède des fonctionnalités très avancées même non disponibles dans Magento 2.1 EE (catégories virtuelles, tri des produits, meilleur facettage, ...).

Nous avons commencé des modules supplémentaires pour l'indexation de contenu supplémentaire comme celui-ci https://github.com/Smile-SA/module-elasticsuite-cms-search)indexer les pages CMS et les ajouter à la saisie semi-automatique (il s'agit toujours d'un POC mais fonctionne déjà ).

N'hésitez pas à l'essayer et à contribuer.

c'est une nouvelle option que je vérifie, une solution intéressante pour magento, utilisant elasticsearch - basée sur lucene - http://www.bubblecode.net/en/2012/06/24/magento-enhance-your-search-results- avec-elasticsearch /

Elasticsearch - sa configuration est plus facile (en magnitude par rapport à solr) - sa construction pour scailing (la réponse de solr à ceci est solrcloud) pas sûr de sphinx, la dernière fois que j'ai vérifié qu'il n'était pas évolutif avec une configuration compliquée (mais une connexion directe à mysql comme mentionné) ici pourrait être intéressant)

Mes expériences récentes avec Solr + Magento pourraient avoir un petit aperçu.

Tout d'abord, il y a les problèmes:

• Bibliothèques PHP fragmentées - Laquelle dois-je utiliser? Combien de lignes de code vais-je devoir corriger dans une bibliothèque non entretenue?
• Des choses supplémentaires à apprendre - je n'avais aucune expérience avec Tomcat avant de sauter dans ce bateau. Ce sera vraiment amusant.
• Très peu de documentation destinée à un développeur expérimenté dans un environnement inconnu. Soyez prêt à apprendre toute cette terminologie Java amusante pour pouvoir lire un guide de configuration.
• Il y a beaucoup d'efforts pour le bricoleur

Dans mon cas, je veux aller avec Solr car il fait ce que je veux. Bien sûr, certains de ces fournisseurs de recherche tiers le feront aussi, mais si je voulais l'utiliser, je serais le gars qui se contente d'un site Web à 200 $. Je n'essaierais certainement pas de repousser les limites de Magento CE.

La recherche prête à l'emploi ne sera tout simplement pas une bonne solution pour moi. J'ai des clients qui vont se fier à la recherche en magasin et les chances de mal orthographier les noms sont très élevées. Cela suffit à lui seul pour vouloir m'éloigner des méthodes de Magento.

Je pense, comme d'autres l'ont également clairement indiqué, que descendre la route de Solr n'est pas une mince affaire. Mis à part les écrous et les boulons de Solr lui-même, vous devrez également vous soucier des implications de l'infrastructure (quelque chose qui m'amène à envisager de tout déplacer vers la colocalisation).

Jusqu'à présent, cependant, ce sera une expérience très enrichissante. J'imagine qu'il faudra encore quelques années avant d'avoir des réponses à tant de questions que j'ai, et d'ici là, nous examinerons la prochaine mode qui s'exécutera probablement dans node.js ou quelque chose et il sera temps de migrer encore une fois.