Shop 5.34.0 Release Notes
5.34.0
Neue Suchmaschinen-Architektur
Mit dieser Version wurde die Architektur der Suche komplett erneuert und im Suchergebnis auch Landingpages und Filter aufgenommen. Die neue Architektur erlaubt völlig flexible Filter in Suchergebnissen und Kategorien, die sich aus den Produktmerkmalen generieren - im Gegensatz zu den im Layout fest hinterlegten Filtern für Marken, Farben, Größen, Bewertungen und dem Preis (bzw. weiteren Shop-spezifisch festgelegten Kategorien), die bisher benutzt wurden. Damit die neue Suchmaschinen-Architektur verwendet werden kann, muss der neue Parameter searchengine auf den Wert default gesetzt werden. Ist der Parameter searchengine leer oder nicht gesetzt, wird die bisherige Architektur weiterhin verwendet.
Findologic Suchmaschine mit Filtern
Auf Basis der neuen Suchmaschinen-Architektur wurde die Option der Suche mit dem Shop-Suchanbieter Findologic integriert. Um die Findologic Suche anstelle der internen Suchmaschine zu verwenden, muss der Parameter searchengine auf den Wert findologic gesetzt werden. Um die Suche an den produktiven oder den Test-Index bei Findologic zu koppeln, muss der neue Parameter Findologic.ShopKey auf den API Key aus dem Findologic Backend gesetzt werden. Findologic ist ein kostenpflichtiges Cloud-Service, das sich auf Suche innerhalb von eCommerce Anwendungen spezialisiert hat. Die Nutzung von Findologic ist immer optional und kann anstelle der internen oder anderer Shop Suchmaschinen verwendet werden.
Shop im Docker Container
Für den Shop ist nun auch eine Konfiguration für den Betrieb in Container Umgebungen (Windows basiert) möglich. Aktuell bietet diese Konfiguration aber noch keine Möglichkeit zur Skalierung bzw. für die Aufteilung von Diensten in weitere Container - diese Restrukturierung ist Teil der Roadmap für 2024.
CMS Modul: Produkt Info
Das neue Modul erlaubt das Einfügen eines Kastens mit Produktbild, Name, Teasertext, etc. inklusive eines Action-Buttons zum Hinzufügen des Produkts in den Warenkorb in eine CMS Seite.
CMS Modul 1:1:1:1 Teilung
Für den schnellen Aufbau von CMS Seiten gibt es das neue Modul 1:1:1:1 Teilung, mit dem die Seite auf Desktop und Tablet in vier Viertel geteilt werden kann. Auf Smartphones werden diese Spalten einfach untereinander gestellt.
CMS Modul: Google Data Layer Purchase
Nach Aktivierung durch setzen des Parameters pages.google auf true kann in die Bestätigungsseite nach einer Bestellung dieses normalerweise unsichtbare CMS Modul eingefügt werden, dass den aktuellen Kauf an den Google Data Layer zur Weiterverarbeitung durch andere Tools meldet. Für das Setzen einer Meldung auf die Bestätigungsseite muss die Zone CHECKOUT.CONFIRM mit Inhalten gefüllt werden.
CMS Modul: Google Data Layer Detail
Nach Aktivierung durch setzen des Parameters pages.google auf true kann in Produktseiten dieses normalerweise unsichtbare CMS Modul eingefügt werden, dass die Anzeige eines Produkts an den Google Data Layer zur Weiterverarbeitung durch andere Tools meldet. Für das Setzen des Moduls in die Artikelseite muss die Zone PRODUCT.SIDE mit Inhalten gefüllt werden.
Neuer Parameter: HideFilter
Der neue Parameter hidefilter legt fest, ob dynamische Filter im Suchergebnis bzw. in Kategorien angezeigt werden sollen. Der Parameter legt nicht nur die Anzeige der Filter, sondern auch die Berechnung der Filter fest und ist damit entscheidend für die Serverlast während der Suche.
B-Ware verkaufen
Produkte können nun auch als B-Ware gekennzeichnet werden, worauf der Kunde beim Abschließen der Bestellung getrennt hingewiesen werden. Die Kennzeichnung kann über das Admin Backend vorgenommen werden.
Kategorieabhängige Templates
Bisher haben alle Kategorien das gleiche Template für die Darstellung der Kategorien als HTML verwendet. In der Kategorie kann nun ein alternatives Template für die Darstellung gesetzt werden. Beispielsweise können damit die Kategorien, die Blätter im Kategorienbaum darstellen, primär Artikellisten darstellen. Kategorien der Zwischenebene werden mit einem alternativen Template dargestellt, dass nur redaktionell gepflegte Empfehlungen oder Text-Content zur Erklärung der weiteren Unterkategorien darstellt. Das Template kann im Admin Backend in den Eigenschaften der Kategorie gesetzt werden.
Vorschaubilder aus Detailbildern
Thumbnails in Produktgallerien und in Such- und Kategoriedarstellungen wurden bisher aus den Vorschaubildern von Produkten berechnet, die in der Vergangheit oft viel kleiner als die Produktbilder waren. Da die Anzeige von verkleinerten Vorschaubildern auf hochauflösenden Bildschirmen inzwischen auch eine erhöhte Qualität benötigt, werden die Thumbnails nun aus den Detailbildern erstellt.
Workflow: BMECat Import verbessert
Die Workflow Aktion zum Einlesen von BMECat Dateien wurde erweitert und importiert nun Artikel auch dann, wenn MIME-Informationen zu Produktbildern unvollständig enthalten sind. Sind im BMECat Bilder als externer URL definiert, wurden diese Bilder bereits bisher automatisch heruntergeladen. Serverfehler beim Herunterladen (z.B. 404) haben aber bisher den Import des BMECats abgebrochen. Nun wird das Produkt ohne Bild importiert.
Workflow Aktion: CryptCleartextPasswords
Die neue Workflow Aktion dient für die Migration von alten Shop Installationen mit unverschlüsselten Kennworten in die Verschlüsselungsart, die für den aktuellen Shop konfiguriert ist. Nachdem ein Workflow mit dieser Aktion einmal abgearbeitet hat, sind die Kennworte neu verschlüsselt und der Workflow kann gelöscht werden. Sollte die Aktion trotzdem nochmals laufen, würden die bereits verschlüsselten Kennworte erkannt und nicht nochmals verschlüsselt werden.
Workflow Aktion: Produktbilder importieren
Die Workflow Aktion Produktbilder importieren kann als Dateiname nun einen Suchparameter wie z.B. *.jpg konfiguriert bekommen. Ist das der Fall verarbeitet die Aktion nicht nur ein einzelnes Bild, sondern alle unter diesem Suchparameter gefundenen Artikelbilder in einem Durchlauf.
Workflow Aktion: Datenbank reorganisieren
Die Workflow Aktion Datenbank reorganisieren säubert die Shop-Datenbank von alten Sessions, nicht bestellten Warenkörben, etc. und reduziert damit die Datenbank-Größe bzw. erhöht die Geschwindigkeit des Gesamtsystems. Es empfielt sich, einen Reorganisations-Workflow mit u.a. dieser Aktion zumindest einmal im Monat im Shop zu planen.
Kriterien für Kennworte können festgelegt werden
Bisher hatte die Registrierung fest implementierte Tests für die benötigte Komplexität eines Kundenkennworts. Mit diesem Release kann die Komplexität selbst festgelegt werden. Der neue Parameter PWMinCharCount legt fest, wieviele Zeichen ein Kundenkennwort mindestens haben muss. Prinzipiell kann ein Kundenkennwort in den meisten Verschlüsselungsarten beliebig lang sein. Der Parameter PWNeedsLowerChar kann auf true oder false gesetzt werden und legt fest, ob mindestens ein Kleinbuchstabe im Kennwort enthalten sein muss. Der Parameter PWNeedsUpperChar kann auf true oder false gesetzt werden und legt fest, ob mindestens ein Großbuchstabe im Kennwort enthalten sein muss. Der Parameter PWNeedsSpecialChar kann auf true oder false gesetzt werden und legt fest, ob mindestens ein Sonderzeichen (wie z.B. !$%&#?) im Kennwort enthalten sein muss. Der Parameter PWNeedsNumberChar kann auf true oder false gesetzt werden und legt fest, ob mindestens eine Ziffer im Kennwort enthalten sein muss. Der Parameter PWMinQuality legt eine Kennwort-Qualität fest, die durch ein externes Service ermittelt wird und auf heuristischen Methoden beruht. Die Kennwortqualität wird mit einem Rating von 0 bis 4 ausgedrückt. Bisher wurde die Qualität 3 verlangt. Soll dieses Service nicht mehr verwendet werden, kann das verlangte Rating auf 0 gesetzt werden.
Kundenpreise mit unterschiedlichen Gültigkeitszeiträume
Bisher wurde pro Kundengruppe/pro Artikel nur ein Preis gespeichert, der zwar ein Gültigkeitsdatum enthalten konnte, allerdings konnte die Shop Datenbank nicht zwei verschiedene Kundenpreise mit unterschiedlichen Gültigkeitszeiträumen speichern. Nun können Kundenpreise für einen Kunden/Kundengruppe auch mehrfach mit unterschiedlichen Startdatum gespeichert werden, um eine automatische Umschaltung der Preise mit Stichtag vorbereiten zu können.
Admin Backend: Kennworte mit SAH256 Verschlüsselung
Wird im Admin Backend bei einem Kunden das Kennwort neu gesetzt, wird das Kennwort zusätzlich zur eingestellten Verschlüsselungstechnik auch als SAH256 Hash gespeichert. Dies garantiert eine zusätzliche Möglichkeit zur Anmeldung, auch wenn die Verschlüsselung des Kennworts geändert wird.
Admin Backend: Suche in Auswahllisten für Kundengruppenx
Bei der Auswahl von Kundengruppen sind die dargestellten Gruppen nun alphabetisch gelistet und sind durch ein Suchfeld ergänzt, das eine schnelle Auswahl der richtigen Kundengruppe erlaubt.
API: REST Endpunkte mit Kostenstellen auf Positionsebene
Die REST APIs wurden um zusätzliche Felder für Kostenstellen auf Positionsebene ergänzt. Die App hat damit die Möglichkeit Kostenstellen auf Ebene der Positionen zu erlauben.
Performance: Produktmerkmale
Durch Caching der Produktmerkmale innerhalb der Stammdaten, können Produktmerkmale nun auch in Kategorie- und Suchdarstellungen verwendet werden, ohne die Performance zu beeinflussen.
Bugfix: Parameter listvariations
Der Parameter listvariations entscheidet, ob beim Suchen alle gefundenen bestellbaren Artikel dargestellt werden (listvariations auf true) oder ob im Suchergebnis gefundene Variantenartikel auf Variantenköpfe zusammengefasst werden (listvariations auf false). Der Parameter war bisher schon vorhanden, hat aber genau umgekehrt als dokumentiert gewirkt. Das wurde mit dieser Version behoben und muss bei Verwendung von Varianten mit Ausrollung der Release in der Konfiguration umgeschaltet werden.
Bugfix: ERP Kundennummer eines Kunden
Die Kundennummer eines Shop Kunden im ERP System kann über das Admin Backend geändert werden, wurde dann aber nicht mehr in die Maske zurückgeladen. Das Problem wurde behoben.
Bugfix: Warenkorb versenden enthält Sonderzeichen anstelle von Leerschritten
Beim Versenden eines Warenkorbs als Link an eine EMail Adresse kann eine begleitende Meldung eingegeben werden. Diese Meldung wurde jedoch URI-Encoded, was normalerweise nur notwendig ist, wenn die Meldung innerhalb eines URLs verwendet werden soll. Das hat beim Empfänger dazu geführt, dass z.B. Leerschritte durch das Zeichen + ersetzt werden. Das Problem wurde behoben.