Hi Stefan,
eigenartig ist auch, dass wenn ich eine PayPal-Testbestellung mache und im PayPal-Vorgang die Zahlung/Bestellung abbreche, kommt ja eine Storno-Mail von der Bestellung, hier ist die Zahlungsbeschreibung dann korrekt enthalten.
Aber gut zu wissen, dann warte ich mal voller Hoffnung auf die stable 4.2.8
Danke dir für die Antwort, sehr schade. 
Ich habe gerade gesehen, das ich auch noch auf die 4.2.6 aus der Membership updaten kann. Das werde ich bei einem Backup noch testen, ob sich hier etwas ändert.
Hallo Zusammen,
ich habe vor kurzem auf die VM Version 4.2.4 geupdatet (es läuft noch Joomla 3.10.12, demnächst sollte es dann einmal auf 4 oder 5 gehievt werden...). Seit dem haben wir ein eigenartiges Phänomen: In den Mail-Bestellbestätigungen steht bei PayPal-Zahlungen nicht mehr der Beschreibungstext der Zahlungsart, sondern nur eine "0". Die Zahlungsart an sich funktoniert aber grundsätzlich. Für PayPal-Zahlungen nutzen wir aktuell noch "VM Payment - PayPal" und nicht das neuere "VM Payment -PayPal Checkout".
Bei allen anderen Zahlungsarten wird alles korrekt in den Bestätigungs-Mails angezeigt, nur PayPal schiesst hier etwas quer.
Hätte wer einen Tipp für mich, woher das kommen könnte?
Grüße
Björn
Kann ich gerne einmal probieren.
Wenn die Fehlermeldung allerdings nicht kritisch sein sollte, dann stelle ich den debug-modus einfach wieder aus bzw. den Error-report auf "Standard", dann wird der Fehler auch nichtmehr angezeigt.
Das Plugin teste ich auf jeden Fall die nächsten Tage einmal.
Vielen Dank schon einmal!
Grüße
Björn
Hallo Stefan, hallo Milbo,
danke für die Erklärung. Beides ist aktiviert:
Ich hoffe das hilft weiter.
Der Fix für die Fehlermeldung bei den selbsterstellten Feldern hat wunderbar funktioniert.
Grüße
Björn
Hallo und vielen Dank für eure Antworten. PHP-Version ist aktuell Version 8.1.24.
Ich probiere die Codeanpassung aus.
Eine Frage hierzu
Zitat
Die deprecated kann man an sich abschalten. Beim ersten fehler geht ohne Trace nichts.
Was ist hier genau mit Trace gemeint? Server-Error logs oder ähnliches?
Ich freu mich auf Rückmeldung.
Hallo zusammen,
ich habe vor kurzem in meiner Testumgebung unseren Shop von J 4.3.2 auf 4.4 und von VM 4.0.22 auf 4.2.4 geupdated.
Seitdem bekomme ich auf den Produktdetailseiten und dem Warenkorb folgenden Fehlercode angezeigt:
Dieser erscheint ganz oben auf der Seite, z.B.: https://update-test.babyonline…aschekorb-reh-detail.html
Beim Warenkorb hatte ich schon die Vermutung, dass es eventuell eine Inkompatblität mit dem genutzen OPC von Rupostel gäbe. Habe hier aber testweise diesen deaktiviert, der Fehler erscheint immernoch.
Im Backend erscheint auf der "Selbsterstelle Felder"-Seite mehrfach diese Fehlermeldung (siehe auch Screenshot anbei):
Ist hierzu irgendetwas bekannt?
Ich würde mich sehr über Hilfe freuen.
Grüße Björn
Hallo zusammen,
ah ok, ich wusste nicht, dass mit Virtuemart 4 kein Menüpunkt auf der obersten Joomla-Admin-Menüebene mehr vorgesehen ist (eigentlich Schade).
Über das Komponenten-Menü funktioniert alles soweit.
Vielen Dank.
Hallo zusammen,
ich habe vor kurzem in meiner Testumgebung meine Installation auf Joomla 4 geupdatet. Soweit hat auch alles grötßenteils funktioniert. Allerdings wird das Virtuemart-Menü nun leider nicht mehr richtig dargestellt:
Leider nicht nur optisch, sondern auch funktionell (lässt sich nichts mehr anklicken/aufklappen). ich hatte schon vermutet, dass da irgendein Menü-Theme nicht richtig installiert ist, habe deshalb das Virtuemart-Paket einfach nochmal neu Installieren mit allen Komponenten, hat aber leider nicht geholfen.
Es wird aktuell VM 4.0.22 und Joomla 4.3.2 genutzt.
Über Hilfe würde ich mich sehr freuen.
Grüße Björn
Hallo Zusammen,
ich würde hier gerne nochmals nachfragen, da ich die "Deaktivierung" der Registrierung ausserhalb des Warenkorbes noch nicht hinbekommen habe.
So wie ich es verstehe müsste ich folgende URLs umleiten:
index.php?option=com_users&lang=de&view=registration
index.php?option=com_users&Itemid=&lang=de&view=registration
index.php?option=com_users&view=registration
Ich habe versucht diese einfach per Redirect in der HTACCESS umzuleiten (einfach auf die Startseite), leider nicht wirkich mit Erfolg:
Redirect 301 /index.php?option=com_users&lang=de&view=registration https://www.startseite.com/
Redirect 301 /index.php?option=com_users&Itemid=&lang=de&view=registration https://www.startseite.com/
Redirect 301 /index.php?option=com_users&view=registration https://www.startseite.com/
Ich lande aber beim Aufruf der URLs leider immernoch in der Registrierung.
Könntet Ihr mir eventuell einen Tipp geben, wie ich die Joomla-Registrierung per HTACCESS blockiere?
Vielen herzlichen Dank im Voraus.
Grüße Björn
Super, vielen Dank!
Das mit den neuen Sprachdateien hat funktioniert, ich kann wieder auf die Produktdetail-Seiten im Backend zugreifen.
Ich wünsche schöne Feiertage und einen guten Start ins neue Jahr.
Grüße Björn
Danke euch,
ich probiere es mit neuen Sprachdateien bzw. mit der von Stefan genannten Erweiterung aus. Ich lasse nur grade noch ein "schnelles" Backup drüber laufen. Ich berichte in Kürze :-).
Grüße Björn
Hallo zusammen,
ich würde das Thema gerne noch einmal hervorkramen. Besagtes Problem beim Aufruf von Produktdetails im Backend habe ich seit der Umstellung auf PHP 8.0. Leider bin ich gezwungen auf PHP 8.0 zu wechseln, da mein Provider PHP 7.4 nicht mehr zur Auswahl anbietet.
Aktuell nutze ich noch Joomla 3 mit VM 3.8.8.
Ich habe nun die Virtuemart Language-Files durchforstet und die oben genannten Ersetzungen durchgeführt (Suchen und ersetzen mit dem Windows Editor). Leider bekomme ich bei den Produktdetails nach wie vor den Fehler.
Ich habe die Sprachdateien "de-DE.com_virtuemart.................", "de-DE.mod_virtuemart_..................." sowie die "de-DE.override.ini" durchsucht. Gleiches mit den vorhandenen en und it Dateien. Oder müssen sämtliche Sprachdateien, nicht nur die VM-spezifischen durchsucht und ersetzt werden?
Oder liegt der Fehler hier eventuell woanders?
Ich freu mich auf Rückmeldung.
Grüße Björn
Vielen herzlichen Dank, da hatte ich wohl Tomaten auf den Augen, dass ich das übersehen habe. 
Grüße Björn
Hallo Zusammen,
ich habe eine Frage bezüglich der Anzeige "Vorrätig" bei den Produktdetails.
Aktuell scheint es so zu sein, dass die Anzahl unter "Vorrätig" erst beim Bestellstaus "shipped" entsprechend reduziert ist. Bestellungen, welche den Status "Confirmed", "Confirmed by Shopper" oder "Pending" haben, scheinen unter der Anzeige "gebuchte, bestellte Produkte" zu finden sein.
Meine Frage wäre hier nun, ob es eine Einstellungsmöglichkeit gibt, welche den Bestand schon beim Bestellstatus "Confirmed", "Confirmed by Shopper" oder "Pending" direkt reduziert und diese nicht erst unter "gebuchte, bestellte Produkte" zuschreibt?
Vielen Dank im Voraus
Grüße Björn
Hallo Stefan,
herzlichen Dank für deine Antwort. Das ist eine gute Idee, da werde ich mich einmal dran versuchen.
Eine Möglichkeit die IP, von welcher die Registreirung aus ging, herauszufinden gibt es nicht?
Grüße Björn
Hallo zusammen,
ich habe die letzten Tage leider sehr viele Spam-Registrierungen in Virtuemart. In der Registrierung wird Recaptcha2 "Ich bin kein Roboter" als Spamschutz genutzt, was aber leider in dieses fällen nicht wirkt. Die Registrierungen kommen ca. alle 4-5 Minuten rein. Das wird doch keiner "von Hand" machen?
Ich nutze aktuell Joomla 3.10.11 und Virtuemart 3.8.8. Dazu den Onepage Checkout von Rupostel. Ich weiss, dass die Virtuemart-Version nicht die neuste ist. Bei einer Migartion zur Version 4 hatte ich zuletzt noch Probleme, daher ist das Update zunächst noch aufgeschoben.
Mein Gedanke war nun die IP zu sperren, von welcher die Registrierungen ausgehen. Allerdings finde ich keine Möglichkeit diese herauszufinden. Ich habe schon in den Log-Dateien geschaut, allerdings kann ich hier keine entsprechende finden. Eventuell schaue ich auch an der flaschen Stelle? Bislang habe ich in ../logs/com_virtuemart.log.php bzw ../logs/error.php geschaut.
Gäbe es eine Möglichkeit die IP-Adresse von einer neuen Registreierung herauszufinden bzw. werden diese überhaupt gelogt?
Über Tipps würde ich mich sehr freuen.
Grüße aus Bergisch Gladbach
Björn
Vielen Dank für die Rückmeldung. Dieser Haken ist wie gesagt nicht gesetzt (siehe Screenshots anbei). Das Eigenartige daran ist halt, dass es bei anderen Accounts soweit funktioniert.
Kundengruppe:
Einstellung Zahlungsart:
Käufer-Einstellung:
Der Haken ist hier nicht gesetzt. Könnte es eventuell sein, dass bei dem betroffenen Kunden irgendwie "unsichtbar" noch die default-Gruppe hinterlegt ist? Ich schau mal in der SQL-Datenbank nach, wobei das wohl eher unwahrscheinlich ist.
Vielen Dank für die Antwort. Der Kunde ist nur in einer Kundengruppe, der Kundengruppe "Kein Rechnungskunde", welche alle Zahlungsarten mit Ausnahme der "nachträglichen Rechnung" hat.
Das ist ja das verwirrende, dass der Kunde anch wie vor diese Zahlungsart nutzen kann. Lege ich einen neuen Testaccount an und gebe diesem nur die Gruppe "Kein Rechnungskunde" kann ich nicht auf Rechnung bestellen. Bislang tritt es nur bei diesem Kunden auf.
Grüße