PrestaShop-Suchindexierung und unscharfe Suche
Verstehen Sie native PrestaShop-Suche, die gemeinsame Such-API, FULLTEXT-Anforderungen, unscharfe Suche und Relevanztests.
Richten Sie das Suchverhalten an den Begriffen aus, die Ihre Kunden tatsächlich verwenden. Prüfen Sie Indexierung, Sprachregeln und Ergebnissichtbarkeit, bevor Sie unscharfe Treffer oder Relevanz abstimmen.
So würden wir vorgehen
Wir würden echte Suchanfragen ohne Treffer und fehlende exakte Artikelreferenzen untersuchen, bevor wir die Suche ersetzen. Das Vorgehen hängt von Ihren Modulen, dem Theme, Integrationen, Katalogdaten, Märkten, Sprachen und dem betreuenden Team ab. Ermitteln Sie, was Suchvorschläge und Ergebnisse abgesendeter Anfragen liefert: Dahinter können unterschiedliche Suchsysteme stehen.
Reparieren Sie zuerst die native Suche, wenn sie den fehlerhaften Ablauf bedient. Proben Sie Konfigurations-, Modul- oder Indexänderungen auf einer Staging-Kopie mit repräsentativen Daten. Vereinbaren Sie erwartete Ergebnisse, bewahren Sie die bisherige Konfiguration auf und planen Sie die Umstellung mit einer benannten Person, die sie zurücknehmen kann.
| Ihre Beobachtung | Erstes Vorgehen | Aufzubewahrender Nachweis |
|---|---|---|
| Importierte Produkte fehlen in nativen Suchergebnissen. | Prüfen Sie die Voraussetzungen für die Anzeige und die Pflege des nativen Index. | Dieselbe Anfrage und das erwartete Produkt vor und nach der Korrektur. |
| Exakte Begriffe funktionieren, Kundenformulierungen oder Tippfehler jedoch nicht. | Prüfen Sie zuerst native Aliasse und gegebenenfalls Einstellungen für unscharfe Suche in Ihrer installierten Version. Bleibt eine Funktionslücke, prüfen Sie Smart Search Revolution für Synonyme, Tippfehlerbehandlung oder weitere Ergebnistypen. | Relevante Treffer in Ihren Sprachen und Ihrem Theme ohne unerwünschte Erweiterung. |
| Ergebnisse sind langsam oder Vorschläge weichen von der Ergebnisseite ab. | Verfolgen Sie beide Suchwege, bevor Sie Erweiterungen ergänzen. | Verantwortliches Modul, Abfrage und Laufzeit für jeden Suchweg. |
| Individuelle Katalog- oder Zugriffsregeln fehlen. | Planen Sie die Integrationsarbeit anhand dieser Regeln. | Erlaubte und verbotene Ergebnisse für jede betroffene Zielgruppe. |
Wenn Sie die Möglichkeiten an Ihrem Shop testen lassen möchten, vergleicht das PrestaShop Module Selection & Fit Assessment verschiedene Ansätze anhand der vereinbarten Anforderungen.
Native und gemeinsame Suche verstehen
Die native PrestaShop-Suche verwendet indexierte Wörter und konfigurierbare Feldgewichte. Produktnamen sind neben Referenzen, Beschreibungen, Kategorien, Herstellern und Attributen eine Eingangsgröße. Erstellen Sie den nativen Index neu oder reparieren Sie ihn, wenn diese Datensätze veraltet sind.
Das gemeinsame Paket myprestarocks/prestashop-search bietet eine separate Abfrage- und Bewertungs-API. Seine Produktsuchlogik liest Katalogtabellen, kombiniert SQL-Bedingungen und kann Wörter durch Sprachregeln und unscharfe Kandidaten erweitern. Ein Modul muss die Suchlogik aufrufen und Ergebnisse darstellen; das Hinzufügen der Abhängigkeit ersetzt nicht den Suchcontroller des Shops.
Ein nach dem Import fehlendes Produkt untersuchen
Angenommen, eine importierte Duschwanne lässt sich aus ihrer Kategorie öffnen, ihre Artikelreferenz liefert aber keinen Suchtreffer. Bestätigen Sie, dass importierte Referenz, Übersetzung, Shopzuordnung und Suchsichtbarkeit korrekt sind, und ermitteln Sie dann das fehlerhafte Suchsystem. Vergleichen Sie bei der nativen Suche dieselbe Anfrage vor und nach der Indexreparatur. Prüfen Sie beim gemeinsamen Suchsystem die Katalogabfrage; ein Neuaufbau des nativen Index aktualisiert dessen Wörterbuch für unscharfe Suche nicht.
Testen Sie anschließend 900 x 900 und ein falsch geschriebenes Produktwort getrennt. Erscheint nach der Tippfehlererweiterung eine unpassende Größe, ist der Relevanztest fehlgeschlagen, auch wenn die Trefferzahl steigt. Behalten Sie beim Anpassen der Rechtschreibregeln die Testfälle für Artikelreferenzen und Maße bei.
Entwicklerreferenz: Produktsuche mit explizitem Kontext aufrufen
Dokumentieren Sie die installierte Paketversion zusammen mit diesen Integrationshinweisen und prüfen Sie ihre API und Standardwerte. Diese Referenz beschreibt das gemeinsame Paket, nicht die nativen Einstellungen oder sämtliche Suchmodule.
Führen Sie die Suchlogik innerhalb von PrestaShop aus, damit Datenbank, Konstanten und Katalogtabellen verfügbar sind. Übergeben Sie für sprachspezifische Erweiterungen neben der numerischen Sprach-ID auch den Sprachcode.
use MyPrestaRocks\Search\SearchEngine;
$engine = new SearchEngine($idLang, $idShop, [
'language' => 'en',
'fuzzy_enabled' => true,
'variants_enabled' => true,
]);
$result = $engine->searchProducts('shower tray 900', [
'limit' => 20,
'offset' => 0,
]);
$products = $result['products'];
$total = $result['total'];Das Ergebnis enthält products, total und query. Zeilen enthalten IDs, Namen und Relevanzwerte; sie sind keine vollständige Produktdarstellung für ein Theme. Die Produktabfrage beschränkt Ergebnisse auf aktive Produkte, die dem ausgewählten Shop- und Übersetzungskontext zugeordnet sind.
Setzen Sie ein angemessenes positives Limit. Wenden Sie die zusätzlichen Kundengruppen-, Sichtbarkeits- und Katalogregeln Ihres Frontoffice sowohl in der Ergebnis- als auch in der Zählabfrage vor der Seiteneinteilung an. Werden nur die abgerufenen Zeilen gefiltert, können unvollständige Seiten und irreführende Gesamtzahlen entstehen. Entwickleroptionen wie extra_where, extra_join und extra_select sind SQL-Fragmente. Erstellen Sie sie in vertrauenswürdigem Anwendungscode, niemals direkt aus Anfrageeingaben.
FULLTEXT korrekt vorbereiten
Die Standardsuchlogik sucht nach einem Index namens ft_mpr_search auf der mit Präfix versehenen Tabelle product_lang. Ihre Textabfrage verwendet MATCH(pl.name, pl.description_short). Der Index muss ein kompatibler FULLTEXT-Index über diese Spalten sein.
Die grundlegende Prüfung kontrolliert den konfigurierten Indexnamen. Ein gleichnamiger normaler Index oder eine inkompatible Spaltenliste genügt nicht für gültiges SQL. Validieren Sie Indextyp und Spalten bei Modulinstallation oder Wartung.
Die Produktabfragelogik erstellt diesen Index nicht für Sie. Nutzen Sie einen Installer oder eine geplante Datenbankmigration. Sichern Sie zuerst und berücksichtigen Sie Zeitbedarf und Sperren bei großen Tabellen. Ein korrekt benannter kompatibler Index aktiviert FULLTEXT-Textbedingungen; ohne Index werden stattdessen LIKE-Bedingungen genutzt. Kennungs- und andere Feldbedingungen können weiterhin andere Abgleichswege verwenden.
Datenbankgrenzen für Wortlängen, Stoppwortkonfiguration und Kollation können das FULLTEXT-Verhalten verändern. Prüfen Sie die MySQL-Einschränkungen für FULLTEXT für Ihren Server. Eine geänderte Indexeinstellung kann den Neuaufbau des Index erfordern. Versprechen Sie nicht, dass LIKE und FULLTEXT identische Ergebnisse oder identischen Ressourcenbedarf haben.
Phrasen, Varianten und Stoppwörter verwenden
Der Tokenizer trennt gewöhnliche Wörter, Phrasen in Anführungszeichen, Ausschlüsse und Begriffe, die Maßangaben ähneln. Testen Sie Abfragen wie shower tray, "shower tray", tray -black und 900 x 900 getrennt. Die Phrasenbehandlung sucht eine zusammenhängende Textfolge im durchsuchten Feld; sie interpretiert keine Satzbedeutung.
WordVariants enthält Regelsätze für Englisch, Polnisch, Deutsch, Französisch, Spanisch und Italienisch. Es handelt sich um Suffix- und Schreibweisentransformationen. Sie sind weder eine vollständige linguistische Analyse noch ein Übersetzungsdienst oder ein universelles Synonymwörterbuch.
StopWords verwendet die Liste der ausgewählten Sprache. Würde die Filterung alle Wörter entfernen, bleiben die ursprünglichen Wörter erhalten. Setzen Sie ohne unterstützte Sprachauswahl keine passende Sprachliste voraus.
Grenzen unscharfer Suche verstehen
Der unscharfe Abgleich vergleicht Suchwörter mit einem Kandidatenwörterbuch. Er kombiniert Editierabstand und Vertauschungen benachbarter Zeichen mit Anpassungen für gemeinsame Präfixe, Phonetik und Konsonantenreihenfolge. Er überspringt exakte Treffer und Wörter unter seiner Mindestlänge und liefert dann eine begrenzte Kandidatenzahl.
Das Standardmaximum beträgt fünf Kandidaten. Der erlaubte modifizierte Abstand beträgt eins für Wörter bis fünf Byte und zwei für längere Wörter. Diese Regeln verwenden an mehreren Stellen byteorientierte Zeichenfolgenoperationen; testen Sie daher akzentuierte und nicht lateinische Abfragen, statt sprachneutrale Tippfehlerkorrektur vorauszusetzen.
Die Wörterbuchabdeckung ist entscheidend. Fehlende, abgeschnittene oder veraltete Kandidatenwörter lassen sich nicht durch höheres Relevanzgewicht wiederherstellen. Auch eine ähnliche Schreibweise bestätigt nicht die Absicht des Kunden. Halten Sie Modellnummern und Maße präzise und testen Sie, ob Erweiterungen unerwünschte Produkte einführen.
Andere Entitäten durchsuchen und Relevanz prüfen
EntitySearch bietet Kategorie-, Hersteller-, Lieferanten- und CMS-Suchen mit entitätsspezifischen Feldern. Erstellen Sie beispielsweise new EntitySearch($idLang, $idShop, $engine) mit der konfigurierten Produktsuchlogik und rufen Sie dann searchCategories('shower', 5) auf. Verwenden Sie zurückgegebene Entitäts-IDs und Metadaten mit dem richtigen Link-Builder.
Durch die Übergabe der konfigurierten Suchlogik werden deren Tokenizer, Sprachvarianten, unscharfer Abgleich und Wörterbuch gemeinsam genutzt. Ohne sie beginnt EntitySearch mit einem leeren Wörterbuch für unscharfen Abgleich. Produkt-FULLTEXT-Einstellungen liefern nicht automatisch Indizes oder identische Bewertung für jede Entität. Berücksichtigen Sie Sichtbarkeits- und Sprachanforderungen jeder Entität in ihrer Integration.
Vereinbaren Sie vor der Abstimmung Abnahmekriterien: zwingend auffindbare Artikelreferenzen und Maße, verbotene Ergebnisse, erwartete Reihenfolge und ein Antwortzeitbudget unter realistischer Last.
- Erstellen Sie einen Testsatz aus echten Begriffen, Referenzen, umgestellten Wörtern, Phrasen, Ausschlüssen, Tippfehlern und Maßen.
- Beziehen Sie aktive und inaktive Produkte, Produkte außerhalb des gewählten Shops und Kundengruppenbeschränkungen ein.
- Prüfen Sie Vorhandensein und Position des gewünschten Produkts, nicht nur das Vorliegen irgendeines Ergebnisses.
- Wiederholen Sie mit und ohne gültigen FULLTEXT-Index und mit jeder unterstützten Shop-Sprache.
- Messen Sie Abfragezeiten mit realistischer Kataloggröße und gleichzeitigen Anfragen.
- Testen Sie nach Importen sowohl das gemeinsame Suchsystem als auch die Pflege nativer Indizes, die Ihr Frontoffice weiterhin nutzt. Legen Sie im Importablauf die Verantwortung für die Aktualisierung von Index und Wörterbuch fest.
Bewahren Sie Begriffe ohne Ergebnisse und unerwartete Treffer als Regressionsliste auf. Stimmen Sie Feldgewichte und Erweiterung erst ab, wenn diese Beispiele den Änderungsbedarf zeigen.
Fragen an Ihren Entwickler oder Ihre Agentur
- Welche Modul- und Paketversionen bedienen jeden Suchweg, und welchen Index oder welches Wörterbuch verwenden sie?
- Wo liegen die Staging-Ergebnisse zu Relevanz, Berechtigungen, Gesamtzahlen und Geschwindigkeit?
- Wer überwacht erfolglose Suchanfragen nach der Umstellung, und was löst die Wiederherstellung der bisherigen Einrichtung aus?
Häufige Fragen von Shopbetreibern
Müssen wir Produktnamen an Kundenformulierungen anpassen?
Vergleichen Sie Kundenbegriffe zunächst mit Ihren Namen, Übersetzungen und Artikelreferenzen. Eine unterstützte Synonymregel kann alternative Formulierungen verbinden, ohne den offiziellen Produktnamen zu ändern; bestätigen Sie, welcher Suchweg sie nutzt.
Garantiert eine bessere Suche mehr Bestellungen?
Nein. Erfassen Sie erfolglose Suchanfragen, Produktbesuche und abgeschlossene Käufe, soweit Ihr Berichtssystem dies unterstützt. Vergleichen Sie Ergebnisse unter Berücksichtigung von Änderungen bei Traffic, Beständen und Aktionen.
Kann dieselbe Suche private Bestellinformationen einbeziehen?
Ja, wenn das gewählte Modul eine authentifizierte, kundenspezifische Bestellsuche unterstützt. Eine individuelle Integration muss vor der Ausgabe von Bestelldaten Authentifizierung und Eigentümerprüfung ergänzen. Die Produkt- oder CMS-Suche allein gewährt diesen Zugriff nicht.