ich habe nun die Version 7.20 vom Plugin Checkout installiert, und es geht wieder,
danke für deine Hilfe!
Das ist nun aber wieder eine alte Version vom 23. April 2024? Aktuell wäre tatsächlich die 7.25 vom 19. August 2024. Eigenartig!
Ich würde mich mit diesem Problem mal an Jumbo von VirtuePlanet wenden.
Hallo Josef,
ich habe mir deine Seite mal angesehen. Wie es scheint, gibt es ein Problem mit dem Adressformular. Aus irgend einem Grund funktioniert es nicht zusammen mit dem "VP One Page Checkout for VirtueMart" von VirtuePlanet.
Ich würde es mal deaktivieren um zu schauen, wie VirtueMart von Haus aus mit einer Bestellung umgeht.
Hallo,
genaues kann ich leider daraus nicht erlesen. Kann es aber sein, dass Du eine Erweiterung in VirtueMart oder im Joomla nutzt, welche nicht Kompatibel ist?
Eventuell beißt sie sich auch nur mit der PHP-Version. Ich würde testweise mal runtergehen auf 8.2.
das Verzeichnis "...../JR-shop/", hast Du das als Unterverzeichnis angelegt? Liegt unter diesesm deine komplette Installation?
Hast Du mal den VM-Debug modus aktiviert, um zu schauen, welcher Fehler angezeigt wird?
Hallo Josef,
willkommen in unserem Forum. Um dir besser helfen zu können, müsstest Du uns noch mehr Informationen liefern.
1. Von welcher Version aus hast Du das Update gemacht?
2. Hat es in der Vorversion funktioniert?
3. Kaufen mit welcher Bezahlmethode?
4. Joomla Version?
5. PHP Version?
Hallo Stefan,
ja ich denke, dass die "Matrosen in Lederhosen" auch dort gern gehört werden. 
Deine Denke "Internetgedanken" kann ich sehr gut verstehen. Daher meinte ebenfalls jemand im Joomla-Forum, "warum sollte ein Provider auch einen ganzen IP-Block sperren, immerhin laufen ja auch andere Dienstleistungen über diese IP's".
Ich meinem speziellen Fall ist es aber nun so, dass wenn ich diese IP-Blöcke wieder freigebe, sich nach ca. 4-6 Stunden meine "com_virtuemart.log.php " mit der besagten Meldung auf einige MB in nur wenigen Stunden aufbläst. Daher würde ich mich freuen, wenn wir eine Lösung finden könnten, diese Abfrage irgendwie vorher abzufangen, oder den Grund für diese zu beheben.
Vielleicht können wir diesen Beitrag auch in die Kategorie "Virtuemart Sicherheit" verschieben, um etwas mehr Aufmerksamkeit zu bekommen. 
Beste Grüße Faro
Im Grunde ist der Server dafür verantwortlich, bzw. sollte der Hoster den Server so einrichten, dass IP-Adressen bei Massenaufrufen nur temporär gesperrt werden.
Auf den meisten Linux-Servern laufen diese Tools sowieso.
Hallo Stefan,
danke für deine Antwort. Ich werde das mal mit meinem Hoster besprechen, warum manchmal auch über Monate hinweg ganze IP-Bereiche z.B. aus Indonesien, welche bereits in anderen Listen als Spam gemeldet wurden, dennoch durchkommen.
P.S. Ich denke nicht, dass ich aus Indonsien Bestellungen bekomme. 
(Kleiner Scherz)
Beste Grüße Faro
Guten Morgen in die Runde,
wie genau führt ihr Euer VM-Update durch? Ich habe öfter Probleme, dass ich trotz Membership das Update nicht über das Backend anstoßen kann. Ich denke, dass der VM-Server nicht immer diese lange Downloadnummer erkennt, welche ich irgendwo in der VM-Config eingebunden habe. 
Ist es generell das gleiche, ob ich ein Update über das Backend mache, oder ob ich mir die aktuelle Version über meinen VM-Account ziehe und diese dann ganz nornal unter "Erweiterungen - Installieren" drüberinstalliere?
Danke der Faro
Hallo Stefan,
wie ich schon schrieb, kann ich in den Server Logs dazu nichts passendes finden, oder ich verstehe nicht, sie korrekt aszulesen. Generell denke ich ebenfalls, dass hier versucht wird, Sicherheitslücken zu finden.
Vor gut zwei Monaten hatte ich eine sehr unschöne Attacke auf mein Shopsystem. Dabei wurden die besagten Logeinträge im Sekundentakt generiert. Zeitgleich wurde der Server mit Anfragen über "Frage zum Produkt stellen" regelrecht bombadiert, sodass 100te E-Mails in wenigen Stunden an mich gesendet worden waren und die "com_virtuemart.log.php" sich innerhalb von 24 Stunden auf gute 40 bis 60 MB füllte.
Natürlich wurde ich daraufhin von meinem Provider aufgrund der Mailattacken an mich, und zu hoher Serverlast vorerst gesperrt!
Erst nach der deaktivierung der Funktion: "Frage zum Produkt stellen" und das Sperren der IP-Adress-Blöcke:
herrschte wieder Ruhe. Zwei dieser IP-Blöcke führen nach England und einer nach Indonesien. Nach der Sperrung der IP-Adressen wurden für eine Woche lang auch keine neuen Logeinträge mehr in die "com_virtuemart.log.php " geschrieben.
Es wäre sehr schön, wenn wir zusammen eine Lösung finden könnten, diese besagten Anfragen vorher abzugreifen. Leider stecke ich dabei technisch nicht so drin wie Du. Daher brauche ich bitte professionelle Hilfe von Dir (Euch).
Danke und beste Grüße der Faro
- ich habe die com_virtuemart.log.php gelöscht und alle möglichen Aktionen (User und Admin) durchgezogen.
- eine neue com_virtuemart.log.php wurde bisher nicht erzeugt.
- Vielleicht einfach ignorieren?
Bei mir ist ebenfalls seit gestern ab ca. 23:25 Uhr Ruhe. Wie ich jedoch über die Monate hinweg weiß, dauert es manchmal 1 bis 2 Tage, bis wieder Einträge in die com_virtuemart.log.php geschrieben werden. Du kannst es bei Dir ja auch mal beobachten.
Hallo HaeFB,
na da bin ich wenigstens nicht der Einzige, bei dem diese Art Logeinträge generiert werden!
An alten und überflüssigen VM-Dateien liegt es nicht, diese habe ich alle entfernt. Wie Du vielleicht in meinem Post #2 gelesen hast, tauchte das Problem erstmals nach dem Wechsel von PHP 7.4 auf 8.1 auf und ist seither geblieben.
Ich weiß bis heute nicht, wer oder was diese Logeinträge generiert. Es gibt nicht einmal in den Serverlogs Einträge mit Datum und Uhzeit zu diesen geschriebenen VM-Errorlogs. Der normale Besuch und Kauf im Shop generiert diese Einträge nicht, wie ich in meinem Beitrag #9 bereits beschrieben hatte.
Schau doch mal bitte in dein administrator/logs Verzeichnis, ob es dort auch eine "error.php" gibt, und wenn ja, was dort mit eingetragen wurde?
Ja, es funktioniert alles!
Guten Tag,
ja, wie erwartet, haben nun andere Bots die Arbeit übernommen, da wieder Error-Logeinträge geschrieben werden. Bitte schaut doch mal in Eure "com.virtuemart.log.php", eventuell bemerkt der eine oder andere die Einträge ja gar nicht, da nicht jeder den Site-Guard laufen hat. Es wäre schön, wenn wir zusammen das Problem beheben könnten.
Kleiner Zwischenbericht.
Eigenartigerweise werden seit heute früh 7:00 Uhr keine virtuemart.log Dateien mehr erzeugt!
Da über den Tag zwei Bestellungen über PayPal eingingen und ich selber zu testzwecken lediglich ein paar Produkte über das Frontend mir angesehen habe, und auch dabei keine Logdateien erzeugt wurden, gehe ich fest davon aus, dass es sich um Bot zugriffe handelt, welche ja auch meistens nachts stattfinden. (Im normalen Shopbetrieb: Käufer - Shopbesuch - Warenkorb - Kaufabschluss, werden definitiv diese virtuemart.log Dateien nicht erzeugt).
Warum nun seit heute früh 7:00 Uhr diese(r) Bot(s) nicht mehr zugreift, kann ich mir nur so erklären, dass er eventuell beim Provider, auch durch andere Zugriffe auffällig war, und somit auf eine Sperrliste gesetzt wurde.
Bleibt nun abzuwarten, ob es so bleibt, oder ob ein anderer Bot seine Arbeit übernimmt.......
Die Frage bleibt jedoch, was oder wie genau fragt ein Bot bezugnehment auf die Beispieleinträge im Spiler aus Post #6, ab?
Hallo Stefan,
ich habe es heute Nacht noch in meinem Testshop getestet. Soweit lief alles ohne Probleme. Seit heute früh habe ich auch meinen Live-Shop auf PHP 8.3 umgestellt. 
P.S. Ich habe es umgestellt, da ich dachte, dass dies mein Problem im Post löst. Hat es aber nicht.
Hallo Stefan,
leider kann ich nicht nachvollziehen, was im Shop aufgerufen wird oder wurde. Auch den Joomla-Debug hatte ich schon aktiviert. Es wird aber nichts gemeldet.
Ich lebe mit diesem Problem nun gut über einem Jahr. Es kommen jeden Tag ca 20 bis 40 dieser Logeinträge. Manchmal ist auch für drei bis vier Tage Ruhe. Daher musste ich schon bei meinem Hoster für den Siteguard meine Benachrichtgungsmail auf zweimal Täglich einstellen, damit ich nicht 20 bis 40 Einzelmails am Tag bekomme.
Natürlich sollte man das nicht tun, da jede Veränderung, welche der Siteguard feststellt sofort erkannt werden sollte. Durch dieses genannte VM-Problem habe ich aber keine andere Wahl.
Ich hatte das Problem auch schon mit Max besprochen, auch Max konnte dieses Problem nicht reproduzieren. Es muss doch eine Möglichkeit geben, anhand der Einträge in der Logdatei herauszufinden, was da wie und wo auf oder abgerufen wird. diese Logeinträge sind seit über einem Jahr immer ein und die selben.
Gruß Faro
Guten Morgen in die Runde,
gibt es jemanden, der VirtueMart schon unter PHP 8.3 nutzt? Funktioniert alles, oder gibt es irgendwelche Probleme?
Danke der Faro
Hallo Gemeinde,
ich muss dieses Thema #1 aus Mai 2023 nochmal aufmachen. Ich habe bisher keine Lösung für das Problem gefunden. Ich bekommen die folgenden und immer gleichen Einträge in die com.virtuemart.log.php täglich geschrieben. Ich habe keine Ahnung, was hier passiert und wie ich das Problem beheben kann.
Was wird hier genau abgefragt, bzw. was kann hier nicht aufgerufen werden? Auch in den Serverlogs finde ich zu den genannten Zeiten keine Einträge.
Ich habe bereits von Max den Tipp bekommen, mal alle Verzeichnisse, Ordner und Dateien per FTP gegen die aktuellen zu ersetzen, da meine VM-Erstinstallation aus 2012 ist. Das hat zwar funktioniert, jedoch auch keine Lösung ergeben.
Bin für jeden Tipp dankbar
Beste Grüße Faro
Hallo Stefan,
danke für's weiterleiten. Der Amazon- Checkout ist für mich schon sehr wichtig, da es momentan für meine Kunden die einzige Möglichkeit ist, auch mit Kreditkarte zu Zahlen.
Danke nochmal und beste Grüße
Faro
Das Adressformular ist nun wieder aufrufbar. Nun jedoch habe ich leider zwei andere Fehler.
Das Eingabefeld für Land und Region wird nun doppelt angezeigt:
Guten Tag,
dieses Problem konnte ich durch deaktivieren der "Use jQuery chosen for dropdowns in FE" in der Konfiguration lösen.
Jedoch gibt es wie es scheint, ein Problem mit Amazon Checkout in J4 und J5. Ich habe von Jumbo von VirtuePlanet nach dem Zusenden von meinem CallStack folgende Info erhalten.
„The template has no relation with the Amazon Pay error. The Amazon pay plugin has some obsolete codes, which makes it incompatible with Joomla 4 and 5. You can fix the current error by making the following change.“
Das bedeutet, dass AmazonPay bereits in den letzten 6 Monaten, in welchen ich J4 nutzte, nicht mehr funktionierte und somit auch nicht in J5 funktioniert.
Nun habe ich den neuen Code, welchen ich von Jumbo freundlicherweise erhalten habe, in die "amazon.php" in Zeile 1579 bis 1588 eingespielt.
Normalerweise sollten alle Käuferdaten vom Amazon- Plugin automatisch geladen werden. Leider werde ich im Amazon checkout aufgefordert, die Adressdaten einzugeben, was ich auch gemacht habe:
Wenn ich nun wieder auf AmazonPay klicke, bekomme ich diesen Hinweis angezeigt:
Wie es aussieht, gibt es hier ein größeres Problem mit dem Amazon- Checkout. Hat jemand ein ähnliches Problem mit AmazonPay und kann mir weiterhelfen?
Danke der Faro
