in den Dokus ist ja nur die Installation via Git/Composer erklärt (die Seiten sind übrigens momentan zum Teil nicht erreichbar). Aber wie genau sieht der richtige Update Weg aus?
Ich will ja kein master auschecken, sondern feste Versionen, also hab ich das bisher so gemacht (Beispiel für 6.1.4).
Aber damit komme ich zB nicht auf 6.1.5, weil es dazu garkeinen Git Tag für den root/developer Ordner gibt, sondern nur für platform und dadurch auch im Backend noch 6.1.4 angezeigt wird. Also ist das ja scheinbar nicht der richtige Weg?
Bei einem Update auf 6.2.0-RC1 gibt es zwar die Git Tags aber hier schlägt psh.phar update fehl. Liegt wohl an einer Plugin inkompatibilität, was ich mir erst noch ansehen muss.
(2/6) Starting
> bin/console plugin:refresh
PHP Fatal error: Uncaught Symfony\Component\Debug\Exception\UndefinedFunctionException: Attempted to call function “next6050” from namespace “Flag”. in /Users/cgross/www/smyla/platform/src/Core/Content/Content.php:38
Beim Copy&Paste ist mir nur das composer install nochmal reingerutscht.
Die lock Datei hatte ich vorher schonmal gelöscht aber lag am vendor Ordner. Hatte das früher bei Magento auch manchmal löschen müssen, wenn wa sbei Composer hin aber bei SW bisher noch nicht bisher.
Sagmal weißt du, wie ich eine eigene Composer.json für aufbauen muss, damit ich einerseits lokal (composer install) die Dev-Umgebung habe und live (composer install --dev) nur die Prod-Umgebung (alsonur das platform-Repo mit Plugins) von Shopware und noch eigene Plugin-Repos im richtigen custom Ordner installiere? Weil ich gerne eine composer.lock hätte, die lokal getestet Versionen von allem festlegt und live exakt das installiert wird und man nicht mit Plugin Updates übers Backend anfängt.
Da müsste ja eigentlich shopware/development unter require-dev aber wie bekomme ich das richtig mit den Pfaden hin, dass es sowohl lokal als auch live jeweils die Ordernstruktur richtig aufbaut?
Hm, dass macht das ganze ja recht umständlich. Plugins und Theme lokal in einer ganz anderen SW-Umgebung zu bauen und dann nochmal zusätzlich lokal dieses Production-Template pflegen, damit man die composer setzen kann und das live direkt auschecken kann.
Hätte halt grundsätzlich ganz gerne, zumindest bei größeren Änderungen, immer einen neuen Shop aufgebaut, damit ein Rollback, zB via Smylink auf den alten Ordner, schnell möglich ist. Aber da kommen ja schon die kostenpflichtigen Plguins von Shopware dazwischen, denn die haben ja sicher kein public Git Repo, dass man in Composer einbinden könnte. Also muss man da ständig die Updates der externen Plugins in eigenen Repos pflegen.
Darf ich mal reinhängen @Shyim wie ist deine Einschätzung: Kann man sich für SW6 schon drauf verlassen, dass die Plugins von Dritten auch per Composer installierbar sind? Wir halten im Moment auch für SW6 noch alle Plugins im Repo des Custom-Projekts.
@Exe wir pflegen die Updates der Plugins eh lokal wg. Testing, da ist es nur ein add/commit ins Repo
@vanwittlaer ich denke das kommt drauf an, wie das Repo aufgebaut ist. Ich habe bisher für jedes eigene Plugin ein Repo angelegt, damit wir die Plugins je nach Bedarf später auch in neue Shops schnell einbinden können und somit nicht nur ein Repo für komplett custom/plugins o.ä. Möglich das ich das noch ändere, weils schon bisschen nervig ist. PHPStorm unterstützt das nicht schön und dadurch verliert man den Überblick, welche Files geändert wurden.
Durch den public Ordner sehe ich nicht mehr so viele Fehler in Plugins im Store. Wenn während der Manuellen Code-Review solche Sachen sehe, lehnen wir auch das Plugin auch ab.
Trotzdem würde ich das einmal überprüfen wollen in einem Staging
Dann fehlt mir aber die psh.phar und dadurch Befehle wie storefront:build usw.
Wie soll ich denn nur mit dem Production Repo lokal ein Theme bauen?
Theme bauen ist schon so ein unfassbar nerviger Krampf in Shopware 6. Jedes storefront:build dauert mind 3:30min, egal ob ich da nur eine Zeile in der SCSS ändere oder mehr. storefront:watch und hot starten zwar etwas und werfen keinen Fehler, erkennen aber nie Änderungen.
Den Build für die Storefront usw. findest du im Production-Template und in der Download-Version im bin-order als normale Shell-Scripts, z.B. bin/build-storefront.sh
Zur Krampfvermeidung brauchst du einen entsprechenden Entwicklungsrechner, dann läuft das auch gut.
Den Build für die Storefront usw. findest du im Production-Template und in der Download-Version im bin-order als normale Shell-Scripts, z.B. bin/build-storefront.sh
Zur Krampfvermeidung brauchst du einen entsprechenden Entwicklungsrechner, dann läuft das auch gut.
Hm werd ich mal probieren über bin/build. Hab ein Macbook Pro 16" mit i9, 32GB RAM und 1 TB SSD. Das ist eigentlich stark genug.
Der alte Magento-Shop läuft lokal gut und ist eigentlich anspruchsvoller von der Leistung, weil über Jahre extrem gewachsen, mit großer DB und unmengen an Anpassungen. Shopware läuft grundsätzlich vom Frontend ok, wobei nach einem Cache leeren die Ladezeiten auch hier sehr schlecht beim 1. Reload sind. Und solche CLI Befehle sind halt alle bei SW bei mir lokal sehr langsam.
Apache 2.4.41, PHP 7.3.13 Web und CLI (512MB memory limit), xDebug 2.9, MySQL 5.7.28 (ebenfalls angepasste Werte)
Hab mir mal das production template installiert. Funktioniert prinzipiell auch. Aber bei bin/build-storefront.sh gibt einen npm Fehler und es wird nie eine neue CSS gebaut. Obwohl bereits npm, node usw. auf dem System installiert ist, scheint das Script nochmal neu installieren zu wollen und kann am Ende jedesmal irgendwelche Pakete nicht finden. Ich schätze mal, mir das SW damit auch noch die Umgebung für meine Node-App zerschossen.
Ja wahrscheinlich. Weiß aber nicht, ob Vagrant mit Parallels zusammen klar kommt. Docker wird ja für Mac nicht empfohlen.
Eigentlich hab ich garnicht die Zeit, da wieder einen Tag rum zubasteln, um eine VM mit dem Image, PHPStorm, xDebug usw. hoffentlich lauffähig zu bekommen. Ich trau der 1 Jahre alten Tutorialseite nicht so ganz, um das mal zu probieren.
Wir hatten früher mal einen Macbook user, der ein Docker von unserem alten Sysadmin für AWS, der eigentlich ständig solche Container kponfiguriert hat, mit allem Drum und Dran eingerichtet bekommen hatte und der war da schon sehr gut drin. am Ende lief es recht langsam und mit etlichen Umwegen und sehr viel Zeitaufwand.
Ich hab mir einmal die Zeit genommen für Docker, muss mich seitdem nicht mehr mit Setup meiner lokalen Maschine rumschlagen. Außerdem, wenn du mehrere Kunden vlt. noch mit verschiedenen Shopware-Versionen betreust kommst du kaum drum herum.
Nein, ich arbeite nur für einen Shop, deswegen war das mit mehreren unabhängigen Umgebungen auch nie wirklich nötig und von großem Vorteil. Aber wie gesagt, Docker wird doch bei Mac eher nicht als performant bezeichnet. Die SW Doku schlägt da Vagrant mit VirtualBox vor. Und natürlich mit dem Development Template und nicht dem Production Template.
Ich hab jetzt sowohl einmal das dev template und einmal das production template installiert. Ich habe meine Plugins ins prod. template rüber kompiert. Diese funktionieren auch. Will ich in meinem Theme Plugin allerdings weitere Templates überschreiben, wird das nie von SW erkannt. Ich habs über
bin/console theme:compile
bin/build-storefront.sh
bin/console cache:clear
probiert. Nie wird mein twig extend geladen. Kopieren ich die Datei in meinen dev Template Installation, funktioniert es sofort. Ich habe in der .env auch schonmal „APP_ENV=dev“ probiert. Hilft auch nichts.
„If you have project specific plugins, place them under custom/static-plugins/{YourPlugin} and require them in your composer.json.“
Ich hatte meine Plugins bisher in custom/plugins gepackt. Was genau ist der Unterschied bei static-plugins? Werde diese immer geladen? Weil mehr als den Einzeler, dass es für projektspezifische Plugins ist, habe ich dazu nicht gefunden.
