Wo lege ich .php-, .js-, .html-, .css-Dateien aus einer Drittanbieter-Bibliothek ab, die mit einer von mir entwickelten Erweiterung verbunden ist?

10

Angenommen, ich möchte eine Magento-Erweiterung entwickeln, die beispielsweise mit einem Open Source-Diagrammpaket oder einer Bildergalerie oder was auch immer verbunden ist, das NICHT Teil der Erweiterung selbst ist. Beim Herunterladen (getrennt von der Erweiterung) wird die Drittanbieter-Bibliothek in einer eigenen .zip-Datei mit allen .php-, .js-, .html- und .css-Dateien geliefert.

Platziere ich auf dem armen Site-Eigentümer, der meine Erweiterung zusammen mit der Drittanbieter-Bibliothek installieren möchte, die Last, die ursprüngliche .zip-Datei eines Drittanbieters auseinander zu ziehen und sie dazu zu bringen, .js in / js, .php in / lib ,. CSS in / Haut usw.?

Oder gibt es eine allgemein akzeptierte "Müllhalde" für .zips von Drittanbietern, auf der der Download bequem wie besehen entpackt und damit fertig werden kann?

best-practice external extensions

— fris
quelle

6

Ich weiß nicht, ob es eine einzige richtige Antwort auf diese Frage gibt, da dies wirklich von dem Code abhängt, den Sie einschließen.

Wenn Sie eine PHP-Bibliothek eines Drittanbieters einbinden möchten, z. B. ein SDK für eine externe API, sollte diese im Verzeichnis / lib Ihres Magento-Projekts abgelegt werden, damit sie von Ihrer Erweiterung, die sie verwendet, aufgenommen werden kann.

Sie verwenden jedoch auch js und css als Beispiele. Wenn Sie js von Drittanbietern in Ihrer Erweiterung verwenden, um Code auszugeben, z. B. einige js, die ein Canvas-Diagramm rendern, sollte dies höchstwahrscheinlich im Verzeichnis / js abgelegt werden, damit es von Ihrer Erweiterung aufgenommen werden kann. Für CSS sollte es wahrscheinlich zum Basis- / Standardthema und zu den Skin-Verzeichnissen hinzugefügt werden.

Leider macht es das Magento 1-Erweiterungssystem nicht einfach, solche Dinge zu verteilen, da die Dateien über das gesamte Projekt verteilt sind und nicht in einem einzigen Verzeichnis enthalten sind. Tools wie Magento Composer Installer und Modman helfen dabei etwas.

— Andrew Kett
quelle

4

Beim Herunterladen (getrennt von der Erweiterung) werden die Erweiterungen von Drittanbietern in einer eigenen .zip-Datei mit allen .php-, .js-, .html- und .css-Erweiterungen geliefert.

Ich war schon immer ein Fan davon, Konventionen aus der Quelle selbst zu erraten, obwohl es mit Magento 1 mehrdeutig sein kann.

Vorausgesetzt, die Bibliothekslizenz eines Drittanbieters ermöglicht das Bündeln, sollten Sie sie entpacken und zusammen mit Ihrer Erweiterung neu verpacken, da es keinen nativen Mechanismus zum Entpacken einer separaten Unterbibliothek gibt (ich könnte mich irren).

Wohin diese Assets gehen, hängt vom Typ und der internen Organisation der Dateien ab. Reine JS-Bibliotheken sollten untergehen ./js/. Dateien, die serverseitig ausgeführt werden, gehören zu ./lib/, wobei zu beachten ist, dass jede PHP-Klasse unter ./lib/durch das (im Wesentlichen PSR-0) Autoload-Schema (siehe Zend Framework 1 Autoload-Konvention) automatisch geladen werden kann. Auf nichts unter ./lib/kann (sollte) über den Client zugegriffen werden (Ref. ./lib/.htaccess).

— Benmarks
quelle

