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.
Voraussetzungen:
- ein über Composer zu installierender Shop
- alle einzufügenden Module ebenfalls über Composer installierbar
- ein öffentlich erreichbares Repository (z.B. kostenfrei bei Github)
- einfache git-Kenntnisse
- praktischerweise ein kostenfreies Konto bei packagist.org
Umsetzung
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.
Sonderfall „Pakete entfernen“
Ü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:
- Demodaten für CE: d3/oxideshop-demodata-ce-replacement
- Demodaten für PE: d3/oxideshop-demodata-pe-replacement
- Demodaten für EE: d3/oxideshop-demodata-ee-replacement
- Paypal-Modul: d3/oxid-paypal-replacement
- Payone-Modul: d3/oxid-payone-replacement
- Paymorrow-Modul: d3/oxid-paymorrow-replacement
- Klarna-Modul: d3/oxid-klarna-replacement
- Amazonpay-Modul: d3/oxid-amazonpay-replacement
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.
Fazit
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