@Till Wird es in absehbarer Zeit denn auch eine finale Updateversion geben, in der die ganzen "Probleme" behoben worden sind? Ich muss @mmatecki z. T. recht geben! Ich denke die Mehrzahl der Anwender / Shopbetreiber sind keine Programmierer oder ähnliches. Ich zähle mich ebenfalls dazu. Daher würde ich auch ungern in irgendwelche Dateien eingreifen oder diese abändern. Daher wäre es toll, wenn es eine finale Version gibt und dies auch an ALLE Betreiber kommuniziert wird. Denn so werde ich wohl NOCH nicht updaten. Grüße...
Ca. 20 Artikel lassen sich nicht aufrufen da kommt folgender Fehler: Unexpected error occurred... Gambio\Shop\Modules\ProductListing\App\Data\Shipping\ProductListingShippingModelFactory::createListingItemShipping(): Argument #3 ($image) must be of type string, null given, called in /var/www/vhosts/xxxxxxxxxxx.de/sus-verbindungstechnik/GambioShop/Modules/ProductListing/App/Data/Shipping/ProductListingShippingRepository.php on line 86 Support-Ticket #101682880
Das nächste Update 4.9.2.0 ist in Arbeit und da werden die hier bereits genannten Fehler korrigiert. Es besteht kein Updatezwang. Wer warten kann und die neuen Funktionen nicht benötigt, kann auch noch z.B. bis zum 4.10 Update warten. Wir zwingen keinen Kunden seinen laufenden Shop jetzt unbedingt sofort auf die 4.9.1.0 zu aktualisieren. Wer nicht bereit ist die hier genannten Fehler selber zu prüfen, dem empfehle ich grundsätzlich erstmal stillzuhalten und auf der 4.8.0.2 zu bleiben.
Wenn ich das hier alles lese, graut es mir schon vor dem Update für die Cloudshops. Da können wir leider nicht entscheiden ob wir warten oder loslegen. Oder?
Alles was mit der neun an zweiter Stelle ist, bekommt Ihr nicht in die Cloudshops, ich denke frühestens 4.10.0.0 und bis dahin sollten die Probleme gelöst sein.
Ich habe aktuell die Version v4.6.0.0 mit PHP 7.4. Muss ich beim Update zuerst die PHP-Version ändern und dann erst das Gambio-Update starten? Mein Anbieter stellt mir die PHP-Versionen 8.0, 8.1 und 8.2 zur Verfügung. Darf ich gleich die aktuellste 8.2 nutzen?
Für die Shopversion 4.9.1.0 brauchst du PHP 8 oder besser 8.1. Die Version musst du umstellen nachdem du die Dateien hochgeladen hast. Also der Vorgang sollte sein. Dateien hochladen, PHP Version auf 8.1 umstellen, dann den /gambio_updater/ aufrufen und das Update zu Ende ausführen. Alternativ kannst du auch erst auf die Shopversion 4.8.0.2 aktualisieren, die läuft auch auf PHP 7.4 Dann kannst du auch erst nach dem Update auf PHP 8.1 umstellen. Nur bei 4.9 musst du vor dem Update auf 8.1 umstellen.
https://tracker.gambio-server.net/projects/gxdoc/wiki/Unterstützte_PHP-Versionen @Till (Gambio): Wenn ich da mal keck nachfragen darf: Gibt es einen bestimmten Grund, warum Du "PHP 8.2" an der Stelle nicht erwähnst? Die PHP 8.2 Kompatibilität ist m.E. eine der Haupterrungenschaften des Updates, steht für Zukunftssicherheit. Aber Ihr stellt Euer Licht auffallend unter den Scheffel, was das angeht.
Ja, das war Absicht, da auch in 4.9.1.0 noch nicht garantiert ist, dass alles mit PHP 8.2 kompatibel ist. Es können immer noch Fehler auftreten die unvorhersehbar.
Guten Morgen zusammen, es geht um folgenden Issue welcher in der 4.9.1.0 umgesetzt wurde: https://tracker.gambio-server.net/issues/69909 Als ich mir den Issue nur in der Theorie angesehen hatte ahnte ich was da in der Praxis folgt. Folgendes Szenario: Konfiguration: Filemanager/Dateimanager für Artikel deaktiviert (die gängigste Variante bei unseren Kunden, die Konstellation mit aktiviertem Filemanager habe ich nicht getestet). Vorgehensweise: Testartikel 1 (sagen wir ein Duschgel) anlegen, befüllen, Bild (nennen wir es testbild-1.jpg) hochladen dafür. Da ein neuer ähnlicher Artikel angelegt werden soll wird der Testartikel 1 dafür kopiert ("dupliziert", nicht "verlinkt"). Ist absolut praxisnah da oftmals Texte oder zumindest die Struktur ähnlicher Artikel dadurch übernommen werden soll. Nun wird der kopierte (duplizierte) Artikel nachbearbeitet, umbenannt in "Testartikel 2", Texte angepasst und das Bild getauscht. Man ahnt was nun passiert: Beim Tausch des Bildes von Testartikel 2 wird das Bild von Testartikel 1 vom Server gelöscht! Es findet keinerlei Prüfung statt ob das Bild noch wo in Verwendung ist! Das gelöschte Bild bleibt übrigens bei Testartikel 1 referenziert, d.h. "nur" die Ressource vom Server wird gelöscht. Im Shop hat dies zur Folge dass das Bild zwar noch im HTML (img-Tag, Attribut src) versucht wird geladen zu werden aber es nicht mehr am Server ist -> hässliches Icon mit alt-Text. Aktuell hätte das zur Folge dass ein Kopieren von Artikeln, bei denen man nachträglich auch ein anderes Bild einstellen möchte, nicht möglich ist. Zumindest nicht wenn man die beschriebenen Auswirkungen nicht haben will. Das kann so nicht bleiben. Das wird bei unseren Kunden dazu führen dass wir das Kopieren "verbieten" bzw. sperren müssen. Aktuell würde keiner unserer Kunden in diesem Zustand auch nur an ein Update denken. Maximal die welche die Bilder per Dateimanager auch jetzt schon bewusst so pflegen mit dem Wissen dass ein Bild dadurch mehrfach artikelübergreifend verwendet wird. Wurde denn hier die Konstellation nicht berücksichtigt dass Artikelbilder auch nach wie vor ohne Dateimanager eingestellt werden können. Das machen ca. 99% unser Kunden ohne Dateimanager. Grüße Walter
Woah nee ey… ich dachte, das wäre längst behoben. Tatsächlich kannst Du auch in 4.8 mit ResponsiveFilemanager fröhlich Bilder zu mehreren Artikeln hinzufügen, löschen und sie werden vom Server gelöscht. Gleiches Spiel in 4.9. Bei manchen Bildern wiederum greift die Prüfung, ob das Bild noch anderen Artikeln zugewiesen ist oder ob es physisch entfernt werden darf:
Ja, es ist nicht zu Ende gedacht und deshalb kam am Ende ein Bug raus. Wir haben hier intern den Issue vor Veröffentlichung der 4.9.1.0 durchgelesen und da schon befürchtet dass das Verhalten so sein wird wie es jetzt ist. Heute habe ich es im Grunde nur noch durch einen Praxistest bestätigt. Ja, mit aktviertem Dateimanager (ResponsiveFilemanager) muss man auch ganz genau wissen was man tut. Darum empfehlen wir den nur unseren Kunden bei denen der Dateimanager sinnvoll ist weil Bilder referenziert werden sollen (z.B. bei 30 Artikeln das selbe Bild). Aber dass das nun auch ohne Dateimanager und für das Kopieren Auswirkungen hat macht aktuell ein Kopieren in den meisten Situationen unmöglich weil das Bild ja meist getauscht wird - zumindest bei unseren Kunden. Das muss schlichtweg nochmals überarbeitet werden oder wieder zurück gebaut werden. Grüße Walter
Als Anwender kann ich das bestätigen, mache ich auch so. Für mich ist das auch kein Bug, das ist schon Schildbürger
Genauso machen wir das auch schon seit Jahren. Das wäre ein Fiasko, zumal die Bild-URL von den verschiedenen Marktplätzen gezogen wird. Bitte um Info von Gambio, ob wir nur in dieser Version aufpassen müssen oder ob es beim Update 4.9.2 wieder hergestellt wird.
Ich mache das "neu" Anlegen immer über das kopieren ohne Filemanager. Wenn ich im Artikelnamen nur die Farbe ändern muss, die Artikelnummer ändern, die Sortierreinfolge auf die Zahl der Artikelnummer und eben nur das Hauptbild ändern muss, ist das die effektivste Bearbeitung. Wenn ich jetzt nur noch "neu" Anlegen kann, in dem ich wirklich alles neu anlegen muss, erhöht sich der Aufwand für das Anlegen mal locker um das 10 fache. Ich hoffe das läuft auch noch so auf der Version 4,8.0.2. Das hab ich letzte Woche eingespielt, aber noch keinen Artikel eingepflegt. Würde heißen, das ich wieder auf 4.7.1.2 runter gehen muss. Da lief alles wie gewünscht.
Auch wenn das nicht gerade die Lösung ist, benutze ich immer einen inaktiven Artikel ohne Artikelbild zum Kopieren.
In der 4.8.0.2 funktioniert das noch wie bisher. Das "neue feature" kam erst mit der 4.9.1.0 rein. Auf keinen Fall zurück auf die 4.7.x. Die war ähnlich instabil wie nun die 4.9.1.0. Sind halt doch immer feature-Versionen die mit der ungeraden Zahl an zweiter Stelle. Maximal stabil sind immer die mit gerader Zahl an Stelle 2, also z.B. 4.6.x, 4.8.x, 4.10.x usw. Grüße Walter
Das wie mit der Einführung mit den Kollektionen brauche ich gerade gar nicht. Da es hier auch zu Problemen mit den Filemanager kam (keine Verwendung von gleichen Bildern in unterschiedlichen Kollektionen) mussten wir alle Bilder in den Stammartikel übernehmen und aus den vorherigen Variationsbildern, die ja weg gefallen waren, raus nehmen. Bestehende Artikel mit Variationsbildern wurden mit dem Update (von Gambio ausgeführt) automatisch in Kollektionen umgewandelt. Eine Folge war absolutes Caos im Images Ordner. Ladezeit des Filemanager von 3 Minuten. Der Filemanager greift bei uns nur bei der Content Bearbeitung. Alles andere wird vom lokalen Rechner hochgeladen. Das soll und muss auch so bleiben.