Die Magento-Suche mit Apache Solr würzen

E-Commerce goes Enterprise
Kommentare

Ein modernes E-Commerce-System kommt heutzutage nicht mehr an einer flexiblen und leistungsfähigen aber dennoch performanten Suche vorbei. Hier stößt man schnell an die Grenzen, die PHP oder auch Magento On-Board mitliefern. Aus diesem Grund wurde das Modul „Enterprise_Search“ entwickelt, das die Integration eines Solr-Servers ermöglicht. Der dadurch erreichte Performance- und Featuregewinn kann sich direkt auf die Conversion-Rate auswirken und ist ein wichtiger Erfolgsfaktor für jeden Shop.

Magento hat sich in kürzester Zeit zu einer der verbreitetsten E-Commerce-Lösungen entwickelt. Dabei waren nicht nur die Übernahme durch eBay und der damit über die Webgemeinde rollende, kommerzielle Marketingzug ein Grund für den Erfolg. Denn auch bei Entwicklern ist das System dank der sehr guten Erweiterungsmöglichkeiten beliebt. So kann eigentlich jeder Controller, Block, Model oder Helper über rewrites erweitert oder sogar über einen Event ohne statische Beziehung zu bestimmten Klassen angepasst werden. Dass das komplette System auf dem verbreiteten Setup von MySQL und PHP aufbaut, senkt die Einstiegshürde und erlaubt, wenn nötig, auch mal einen tiefen Blick unter die Haube. Ein weiterer Pluspunkt ist das Zend Framework 1, auf dem das System basiert. Es besitzt bekannterweise einen guten Ruf und ist weit verbreitet.

Um das Modul für die Integration von Apache Solr in Magento zu nutzen, ist zwingend die Enterprise-Version notwendig. Im Gegensatz zur kostenlosen Magento-Community-Version bietet sie einige Module und Support von Magento selbst, um wirklich umfangreiche und stark frequentierte Shops einfacher und schneller zu entwickeln. Es bietet unter anderem auch ein erweitertes ACL, Content Staging, Kundensegmentierung, CMS+ mit Versionskontrolle, Full Page Caching, RMA-Funktionalität, persistente Warenkörbe und die für uns in diesem Artikel interessante Solr-Suche. Ein durchschnittliches Magento-Enterprise-System wird in der Regel dann eingesetzt, wenn man für seinen Shop mehr als 50 000 Besucher/Monat oder über 500 Bestellungen/Monat erwartet. Die Installation beider Systeme und Weiterentwicklungen unterscheiden sich dagegen nicht.

Setup von Magento

Nach dem Download der aktuellen Enterprise-Version entpackt man sie in ein beliebiges Verzeichnis im Document Root, sodass die index.php danach über den Webserver aufgerufen werden kann. Durch das Öffnen dieser Seite im Browser wird der begleitende Setup-Assistent von Magento aufgerufen. Im ersten Schritt, „License Agreement“, müssen die Lizenzbedingungen akzeptiert werden, der darauf folgende Klick auf CONTINUE führt zu einer Ansicht, auf der man die „Localization“ für seinen Shop einrichten kann. Nach diesen ersten Grundeinstellungen landet man im Tab „Configuration“ und kann die Verbindung zur Datenbank einrichten (Abb. 1).

Abb. 1: Tab „Configuration“ im Setup-Assistenten für Magento

Aktuell wird von Magento standardmäßig nur MySQL als Datenbanktyp angeboten, und es muss bereits zuvor manuell im MySQL-Server eine leere Datenbank angelegt werden. Aus Sicherheitsgründen empfiehlt es sich natürlich, einen eigenen Datenbankuser anzulegen, der nur Zugriff auf diese eine Datenbank besitzt. Muss die Datenbank mit anderen Systemen geteilt werden, ist es möglich, um Namenskonflikte zu vermeiden, ein Tabellenpräfix anzugeben, der dann automatisch vor jede Tabelle gesetzt wird. So kann man auch mehrere Magento-Systeme in einer einzigen Datenbank betreiben.

