Ich sehe in vielen OXID7 Modulen den folgenden Abschnitt in der composer.json:
"config": {
"allow-plugins": {
"oxid-esales/oxideshop-composer-plugin": true,
"oxid-esales/oxideshop-unified-namespace-generator": true
}
}
Kann mir jemand kurz erklären, was damit erreicht wird und ob es sinnvoll ist, dies in den eigenen Modulen ebenfalls einzubinden?
Diese Einstellung wirst Du in der composer.json des installierten Shops gefunden haben. Das ist eine Konfiguration von Composer und hat mit den Shop-Plugins nichts zu tun. Wenn dies tatsächlich in einem Modul drin steht, dürfte das dort wirkungslos sein.
Warum gibt es das?:
Es gibt Composer-Pakete, die in den Installationsablauf eingreifen können und z.B. Code verändern können. Da das sicherheitsrelevant ist, müssen solche Erweiterungen bei der ersten Verwendung vom Techniker bestätigt werden. Da gibt es im Composer-Prozess eine entsprechende Nachfrage. Wenn das dort bestätigt wurde, sind diese freigegebenen Scripte dauerhaft in der composer.json des Shops hinterlegt.
Es wird also keinen Nutzen ergeben, das in Deinen Modulen einzutragen.
Hallo Daniel, danke für deine Antwort.
Die config-Einstellung für Composer ist z.B. hier aufgeführt in diesem composer.json Beispiel für ein Modul:
Auch das PayPal Modul von OXID hat diesen Abschnitt in der composer.json:
Aber wenn die Angabe keine Auswirkung hat, werde ich das entsprechend rausnehmen.
Ich befürchte, bei der Vorlage wurde zu weit übers Ziel hinausgeschossen.
Man kann zwar da alles reinschreiben. Composer unterscheidet jedoch bei der Verwendung der Einstellungen strikt die Herkunft. So werden nur bestimmte Angaben aus der composer.json von Dependencies (egal welches Levels) verwendet. Möchte man diese eintragen, müssen diese zwangsweise in die composer.json der Root-Packages.
Aus dem Beispiel werden folgende Abschnitte ignoriert, wenn das Modul als Abhängigkeit installiert wird:
Diese Angaben sind aus Sicherheitsgründen ausschließlich der root composer.json vorbehalten. Details findest Du dazu unter The composer.json schema - Composer und in den als “root-only” markierten Abschnitten.
Vielen Dank. Vermutlich sind die Angaben dann für das Entwickler-Setup oder ähnliches enthalten.
Dann kann ich die Angabe bei mir auf jeden Fall rauswerfen.
Richtig.
Nebenbei sind wir der Meinung, dass die Abhängigkeiten des Beispiels hier zu wenig sind. Für OXID-Module müsste da eigentlich auch zwingend mindestens eine Definition der Shopversion rein:
"require": {
"php": "^8.0 | ^8.1",
"oxid-esales/oxideshop-ce": "~7.1.0"
},
für die Freigabe im OXID 7.1. Sonst könnte man das Paket auch in einem OXID 6 installieren (was erst durch Fehler im Betrieb auffallen würde) oder sogar in Projekten, die nicht mal ein OXID-Shop sind (was erst recht keinen Sinn ergibt).
Ich stimme der Antwort bezüglich allow-plugins nur bedingt zu.
Bei OXID-Modulen wirst du das vermutlich häufiger finden, weil wir bei unseren Tests und während der Entwicklung dazu übergegangen sind, das jeweilige Modul als root-Package zu verwenden. Sprich du installierst den Shop als dependency zum Modul dazu und nicht umgekehrt das Modul zum Shop.
Und die root-composer.json braucht eben (in neueren composer-Versionen) diese Definition, um die beiden Plugins zu laden.
Ein Beispiel findet ihr auch im Modul-Template unter GitHub - OXID-eSales/module-template: Reusable module template
Hallo Sven, danke, dass du das nochmal klarstellst. Von dem von dir beschriebenen Setup bin ich jetzt dank Daniel ungefähr bereit schon ausgegangen. Dass das Modul als Root-Package verwendet wird und dafür der config Eintrag enthalten ist.