Jump to content
xt:Commerce Community Forum

66mausi

Members
  • Content Count

    58
  • Joined

  • Last visited

Everything posted by 66mausi

  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!
  16. Hallo! Gab es inzwischen hierzu eine Lösung? Wir haben exakt das selbe Problem! lga
  17. Problem ist: Das Veyton anscheinend längere Namen zu läßt, es aber dann bei Bildzurodnung bei Artikeln zu Problemen kommt - Bild wird nicht angezeigt ("Broken Image").
  18. ... da ich gerade vor dem selben Problem stand - hier die Lösung, welche ich aber noch nicht ausprobiert habe: http://www.tinymce.com/wiki.php/tinymce_faq#Paths.2FURLs_are_incorrect.2C_I_want_absolute.2Frelative_URLs.3F bzw. unter /conf/conf_tinymce.php ... dort den Pfad anpassen.
  19. Hat jemand schon Erfahrungen mit der neuen - Kaufversion - dieses Plugins? Bestellungen bearbeiten | Plugins | xt:Commerce Veyton | Onlineshop | BuI Hinsche GmbH
  20. ... würde mich auch interessieren. {$tpl_url_path} scheint es z.B. leider nicht zu geben (weiße Seite nach dem Absenden).
  21. Gibt es jetzt eigentlich eine Lösung für einen Produktlink nach dem Schema für Content-Links ({product prod_id=123...) ?
  22. ... ich kenne das von vielen anderen Projekten, dass man sich als Reporter für einen Bugtracker wie z.B. Mantis (Mantis Bug Tracker) anmelden kann. Ich nutze das relativ oft, da Fehler nur beseitigt werden können, wenn sie jemand meldet (entwickle selber Software).
  23. Hat sich erledigt! Hatte nach "Statistik" gesucht und nicht nach "Bestellstatistik" und daher nicht gesehen, dass der Fehler bekannt war. Ich dachte die Patchtes werden immer direkt in das aktuelle Download-Archiv eingebaut ...
  24. ... im Prinzip ist das ja schon OK, von wegen Shop auf der einen Seite und die WaWi auf der anderen Seite. So ist das bei anderen Herstellern auch. Nur sollte man dann Konsequent sein, also das Plugin gar nicht mehr supporten. So weiß man nicht woran man dran ist. Oft ist ja so, dass ein Kunde etwas möchte, was man dann eben schnell anrecherchiert, anbietet und dann nen Reinfall erlebt weil etwas wegen Bugs nicht funktioniert, die dann noch nicht einmal beseitigt werden. Wirft wirklich kein gutes Licht. Der Kunde macht da kein Unterschied. Für Ihn ist xt:Commerce dann Mist. Was das Bugfixen und das Einfügen von Verbesserungen ansonsten betrifft, hinken die Entwickler wirklich oft hinter her bzw. es tut sich nicht viel (weiß allerdings nicht, wie das ist wenn ich mich am Bugreporting beteilige). Ich steige nur nicht um, weil ich keine Zeit für ein anderes System habe (ok, evtl. sollte ich die Zeit des Ärgerns lieber dafür verwenden). Aber andere Systeme haben auch ihre Macken, denke ich mir dann immer. Was ich aber echt zugute halten muss, ist, dass der Support was Lizenzierung etc. betrifft 100% OK, nett und sehr schnell ist! LOB! ga
×
×
  • Create New...