hat jemand Erfahrung mit dem Wendnet PayPal Modul?
Ich habe CE4.6.1, habe das Modul mit viel Schwierigkeiten installiert, aktiviert, Views aktualisiert, tmp gelöscht, im Admin ein und ausgeloggt und habe keinen PayPal log unter bestellungen und kann es nicht aktivieren.
Alles mehrfach mit Installation wiederholt.
Was mir noch unklar ist ist in der Beschreibung der Punkt 3: Zitat:
SQL Erweiterungen manuell istallieren: sql/install_utf8.sql
Kann mir jemand weiterhelfen?
Hier mal der Auszug von der Anleitung:
Installation:
Alle Dateien aus dem Verzeichnis “copy_this” ins Stammverzeichnis des Shops kopieren
(WICHTIG: bei Update auf Version 1.1.0 die Modul-Ordner “translations” und “views” löschen,
und im Modul-Ordner “core” die Datei “oxwnpaypal.php”!)
WICHTIG: nicht vergessen die vendormetadata.php zu kopieren!
Modul aktivieren:
Modul-Menü im Backend öffnen: Erweiterungen / Module / Wendnet-PayPal
Button “Aktivieren” klicken (WICHTIG: Bei Modul-Updates vorher deaktivieren!)
Die Modul-Einstellungen anpassen (HINWEIS: dort die Mail-Adresse Ihres PayPal-Kontos eintragen!)
Nur für OXID 4.6.x:
Entweder einmal das PayPal-Log im Backend aufrufen (“Bestellungen verwalten”),
oder SQL-Erweiterung manuell installieren: “sql/install_utf8.sql” oder “sql/install_latin1.sql”
Error message : You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘UPDATE oxpayments SET OXACTIVE=1 WHERE OXID=‘oxidpaypal’; INSERT IGNORE I’ at line 4
Ja holla,
immer diese Parallel-Diskussionen. Sorry, eben erst gesehen, aber eigentlich hatten wir das alles schon per Mail geregelt (ja, sogar Sylvester gibts Support). Laufen tut es also längst, wenn auch ohne das Log-Menü im Admin, was ein absoluter Sonderfall dieses einen Shops zu sein scheint (und eher Kosmetik ist).
Warum ich aber auch kurz dazu melde, ist dieses Problem beim Installieren des SQL-Setups. Eigentlich passiert dies ja vollautomatisch durchs Modul, nur eben leider nicht in diesem Shop wg. dem Log. Und der Import per Service-Tool ging tatsächlich nicht, da ich dort in einem Text ein “ß” stehen habe. Nun stellt sich die Frage, warum dies Probleme macht und ich sehe es bisher als OXID-Bug. Per PMA gibt es logischerweise keinerlei Probleme mit Sonderzeichen. Es ist auch egal, ob ich ein Latin-1 oder UTF-8 File importiere oder ins Feld einfüge. Erst, wenn man statt “ß” ein “ss” schreibt klappt es. Nun habe ich zwar “lernen” dürfen, dass man “Abschluss” tatsächlich ohne “ß” schreibt und damit auch eine Lösung für den Import parat, aber es geht ja ums Prinßip…
Evtl. trage ich es also in Kürze mal als Bug ein, wenn niemand widerspricht(?).
Grüße vom (ab und zu mitmachenden) Wendnet!
(PS: auch die Views-Aktualisierung übernehmen meine Module automatisch, soweit überhaupt nötig, hier übrigens nicht. Trotzdem natürlich danke für die rege Unterstützung hier!)
Zu Admin Service Tools “SQL ausführen” und “SQL importieren” kann ich auch bestätigen, dass dieser Weg nicht immer funktioniert und ggf. eine "Error message : You have an error in your SQL Syntax …"ausgibt. Das selbe SQL-Statement läuft dann aber in phpMyAdmin einwandfrei.
Bei der Installation Deines PayPal-Moduls gab es jedoch noch nie Probleme, zumal das SQL-Statement automatisch ausgeführt wird, ohne o.g. Tool.
So, und ich habe mir den SQL-Import (OXID-Service-Tool) mal eben etwas genauer angesehen. Hatte nämlich den Verdacht, dass dort einfach nur ein utf8_encode fehlt o.ä., und im Prinzip stimmt dies wohl auch. Allerdings ist es komplizierter zu ändern, da dort ja die einzelnen Chars geparst werden und viel mit strlen() gearbeitet wird. Es bräuchte dann aber mb_strlen() und entsprechende Pendants für alle Stringoperationen. Deswegen nämlich auch die Fehler. Es liegt beim Paypal-Modul nicht direkt am “ß”, wenn man das SQL-Statement nämlich isoliert, kann man es auch importieren. Aber da strlen() wg. “ß” nicht passt, knallen einem die nachfolgenden Statements um die Ohren.
Ich bin nun allerdings verwundert, warum in diesem Service-Tool nicht die vorhandenen OXID-Multibyte-Funktionen genutzt werden, ist das ein Versehen oder Absicht? Das könnte man jedenfalls optimieren und evtl. auch gleich wie in PMA: mit einem Häkchen für UTF-8 (oder charset-selectbox), dann wäre es am flexibelsten. Klar soll das Tool kein PMA ersetzen, aber diese nicht unwichtige “Kleinigkeit” fehlt irgendwie…
jupp, das riecht zwar nicht nach Bug, aber zumindest nach übersehener Weiterentwicklung bzgl. Ute Facht
nachdem dieser Weg für viele User beim Module installieren beschritten werden dürfte, sollte man da evtl. mal was tun - sei es von OXID-Seite oder via github durch die Community
leider bin ich als Programmier-Legastheniker da aussen vor, ich gebs aber mal weiter
@hebsacker: d’accord, sehe ich ähnlich. Und als Programmierer fragte ich mich zuerst, warum es überhaupt so umständlich gelöst wurde, eben mit diesem Parsen der einzelnen Zeichen. Der Mini-Importer aus meinem Paypal-Modul (und anderen) z.b. geht ganz simpel dabei, und trennt das SQL einfach an den Semikolons auf und importiert dann die Statements ohne Probleme.
Aber der Haken sind dann die Fälle, wo in einem Feld-String auch ein “;” vorkommt, logisch. Oder es könnte ja auch in einem Kommentar stehen, hm. Also macht das Parsen schon Sinn, das Problem kenne ich von meinem PHP-Obfuscator. Gerade wenn Strings und/oder Kommentare auch noch verschachtelt sind, versagen irgendwann die regexps oder werden einfach zu komplex.
Ich würde also vorschlagen: “einfach” den Import-Code aus PMA übernehmen (darf man doch, oder), dann ist man wohl auf der sicheren Seite!