Danke Ben. Ihre Antwort ist sinnvoll, bedeutet jedoch, dass Websitebesitzer die Bibliothek von Drittanbietern nicht einfach auf die neueste Version aktualisieren können, unabhängig von der Magento-Erweiterung, die mit ihr verbunden ist. Es sei denn, die verstehen genau, wie alles zusammen hängt, und selbst dann ist es schmerzhaft, alle Teile in die richtigen Schlitze zu stecken. Dies ist ein Segen in dem Sinne, dass Versionen der Erweiterung und der Bibliothek von Drittanbietern konsistent bleiben, aber ein Schmerz, wenn neue Versionen der Bibliothek von Drittanbietern Fehlerbehebungen und neue Funktionen bieten und gleichzeitig die Abwärtskompatibilität beibehalten.

— Freitag,

1

"Dies ist ein Segen in dem Sinne, dass Versionen von Extension und Third Party Lib konsistent bleiben ..." Das ist das Ticket! Ihre Änderungen sind Ihre Änderungen. In Magento 2 ist dies dank Composer alles etwas einfacher.

— Benmarks

1

Sie möchten also eine Erweiterung erstellen und verwenden eine externe Ressource / ein externes Paket zum Erstellen. Unabhängig davon, welches Paket Sie in Ihrer Erweiterung verwendet haben, sollte Ihre Erweiterung meiner Meinung nach den Best Practices von Magento entsprechen. Das bedeutet, dass Sie alle JS-, CSS- und Images von der externen Ressource trennen und in base\defaultThemenpaketverzeichnissen ablegen sollten .

Das heißt, es gibt keinen solchen eindeutigen Speicherort für die Platzierung von Paketressourcen von Drittanbietern. Wenn Sie eine coole Erweiterung liefern, sollten alle js, css und Bilder, die sich auf Ihre Erweiterung beziehen, an einem Ort aufbewahrt werden, an dem normalerweise ein anderer Entwickler nachsehen wird, und in fast allen Fällen handelt es sich um das base/defaultThemenpaket.

Zusamenfassend

Alle Ihre Erweiterungen sollten untergehen

skin\frontent\base\default\js\[your_extension]\[all_of_your_js_files]
skin\frontent\base\default\css\[your_extension]\[all_of_your_css_files]
skin\frontent\base\default\images\[your_extension]\[all_of_your_images]

//for third parties, you can create an inner directory, to specify it
skin\frontent\base\default\js\[your_extension]\[your_external_resource]\[resource_js_files]
skin\frontent\base\default\css\[your_extension]\[your_external_resource]\[resource_css_files]
skin\frontent\base\default\images\[your_extension]\[your_external_resource]\[resource_image_files]

Auf diese Weise kann ein anderer Entwickler problemlos JS, CSS und Bilder (auch Ihrer externen Ressourcen) Ihrer Erweiterung finden. Da Sie ein zusätzliches Unterverzeichnis verwenden, um die externen Ressourcendateien in Ihrem Verzeichnis für Erweiterungsnamen anzugeben, erhalten andere den besten Hinweis darauf, dass Ihre Erweiterung auf Paketen von Drittanbietern basiert.

Ich empfehle Ihnen daher, die externen Pakete zu trennen und sie zu einem Teil Ihrer Erweiterung zu machen, damit ein anderer Entwickler Ihre Abhängigkeiten leicht finden kann. :-)

BEARBEITEN - 1

Sie sollten Ihre Erweiterungslast nicht für Ihren Websitebesitzer belasten. Sie können diese Schwierigkeit vermeiden, indem Sie Ihre Erweiterung richtig ausrichten. Das heißt, wenn Sie alle zugehörigen Dateien in den angegebenen Verzeichnispositionen speichern, sollte ein Websitebesitzer lediglich Ihre Erweiterung abrufen und dann Ihre Erweiterung aus dem Anwendungsstammverzeichnis zusammenführen. dh Richten Sie Ihre Nebenstelle richtig aus. Es sollte so aussehen.

/app
|_____code\community\Namespace\Module\...
|_____design
|        |_____frontend\base\defalt\...
|        |_____adminhtml\base\defalt\...

