Beiträge von Babelfisch

Zitat von r23

Keine gute Idee - sondern belastet nur unnötig den Entwickler. Es reicht wirklich aus, wenn man bei einem Open Source Projekt den Entwickler auf ein Problem 1x EINMAL hinweist.

Es ging um ein Ticket beim Support und nicht um ein Issue bei GitHub. Und das kann sehr wohl sinnvoll sein, da der Support dann schnell mitbekommt, dass das Problem größer ist.

Zitat von r23

Und wenn die erste Fehlerbeschreibung schrootig fehlerhaft ist - kann man die Bug-Meldung durch weitere Details erweitern.

Ticket, nicht Issue! Und so „schrottig“ war meine Fehlerbeschreibung gar nicht.

Zitat von r23

Und bevor man irgendwelche Änderungen durch UPDATES an seinem WooCommerce durchführt ist es sinnvoll, diese in einer Testumgebung _vorher_ auf Fehlerfreiheit zu prüfen... wriklich - erleichtert das leben ungemein.

Habe ich und ich habe sogar eine Bestellung über Amazon Pay getestet. Dass das Plugin alle anderen Zahlungsweisen blockiert, hatte ich leider nicht auf dem Schirm. Nicht jeder testet (vermutlich wie du) wirklich alle Funktionen vom Shop bei einem Minor-Update eines Plugins.

Zitat von r23

Amazon Pay verwendet kein Mensch!

Echt jetzt? Da berichten dir zwei Shop-Betreiber, dass Amazon Pay von den Kunden sehr gut angenommen wird und du kommst mit einer blöden Statistik?

Du kannst natürlich gerne auf die Statistik vertrauen und Potential verschenken. Ich teste so was lieber mit meinen eigenen Kunden und vertraue da keiner Statistik.

Wenn du in deinem PHP-Script zwischen jeder Aktion (also bspw. zwischen jedem Produkt-POST) folgende Funktion aufruft, kannst du den Timeout normalerweise umgehen und das Script beliebig lange laufen lassen:

[FONT=Courier New]set_time_limit(0);[/FONT]

Gruß

Der WooCommerce Support hat das Problem mittlerweile an die Entwickler weitergegeben und will sich melden, wenn sie mehr wissen.

Danke für die Bestätigung! Kannst du bei woocommerce.com bitte auch noch ein Ticket aufmachen? Je mehr Tickets kommen, umso schneller sollte es gefixed werden.

Das Amazon Pay so selten eingesetzt wird, kann ich mir fast nicht vorstellen, zumal es bei uns aus dem Stand zur häufigsten Zahlungsweise geworden ist und PayPal, Stripe und Vorkasse überholt hat.

Aber egal, ein Ticket hatte ich gestern erstellt und mal schauen was da passiert. Meine Erfahrung ist halt, dass nicht sofort reproduzierbare Probleme gerne liegengelassen werden – bei kostenlose Plugin sowieso.

Vielleicht meldet sich ja trotzdem noch jemand hier, der Amazon Pay mit dem offiziellen Plugin einsetzt und kann das Problem bestätigen oder halt nicht. Sollte das Ticket was bringen, schreibe ich das hier natürlich auch.

Wenn dich das Problem nicht interessiert und du keine Lösung hast, dann musst du auch nicht antworten. Niemand zwingt doch dazu.

Wir alle wissen genau, wie toll die Tickets bei WooCommerce bearbeitet werden und das man ohne Verifizierung mit einer „nackigen“ Installation ohne weitere Plugins und Themes kaum ernstgenommen wird. Genau das ist aber bei Zahlungsplugins schwer machbar, weshalb es mir schon mal helfen würde, wenn irgendjemand hier sagen würde a) bei mir funktioniert alles auch nach dem Update oder b) ich habe das gleiche Problem.

Deshalb stelle ich auch mal Fragen hier im Forum.

Support zum Amazon Pay Plugin. Das habe ich schon mehrfach versucht aber dafür fühlt sich irgendwie niemand zuständig.

Außerdem wollte ich auch erst sowieso mal hier nachfragen, weil das Plugin ja sicherlich nicht so selten im Einsatz ist.