Der Base URL wird automatisch erkannt und muss nur angepasst werden, wenn er anders lauten soll, als der aktuell aufgerufene URL. Zu Testzwecken nicht notwendig – aber für ein Produktivsystem empfohlen, um es den Scriptkiddies nicht allzu einfach zu machen – ist die Anpassung des Admin Path, über den später die Administrationsoberfläche aufgerufen werden kann. Nachdem die Eingaben mit Klick auf CONTINUE bestätigt und vom Setup-Assistenten geprüft wurden, wird die vollständige Datenbankstruktur automatisch angelegt. Dieser Schritt kann einen Moment dauern, da bereits das Standarddatenbanklayout von Magento in der aktuellen Enterprise-Version 1.12.0.1 aus 422 Tabellen besteht. Besonders das Entity Attribute Value Model bietet zwar sehr viel Flexibilität und ist sehr umfangreich bei der Definition von Attributen zu Entitäten, wirkt aber beim ersten Blick auf die Datenbank durchaus komplex.

Im nächsten Schritt, „Create Admin Account“, werden Vor- und Nachname des Admins benötigt, um sie später in diversen Masken sauber formatiert auszugeben. Zur automatischen Benachrichtigung wird die E-Mail-Adresse abgefragt und man kann den Benutzernamen und das Passwort des Administratorkontos frei wählen. Danach ist der Shop bereits mit dem Standard-Enterprise-Theme aufgesetzt und unter dem vorhin festgelegten Base URL aufrufbar. Sollte es doch einmal zu Problemen kommen, findet man die Magento-eigenen Log-Dateien unterhalb des Document Root in /var/log/.

Quelle Aufmacherbild: concentrated serious girl carefully viewed with magnifying glass in a piggy bank via Shutterstock / Urheberrecht: Vladimir Gjorgiev

[ header = Suche ]

Suche