/skin
|_____frontend\base\default\js|css|images\[your_extension]\all_theme_related_files
|_____frontend\base\default\js|css|images\[your_extension]\all_theme_related_files

BEARBEITEN - 2

Wenn es einige Pakete gibt, die für alle Magento-Anwendungen gemeinsam genutzt werden sollen (z. B. eine Javascript-Bibliothek oder ein PHP-Paket usw.), können Sie sie in ein \libVerzeichnis stellen.

Es ist richtig, dass möglicherweise doppelte Dateien vorhanden sind, wenn zwei Erweiterungen auf denselben Ressourcenpaketen basieren. Sie können auch unterschiedliche Versionen desselben Ressourcenpakets verwenden. Grundsätzlich sollte Ihre Erweiterung jedoch nur die Ressource Ihrer Erweiterung verwenden (und kann sich auf die Standardressourcen von Magento stützen) und nicht auf die Ressourcen anderer Erweiterungen, es sei denn, Ihre Erweiterung ist eine "Erweiterungsversion" einer Erweiterung eines Drittanbieters.

— Rajeev K Tomy
quelle

Vielen Dank. Ihre Antwort bevorzugt die Sichtweise des Entwicklers und nicht die Seite des Website-Eigentümers. Aber ich denke, so ist es in Magento? Ich kenne andere CMS, die Orte zum Entpacken von Archiven / Bibliotheken von Drittanbietern vereinbart haben, um alle Dateien so zusammenzuhalten, wie sie im Original sind.

— Freitag,

1

Ja. Ich weiß, dass es frustrierend ist, eine Paketressource zu trennen. Magento verlangt es. Es gibt keinen einfachen Weg dafür. In den Best Practices von Magento heißt es: "Sie sollten alles js, css, imagesim base\defaultPaket behalten ". Siehe auch meinen Bearbeitungscode

— Rajeev K Tomy

Hallo Rajeev ... Eine weitere Konsequenz des Einfügens der externen Ressourcen- / lib-Dateien unter "your_extension" ist, dass sie nicht von anderen Erweiterungen gemeinsam genutzt werden können, die möglicherweise auch die Ressource / lib verwenden. Sie erhalten also mehrere Kopien, möglicherweise verschiedene CLASHING-Versionen, die auf derselben Seite geladen sind. Autsch!

— Freitag,

siehe meine Änderungen bitte

— Rajeev K Tomy

0

Magento hat einen eigenen Paketmanager namens Magento Connect. Sie sollten diese Anleitung aus der offiziellen Dokumentation lesen, um zu verstehen, wie das Paket aussehen sollte. Sie können Ihr Modul aus einer Magento-Installation packen, sobald Sie die Struktur verstanden haben.

— mbalparda
quelle

Vielen Dank für Ihre Antwort, aber es ist nicht ganz das, was ich gefragt habe. Es geht nicht darum, wie ich meine Erweiterung verpacke, sondern darum, wo im Magento-Dateibaum Dateien von Drittanbietern abgelegt werden sollen, die NICHT Teil des Kerns oder meiner Erweiterung sind, aber als Teil des Systems aufgenommen werden müssen. Wo fordere ich Benutzer auf, diese Dateien abzulegen? Gibt es einen Standard-Spot (oder Spots) für Dateien von Drittanbietern?

— Freitag,

Es hängt tatsächlich mit dem Link zusammen, den ich Ihnen gesendet habe. Js und CSS haben wie jede andere Erweiterungsdatei ihre eigenen Ordner für Pakete. PHP-Dateien können sich entweder im Ordner root lib oder im Modulordner in einem lib-Ordner befinden.

— Mbalparda

OK danke. Ihre Antwort lautet also: Ja. Magento-Site-Builder müssen das Archiv von Drittanbietern entpacken, die PHP-, JS-, HTML- und CSS-Teile aus diesem Archiv ziehen und diese Dateien in den entsprechenden Slots im Magento-Dateibaum neu verteilen. Es wird NICHT als bewährte Methode angesehen, dem Site Builder zu erlauben, einfach das gesamte Archiv eines Drittanbieters in einem für diesen Zweck festgelegten, gemeinsam vereinbarten Verzeichnis zu entpacken, in dem die zugehörigen Erweiterungen die Dateien von Drittanbietern nach Bedarf enthalten.

