Beiträge von StefanSTS

    Suche im Paypal Plugin im zweiten Reiter die Einstellung


    -> Beschränken der Statusänderung über IPN auf 'erfolgreich'

    (Der Name der Einstellung ist sprachlich ein wenig ungewöhnlich.)


    Dort dann Status P "In Bearbeitung" auswählen, so dass nur vom Status P auf Status C geschaltet werden kann.

    Das sollte helfen.

    Die Einstellung war mir aus dem Gedächtnis gerutscht. Das ist zwar im Grunde keine Lösung für den Bug, dass vom gleichen Status auf den gleichen Status aktualisiert werden kann, aber der Zweck sollte erfüllt werden.


    Grüße

    Stefan

    Servus,


    die 4.0.8 ist draußen, richtig.

    Die Werbetrommel wird meistens nach ein bis zwei, drei Tagen gerührt bis der Newsletter durch mehrere Revisionen gelaufen ist, und die ersten die Version ohne Update-Benachrichtigung gefunden haben.


    Wir haben die letzen Wochen intensiv getestet und die Bugs sind jetzt soweit raus. In freier Wildbahn finden sich meistens dann doch noch einige Kleinigkeiten.

    Wahrscheichlich werde ich diese Version bald meinen Kunden empfehlen, denen ich bisher empfohlen habe, auf 3.8.9 zu bleiben.

    Die Testsysteme werden diese und nächste Woche heiß laufen.


    Es gab in letzter Minute noch ein "Feature" zum Laden der Kategorien. Das sieht in meinen wenigen Tests gut aus, allerdings sollten dort alle Early Adopters noch einmal in einer Testinstallation drüber schauen. Nur zur Vorsicht.


    Um meine Zuversicht auszudrücken, hab ich auch gerade mein deutsches Sprachpaket aktualisiert und veröffentlicht. Da müssen allerdings noch ein paar schönere Formulierungen hinein. Dann wird es ein neues Sprachpaket geben.


    Grüße

    Stefan

    Die Logs, die in VM verlinkt sind, sind interne Fehler-Logs von VM, Paypal usw., da geht es im Grunde nur um Fehler oder wichtige Infos.


    Alle Server-Anfragen sind in den Server Logs zu finden, die man je nach Provider in unterschiedlichen Bereichen findet.

    Am besten beim Provider in der Dokumentation schauen.


    Die IP zu blockieren ist aber nicht hilfreich, das macht eigentlich ein gut eingerichteter Server schon, wenn es mehrere Versuche von der gleichen IP gibt.

    Die Spamer benutzen aber heutzutage einen ganzen IP-Pool, da hilft blockieren nicht wirklich.

    Man sollte Spam-Registrierungen durch Logik im Registrierungsprozess verhindern.

    Wenn bei den Spamern immer nur die rote Erfolglos-Leuchte angeht, dann gehen die woanders hin.


    Grüße

    Stefan

    Hallo Björn,


    die Registrierungen kommen meistens über Joomla.


    Ich empfehle, die Joomla-Registrierung über die .htaccess zu blockieren und nur die VirtueMart-Registrierung oder die Registrierung über den Checkout zuzulassen.

    Wichtig: Im Plugin "VM Framework Loader during Plugin Updates" den Redirect von Joomla zur VM Registrierung ausschalten.

    Damit fällt ein Großteil der Anmeldungen weg.


    Persönlich benutze ich kein Captcha für die Registrierung. Die Registrierung lasse ich nur zu, wenn etwas im Warenkorb liegt. Das können bisher nur Menschen umgehen. Damit sind bei mir Spam-Anmeldungen in den letzten Jahren bei abgerundet Null.


    Grüße

    Stefan

    Ehrlich gesagt, habe ich nicht nachgeschaut, weil ich die Dateien direkt aus dem VM-Repository nehme und die von Transifex produzierten Dateien, die vom VM-Projekt verwendet werden, nicht getestet habe. Ich habe leider nicht für alles Zeit.


    Der ganze Ablauf über Transifex mit hin- und herkonvertieren hat schon öfter einmal Fehler verursacht. Das war der Grund, warum ich die Sprachpakete für meine Kunden angelegt hatte. So habe ich immer die originalen en-GB daneben und kann die Dateien schnell vergleichen.

    Meine Sprachpakete erscheinen dann immer in den Joomla-Updates, wenn neue Versionen zur Verfügung stehen. Möglicherweise gibt es diese automatische Update-Version ja auch demnächst von VM direkt.

    Um es für alle Sprachen zu automatisieren, oder von der Transifex-Praxis wegzugehen, was zwei verschiedene Dinge sind, wäre aber einiges an Arbeit nötig und im Moment gibt es mit Joomla 4 und PHP 8.x Arbeit im VM-Core ohne Ende.


    Transifex ist eine tolle Erfindung, um Übersetzungen in vielen Sprachen von unterschiedlichen Teams zu erstellen, aber es ist halt auch komplexer als einfach nur Text-Dateien im Repository zu bearbeiten.


    Falls jemand die Sprachpakete mit den Fehlern mit meinen vergleichen möchte, immer ran an den Speck, VM ist ein Community-Projekt.


    Grüße

    Stefan

    Hallo Kurt,


    beim Helix Ultimate bin ich leider raus.

    Meiner Meinung nach ist SP einer der Code-schlechtesten Page Builder, die aktuell auf dem Markt sind.
    Ich habe vor Jahren davor gewarnt, dieses komplexe System einzusetzen und tue das auch weiterhin.


    Für einen neuen Shop kann ich nur empfehlen, die Wahl noch einmal zu überdenken.

    Wenn es schon ein Page Builder sein muss, dann wenigstens einer wie Yootheme Pro, der vernünftiges HTML produziert, wobei ich den selbst auch nicht einsetze. Ich habe mit Yootheme Pro jedoch einige Male arbeiten müssen. Zumindest die Programmierung sieht dort sauber aus und er produziert gutes HTML. Nicht 20-fache Verschachtelungen für den Text-Inhalt einer Box. Das war ein krasser Vergleich im Gegensatz zu Yootheme Pro. SP 20 Verschachtelungen, Yootheme 8 Verschachtelungen für die gleiche Box.


    Am besten ist ein eigenes Template oder so etwas wie die Templates von VirtuePlanet, die sich wenigstens an die Joomla- und VirtueMart-Regeln halten und einfach zu bearbeiten sind, weil das Override-System mit Sinn angewendet wird.


    Wie man merkt, kocht mein Blut beim SP hoch. Für irgendwelche einfachen Schrebergärtenseiten mag das nett sein, wenn man sich die Seite zusamemnklicken möchte, aber für einen Shop, der über Jahre zuverlässig laufen soll, und der auch ordentliche Werte in den Web Vitals erzielen soll, ist das in meinen Augen keine gute Wahl.


    Grüße

    Stefan

    Servus,


    vielleicht hilft es, die Liste einzusehen, in der die unterschiedlichen Status (Mz.) der Bestellung zu sehen sind.
    Im Backend in der Bestellung oben rechts.
    Wird da zwischen Bestätigt und einem anderen Status hin- und hergeschaltet?
    Evtl. die Uhrzeit der Statuswechsel mit den Error Logs vergleichen.


    STS

    Du hast da scheinbar mehrere Standard-Default-Gruppen.


    Die Gruppen mit ID 5 und ID 8 sind irgendwie dazu gekommen.

    Ich würde, erst im Testshop, die beiden mit ID 1 und ID2 aktivieren und dann in der Datenbank die 5 und 8 rauswerfen.


    Da könnte ein nicht angezeigter Fehler auftreten, wenn zwei Standardgruppen default vorhanden sind, und dann wird evtl. der Code zur Einordnung in die Gruppe nicht ausgeführt. Oder es wird versucht, in die deaktivierte Gruppe zu verschieben.


    Grüße

    Stefan

    Hallo Helmut,


    das ist bisserl kompliziert.

    Die registrierten Kunden werden keiner Gruppe zugewiesen,

    --> und damit fallen sie in die Gruppe default.


    Im Grunde heißt das, die registrierten Kunden werden als in der Gruppe default behandelt, wenn keine Gruppe zugewiesen ist.


    Ich habe die überwiegenden Shops auf 3.8.9.10473 laufen. Bisher habe ich dazu noch keine solcher Fehlermeldungen bekommen.


    Weil's "plötzlich" einfach auftaucht:

    Ist es sicher, dass der Shop noch auf PHP 7.4 läuft, oder ist da evtl. eine automatische Umstellung auf PHP 8 gewesen?


    Wenn die Fehlermeldungen in Joomla (im Testshop) auf maximum gestellt werden, gibt es dann irgendwelche Meldungen?


    Grüße

    Stefan