Um nicht im Leeren suchen zu müssen und die ersten Suchergebnisse zu finden, werden wir zunächst die gewünschten Produkte im Shop anlegen müssen. Nach dem Login in der Administrationsoberfläche (Standard-URL: http://localhost/admin) kann dies über den Menüpunkt CATALOG | MANAGE PRODUCTS erledigt werden. Neben der Tatsache, dass alle mit einem Stern markierten Pflichtfelder ausgefüllt werden müssen, ist es erforderlich, dass das Produkt aktiviert (Status: „Enabled“) und beim Eintrag „Visibility“ auf „Catalog, Search“ oder auch nur „Search“ gesetzt wird, da es sonst zwar aufgerufen, aber nicht über die Suche gefunden, werden kann. Das ist z. B. für Produkte interessant, die der Kunde zwar kaufen kann, aber in Kombination mit anderen Produkten eben kein Suchergebnis erzeugen sollen. Last but not least bietet Magento eine integrierte Lagerverwaltung, die direkt nach der Installation aktiviert ist. Um unser Produkt dennoch zu finden, obwohl es in keinem Lager verfügbar ist, muss im Tab „Inventory“ das Feld „Manage Stock“ auf „No“ stehen. Das Drop-down hierzu ist standardmäßig deaktiviert, da die Checkbox „Use Config Settings“ aktiviert ist. Dies führt dazu, dass die Einstellung aus der Default-Konfiguration des Shops übernommen wird. Also: Checkbox „Use Config Settings“ deaktivieren und danach im Drop-down „Manage Stock“ „No“ auswählen.

Nach dem Speichern des Produkts kann es nun direkt im Frontend gefunden werden. Um das zu überprüfen, wird im Sucheingabefeld ein Teil des Produktnamens eingegeben und die Anfrage abgeschickt. Wenn der Browser den Ladevorgang beendet hat, erscheint das Produkt in einer bereits gestylten Ansicht und kann prinzipiell schon in den Warenkorb gelegt werden. So weit, so gut. Allerdings läuft diese Suche nun direkt über die bekannte PHP/MySQL-Kombination und stößt beim Thema Reaktionszeit, Funktionalität und auch bei größeren Datenmengen sehr schnell an ihre Grenzen.

Apache Solr

Apache Solr [1] hat sich durch die große Open-Source-Community zu einer sehr guten Alternative zu kommerziellen Produkten im Enterprise-Search-Sektor entwickelt. Das System basiert auf dem Projekt „Apache Lucene“ [2] und bietet u. a. eine sehr schnelle Volltextsuche mit der Möglichkeit zur zusätzlichen Filterung durch Facetten und das Hervorheben von Suchwörtern. Daneben gibt es noch eine Reihe weiterer Features wie das Clustering und das Einfügen von Rich-Dokumenten wie Word oder PDF. Sehr interessant ist zudem die Möglichkeit einer Geo-Suche, um z. B. in einem bestimmten Umkreis auf einem Koordinatensystem nach Ergebnissen zu suchen.

Hilfreich für uns und mit vielen Lösungen zu häufigen Anforderungen, die über das Standard-Setup hinausgehen, ist das „Apache Solr 3.1 Cookbook“ von Rafal Kuc bei Packt Publishing.

Tomcat

Apache Solr ist in Java entwickelt worden. Um es also auf der üblichen XAMPP-Umgebung nutzen zu können, installieren wir einen Tomcat-Server [3]. Die Installation wird hier an Hand eines Windows-Betriebssystems erklärt. Der Server ist allerdings für verschiedene Betriebssysteme verfügbar, die Installation unterscheidet sich dabei kaum. Die aktuelle Version 7.0.32 kann als binäres Paket oder auch im Quellcode heruntergeladen werden [4]. Der Einfachheit halber entscheiden wir uns für die binäre Variante des Windows Service Installers [5], das dort genannte „Core“-Paket ist dabei ausreichend. Nach dem Start der ausführbaren Datei öffnet sich ein übliches Windows-Installationsfenster. Die Portkonfiguration belassen wir bei der Standardvorgabe (Abb. 2).

Abb. 2: Portkonfiguration über den Tomcat-Installer

Nach der Portkonfiguration muss der Pfad zur Java Runtime angegeben werden. Sollte sie noch nicht installiert sein, kann man sie sich jederzeit auf der Java-Website [6] besorgen.

Im folgenden Schritt setzen wir den Installationspfad auf c:tomcat. Sollte hier ein anderer Pfad ausgewählt werden, muss daran gedacht werden, dass mögliche Pfadangaben in den folgenden Konfigurationsbeispielen anzupassen sind. Nach der Installation entscheiden wir uns dafür, den Server von Apache Tomcat direkt aus dem Erfolgs-Screen heraus zu starten.

Der URL http://localhost:8080/ sollte nun über einen Browser aufrufbar sein und die Tomcat-Startseite anzeigen. Um auch für Zeichen außerhalb des ASCII-Bereichs gerüstet zu sein, muss die Serverkonfiguration unter confserver.xml erweitert werden (Listing 1)

  
    
      ...
    
  

[ header = Servlet ]

Servlet

Als nächsten Schritt besorgen wir uns nun Solr selbst. Hierzu gibt es zahlreiche Mirrors auf der Apache-Seite [7], von denen wir uns die Version 3.6.1 herunterladen können. Die komprimierte Datei wird in ein temporäres Verzeichnis entpackt und der Inhalt von examplesolr nach c:websolr kopiert. Auch hier kann prinzipiell ein anderes Verzeichnis gewählt werden, die folgenden Konfigurationsbeispiele müssen dann ebenfalls angepasst werden. Hier werden später die Solr-Konfigurationsdateien und -daten gespeichert – und es ist unser Home-Verzeichnis von Solr.

Der Tomcat-Server muss nun heruntergefahren werden, sodass Solr eingerichtet werden kann. Dazu wird die Datei /dist/apache-solr-3.6.1.war aus dem entpackten Verzeichnis nach c:tomcatwebapps kopiert und in solr.war umbenannt. .war steht für „Web Archive“ und beinhaltet die Servlets von Solr selbst.

Nun wird dem Tomcat-Server beigebracht, wo sich das Solr Web Archive befindet, das wir bereits entpackt und verschoben haben. Dies kann im Servlet-Container „Catalina“ getan werden, der automatisch mit dem Tomcat-Server zusammen installiert wurde. Es muss eine XML-Datei angelegt und unter c:tomcatconfCatalinalocalhostsolr.xml gespeichert werden. Der root-Knoten der XML-Datei ist ein Context-Fragment [8] und muss im Attribut auf die vorhin kopierte solr.war-Datei zeigen. Zudem wird über das Attribut debug= „0“ die Debug-Ausgabe deaktiviert. Tomcat verhindert standardmäßig, dass verschiedene Webapplikationen untereinander kommunizieren, was allerdings mit dem Attribut crossContext= „true“ für Solr aktiviert werden sollte. Damit das alles Wirkung zeigt, müssen wir Solr mitteilen, wo sich sein von uns angelegtes Home-Verzeichnis befindet. Dies kann über ein Environment-Element innerhalb des Context-Knoten realisiert werden. Im Attribut name wird der Name der Umgebungsvariablen auf solr/home gesetzt, der type ist ein java.lang.String und der value lautet in unserem Fall c:websolrexamplesolr. Um sicherzustellen, dass dieser Wert auch definitiv genutzt und, falls vorhanden, überschrieben wird, setzen wir noch das override-Attribut auf „true“. Der Inhalt der Datei sieht also folgendermaßen aus:


  

Der Tomcat-Server kann nun wieder gestartet werden und danach sollte man unter http://localhost:8080/solr/admin die Solr-Administrationsseite sehen (Abb. 3).

Abb. 3: Solr Administrationsseite nach der Installation

Wenn es wider Erwarten doch einmal Probleme gibt, bietet Tomcat eine Fülle an Log-Dateien an, um detaillierte Informationen zu den Problemen zu bekommen. Sie befinden sich im Tomcat-Installationsordner im Unterverzeichnis logs und werden täglich rotiert. Alle Fehler werden in der Datei logstomcat7-stderr.YYYYMM-DD.log protokolliert.

Verbindung

Nachdem nun sowohl die Standard-Magento-Suche als auch die Solr-Instanz laufen, ist das nächste Ziel, beide zu verheiraten und sie miteinander kommunizieren zu lassen. Um das Leben einfacher zu machen, liefert Magento Enterprise bereits eine fertige Konfiguration für einen Solr-Core mit. Sie befindet sich in der Magento-Installation in dem Unterverzeichnis /lib/Apache/Solr/conf/. Die Dateien werden in das Solr-Home-Verzeichnis (c:websolrconf) kopiert. Nach dem Kopiervorgang muss der Tomcat-Server wiederum neu gestartet werden.

Wenn Solr nun die Konfiguration für Magento bekannt ist, muss Magento noch entsprechend konfiguriert werden, um statt wie bisher MySQL unseren eigenen Suchserver zu nutzen. In der Administrationsoberfläche kann dies unter dem Menüpunkt SYSTEM | CONFIGURATION | CATALOG | CATALOG | CATALOG SEARCH getan werden. Im Eingabefeld „Search Engine“ ist hier „MySql Fulltext“ vorausgewählt, durch die Änderung auf Solr ändert sich die Eingabemaske und erlaubt uns eine detaillierte Konfiguration zum Server. Neben Hostname und Port können hier auch der Solr-Username, -Passwort und -Serverpfad eingestellt werden. Für das erste Setup muss allerdings nur der Port auf 8080 geändert werden, alle anderen Einstellungen sind in Ordnung und können so beibehalten werden. Die Verbindung kann nun direkt in der Maske, noch vor dem Speichern, durch Klick auf TEST CONNECTION geprüft werden.

[ header = Web Service ]

Neben der Konfiguration der Verbindung selbst gibt es bei der Nutzung von Solr auch die Möglichkeit, Suchvorschläge zu nutzen. Das genaue Verhalten – ob aktiviert, wie viele Vorschläge angezeigt werden und ob deren Trefferanzahl direkt ausgegeben werden soll – kann hier definiert werden (Abb. 4).

Abb. 4: Solr-Konfiguration innerhalb der Magento-Administrationsoberfläche

Zwar funktioniert nun die Verbindung zwischen Solr und Magento, allerdings werden bei einer Suche nach Produkten im Shop-Frontend keine Suchergebnisse mehr angezeigt. Das liegt daran, dass der eingerichtete Solr-Index noch nicht mit Daten befüllt wurde. Der aktuelle Inhalt des Index lässt sich jederzeit über den LukeRequestHandler [9] einsehen und ist über den URL http://localhost:8080/solr/admin/luke aufzurufen.

Das Befüllen des Indexes kann in der Magento-Administrationsoberfläche manuell über den Menüpunkt SYSTEM | INDEX MANAGEMENT ausgelöst werden. Hier erhält man eine Übersicht aller Indexe, die innerhalb der Magento-Instanz konfiguriert sind. Relevant für die Suche und damit Solr ist der Index mit dem Namen „Catalog Search Index“. Nach dem manuellen Auslösen der Indexierung über den Link „Reindex Data“, sieht man via luke die Änderungen im Inhalt des Index. Auch hier ist die bereits genannte Log-Datei von Tomcat ein sehr guter Anlaufpunkt, wenn es doch einmal zu Problemen kommt.

Mehr ist nicht notwendig, um die Ergebnisse direkt im Frontend angezeigt zu bekommen. Auch die Suggest-Suche liefert from the Scratch als AJAX-Integration Vorschläge, wenn man mindestens zwei Zeichen in das Suchfeld eingegeben hat.

Web Service

Magento überträgt die Daten über die POST-Methode im JSON-Format an den Solr-Web Service und ruft sie im selben Format via GET ab. Der Magento-spezifische Quellcode befindet sich im Modul „Enterprise_Search“, das komplett im Magento-Installationsverzeichnis unter /app/code/core/Enterprise/Search/ gespeichert ist. Das Enterprise_Search-Modul kommuniziert aber nicht direkt mit dem Solr Web Service, sondern baut seinerseits auf die Apache_Solr Library [10] auf, die innerhalb von Magento im Verzeichnis /lib/Apache/Solr/ zu finden ist.

Queries

Um selbst mit einzelnen Solr-Queries zu experimentieren, genügt ein gewöhnlicher Browser, da der Web Service auch auf GET-Anfragen reagiert und standardmäßig XML-Ergebnisse zurückliefert. Eine relativ simple Abfrage würde folgendermaßen aussehen: http://localhost:8080/solr/select/?q=foobar. Über den weiteren Parameter wt kann das Rückgabeformat bestimmt werden, ein möglicher Wert neben „xml“ wäre hier „json“. Für eine bessere Lesbarkeit ist auch der Parameter indent=on hilfreich, der dafür sorgt, dass die Ausgabe in einer menschenlesbaren Form eingerückt wird.

Werden nicht alle im Index befindlichen Daten benötigt, können die Übersicht verbessert und auch das Übertragungsvolumen verringert werden, indem im Parameter fl mit Komma separiert die zurückzuliefernden Felder angegeben werden.

Das Ergebnis besteht dabei immer aus dem response-Wurzelelement, innerhalb dessen es zwei Kindelemente gibt. Das erste Kindelement lst, mit dem Attribut name und dem Attributwert responseHeader, enthält neben den bei der Anfrage übermittelten Parameter die Ausführungszeit dieser Abfrage im Kindelement mit dem Attribut name=“QTime“ und den Statuscode, der im Erfolgsfall 0 zurück liefert. Die Statuscodes sind nicht weiter dokumentiert, können aber im Solr-Quellcode oder in Tabelle 1 gefunden werden.

Tabelle 1: Statuscodes der Solr-Response aus SolrException

Die Response auf die Anfrage, die nach dem Wort „foobar“ sucht und nur die Felder attr_name_en und attr_description_en zurückliefern soll, sollte also, sofern ein Produkt mit dem Namen vorhanden ist, wie folgt aussehen: http://localhost:8080/solr/select/?q=foobar&indent=on&fl=attr_name_en,at…. Das Ergebnis wird in Listing 2 gezeigt.


  
    0
    119
    
      attr_name_en,attr_description_en
      on
      foobar
    
  
  
    
      description to my foobar product
      foobar product
    
  

[ header = Funktionalität erweitern ]

Funktionalität erweitern

Leider werden in der aktuellen Enterprise-Version, im Gegensatz zum sonstigen Magento-Code, in diesem Modul keine Events ausgelöst. Um nicht in rewrite-Konflikte zu geraten wenn mehrere Parteien an der Erweiterung der Suchfunktionalität arbeiten, hat es sich bewährt, zunächst ein Modul zu entwickeln, das die entsprechend benötigten Klassen über einen rewrite erweitert und dort die benötigten Events auslöst. Darauf aufbauend kann dann ohne größeres Konfliktpotenzial an die nun vorhandenen Events angeknüpft werden.

Multi-Core

Es ist ebenfalls möglich, mehrere Cores innerhalb eines Solr-Servers zu betreiben. Dies kann mehrere Gründe haben: so kann es sinnvoll sein, neben den Produkten weitere Daten wie z. B. Kategorien, Hersteller oder Produktreihen zu indizieren und separat auszuwerten. Die Integration dieser Cores in Magento muss allerdings manuell über eine Erweiterung des Enterprise_Search-Moduls erfolgen und hätte leider den Umfang eines eigenen Artikels. Ein weiterer wichtiger Einsatzzweck kann aber die Integration mehrerer eigenständiger Magento-Instanzen in einem Solr-Server sein, wenn entweder mehrere Magento-Instanzen auf demselben Server parallel laufen oder aber der dedizierte Solr-Server geteilt werden soll.

Um das zu bewerkstelligen, muss die solr.xml im Solr-Home-Verzeichnis erweitert werden. Wenn hier Arbeiten vorgenommen werden, sollte zuerst der Tomcat-Server heruntergefahren werden. Die solr.xml besteht am Anfang aus einem solr-Wurzelknoten und enthält einen Container mit dem Namen cores. Im Standard-Setup ist hier lediglich ein einziger Core collection1 mit dem aktuellen Arbeitsverzeichnis als Instanzverzeichnis definiert. Obwohl wir diesen Namen zuvor in der Magento-Administrationsoberfläche nicht definiert hatten, wurde er genutzt, da im core-Elternelement im Attribut defaultCoreName des Standard-Core definiert ist.

Prinzipiell ist es möglich, für beide Cores dieselbe Konfigurations- aber verschiedene Datenverzeichnisse zu verwenden. Es ist aber zu empfehlen, dies sauber zu trennen, da ggf. unabhängig voneinander die Konfigurationen der einzelnen Cores angepasst oder erweitert werden sollen. Damit wir nun eine klare Struktur in das System bringen, empfiehlt es sich, im Solr-Home-Verzeichnis ein Unterverzeichnis /cores/ anzulegen. Zum Test werden dort die zwei weiteren Unterverzeichnisse /shopfoo/ und /shopbar/ angelegt, die unsere zwei getrennten Cores darstellen. In beide muss das /conf/-Verzeichnis auf dem Solr-Home-Verzeichnis kopiert und ein zweites Verzeichnis namens /data/ angelegt werden. Um dieses Verzeichnis zu konfigurieren, gibt es zwei Möglichkeiten. Die erste Variante wäre das entsprechende XML-Element dataDir in shopfoo/conf/solrconfig.xml und auch in shopbar zu ändern. Das Setzen dieser Konfiguration ist aber auch von außerhalb über die zentrale Datei solr.xml möglich. Statt das Element also in der solrconfig.xml anzupassen, wird es dort auskommentiert und als Kindelement des jeweiligen core-Elements in solr.xml definiert. Zudem wird hier auch das jeweilige Instanzverzeichnis der zwei Cores festgelegt. Die Datei sollte danach dem Beispiel in Listing 3 entsprechen.


  
    
      
    
    
      
    
  
 

In der Magento-Administrationsoberfläche muss nun wieder im Bereich SYSTEM | CONFIGURATION | CATALOG | CATALOG | CATALOG SEARCH der Solr Server Path angepasst werden. Hier geben wir nun solr/shopfoo, bzw. solr/shopbar für die zweite Instanz, an. Der Tomcat-Server kann wieder gestartet werden. Zu guter Letzt muss die Befüllung des Index erneut ausgelöst werden, da sich die Position des /data/-Verzeichnisses geändert hat und somit keine Daten mehr vorhanden sind.

Alternativen

Wenn man sich dafür entscheiden sollte, die Community- statt der Enterprise-Version von Magento einzusetzen, wird die Integration von Solr leider nicht On-board mitgeliefert. Hierfür kann man im Netz diverse freie und kostenpflichtige Module von Drittanbietern finden, die ein ähnliches Leistungsspektrum bieten [11], [12], [13]. Als weitere Möglichkeit bleibt einem natürlich auch die Herausforderung, die Anbindung selbst zu integrieren und optimal an die eigenen Bedürfnisse anzupassen, da die Apache_Solr Library [10] unter der „New BSD Licence“ zur Verfügung steht. Sollte man schon Erfahrung in der Entwicklung von Magento gesammelt haben, ist das Aufsetzen eines neuen Moduls schnell geschehen.

Fazit

Die Einrichtung dieses Setups ist trotz der vielen notwendigen Einzelschritte recht einfach und führt direkt zu einer schnellen und funktionalen Lösung, die, wenn man zunächst keine weiteren Anforderungen hat, direkt eingesetzt werden kann.

Auch darüber hinaus ist es durch die gute Erweiterbarkeit von Magento möglich, diese Funktionalität entsprechend seinen Bedürfnissen anzupassen. So kann man über die Entwicklung von Modulen auch Kategorien oder andere Daten in den Index legen, eine Autokorrektur integrieren oder die Filtermöglichkeiten erweitern und somit noch bessere Suchergebnisse erhalten. Der Fantasie sind hier keine Grenzen gesetzt.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -