Servus HaeFB. Du brauchst die File nicht sichern, weil ich solche fixe zuerst im Core fixe und dann ins Forum kopiere.
Zum wirklichen Problem. Eventuell würde es reichen, wenn ich im Productdetail menu eintrag die Möglichkeit gebe, keine Produkt ID einzutragen? So machen wir das mit den Kategorien ja auch, da reicht auch eine 0er Kategorie, unter der sich dann alle Kategorien sammeln.
Btw, coooler Avatar 
/j4vm3/libraries/src/Document/PdfDocument.php (line 212)
einfach das JResponse gegen vResponse tauschen. Fix wird in der nächsten Version sein.
Der Tipp von opschwarz? Das mußte ich jetz mal gleich checken. Der Code is noch drin. Ich entferne die Option,...
(5 minuten später)
so is raus. Nicht in allen Sprachdateien, aber in der englischen. Da stand schon seit Jahren drin, das es deprecated, also veraltet ist.
Interessanter Hinweis, Eigentlich muß die ganze Option weg, mit zugehörigen Code. Is sogar in Deutschland verboten, weil Daten auf US servern landen können.
Das habe ich eben geändert. Mit dieser Änderung sollte es auch mit Varianten und Steuer funktionieren. https://forum.virtuemart.net/i…49334.msg533611#msg533611
Ergänzung zum Punkt »Bilderauswählen funktioniert nicht mehr«:
Nach dem Update auf VM 4.0.12 habe ich das gleiche, oben beschriebene Problem, dass ich im Karteireiter »Produktabbildungen« keine Bilder mehr auswählen kann.
Da ich noch mit Joomla! 3.10.11 (PHP 8.0.2) arbeite, gehe ich davon aus, dass es nicht mit dem Joomla! 4-Update sondern mit dem VM 4.0.12-Update zusammenhängt.
Um dieses Problem zu lösen, muss man in der VM-Konfiguration (/administrator/index.php?option=com_virtuemart&view=config) das »Neue Admin Template (Beta)« aktivieren.
Wenn das tatsächlich die finale Lösung sein sollte, wäre es überlegenswert das »(Beta)« beim neuen Admin Template zu streichen, und das Template sogar zum Default zu machen. [Mich hat das »Beta« immer abgeschreckt; persönlich bin ich Arch, aber auf Produktivsystemen eher Debian Stable…]
Das ist tatsächlich noch ein alter falscher Text. Neue Installationen wählen automatisch das neue Template. Das ist bereits so. Das alte Template wird nur noch für j3 Installationen supported.
Da PHP8, das erstemal seit php5 inkompatibel zu vorherigen Versionen ist, wird j3 auch nicht mehr lange in freier Wildbahn anzutreffen sein. Ich habe gerade mein Entwicklungsserver auf php8 geupdatet und werde auch bald nicht mehr auf j3, sondern auf j4.2 entwickeln.
Oder eventuell den Browser Cache leeren. Wir haben jetzt /VM4j3/templates/horme_3/js/jquery-ui.min.js?vmver=1.13.2 nicht mehr 1.9.2
Tja, leider sind einige von uns (ich auch!) zu früh auf VM4 in Produktivsystemen umgestiegen. Mit verantwortlich war sicherlich auch der PHP8-Updatezwang einiger Provider.
Tja, PHP8 ist noch das geringste Problem. Joomla 4.2 hat am meisten Probleme gemacht, betone nicht joomla4.0!, sondern 4.2
Die von Silke beschriebene Preisreduktion auf absolute Beträge, ohne zu überlegen, wie viel Prozent das im Einzelnen sind, ist sicherlich kein Einzelfall, viele Shop-Betreiber machen das so. Bisher konnte das sehr einfach mit dem »Überschreiben«-Feld gelöst werden, welches nach Stefans Ausführungen aber zu anderen Problemen führt.
Ja, wie erläutert, es ist nichts weg. Verwunderlich ist für mich nur, warum die Fehler beim Überschreiben, so selten erwähnt wurden.
Und wäre es in der Zwischenzeit möglich, im alten Admin-Template die Medienverwaltung zu fixen, so dass das Bilderauswählen unter VM4 wieder funktioniert? Dann könnte man mit dem alten Admin-Template normal weiterarbeiten und hätte etwas Zeit gewonnen.
Für mich funktioniert das. Meinst du in j3? oder in j4? Das alte Template ist für j3 und das neue Template für j4
Soviel Diskussion und Halbwissen.
1. Das Feld ist nicht entfernt!
2. Das Feld wird weiterhin angezeigt, wenn etwas drin steht (egal was man einstellt)
3. Einfach die Option "Experten-Preisgestaltungsoptionen anzeigen" aktivieren. In der VM Config unter Tab Preiskonfiguration.
Also, das einfachste ist einfach, die Option im Backend zu aktivieren. Dann ist alles da.
Seit X Jahren das Gleiche Problem. Die meisten User beschweren sich, warum es bei uns soviele Optionen bei den Preisen gibt, also habe ich alle "entfernt", was der Normalo nicht braucht. Dann die Beschwerde, das es weg ist. Dabei habe ich es extra so geschrieben, das es automatisch weiterhin da ist.
Silgra, der Kommentar hier
"- Endpreis
und ein Sale-Preis ist da nicht dabei. "
Das ist doch reine Sprache. Ich kenne im Deutschen keinen Sale-Preis, z.B. Ich verstehe aber was du meinst. Im Englischen haben wir "Cost price", "base price" und "Final price", das wurde übersetzt zu "Selbstkostenpreis", "Basispreis", "Endpreis". Man könnte auch hinschreiben, Einkauf, Netto, Brutto. Ich mache aber die Übersetzung nicht, ich kann nicht alles machen.
"Ich kann auch eine Komplikation des Systems nicht verstehen, da ja immer der jeweilige Endpreis der echte Preis ist."
Also wie Stefan schon erwähnt hat, kann sich dieser Preis eben ändern, einmal durch Varianten und das anderemal durch Rechenregeln. Discounts, welche durch die Kategorie oder die Shoppergruppe kommen. Da kommt der nächste Kunde und kauft gleiche ohne Steuern ein, usw,...
Das einzige was ich hier wirklich als Nichtgedeckten Bedarf sehe, ist die Möglichkeit in VM einen einfachen Preisüberschrieb zu machen. Die Frage ist halt nicht trivial, wie soll der Preisüberschrieb reagieren. Varianten drauf addieren? Ich bin für "ja".
Hier ist der Thread, wo wir diskutieren, was es braucht, damit dieses alte Feature richtig läuft.
https://forum.virtuemart.net/index.php?topic=149334.0
um gottes willen, nicht auf migration. Das ist für vm1 shops!
Media synchronisieren, ERSTES TAB!
Ah was, glei Hand anlegschn.
Eine Idee wäre noch eine Checkbox, welche direkt eine Kategorie zur Rechenregel anlegt. Könnt man auch in der db speichern mit einer extra spalte, so daß die REgel und Kategorie sozusagen darüber "Bescheid" wissen.
Wenn die Änderungen für j4.2 nicht soviel Zeit fressen würden, gäbe es Unzerdirekt bereits im Core.
War eigentlich für September gedacht.
Bitte diese Datei testen. Das .txt am Ende entfernen und ins model Verzeichnis laden \administrator\components\com_virtuemart\models
Wie schauts mit dieser Version aus? https://dev.virtuemart.net/att…32_package_or_extract.zip
Ah ich sehe gerade dein Bild nochmal genauer an. du hast 3 Defaultgruppen und davon 2 published. Dann halt noch umfassender
Damit sollte es einfacher sein, solche Probleme zu reparieren bzw sollte der neue Code verhindern das sowas passieren kann.
Wie passiert sowas? ich behaupte mal kühn der shop ist ein paar Jahre alt, denn früher konnte man da rumfuhrwerken wie man will.
Wobei das nicht mehr so ganz klar ist, worran das wirklich liegt. Denn Joomla hat seine Sprachdateien nicht angepasst. Hmmmm
Ich mein, ich hab sowas schonmal gesehen. Vielleicht eine Idee, nach einem Joomla plugin suchen, und in Joomla den Vm Pfad aufsuchen und dann mit dem etwagigen Plugin hochladen. Dann auf Tools/Werkzeuge und Synchronisiere Medien oder so ausführen. Dann sollten sie in VM sein. Vielleicht gibt es auch etwas für VM direkt. Aber andererseits, ich meine, die meisten Kunden welches sowas hatten, haben das extern aufm Desktop vom hochladen in einer Batch gemacht. imho z.B. mit Irfanview. So mal als Ideen, eine direkte Lösung habe ich leider nicht.
Also ich hab den Fall untersucht. Die Standard Käufergruppen sind auf die id 1 und 2 fixiert. Das heißt speichert man eine Käufergruppe mit id 1 bzw 2 ab, dann bekommen die automatisch immer shoppergroup additional = 0 und eben default 1 bzw default 2.
Default 1 ist die Registrierte Käufergruppe und Default 2 ist die Gastkäufergruppe. Diese 2 Käufergruppen sind speziell. Sie werden nicht dem Kunden fest zugewiesen, wie andere Käufergruppen, sondern dynamisch. Das liegt daran, daß die Gastgruppe in jedem Fall dynamisch sein muß. Der Kunde ist ja Gast und noch zu nichts zugewiesen.
Einfach Lösung, einmal auf die Gruppe mit Id=1 gehen als Name entweder Gast oder COM_VIRTUEMART_SHOPPERGROUP_GUEST speichern. Dann das gleiche mit id=2 und eben Registriert bzw COM_VIRTUEMART_SHOPPERGROUP_GUEST. Die Beschreibung ist auch übersetzt, jeweils einfach mit _TIP, also COM_VIRTUEMART_SHOPPERGROUP_GUEST_TIP.
Dann sollte alles sich von selbst repariert haben. VirtueMart hat so einige "Reperatur" Mechanismen beim speichern. Das kann auch ins Auge gehen. z.B. überprüfe ich gerade, ob vielleicht die update routine sich da eingemischt haben könnte. Aber ich sehe nichts. Ich hab mal in die check routine beim speichern noch dazugefügt,
Damit sollte auch das erledigt sein. Shared ist für Multivendorshops und virtuemart_vendor_id = 1 sorgt dafür, daß es nur der Hauptvendor sieht/editieren kann.
So nu noch zu den anderen "Rätseln" die hier aufgeworfen wurden bzw garnicht angesprochen wurden.
Es gibt da noch diesen Haken "Zusätzliche Käufergruppe", wenn man eben nicht in einer Default Kategorie ist. Und da kommt das dynamische Zuweisen richtig zum Zuge. Man kann damit Käufergruppen so einstellen, daß sie die Zuordnung zur Default Käufergruppe verdrängen. Das ist für B2C plus B2B shop z.B. sehr interessant. z. B. man hat alle Shoppergruppen für B2C Kunden mit den Haken bei "Zusätzliche Käufergruppe". So können Discounts, Shipment, Payments, etc geregelt werden. Btw discounts wie das Quantityplugin brauchen eben Käufergruppen um gut arbeiten zu können. So und nu kommt der Trick, man macht eine Käufergruppe und nennt sie z.B. B2B und ohne den Haken, zusätzliche Käufergruppe. Jetzt bekommt der Kunde nicht mehr die Spezialdefault Käufergruppe zugeteilt, sondern nur noch die Anderen!
Und nu eben der Trick, weisst man einer Bezahlmethode keine Käufergruppe zu, gilt sie für ALLE Käufergruppen. Das ist ein Hauptprinzip in VM, welches sich eigentlich durch die GUI ergibt. ist nichts eingetragen, wird die Bedingung nicht geprüft und gilt folglich FÜR ALLE. Also entferne wieder alle Käufergruppen aus den Bezahl und Versandmethoden.
Wenn man jetzt z.B. nicht will, daß der B2B Kunde eine Versand/Bezahlmethode, etc nicht sehen soll, weil er z.B. was eigenes, besseres bekommt, so weisst man diesen die default Käufergruppengruppen zu (also die 2).'
Tja und die Andere Version ist, denke ich noch viel offensichtlicher, wenn man den B2B Kunden also zusätzliche Käufergruppe konfiguriert. Da ist alles für die B2B Käufergruppe extra sichtbar und alles andere bleibt erhalten. Es fehlt höchstens noch ein Haken der die 2 default Gruppen automatsich setzt, wenn man möchte (wiederrum dynamisch, das wäre interessant).
Da musste ich den Versandarten noch die richtigen Kundengruppen zuordnen.
Raus damit, alte VM Regel, steht weniger drin, weniger Probleme! oder wie oben im Detail erklärt 
Ich wollts einfach nochmal unterstreichen
Frage mich, warum er das immer noch anzeigt: Price settings overriden by shopper groups: -default-
Die Haken sind raus bei Käufergruppenspezifische Preisanzeige
Ah danke, ja. Das war ein Bug, habe ich gleich mal gefixed. Du hast die Sampledaten installiert. Die Abfrage schaute nicht auf den Haken, ob es die extra Config beachten soll, sondern ob was in der extra Config drin steht. Nu wird das veröffentlichte Release doch eine 33er