Wendnet PayPal Modul lässt sich nicht aktivieren

#1

Hallo zusammen,

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:

  1. 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!

  2. 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!)
  3. 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”

  4. /tmp leeren und Backend neu laden

0 Likes

#2

versuchs mal unter service > tools die datei reinzujagen.

0 Likes

#3

Hab ich gemacht :
SQL query (1) : CREATE TABLE IF NOT EXISTS oxwnpaypal (

OXID char(32) NOT NULL DEFAULT ‘’,

OXORDERNR int(11) unsigned NOT NULL DEFAULT ‘0’,
OXORDERID char(32) NOT NULL DEFAULT ‘’,

Affected rows : 1
SQL query (2) : INSERT IGNORE INTO oxpayments (OXID, OXACTIVE, OXDESC, OXADDSUM, OXADDSUMTYPE,
OXADDSUMRULES, OXFROMBONI, OXFROMAMOUNT, OXTOAMOUNT, OXVALDESC, OXCHECKED, OXDESC_1,
`OXVALDESC…

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

Error number : 1064

ist die Meldung und klappt immer noch nicht:-(

0 Likes

#4

Führe die SQL Datei mal im PHPmyAdmin aus, das sollte gehen, dann im Shop die Views aktualisieren.

LG Pasquale

0 Likes

#5

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… :wink:

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!)

0 Likes

#6

@ Mitmacher,

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.

0 Likes

#7

@earlybird: Danke für die Rückmeldung! :slight_smile:

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…

0 Likes

#8

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

0 Likes

#9

@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! :smiley:

0 Likes

#10

Hi,

ich hab mal einen Bug draus gemacht:
https://bugs.oxid-esales.com/view.php?id=5592

Falls es da noch Anmerkungen oder Änderungen gibt, schreibt bitte gern einen Kommentar rein.

Gruß

0 Likes

#11

Prima, danke! Betrifft ja nicht nur mich, aber trotzdem… :slight_smile:

0 Likes