Servus Forum, um Shopware aus GitHub nutzen zu können, gleichzeitig aber unsere eigenen Plugins und Templates in einem Repository zu sichern, aus dem heraus auch das Deployment in die diversen Umgebungen (Development(s), Staging, Production) erfolgt, sind wir folgenden Weg gegangen: 1. Das Shopware-Repo von GitHub lokal geklont 2. Zusätzliche Remote-URL angelegt zu unserem eigenen Repo. 3. Neuen Branch angelegt, auf dem wir jetzt entwickeln. Wenn eine neue Version von Shopware released wird (wie aktuell 4.1.4), wird der entsprechende Commit aus dem master-Branch in unseren development-Branch gemerged und alles ist ok. Eigentlich. Zunächst: Ist an dieser Herangehensweise grundsätzlich etwas auszusetzen? Das eigentliche Problem ist aber folgendes: Wie kann ich das eigentliche Update (der DB) jetzt durchführen? Theoretisch müsste ich doch entweder im Browser die /update/index.php aufrufen oder auf der Konsole /update/update.php ausführen? Im GitHub-Repo gibt es aber gar kein update-Verzeichnis? Kann mir hier jemand auf die Sprünge helfen? Vielen Dank schonmal! Martin
Hi, wenn du GitHub verwendest musst du anders Vorgehen, als mit den fertigen Packages. Hier ist beschrieben wie das funktioniert: https://github.com/ShopwareAG/shopware-4#start-hacking Vg, Marcel
Die Verwendung der build/ApplyDeltas.php hat’s gelöst.
Doch noch nicht final gelöst! Bei Verwendung eines Shopware-Git-Clones von Github werden die PHP-Konstanten VERSION und REVISION nicht gesetzt, sondern stehen auf ‚__VERSION__‘ bzw. ‚__REVISION__‘. Das hat zwar zunächst augenscheinlich nur optische Konsequenzen im HTML-Title des Backends und in der Systeminfo, tatsächlich geht es aber noch ein ganzes Stück tiefer und da wird es dann verheerend… Bei der Installation beispielsweise des PayPal-Plugins muss dieses dummymäßig aus dem Shopware-Store geladen werden (in Shopware_Controllers_Backend_PluginManager->downloadDummyAction()). Das erledigt die Methode CommunityStore->downloadPlugin(). Der verwendete Zend_Http_Client bekommt dabei einen User-Agent verpasst, der sich aus „Shopware/“ und der Versionsnummer zusammensetzt, also z.B. „Shopware/4.1.3“. Wenn aber die Versionsnummer den Wert „__VERSION__“ hat, ist der User-Agent logischerweise „Shopware/__VERSION__“. Problem: Mit ungültigem User-Agent liefert der CommunityStore eine leere Response zurück, was zur Folge hat, dass sich das Plugin nicht installieren lässt (Fehlermeldung: „Given file is no zip archive“)! Außerdem funktioniert die Abfrage, ob Updates vorhanden sind im Plugin-Manager ebenfalls nicht. Die oben erwähnten Konstanten sind in der /engine/Shopware/Application.php definiert. Sobald diese einen gültigen Wert haben, funktioniert wieder alles einwandfrei. Ein gültiger Wert für Shopware 4.1.4 ist z.B.: ... class Shopware extends Enlight\_Application { const VERSION = '4.1.4'; const VERSION\_TEXT = ''; const REVISION = '201312061433'; ... Wie ist das denn bei Installation aus dem Github-Repo angedacht? Soll die Application.php händisch angepasst werden? Gibt es irgendwo im ant-File oder in der ApplyDeltas.php eine (von mir übersehene) Stelle, an der die Version gesetzt würde, bzw. gibt es Pläne das zu ergänzen? Alternativ könnte man die Definition der Version auch an eine andere Stelle auslagern, z.B. irgendwo im Configs-Dir. Input/Meinungen hierzu?
Gibt es mittlerweile eine Lösung für dieses Problem? Ich hänge derzeit an ähnlicher Stelle (Installation via git (Shopware Versionen 5.0.2 bis 5.0.4), ant-build etc.). In meiner Application.php finden sich leider auch nur default-Werte für die Konstanten VERSION, VERSION_TEXT und REVISION: const VERSION = '\_\_\_VERSION\_\_\_'; const VERSION\_TEXT = '\_\_\_VERSION\_TEXT\_\_\_'; const REVISION = '\_\_\_REVISION\_\_\_'; Danke für jeden Hinweis.
Hallo zusammen, wie schon hier im Thread vermutet, haben wir ein 500 Zeilen langes ANT-Build-Script. Neben dem Setzen der Versionsnummer, hat es auch einige andere QA & Update Targets. Das Target zum Setzen der Versionswerte sieht so aus: [code]
<replacefilter token=" ___VERSION___" value="${git.newtag}"></replacefilter>
<replacefilter token=" ___VERSION_TEXT___" value="${git.newtag_text}"></replacefilter>
<replacefilter token=" ___REVISION___" value="${revision}"></replacefilter>
</replace>
</target>[/code] Damit wird aber nur die Version in Shopware gesetzt. Eine Garantie oder Support können wir darauf nicht geben, da ja keine Änderungen direkt am Quellcode vorgenommen werden sollte. Da wir aber keine Versionsnummer "commiten", könnt ihr das ja ohne Probleme machen. (kein Konflikt) Und es fehlt z.B. auch das Build-Target um die MD5-Hashes für die Systeminfo zu erzeugen. Da ihr aber GIT zu Versionskontrolle habt, wäre es eh doppelt. Gruß Heiner