Seit gestern ist unser neues D3 Helpcenter unter https://faq.d3data.de online!
Hier finden Sie ab sofort Handbücher zu unseren Modulen sowie Hilfen, Tipps und Tricks zu den verschiedensten Bereichen des Online-Shops.
Mit dem neuen Helpcenter wurde unsere FAQ unter faq.oxidmodule.com abgelöst.
Der aktuelle OXID-Shop besteht, im Gegensatz zu älteren Versionen, nicht aus einem großen Dateipaket, welches den gesamten Shop enthält. Vielmehr setzt sich die Shopinstallation heute aus vielen Einzelpaketen zusammen. Um dessen richtige Zusammenstellung kümmert sich Composer während der Installation.
Startpunkt für die Shopinstallation ist das Paket oxid-esales/oxideshop-project welches selbst aber keine Shopdateien enthält. Dieses bringt ausschließlich Informationen über weitere erforderliche Pakete mit (Metapackage). Installiert man dieses, werden die darin benannten Packages nachgeladen, die selbst ebenfalls weitere Pakete nachfordern können. Schlussendlich ergibt dies dann einen kompletten OXID-Shop.
Nun werden aber die Wenigsten diesen Basisshop verwenden. Meist werden noch Module nachinstalliert. Im besten Fall kommen diese ebenfalls als über Composer installierbare Pakete.
Wenn man diese Shop- und Modulkombination häufiger benötigt oder sich die Nachinstallation sparen will, kann man sich die individuelle Zusammenstellung auch schon passend vorbereiten. Dann steht nach der Installation sofort der komplette Shop mit allen Modulen fertig zur Verfügung.
Um diese angepasste Installation vorzubereiten, tauschen wir einfach das oberste Package des Abhängigkeitenbaums aus und verändern dieses nach unseren Erfordernissen.
Hierzu legen wir uns einen Fork des Original-Repositories https://github.com/OXID-eSales/oxideshop_project an. Das geht bei Github ganz einfach über den Button „Fork“ (rechts oben).
Den neuen Fork klonen wir zur lokalen Bearbeitung auf unseren Computer.
In unserer Kopie finden wir nun mehrere Entwicklungszweige (Branches). Im Master-Zweig befindet sich die Datei `composer.json`, in der wir die ID `oxid-esales/oxideshop-project` gegen eine neue individuelle ID austauschen. Ich habe mich dazu entschieden, den ersten Teil (den Vendor) anzupassen. Meine Version sieht dann so aus:
{
"name": "d3/oxideshop-project",
"type": "project",
"description": "This file should be used as an OXID eShop project root composer.json file. Entries provided here intended to be examples and could be changed to your specific needs.",
"license": [
"GPL-3.0-only"
]
}
Diese Datei speichern wir und übertragen diese (mit „add“, „commit“ und „push“) in unser Repository in den Master-Zweig.
Dann wechseln wir in den Zweig für unsere aktuell gewünschte Shopversion. In meinem Fall wechsel ich zu **b-6.1-ce**, da ich später die Community Edition in Version 6.1.x installieren möchte. Auch dort ändern wir in der `composer.json` die ID auf unsere neue Version ab. Wählt für andere Shopeditionen und -versionen einfach den passenden Zweig.
Im Abschnitt `require` können wir nun zusätzlich alle Module eintragen, die automatisch mit installiert werden sollen. Die erforderlichen Angaben erfahrt ihr beim jeweiligen Modulautor. In meinem Fall habe ich unter anderem die Module Internals aus der Community nachgetragen. Alle Paket-Einträge müssen mit einem Komma getrennt sein. Nur der letzte Eintrag darf nicht mit einem Komma enden.
Der erste Eintrag (hier `oxideshop-metapackage-ce`) muss erhalten bleiben.
"require": {
"oxid-esales/oxideshop-metapackage-ce": "v6.1.3",
"oxid-community/moduleinternals": "^2.0"
}
Auch diese Änderung speichern wir und übertragen diese ins Repository.
Für andere Shopeditionen und -versionen könnt ihr die anderen Zweige ebenfalls noch anpassen.
Nun machen wir unser neues Paket der Öffentlichkeit noch bekannt.
Dazu melden wir uns auf packagist.org an und rufen „Submit“ auf. Dort tragen wir die URL unseres Repositories ein. Dann wird geprüft, ob unsere vergebene ID eindeutig ist. Wenn diese schon verwendet wird, tauscht ihr die ID an den oben beschriebenen Stellen bitte noch einmal aus.
Nach einer kurzen Wartezeit könnt ihr die Shopinstallation mit diesem neuen Befehl gleich komplett ausführen:
composer create-project --no-dev d3/oxideshop-project my_oxid_eshop_project dev-b-6.1-ce
Verwendet darin natürlich eure eigene Paket-ID.
Wenn eine neue Shopversion veröffentlicht wird, gibt es auch Änderungen am oxidproject-Package. Übernehmt dann diese Änderung bitte in eure angepasste Datei, wenn ihr dorthin aktualisieren wollt.
Über den beschriebenen Weg könnt ihr Pakete einfach hinzufügen. Etwas schwieriger wird es, wenn ihr Pakete entfernen wollt, die der Shop selbst mitbringt. Manch einer benötigt z.B. die Demodaten nicht oder möchte auf eines der Zahlartenmodule verzichten, die der Shop im Standard enthält.
Da sich diese Pakete mitten im Abhängigkeitsbaum befinden, wäre es sehr aufwändig, diese komplett aus der Installation zu lösen. Composer bietet jedoch die Möglichkeit, solche Pakete einfach zu ersetzen. Wir können dann stattdessen leere Pakete mitgeben, die sich wie zusätzliche Module installieren lassen.
Diese Ersatzpakete werden für jedes zu ersetzende Modul separat erstellt. Für die üblichen Fälle haben wir diese schon fertiggestellt:
Diese Pakete könnt ihr genauso in eure composer.json aufnehmen, wie neue Module. In unserem Installationsprojekt sieht dies dann beispielsweise so aus:
"require": {
"oxid-esales/oxideshop-metapackage-ce": "v6.1.3",
"oxid-community/moduleinternals": "^2.0",
"d3/oxideshop-demodata-ce-replacement": "*"
},
So verzichten wir in unserer Beispielinstallation auf die Demodaten.
Natürlich könnt ihr diese Ersetzungen auch jederzeit manuell in einem schon bestehenden Shop installieren.
Die Ersetzung lassen sich genauso jederzeit wieder entfernen, wenn ihr die originalen Module dennoch später einsetzen wollt.
Ersetzungen müssen natürlich nicht grundlegend leer sein. Damit könnt ihr theoretisch auch alternative Inhalte (z.B. temporäre Bugfixes o.ä.) für ein bestehendes Paket ausliefern.
Unsere neue Paketstruktur sieht nun so aus:
Die eShop-Zusammenstellung muss nicht in Stein gemeiselt sein. Mit überschaubarem Aufwand lassen sich angepasste Installationpakete erstellen.
Die Replace-Funktion von Composer ist ein wenig dokumentiertes, aber mächtiges Werkzeug, um bestehende Paketzusammenstellungen und -inhalte zu ändern.
Das hier eben beschriebene Projekt findet ihr installationsfähig unter d3/oxideshop-project.
Wir wünschen euch viel Spaß beim Ausprobieren.
Euer Team von D3
Seit dem 01. August 2019 haben wir uns auf neues Terrain begeben und unseren ersten Auszubildenden, Max Buhe, ins Boot (Unternehmen) geholt.
Max wird bei uns unter fachkundiger Anleitung seine Ausbildung zum Fachinformatiker – Fachrichtung Anwendungsentwicklung absolvieren und in 3 Jahren hoffentlich erfolgreich abschließen. Dazu hat unser Daniel Seifert im letzten Jahr einen Ausbilderschein gemacht.
Wir wünschen uns eine gute und konstruktive Zusammenarbeit und für Max viel Erfolg und Freude bei seiner Ausbildung.
Ab Mitte September tritt die Zahlungsdiensterichtlinie PSD2 (Payment Services Directive 2) vollends in Kraft.
heidelpay hat alle aktiven Schnittstellen (SGW, NGW, MGW) bereits technisch dafür vorbereitet und wird für alle Händlerverträge zusätzlich das 3D Secure Verfahren aktivieren.
Damit sind für Sie als Händler grundsätzlich keine technsichen Anpassungen notwendig.
Dennoch sollten Sie die Aktualität Ihrer eingesetzten Modulversion prüfen.
Generell empfehlen wir ab Shopversion 4.9.0 / 5.2.0 mind. die Modulversion 5.2.3.4.
Um die für Ihren Shop aktuellste Modulversion zu ermitteln, verwenden Sie bitte unsere Modulverfügbarkeitsliste.
Informationen zur PSD 2 finden Sie unter folgenden weiterführenden Links:
Heidelpay: Themenreihe zur PSD2
Gastblog: Die PSD2 auf der Zielgeraden
Die E-Payment Komplettlösung
Für unser Modul „Erweiterte Suche“ gibt es ab sofort ein neues Update für die Shopversionen ab 6.0.0
Damit können Attributwerte zu Gruppen zusammengefasst werden, die komplett ausgewählt werden, obwohl der Shopbesucher nur einen Wert daraus selektiert hat.
Dies ist z.B. sinnvoll bei regionsspezfischen Größenangaben, die sich gegenseitig überschneiden. Dann ist es egal, ob der Kunde die US-Größe oder die EU-Größe wählt. Er erhält dann immer die Produkte aus beiden Bereichen passend.
Ein weiterer Einsatzfall sind z.B. auch fein differenzierte Farben. Für rote Artikel reicht dann die Auswahl von „tomatenrot“, um auch alle anderen Rottöne zu erhalten.
Diese Funktion lässt sich pro Attribut einstellen. Die korrespondierenden Werte werden im Synonymeditor gepflegt.
Zur Einrichtung gibt es eine Hilfeseite im Handbuch.
Das WaWi-Modul verändert die Suchabfragen des Shops deutlich, so dass es bei Einsatz der beiden Module zu Inkompatibilitäten kam. Die uns bekannten Fälle sind hierin korrigiert, so dass beide Module zum heutigen Stand kompatibel sind.
Erwerben können Sie das Modul wie gewohnt in unserem Moduleshop.
fehlertolerante Suche mit zusätzlichen Filter- und Anzeigemöglichkeiten
OXID veröffentlichte heute die neuen Shopversion 6.0.5 sowie 6.1.4.
Unter anderem enthalten diese Versionen einen Fix für eine kritische Sicherheitslücke.
Damit ist es einem Angreifer möglich sich Zugriff auf den Adminbereich zu verschaffen.
Weitere Informationen dazu finden Sie unter folgenden Links:
Security Bulletin 2019-001
Release Notes 6.0.5
Release Notes 6.1.4
Die Patches sollten kurzfristig in den betroffenen Shops eingespielt werden.
Ältere Shopversionen < 6.0.0 sind von der Sicherheitslücke nicht betroffen!
Generell empfehlen wir den Adminbereich immer zusätzlich mit einem Verzeichnisschutz zu versehen.
Für unser Modul „Auftragsmanager“ gibt es ab sofort ein neues Update für die Shopversionen 4.10.x / 5.3.x.
Mit dieser Version kann nun jeder Aufgabe jedem Trigger ein vorab auszuführender sowie ein danach auszuführender Scriptaufruf mitgegeben werden. Die Scripte werden direkt vor dem Anwenden der konfigurierten Aktionen bzw. direkt danach gestartet.
Mit dem Vorab-Script können z.B. Aufräumarbeiten durchgeführt werden.
Unser Beispiel für das Danach-Script ist das Versenden von während der Aufgabe erstellten Listen.
Da beiden Scripten das jeweilige Auftragsmanagerobjekt (also die eigentliche Aufgabe) mitgegeben wird, kann darin z.B. auch die Aufgabe zur Laufzeit umkonfiguriert werden. Nutzbar ist dies z.B., in dem ein Feld mit dem aktuellen Datum befüllt wird. Dies lässt sich so im Standard nicht einstellen. Durch die Scripte kann aber der neue Feldinhalt auf das aktuelle Datum gesetzt werden.
Wie sonst beim Auftragsmanager gibt es auch hier vermutlich unzählige Einsatzfälle.
Die Scriptausführungen sind nur in der Premium-Edition verfügbar!
Erwerben können Sie das Modul wie gewohnt in unserem Moduleshop.
Lassen Sie wiederkehrende Aufgaben automatisch nach frei definierbaren Regeln ausführen
Für unser Modul „Auftragsmanager“ gibt es ab sofort ein neues Update für die Shopversionen ab 6.0.0.
Folgende Änderungen sind enthalten:
Neue Funktionen:
Neben den beiden bisherigen Triggern (Cronjob und manuelle Ausführung) können die Aufgaben nun auch den neuen Triggern „onOrderFinalize“ bzw. „onOrderSave“ zugeordnet werden.
Für „onOrderFinalize“ heißt dass, dass diese Aufgabe sofort ausgeführt wird, sobald das Finalisieren einer Bestellung abgeschlossen ist. Dann wird auch nur diese eine aktuelle Bestellung bearbeitet.
Ein extra Aufruf (z.B. via Cronjob) ist nicht mehr nötig.
Analog läuft das auch mit „onOrderSave„.
Die Aufgabe wird für die jeweils aktuelle Bestellung gestartet, sobald diese gespeichert wurde.
Die Trigger „Cronjobaufruf„, „onOrderFinalize“ und „onOrderSave“ berücksichtigen immer die eingestellten Bedingungen. D.h., wenn die aktuelle Bestellung nicht zur Bedingung passt, wird die Aufgabe darauf nicht angewandt.
Beim Trigger „manuelle Ausführung“ erschien die Aufgabe bisher immer bei allen Bestellungen, egal ob diese den eingestellten Bedingungen entsprach. Das kann nun am Trigger ebenfalls eingestellt werden, ob auch hier die Bedingungen beachtet werden sollen. Passen die Bedingungen dann nicht, wird die Aufgabe im Order-Tab auch nicht angeboten.
Jeder Aufgabe kann jedem Trigger einen vorab auszuführenden sowie einen danach auszuführenden Scriptaufruf mitgegeben werden. Die Scripte werden direkt vor dem Anwenden der konfigurierten Aktionen bzw. direkt danach gestartet.
Mit dem Vorab-Script können z.B. Aufräumarbeiten durchgeführt werden.
Unser Beispiel für das Danach-Script ist das Versenden von während der Aufgabe erstellten Listen.
Da beiden Scripten das jeweilige Auftragsmanagerobjekt (also die eigentliche Aufgabe) mitgegeben wird, kann darin z.B. auch die Aufgabe zur Laufzeit umkonfiguriert werden. Nutzbar ist dies z.B., in dem ein Feld mit dem aktuellen Datum befüllt wird. Dies lässt sich so im Standard nicht einstellen. Durch die Scripte kann aber der neue Feldinhalt auf das aktuelle Datum gesetzt werden.
Wie sonst beim Auftragsmanager gibt es auch hier vermutlich unzählige Einsatzfälle.
Die Scriptausführungen sind nur in der Premium-Edition verfügbar!
Da die Triggereinstellung nun deutlich umfangreicher sind, wurden diese aus dem „Stamm“-Tab herausgelöst und in einen eigenen „Auslöser“-Tab verlagert.
Jede Adminseite hat nun eine kurze aufklappbare Beschreibung, was sich darin jeweils konfigurieren lässt. Das soll das Zusammenspiel der jeweiligen Tabs verdeutlichen.
Erwerben können Sie das Modul wie gewohnt in unserem Moduleshop.
Lassen Sie wiederkehrende Aufgaben automatisch nach frei definierbaren Regeln ausführen
Für unsere Modul „Content Tabs“ gibt es ab sofort einen neuen Patch für die Shopversionen ab 6.0.1
Bislang war der Trigger zum Speichern der zusätzlichen Langtextfelder immer das Eingabefeld für den Aktivstatus des ersten Langtextes. Wurde dieser (im Admin) nicht übergeben, konnte das recht aufwändige Speichern der Langtexte entfallen. Im Importer gibt es jedoch den Fall, dass zwar Langtexte, jedoch nicht der 1 Aktivstatus gesetzt werden. Folglich wurden in manchen Fällen die Langtexte nicht an die Artikel übertragen. Im Modul wurde der Trigger nun auf alle vorhandenen Aktivfelder erweitert. So muss in der Updateliste nur ein beliebiges Aktivfeld übergeben werden, dass die Langtexte gespeichert werden.
Das Modul fügt zusätzliche Langtextfelder den Artikelobjekten dynamisch hinzu, da diese Felder in der Datenbank an anderer Stelle abgelegt sind. Jedoch lieferte die Methode, die alle Feldnamen für eine Datenbankabfrage zusammenstellt, diese Felder fälschlicherweise mit aus, was zu fehlerhaften Abfragen anderer Module führte. Diese Felder wurden nun entfernen.
Erwerben können Sie das Modul wie gewohnt in unserem Moduleshop.
Stellt auch umfangreiche Inhalte auf der Artikeldetailseite übersichtlich da
Für unser Modul „Importer“ gibt es ab sofort ein neues Update für die Shopversionen ab 6.0.0.
Sie haben unter /D³ Module/Importer/Artikelimport/Artikelfelder/ eine neue Checkbox Möglichkeit, mit der sich alle Update-Haken de- / aktivieren lassen.
Sie haben unter /D³ Module/Importer/Bildimport/Stamm/ eine neue Auswahlmöglichkeit „Aktion nachdem ein Bild importiert wurde:“. In der Auswahl finden Sie 3 Optionen:
Bild löschen ~ Der Bildimport löscht nach dem Bildimport, die Datei aus dem Quellverzeichnis (/source/import/pictures/)
Bei der letzten Option, ist das nachfolgende Feld „absoluter Pfad zum Zielverzeichnis“ ein Pflichtfeld.
Der absolute Pfad zum Zielverzeichnis können Sie beispielhaft aus der config.inc.php Datei des Shops entnehmen. Suchen Sie nach dem Eintrag „sShopDir“, kopieren Sie diesen und fügen Sie den angepassten Pfad in das Feld ein.
Sie haben unter /D³ Module/Importer/Bildimport/Stamm/ eine neue Checkbox „Masterbilder am Artikel voher entfernen (empfohlen)“.
Es kam im Mall Tab in den CE + PE Versionen zu einem Fehler, da man keinen Shop auswählen bzw. speichern konnte.
Erwerben können Sie das Modul wie gewohnt in unserem Moduleshop.
Modul für den Import großer Artikelmengen aus einer Excel Datei
