Ich klicke mich gerade so durch den Adminbereich. Bei "Hermes" und dessen Untermenüs kommt diese Fehlermeldung: Unexpected error occurred... Class 'Messages' not found Ein Klick auf "Inhalte" öffnet jetzt sofort den Style Editor Damit fällt die Möglichkeit weg das Theme aus dem Admin heraus ändern zu können ein reines Aufklappen der Untermenüs ist so nicht mehr möglich - an die kommt man nur noch über das aufgeschobene Hover-Feld Das finde ich ungünstig gelöst. Ein Verschieben der Untermenüs, z.B. Content-Manager auf Platz 1 und SE auf Platz 2 macht das aus meiner Sicht Nutzerfreundlicher Bei Mailbeez kommt auch ein Fehler: Unexpected error occurred... Class 'Gambio\Core\Configuration\Models\Write\Configuration' not found
Ahh Gambio is back! Kurze Frage: Von wann ist dasneue PostFinance Modul? Also wann wurde da die letzte Akualisierung von SwissWebXperts gemacht? Ich frage dies, weil ich schon Vorabzugang zu dem Modul erhalten habe und es dann Anfangs nicht richtig funktioniert hat mit dem "PostFinance Checkout Flex" - das Modul war wohl vor allem für den "Checkout All-In-One" ausgelegt. SwisswebXperts hat dann aber schnell geholfen und das Modul geupdatet. Ist diese aktuellste Version mit der Fehlerbehebung auch im neuen Gambio Update? Das wäre, für später dann, sehr wichtig.
Es ist der jüngste gemeinsame Stand mit Swisswebxperts. Die hatten das Modul geschrieben, wir haben das dann gecheckt, dann wurden gemeinsam diverse Sachen geändert und gefixed die Probleme machten, das ist jetzt im Shop. Du hast garantiert nichts neueres.
Das ist bekannt, wir sind in Gesprächen mit Mailbeez, eine Lösung wird aber ziemlich sicher einige Tage dauern.
Habe eben im Mail Verkehr nachgeschaut und die letzten Änderungen an meinem Modul von SwissWeb wurden am 19. Juli 2021 getätigt, seit dem funktioniert das Modul mit dem "Checkout Flex" Vertrag auch.
Vielen Dank an euch beide für die Adleraugen. @Devil @barbara Ich habe für die Fehler die ich reproduzieren konnte und vermeintlich durch das Update entstanden sind soeben bereits diverse Bug-Tickets angelegt, sodass diese voraussichtlich mit der beta2 gelöst werden.
Könnte es sein, dass es Probleme mit den Optionen gibt, wenn vor dem Update keine Attribute installiert waren? Ich war in einem Testshop (kein Supportvertrag) der Eigenschaften hatte, aber in Optionen wird nichts angezeigt. Neue Optionen lassen sich auch nicht anlegen, In den Logs findet sich so etwas: ERROR: An unexpected error occurred while handling an incoming request.
Das gleiche Problem habe ich auch. Zum Testen hatte ich Gestern einen 4.4.0.3 installiert und dort Artikeleigenschaften angelegt. Danach habe ich das Update installiert. In den Varianten werden die Eigenschaften angezeigt, jedoch nicht in den Optionen. Auch nicht bei dem Artikel. Sobald ich eine Option anlegen möchte erscheint die Meldung "Die Änderung wurde gespeichert" zusammen mit "500 - Internal Server Error". Gespeichert wird leider nichts. Ich dachte zuerst, das einem Ordner evtl. die Schreibrechte fehlen. Glaube aber damit liegt ich aber falsch.
Ich weiß, es geht hier allgemein um die 4.5.1.0 Beta1 und nicht konkret um dieses Problem, aber auch ich hatte sehr gehofft, dass die Sache mit den Sonderangeboten gleich mit angegangen wird, wenn die Optionen eingeführt werden. Ich denke fast jeder Shopbertreiber sollte das Problem kennen, und es ist auch nur logisch, wenn Sonderangebot auf SKU-Ebene angelegt werden können. Das Problem an den alten Eigenschaften war eigentlich, dass sie nicht als eigenständiges Produkt vom Shop gesehen wurden, was aber falsch ist. Eine Eigenschaft ist eine SKU, und eine SKU ist ein physisches Produkt mit allen Eigenschaften, die ein Produkt haben kann: Sichtbarkeiten und Preise für verschiedene Kundengruppen, Sonderpreise, Erscheinungsdatum, Ablaufdatum, Gewicht, Größe, Versandkostenzuschlag, EAN, Lagerort (ja, wir haben Lagerorte in Gambio hinterlegt), ab 18 Einschränkung, Zusatzfelder, etc. etc. einfach alles. Jedes mal, wenn man sagt: "Na das brauchen wir nicht, das reicht, wenn es im Stammartikel steht" begeht man einen grundsätzlichen Denkfehler, der einem früher oder später auf die Füße fällt. Es kann zufällig sein, dass ein T-Shirt nur die Eigenschaften "Rot", "Blau" und "Grün" hat, die das gleiche kosten, das gleiche wiegen und alle nicht ab 18 sind. Aber das Leben ist vielfältiger als T-Shirts in unterschiedlichen Farben. Natürlich wäre es schön, wenn man die Möglichkeit hat, dass die Option einfach die meisten Eigenschaften von ihrer Mutter übernimmt, damit es nicht überkompliziert wird. Aber es müsste eben auch die Wahl geben, davon abzuweichen. Das so als Feedback aus der Versandhandels-Praxis.
Hallo Wilken, ich muss mich nun auch mal mit der Umstellung beschäftigen. Bei den Template-Einstellung werden mir u.a. das "Honeygrid (Theme)" und das "Malibu (Theme)" angeboten. Mit welchem kann ich die bestehenden Einstellung vom Shop am Besten übernehmen? Zur Zeit nutze ich das Honeygrid (Template). Vielen Dank schon mal im Voraus.
Das ist nicht falsch. Du denkst das anders als wir, aber deswegen ist deins nicht richtig und unser falsch. Es ist schlicht anders, mit allem was das mit sich bringt. Wir sehen Varianten nicht als eigenständiges Produkt, sondern als Variante eines Produkts. Nein, so sehen wir das nicht. Ich verstehe was du willst, aber das ist nicht das Ziel von Varianten das zu sein. Unterschiedliche Preise und Bestände von Varianten sind über Varianten/Eigenschafftenkombination durchaus abzubilden. Es sind aber eben keine "damit kann man alles tun"-Dinger. Der Scope ist bewusst eingeschränkt, um andere Probleme zu vermeiden. Ein Beispiel: Eine Vervielfachung von Vollprodukten macht jegliche Datenbankproduktabfragen in MySQL grösser. Der Shop würde empfindlich langsam, wenn es da viele von gibt, das hält der (oder besser ein Standardhosting..) nur im überschaubaren Rahmen aus. Eigenschaftenkombinationen haben viel viel weniger Fett. Gibts derzeit nicht. Mit deinem Problem sind wir übrigens in unserem Konzept zu Variantenartikeln auch durch Planungsschritte gegangen und haben überlegt sowas zu bauen. Ein wichtiger zu lösender Punkt war dabei zum Beispiel auch wie wir Leute hindern viele Vollproduktvarianten anzulegen, eben weil wir die nicht in Masse haben wollen, weil das dann schiefgeht. Dazu haben wir einige Gedanken und Pfade als Zukunftsoption im Papier. Wir haben uns aber nun erstmal entschieden andere Dinge zu machen, die wir wichtiger fanden und haben das hinten angestellt. Wichtiger war uns zum Beispiel was für den Anschluss von Wawis zu tun, diverse Altlasten loszuwerden, ein paar Logikleichen rauszukriegen, möglichst niemanden aus dem Bestand durch Updates vor sehr viel Arbeit zu stellen,...
Ich habe das in mehreren Installationen versucht zu reproduzieren, kam allerdings nicht auf das selbe Ergebnis. Bei einer Neuinstallation von beispielsweise GX 4.4.0.3 sind die Attribute regulär erstmal deaktiviert. Wenn ich hier nun das SP 4.5.0.1 beta1 installiere, wurden die bestehenden Attribute automatisch in Optionen umgewandelt. Hier konnte ich nach dem Update dann auch problemlos weitere Optionen hinzufügen oder bearbeiten. Ein wenig stutzig macht es mich dennoch, da sowohl du, als auch @Nohly das Problem geschildert haben. Daher werde ich hier noch weiter nachforschen. Die von dir genannte Funktion wäre nur für Eigenschaften, beziehungsweise nun Varianten. Eine Möglichkeit um dies bei den Optionen (Attributen) abzustellen besteht derzeit nicht. Diese werden angezeigt, insofern eine Artikel-Nr. angegeben wurde. Da diese Angabe in der beta1 aktuell leider Pflicht ist, wird diese somit immer angezeigt. Dies sollte allerdings nicht die Norm sein und wird noch angepasst. Gerne kann ich dies allerdings generell als Wunsch aufnehmen. Hierzu habe ich soeben noch weitere Bug-Tickets angelegt, die ebenfalls dieses Thema betreffen, danke für den Hinweis.
Bestehende Attribute s Dann hast Du aber Attribute installiert und eingerichtet, vor dem Update (sonst könnten keine Attriubte umgewandelt werden )
Ich meinte natürlich die bestehenden Eigenschaften (Größe und Farbe) wurden in die korrespondierenden Optionen umgewandelt und daraus wurden dann die Varianten bei bestehenden Artikeln erzeugt.
Die Varianten waren auch im Artikel zu sehen, nur an die Optionen kommt man nicht, die werden nicht angezeigt
Du willst mir irgendwie wiedersprechen, aber eigentlich sind wir gar nicht anderer Meinung. Ich sage nur, dass eine solche Variante ein pysisches Objekt ist, das in einer Plastikkiste im Regal liegt. Was dieses Objekt von dem Objekt in der benachbarten Kiste unterscheidet, mit dem es zu einem Mutterprodukt zusammengruppiert ist, wisst ihr nicht. Es ist ein eigenständiges Produkt, in dem Sinne, dass der Kunde dieses Produkt kauft, und nicht das andere. Es geht mir nur darum, den Scope nicht wieder so einzuschränken, wie es bisher bei den Eigenschaften der Fall war. Wie man es dreht und wendet, das war einfach keine gute Entscheidung, wie das gemacht wurde. Das zeigt das einfache Beispiel mit dem Abverkauf einzelner Varianten, worauf ich hier geantwortet habe, nachdrücklich. Und es ist bei weitem nicht das einzige Problem. Ich kann die Optionen gerade nicht selbst ausprobieren, ich kann nur in die API-Dokumentation schauen. Und da sehe ich auf Anhieb keine Kundengruppenpreise und keine Zusatzfelder. Wenn wenigstens der Preis kein double sondern ein array wäre und es ein einzigen Einträg mit "additional values" gäbe, wo ich noch ein array mit Zusatzkram (wie gesagt: Lagerort) übertragen könnte, wäre das schon ein Riesenunterschied. Das kann doch nicht die Datenbank-Last verdoppeln, oder?
Ich glaube wir lagern das mit den Möglichkeiten der Varianten aus das geht hier weiter: (Link nur für registrierte Nutzer sichtbar.)