Nach Update J!3.5.1 geht Bezahlarten basierend auf Standard-Plugin nicht mehr durch

  • Habe ein Projekt migriert, von J!2.5.28 auf J!3.5.1 und VM 2.6.22 auf VM3.0.14. Migration war an sich erfolgreich. Allerdings funktioniert die Bezahlung per Bank-Transerer / Nachnahme (also plugin payment standard) nicht - PayPal geht demgegenüber. Erhalte beim abschließenden Absenden der Bestellung eine Meldung "Error: 0 - Invalid address: Max Mustermann".


    Nun habe ich mal nachgeforscht, wann dieser Fehler auftritt - leider erhält man weder über die Error-Log noch über das VM- oder J!-Debug dazu eine Fehlermeldung: Dieser Fehler tritt scheinbar nur und erst auf unter J!3.5.1, solange ich im Projekt noch J!3.4.8 verwende geht es (also bis zum vorm Update und auch nach einem Restore wieder, einziger Unterschied J!Version).


    Habe mal in den Quelltexten herumgestochert. Der Abbruch bzw. die Fehlerseite wird vermutl. erzeugt, weil das Absenden der Vendor-Mail über shopfunctionsf::sendVmMail() fehlert. Warum genau, die Kenntnis fehlt mir noch? Evtl. weil zw. den Joomla-Versionen $recipient unterschiedlich als array bzw. als string erwartet wird?


    Bin jedenfalls total entnervt, weil bis zu diesen spärlichen Erkenntnissen schon 3 Tage Fehlersuche vergangen sind, die mir keiner bezahlt. Brauche also dringend eine Lösung.


    Mal anders gefragt: Hat jemand eine Installation mit J3.5.1 und VM3.0.14 bei der der Checkout mit Standard-Bezahlg. funktioniert? Evtl. liegt es ja zusätzl. an irgend einer meiner Konfig.?

  • Danke Faro, Du bist mein Held. Danke auch für die schnelle Hilfe. Das hat mir vermutl. weitere Stunden erspart.


    Interessant: Wenn man so dicht vor der Lösung steht, dann kann man auch die richtigen Fragen stellen. Hatte schon seit Tagen gesucht, aber vor meinem Post und dann mit meinen erkämpften Erkenntnissen nicht mehr.


    Ich bin aber auch jetzt überrascht, dass so ein Bug, so tiefenentspannt bearbeitet wird. Wie lange ist 3.5.1? draußen? Problem schon bekannt und noch immer nicht gefixt ... Da lässt man noch weitere Shopbetreiber mit dem J!Update in diese Falle tappen. Das ist der noch gut dran, dem der Fehler gleich auffällt. Andere wundern sich nur über die ausbleibenden Umsätze, weil irgend eine Bezahlart still und heimlich bockt. Klar, dass das nicht VM-Core-Problem ist sondern im Joomla Core-Funktionen geändert wurden. Echt ärgerlich. Evtl. sollte man für solche Fälle ein Frühwarnsystem einführen.

  • Als Joomla-Bug würde ich es nicht bezeichnen. Ein CMS entwickelt sich immer weiter. Wie man lesen konnte, wurden ab Version J 3.5.1 Änderungen am phpMailer vorgenommen. Diese hatten zur Folge, dass diverse Extensions nicht mehr richtig funktionierten.
    Außer VM wurde mir bekannt, dass auch Gästebücher, Kontaktformulare u.a. von der Änderung im Joomla-Core beroffen waren.
    Diese gilt es nun zu Aktualisieren


    Gruß Faro

  • Richtig, per Definition kein Bug. Aber wenn sich im Core mal eben eine so zentrale Funktion ändert, dann sollte man damit behutsam verfahren, so dass Erweiterungsentwickler überhaupt 'ne Chance haben mit Updates darauf zu reagieren. So entspannt Wie Du kann ich das leider nicht sehen: "Diese gilt es nun zu aktualisieren".


    Es wäre doch kein Problem gewesen, abzufragen ob die Parameter evtl. noch alt als string oder schon neu als Array übergeben werden. Das Mindeste wäre im "Alt-Fall" eine sinnvolle(!) Fehlerausgabe. Mit "Error: 0 - Invalid Address" kann man doch wirklich nichts anfangen.


    Nach den vielen Sicherheitslücken / -patches von J! über den Jahreswechsel 15/16 ist man nun geneigt gewesen zeitnah zu updaten. Wie ich nun erleben durfte, ist auch das ein Risiko - vermutl. sogar größer als gehackt zu werden ;-). Damit macht sich J! keine Fans.


    Ich arbeite nun seit 9 Jahren mit J!+VM tgl. und progr. auch. Für mich als Dienstleister ist es ein Horror, Tage über unerwarteten Problemen in Kundenprojekten zu hocken die ich nicht mal in Rg. stellen kann.


    Ich weiß von Max, dass es zw. VM- und J!-Core-Team schon ein wenig knirscht. Sicher auch aus solchen Ereignissen begründet. Wir sollten dann wenigstens als VM-Gemeinde geeignet darauf reagieren - evtl. mit o. vorgeschlagenen Frühwarnsystem - z.B. als Mailingliste o. wie auch immer.

  • Einen Fallback in Joomla zu schreiben, der beides zulässt, und unter den Debug-Meldungen dann eine Warnung ausgegeben hätte, hätte sicher fünf bis zehn Minuten mehr Zeit gekostet. Damit hätte man ein wenig Zeit gehabt, aber war leider nicht. Gab auch Joomla-Interne, die da intern vorher schon auf die Rückwärtskompatibilität hingewiesen haben.


    Die neue VM-Version sollte dazu eigentlich am Freitag herauskommen, aber leider lag noch etwas mit der ACL im Argen, deshalb hat es plötzlich gehakt. Eine neue Version ist aber sicher sehr bald zu erwarten. Damit sind dann auch die Joomla-Änderungen, die ich sehr wohl als provozierten Bug sehe, verarztet. Verantwortungsbewusste Programmierer bauen in solchen Fällen einen Fallback ein. Als gutes Bespiel kann man da das Vorgehen von Max beschreiben. VM besitzt inzwischen "unendlich viele" Fallbacks.


    So short
    Stefan


    Noch ein PS-Spruch für an die Wand: Wer sein System nicht immer zuerst auf einer Testspiegelung aktualisiert, spart am Ende keine Zeit.

  • Ja Stefan, das trifft's. Aber mal sehen ob mein Hinweis/Bitte sich auf die Zukunft auswirkt. Ich glaube, es wird eher so "entspannt" weitergehen.


    Im übrigen mache ich ich eine Migration nicht am lebenden Patienten. Allerdings war ich bisher der Auffassung, dass ein kleines Joomla- oder VM-Update schon mal am lebenden Projekt riskiert werden darf. Dafür gibt's ja nen Backups.


    Ein Crash war auch nicht der Grund meines Ärgers (hätte es aber sein können), sondern die 3 Tage Fehlersuche resultierend aus einer nachlässigen Programmierg., die dürftige Abstimmung zw. J! und Extensions(VM) und mangelnde Inform. in Rtg. Anwender/Entwickler.


    Euch respektive faro noch mal Dank für Eure Posts