Jump to content
xt:Commerce Community Forum

66mausi

Members
  • Content Count

    58
  • Joined

  • Last visited

  1. ... das habe ich ja auch gemacht, aber danach hieß es dann, dass der Code wegen falscher PHP Version nicht entcodiert werden kann. Habe jetzt wieder die V.1.2.3 installiert.
  2. "Das neue Paypal Plugin braucht PHP 5.4. Ich hatte das Standard 5.3 installiert." ... das Modul gibt es aber auch für PHP 5.2, nur leider ist das mit PHP 5.3 codiert ...
  3. ps. eine Umstellung auf PHP 5.3 (temporäre) brachte keinen Erfolg.
  4. Hallo, habe mir das neue PayPal Plugin 2.3 für PHP 5.2 herruntergeladen. Nach der Installation kommt ein Hinweis beim Bestellvorgang (SYSTEM_DEBUG=true), dass die IonCube Version nicht korrekt sei. Ok, geupated und nun kommt "class.paypal.php was encoded with the PHP 5.3 ionCube Encoder and requires PHP 5.3 to be installed. in Unknown on line 0". Öhh? Weiß jemand dazu mehr? lga
  5. ... mit dem JS-Fehler scheint es nichts zu tun haben. Hatte gerade keinen JS-Fehler und trotzdem keinen Bestellstatus.Habe mir die generierten Quelltexte angeschaut. Der komplette Block mit den Bestellstatus fehlt. Der Seitenfooter wird wieder ganz normal generiert. Also scheint es kein Abbruch der Ausgabe zu sein. Merkwürdig nur, dass ab dann das ganze Backend streikt bzw. bei anderen Seiten wie z.B. der System-Log-Seite eine weiße Seite ausgegeben wird.
  6. ... habe gerade das selbe Problem bei 4.016. Plötzlich macht eine Bestellung Probleme und es gibt einen JS-Fehler in der ext-all.js Z. 28 und TypeError in Z.10. ga
  7. ... scheint hiermit verwandt zu sein: http://www.xt-commerce.com/forum/xt-commerce-4-0-adminbereich/106803-die-letzte-seite-des-kategorie-listings-backend-wird-nicht-angezeigt.html Gab es bei Dir eine Lösung?
  8. Hi, habe bei einem Kunden das selbe Problem. Es tritt sporadisch auf. Habe schon alles mögliche versucht. DB Optimierung, MySQL und PHP-Logs angelegt, php.ini optimiert. Bisher alles ohne Erfolg. Wenn es wenigstens einen Fehlerhinweis gäbe. Grüße, Andreas
  9. ... und schon wieder passiert! Nach der Preisänderung bei einem Artikel hatten alle zig tausend Artikel diesen als Master eingetragen. Ich trage das jetzt in die Bugbase ein. Die Beschreibungsfelder haben keinerlei Sonderzeichen enthalten.
  10. ... da nur ich den Shop betreue und die Zugriffe habe, muss es durch Veyton selber passiert sein. Ich selber war aber seit Tagen nicht mehr dran und der Kunde hat Null Ahnung von den Dingen. Und falls es ein "Hack"-Versuch war - würde das Ergebnis sicherlich anders aussehen. Was ich mit meinem SQL-Statement zeigen wollte war, dass es halt keine "Schleife" benötigt. Ein falsch zusammengesetzter SQL-String kann dazu führen das alle Artikel plötzlich einen bestimmten Wert erhalten. Ist mir in einer eigenen Anwendung selbst schon passiert. Je nachdem welche Filter eingestellt wurden, wurde die WHERE-Anweisung hinten nicht angesetzt und das Ergebnis erhielt Werte die nicht hätten auftauchen dürfen. Das gleiche kann ja durch (unabsichtliche/absichtliche) Übergabe eines Strings passieren, der nicht gefiltert wurde (SQL-Injection).
  11. ... ich meinte natürlich mit Name die Artikelnummer. Hast mich aber falsch verstanden. Ich meinte, dass Veyton das selbstständig (!) gemacht hat und nicht ich. Die SQL-Anweisung war nur als Beispiel gedacht was da passiert sein muss. Der Kunde hat ganz normal Artikel im Backend eingepflegt als plötzlich alle zig tausend Artikel einen Mastereintrag hatten. Das läßt sich durch das Backend ja nicht machen (also mal eben tausenden Artikeln einen Master zuordnen), daher vermute ich einen Scriptfehler bzw. das Eingaben von Sonderzeichen oder eines '; z.B. zur fehlerhaften SQL-Anweisung führten.
  12. Hallo! Gestern rief mich ein Kunde ganz aufgeregt an. Fast alle Artikel seines Ultimateshop 4.016 waren nicht mehr sichtbar. Alle Artikel hatten einen bestimmten Masterartikel als Master augeführt. D.h. statt UPDATE xt_products SET products_master_model = 'Artikelnummer' WHERE products_id=xxx muss ein UPDATE xt_products SET products_master_model = 'Artikelnummer' ausgeführt worden sein. Bleibt die Frage nur wie? Angeblich wurden keine Sonderzeichen verwendet, die den SQL-Befehl zerpflückt haben könnten. Ein bekannter Bug? Der Firefox ist wohl hin und wieder mal wegen seiner "tollen" JavaScript-Performance abgestürzt. Das wird aber eher unwahrscheinlich der Grund gewesen sein. ga
  13. ... ok, einfach mal ins Handbuch schauen: cronjob.php?api=csv_export&id=dfbd3cab740eaed4fc01aec136dd8801 statt "feed_id"
  14. Hallo! Gibt es inzwischen eine Lösung für das Ausführen des Exports via Cronjob? Die Hookpoints scheinen alle OK zu sein und sind aktiv. Aber Veyton kann anscheinend nix mit der Feed-ID anfangen und wirft daher eine allgemeine Fehlerseite raus "Liebe Kundin, lieber Kunde. ...". Beim Standard-Export funktioniert das mit dem Cronjob prima ... Grüße, Andreas
  15. ... merkwürdig. Der Kunde hat nun einen neuen Artikel angelegt und nun erscheinen wieder alle Artikel!
×
×
  • Create New...