Seite dem gestrigen Update des WooCommerce Amazon Pay Gateway Plugins auf Version 1.10.0 blockiert das Plugin alle anderen Zahlungsweisen. Zahlt man nicht über Amazon Pay und wählt stattdessen eine andere Zahlungsweise wie PayPal oder Stripe aus, passiert beim Klicken auf den Kaufen-Button nichts und in der Browser-Konsole kommt nur diese Meldung:

Invalid parameters passed to OffAmazonPayments.initConfirmationFlow. | Widgets.js?ver=1.10.0:45

Vorher kommen in der Konsole auch noch ein paar Warnungen aber eigentlich keine Fehlermeldungen. Der Fehler hängt auf jeden Fall mit dem Plugin-Update zusammen. Gestern hat noch alles funktioniert.

Da ich nicht wirklich weiß, wer für das Plugin überhaupt zuständig ist und wo man Fehler melden kann, wollte ich erst mal hier nachfragen, ob jemand schon eine Lösung dafür hat. Ich konnte Amazon erst mal nur deaktivieren.

WP 5.2.1
WC 3.6.4

BTW: Wenn ich in WooCommerce bei Mehrwertsteuer → Steuer Optionen testweise den Haken vor „Steuern auf der Ebene der Zwischensumme runden, statt pro Position zu runden“ setze, rechnet er schon im Warenkorb falsch. Drei unterschiedliche Produkte á 2,50 Euro sind im Warenkorb dann 7,51 Euro.

Der Fehler tritt auch mit deaktiviertem Germanized (sowie alle relevanten Plugins ebenfalls deaktiviert) auf. Scheint also wirklich von WooCommerce zu kommen.

Moin Moin,

Irgendwie gibt es seit WooCommerce 3.6 wieder einen Rundungsfehler bei der Berechnung der Zwischensumme. Meine Artikel sind alle als Brutto-Preise angegeben und die Zwischensumme ist deshalb auch Brutto.

Bestellt man nun bspw. zwei unterschiedliche Artikel á 15,00 Euro, wird im Warenkorb noch die richtige Zwischensumme von 30,00 Euro angezeigt. Nach dem Kauf sieht es jedoch sowohl in den Bestelldetails, der Bestätigungsmail und der Rechnung so aus:

Artikel 1: 15,00 Euro
Artikel 2: 15,00 Euro
Zwischensumme: 29,99 Euro
Gesamt: 30,00 Euro
inkl. 19% MwSt. 4,78 €

Gesamt stimmt wieder aber die Zwischensumme hat immer einen oder zwei Cent Rundungsfehler und das sieht doch ziemlich unprofessionell aus.

Hat jemand ’ne Idee, ob sich da an der Konfiguration was geändert hat oder ob es nur ein Bug ist? Hängt definitiv entweder mit dem Update auf WC 3.6 oder evtl. auch dem von Germanized zusammen. Vor den letzten Updates hatte noch alles gepasst.

Wordpress: 5.1.1
WooCommerce: 3.6.2
Germanized (Pro): 2.2.11 (1.9.12)

Zitat von Edi

Ja, da war ich zu direkt, und dafür entschuldige ich mich bei Dir.

Kein Problem, angenommen.

Zitat von Edi

Die Diskussion hat mich allerdings einmal mehr darin bestätigt, dass WooCommerce keine ernstzunehmende Shop-Software ist. Wer sie verwendet, entschuldige: sollte das Know-how einer Fachperson haben, um Probleme selber beheben zu können. Andernfalls muss in Kauf genommen werden, dass der Shop während Tagen oder über Wochen nicht oder nur mangehalft läuft.

Da hast du sicherlich nicht unrecht aber wenn der Shop einmal damit läuft und man verschiedene eigene Erweiterungen dazu entwickelt hat, dann ist ein Wechsel auch nicht so leicht. Außerdem finde ich gerade die REST-API von WooCommerce wirklich super und einen ähnlichen Funktionsumfang habe ich bei meiner Evaluierung letztes Jahr bei anderen in Frage kommenden Shop-Systemen nicht gefunden.

Externe Plugins nutze ich sowieso nur extrem sparsam, da auf längere Sicht viele Plugins mehr Probleme machen als sie lösen.

Zitat von r23

kein Grund zur Entschuldigung. Wer vor dem Posten und den erneuten Anschieben noch nicht einmal in die Bugliste schaut - darf ruhig was auf den Deckel bekommen. Geiz ist halt Geil und man verzichtet auf den Fachmann und nervt mit bekannten Probelem halt nur rum.

