Beiträge von Mario_b

*Bump* dieser Bug ist immernoch drin

Stimmt, customweb kann ich auch empfehlen was Zahlungssysteme angeht, ich habe jetzt ein paarmal für Kunden mit denen zutun gehabt, ging hauptsächlich um Saferpay dabei, hat sehr gut geklappt.

*bump*

Ich musste auch grad feststellen, dass ich bei einer frischen 2.5.13 Version des Shops das hier beschriebene Problem noch besteht.

Ich habe für Kunden in 2-3 com:seo Shops eingebaut, ist ne Weile her, aber ich meine mich daran zu erinnern, dass es fummelig war wegen irgendwelcher Javascriptprobleme auf dem 1Pagescheckout . Geklappt hat es aber letztendlich.

ist eigentlich relativ simpel zu reproduzieren, Voraussetzung ist aber, dass nicht nur eine Sprache aktiv ist sondern z.B: auch englisch , siehe hier mein Beispiel von gerade eben auf der v2ultimate.de Demo (aktueller 2.5.11)

Um es im Demoshop nachzuvollziehen hab ich nur folgendes gemacht :

Sprache englisch aktiviert (ist im Demoshop default auf aus )
Boxenmanager aufrufen
Neue Box anlegen , dabei ist es sogar egal ob ich nur `nen deutschen Titel oder auch die englischen Felder befülle
Box nochmal aufrufen und irgendwas ändern , z.B. die Position - speichern
Danach ist die Box (mindestens) Doppelt und der englische Teil ist auch wieder weg...

B2C Shop

Vorkasse (mir Rabatt) (wird selten)
Sepa LS bis 250€ (wird kaum genutzt)
Rechnung - bis 200€ Warenwert "selbst", wenn der Warenwert darüber liegt wird Billsafe verwendet um das Ausfallrisiko zu minimieren - die meisten Kunden wählen Rechnung
Paypal - wird häufig genutzt
Sofortüberweisung (wird kaum noch genutzt)
Kreditkarten via Payone - wird selten genutzt, eigentlich fast nur von ausländischen Kunden
Amazon Payments - wird sehr häufig genutzt

Altoba : Naja, normalerweise würd ich sagen "bei den anderen wirst du mit der Anforderung auch nicht glücklich/fündig" , also dem Variantensystem, wobei ich in dem Fall mit "die anderen" nur modified und gambio meine. Was modified/com:seo/gambio angeht, hat com:seo trotz allem die Nase meiner Meinung nach weit vorne, auch wenn natürlich bei weitem nicht alles rund läuft und vieles noch zu wünschen übrig lässt, aber naja der Einäugige unter den Blinden eben

Wenn es aber keinen zwingenden Grund gibt bei der xt-basis zu bleiben und du auf das Variantensystem angewiesen bist, ist ein Wechsel vielleicht wirklich das beste. Selbst wenn com:seo `ne Attributmatrix einführt, wird es vermutlich in der Folge noch `n paar Monate dauern bis der Teil bugfrei ist, durch Feedback der Anwender einfach bedienbar gemacht wurde und richtig rund läuft. Bei einem System was das Feature schon Länger mitbringt, sollte diese Wartezeit dann wegfallen.

Uh das ist wirklich ziemlich übel wenn es sich tatsächlich so wie beschrieben verhält, wundert mich , dass es noch nicht größere Wellen schlägt (bei modified z.B. ist davon noch keine Rede) - was mich interessieren würde: Welche Shopsysteme waren betroffen, weist du da waas Jotest ?

Hm, tatsächlich - bei dir fehlt laut Quelltext das create_account Formular auf der Loginseite, wenn du mal nach <form> suchst siehst du was ich meine... ich hab das Update noch nirgends gemacht, kann daher an der Stelle leider nicht sagen ob`s daran liegt oder was anderes da mit reinspielt :-/

FWTGMBH : mach mal deinen Newsticker aus, dieser verursacht einen Javascriptfehler der vermutlich die Ursache für die zerschossene Loginseite ist, dann sollten sich deine Kudnen zumindest wieder registrieren können solange bis webdesign Erfurt das gefixt hat.