— Freitag,

Ja. Alles, was Sie beschrieben haben, ist bereits in dem in der Dokumentation beschriebenen Verpackungsprozess enthalten.

— Mbalparda

Nun, ich habe diese Dokumentation gelesen, aber sie sagt nichts über meine Frage aus. Es werden nur Dateien behandelt, die Teil der Erweiterung sind, die Sie entwickeln und die Sie verpacken möchten. Es wird nicht angegeben, wo Dateien von Drittanbietern abgelegt werden sollen, die NICHT Teil der Erweiterung sind, z. B. ein Kalender, eine Bildergalerie oder ein Diagrammpaket. Möglicherweise möchten Sie diese nicht mit der Erweiterung verpacken, die Sie entwickeln, damit sie unabhängig aktualisiert werden können. Die Frage wird dann, wo die Dateien von Drittanbietern abgelegt werden sollen. Was ist der Best-Practice-Ansatz für diese?

— Freitag,

0

Grundsätzlich Magento seine eigene Struktur zu halten , verwendet .php, .phtml, js, css, imagesDateien.

Für Entwickler von Magento-Erweiterungen ist es sehr wichtig, dass Sie dem Magento-Weg folgen. Überprüfen Sie diesen Link .

Damit,

Ihre .phpDateien sollten sich im app/code/communityOrdner befinden
Ihre jsDateien können in einen jsOrdner oder in einen skin/frontend or adminhtml/your_theme_pack/your_theme/jsOrdner verschoben werden
Ihre cssDateien können in einen skin/frontend or adminhtml/your_theme_pack/your_theme/cssOrdner verschoben werden
Ihre imagesDateien können in einen skin/frontend or adminhtml/your_theme_pack/your_theme/imagesOrdner verschoben werden
Ihr files should go toOrdner 'html app / design / frontend oder adminhtml / template`

PS-Frontend bedeutet, wenn Ihre Erweiterung für den Front Store bestimmt ist, und adminthml bedeutet, dass Ihre Erweiterung für den Admin-Bereich bestimmt ist.

Es gibt spezielle Möglichkeiten, diese Dateien in Magento zu speichern. Sie sollten sie daher befolgen.

Ich würde auch prüfen, ob Ihre gewünschten / Kopierfunktionen bereits im Magento / Zend-Framework verfügbar sind. Zum Beispiel sind das Erstellen von PDFs, das Senden von E-Mails, das Lesen von XML usw. bereits in Magento erstellt.

Hoffe das hilft.

Update 1

Wenn Sie Ihre Dateien nur irgendwo aufbewahren möchten, können Sie sie überall aufbewahren. Sie können sogar einen neuen Ordner im Magento-Stammverzeichnis erstellen. Dies ist jedoch keine bewährte Methode für Magento, das Ihren Server beim Ausführen dieser Dateien lädt. Sie möchten dies überprüfen https://magentotherightway.com/

— Adarsh Khatri
quelle

Danke für den Link und die Erklärung. Aber ich frage nicht nach der Erweiterung selbst. Ich frage, wo der Code eines Drittanbieters abgelegt werden soll, der nicht in der Erweiterung enthalten ist. Gibt es einen gemeinsam vereinbarten EINZELNEN Standort dafür?

— Freitag,

Wenn Sie Ihre Dateien nur irgendwo aufbewahren möchten, können Sie sie überall aufbewahren. Sie können sogar einen neuen Ordner im Magento-Stammverzeichnis erstellen. Dies ist jedoch keine bewährte Methode für Magento, das Ihren Server beim Ausführen dieser Dateien lädt. Sie möchten diese magentotherightway.com

— Adarsh Khatri

Verteilte Erweiterungen sollten niemals im localCodepool installiert werden .

— Benmarks