Wie konnte ich nur so dumm sein und den Bug „Implement locking mechanism for data updates to work around race conditions“ nicht auf Anhieb als mein Problem erkennen? Tzzzz…

Zitat von Edi

Jetzt soll das Problem sowieso plötzlich ein Bug sein.

Soll nicht nur, ist sogar ein Bug und soll mit 3.3.0 gefixed werden:

https://github.com/woocommerce/woocommerce/issues/15780

Und Mike Jolley rät übrigens bis zum Fix das gleiche wie chezzone:

https://github.com/woocommerce/woocommerce/issues/15951

Danke noch mal an chezzone!

Zitat von Edi

Eine Shop-Software, bei der über Monate ein solcher Bug nicht gefixt würde, wäre eine Katastrophe.

Katastrophe ist zu hart aber vorkommen sollte das wirklich nicht, zumal PayPal in der Entwickler-Doku explizit vor diesem Problem warnt.

Zitat von Edi

Lassen wir es. Mir ist es egal, wenn Dein Shop nicht funktioniert. Und andern ist es vielleicht eine Warnung.

Vielleicht nimmst aber auch du es dir mal zu Herzen und gehst dein Gegenüber nicht gleich so an und unterstellst fehlendes Fachwissen. Muss ja nicht sein.

Ich frage mich, was du hier im Forum überhaupt suchst, wenn du bei einer Frage sowieso gleich zu irgendwelchem Fachpersonal rätst. Zumal es sich hier ja sogar sehr wahrscheinlich um einen Bug von WooCommerce handelt, da laut PayPal der gleichzeitige Einsatz von IPN und PDT sehr wohl erlaubt ist und es mit WooCommerce 2 auch über ein Jahr lang funktioniert hat.

Aber egal, deine Einschätzung meines Fachwissens ist mir herzlich egal und mit chezzones Hilfe habe ich einen Workaround gefunden, bis sich Automattic mal meldet.

Zitat von chezzone

Du nutzt PDT und IPN zeitgleich, die kommen sich anscheinend in die Quere! Zwei Systeme die auf verschiedenen Wegen das gleiche bewirken sollen. Deaktiviere am besten PDT indem du in den PayPal Einstellungen den "Indentitätstoken" rausnimmst. Ich denke, dass sich das Problem damit erledigen sollte!

Stimmt, das werde ich mal versuchen und das sollte das Problem lösen. Ich verstehe nur nicht, wie es überhaupt zu beiden Zahlungsbenachrichtigungen kommen kann. PayPal sollte doch immer nur auf einem Weg benachrichtigen und vor WC 3 ist mir so was auch nie untergekommen.

Edi: Nur weil ich hier ab und an mal hier was anfrage, muss du nicht gleich mein Fachwissen beurteilen und unseren Shop als Hobby bezeichnen. Wenn das für dich so ein einfaches Problem war, dann hättest du auch gleich einen Lösungsvorschlag bringen können.

Mein WooCommerce-Support? Wenn du damit Automattic meinst, die haben sich noch nicht auf meine Anfrage gemeldet.

Ansonsten betreibe ich unseren Shop selber und garantiert nicht als Hobby. Für dieses Problem habe ich jedoch noch keine Lösung gefunden und ich hatte halt gehofft, dass hier vielleicht jemand schon mal darüber gestoßen ist und evtl. sogar schon eine Lösung hat.

Hmm, keine eine Idee dazu? Habe diesen Fehler jetzt schon mehrmals gehabt und das macht langsam echt Probleme.

Grrrr, ein vergessener Codeschnipsel in der functions.php des Child Theme enthielt noch ein date_default_timezone_set('Europe/Berlin') :roll:

Wieder einmal zeigt sich, dass das Problem vor dem Rechner sitzt. Danke für die Hilfe und Geduld!

Zitat von Edi

Kann/sollte zwar nicht daran liegen, aber versuche es einmal mit 7.0 oder 5.6.

Die 7.0.20 habe ich schon probiert und 5.6 kann ich wegen anderer Scripte unter der Domain nicht testen, da die PHP 7 brauchen. Unter 7.0 ist die Zeit jedenfalls immer noch falsch und PHP 5.6 werde ich mal versuchen lokal zu testen.

Nachtrag noch zur Frage von Edi:

PHP Version ist 7.1.6
Server ist ein Managed Server bei DomainFactory