Ist bei mir auch der Fall , ich habe jetzt zwar ein Kundenkonto auf commerce:seo , aber alle Bestellungen fehlen (habe immer nur auf seo-template.de eingekauft).

Möglicherweise habe ich auch mal ein Konto auf commerce:seo frühergehabt, hab es aber wie gesagt nie verwendet zum bestellen.

Mit besten Grüßen!

Mario

Nein, das ist technisch nicht machbar, vom Klick auf den Button im Browser des Users bekommt der Shop nichts mit, das findet rein auf der User-Seite statt ohne jegliche Rückmeldung.

Ah ok, ja alles klar - kann ich gut verstehen und nachvollziehen!

Ich bin ja nun auch kein Freund von Shopgate, aber in diesem Fall hab ich `nen Kunden der voll drauf steht - "Du, ich habe bei denen sogar meine eigene APP, EINE APP!!!"

*hmpf*... ohne Worte

Die includes/external/shopgate/plugin.php verursacht einen Fehler bei der Aktualisierung einer Bestellung

Fatal error: require_once(): Failed opening required '/kunden/xxxxxxxxxxxx/webseiten/v2next/inc/xtc_db_prepare_input.inc.php' (include_path='.:/usr/local/lib/php') in /kunden/xxxxxxxxxxxxxx/webseiten/v2next/includes/external/shopgate/plugin.php on line 32

die xtc_db_prepare_input.inc.php ist ja nun in die cseo_db.inc.php gewandert, nach der Anpassung der Zeile verschwindet der Fehler.

Auf einem anderen Blatt steht aber m.E. noch folgendes: im Shopgate Backend selbst kann man den Pfad der Schnittstelle nicht ändern, dort geht ausschliesslich domain.tld/shopgate/api.php - in der aktuellen Version scheint ihr aber die api.php nach includes/external/shopgate/api.php verschoben zu haben, dadurch lässt sich nun keine Verbindung zu shopgate mehr herstellen.

Beste Grüße!

Mario

ach komm, der Dezember ist doch noch nicht rum - ich rechne fest mit dem Update morgen, so um 23:50 herum...

Grundsätzlich halte ich die Supportgebühr für `ne berechtigte/gute Sache , kann der Qualität des Shops nur zuträglich sein.

Schaut man sich die beiden Extreme an (modified, keine Supportgebühr, dafür Stillstand) und Gambio (149€ pro Jahr + laufend Updates die kaum ein Gambioshopbetreiber selber durchführt sondern kostenpflichtig durchführen lässt), wäre es schön wenn com:seo am Ende irgendwo dazwischenliegt.

Mich würde aber interessieren wie es dann genau gehandhabt werden soll, falls ihr euch da schon was im Detail überlegt habt würde ich mich über die Info hier freuen.

doch, zu sehen in der VariationWert.php und der Variation.php - die werden offenbar jedesmal stumpf neu angelegt, also kein Update

Was auch ganz interessant ist : Normalerweise hast du ja die Artikelmerkmale ansich nur einmal, sagen wir "Größe" und eben die Optionswerte "S" , "M" , "XL" dazu - mit JTL scheint man dann aber auch das Artikelmerkmal "Größe" 3 mal zu haben....

Hi allerseits,

ich steh hier grad vor einem Problem, und zwar überschreibt der JTL Connector beim Artikelabgleich regelmäßig die cseo-eigenen Erweiterungen am Attributsystem, genauer die dort hinterlegten Grundpreisangaben.

Beispiel : Im Shop wird dem Attributwert "Größe: 10kg" eine Grundpreisangabe mitgegeben (da die sin JTL offenbar nicht möglich ist), nach einem Artikelabgleich ist diese Angabe leider wieder verschwunden, da offenbar alle Attributwerte jedesmal neu geschrieben und nicht aktualisiert werden. Ist das schonmal jemandem aufgefallen , oder ist da sonstwo ein Bug im Spiel und sollte so eigentlich nicht laufen?

Mit besten Grüßen!

Mario

Ich verweise nochmal auf die Idee mit dem Cookie, das sollte deutlich einfacher darüber sein.

Hm, naja vielleicht denk ich da auch zu kompliziert - hast du mal versucht einfach spasseshalber eine ebene höher die application_top.php zu includen ?