Beiträge von st-SaHiB

mhhh, komische sache. Hatte den Shop in aktueller Version runte rgeladen und installiert, später dann
cseov22_fp1 2.2.1.0
cseov22_fp2 2.2.2.0
cseov22_qf2221 2.2.2.1
installiert. Irgendwo muss ich dann wohl unterwegs nen Fixpack vergessen haben...
Muss aber auch gestehen, wenn man wie ich, immer nur alle Jubeljahre rein schaut, wenn mal wieder 'n neues Projekt ansteht, ist es verdammt schwer den überblick zu bewahren, welche Fixes man installieren muss. Ich mach ja nur so 3-4 Shops im jahr (zum Glück *g*)
Dann mal danke für den Support und sorry, falls ich hier wegen ner veralteten Version unruhe rein gebracht habe.

ok, da liegt der Hund begraben.
Wenn ich "speichern" klicke, dann landet nichts in der Session:
$_SESSION[t10lsqf]: array() <-- hier sollten denke ich die Bankdaten drin stehen.

Im POST wurden folgende Parameter per Ajax übergeben:

array(
['xajax'] =>'updatePaymentModule'
['xajaxr'] =>1355406325143
['xajaxargs'] =>array([0] =>'<xjxquery><q></q></xjxquery>')
)

Hier sollten wophl Sachen wie banktransfer_blz mit dabei stehen...

Hab jetzt mal die banktransfer_blz.sql importiert und die entsprechende Funktion im Modul aktiviert - jetzt werden die Daten korrekt übertragen und passende in die $_SESSION['t10lsqf'] gespeichert:

array(
['payment'] =>'banktransfer'
['banktransfer_num'] =>1
['pmodule'] =>4
['banktransfer_owner'] =>'TestName'
['banktransfer_blz'] =>6729****
['banktransfer_number'] =>2610****
['recheckok'] =>
['cod_num'] =>2
['moneyorder_num'] =>3
['paypal_num'] =>4
['vrepay_kreditkarte_num'] =>5
)

Damit wäre der 1. Fehler lokalisiert. Gehen tuts aber noch immer nicht.
Wenn die after_process versucht zu speichern, bedient diese sich der Variblen aus dem objekt.
$this sieht zu dem zeitpunkt aber so aus:

banktransfer(
code ='banktransfer'
title ='Lastschriftverfahren'
description ='Lastschriftverfahren'
enabled =1
sort_order =0
min_order =0
info =
order_status =1
banktransfer_bankname =
banktransfer_owner =
banktransfer_blz =
banktransfer_number =
banktransfer_prz =
banktransfer_status =10
banktransfer_fax =
)

Grund hierfür ist widerum daß die before_process die pre_confirmation_check aufruft und der den POST array als parameter übergibt. Darin stecken aber nicht wie gehofft die POST Daten vom Formular, sondern:

array(
['comments'] =>
['comments_added'] =>'YES'
['checkout_xajax'] =>1
['conditions'] =>'conditions'
['revocation'] =>'revocation'
)

Hab das jetzt mal ganz pragmatisch in der after_process Z.295 gelöst:

$banktransfer_validation = new AccountCheck;
$name = $banktransfer_validation->query(trim(str_replace(' ', '', $_SESSION['t10lsqf']['banktransfer_blz'])));
$this->banktransfer_bankname = $name['bankname'];
$this->banktransfer_blz = xtc_db_prepare_input($_SESSION['t10lsqf']['banktransfer_blz']);
$this->banktransfer_number = xtc_db_prepare_input($_SESSION['t10lsqf']['banktransfer_number']);
$this->banktransfer_owner = xtc_db_prepare_input($_SESSION['t10lsqf']['banktransfer_owner']);
(...)
xtc_db_query("INSERT INTO banktransfer (orders_id, banktransf...

Damit beschreib ich mir die nötigen Daten für den Query an Ort und Stelle mit den Daten aus der Session. Nicht schön, hab aber kein Bock zu suchen, wo unterwegs die POST Daten verloren gehen. Aber Du weißt das doch bestimmt und kannst das leicht "ordentlich" fixen... Wäre shcon schön, wenn so ein Standardmodul wie Lastschrift auch funktioniert.

der Shop ist http://www.alex-mundorff.de/de/index.html alelrdings ist lastschrift derzeit deaktivert - bringt ja nichts, wenn man hinterher beim kunden anrufen muss um die Bankverbindung zu erfragen...
Das Problem trat bei 3 testbestellungen mit verschiedenen usern auf, scheint also reproduzierbar. Allerdings sidn 3 bestellunen jetzt nicht so viel, al daß ich ausschließen könnte, daß es hin und wieder funktioniert. Aber hin udn wieder reicht halt auch nicht

hab mir Deinen Qucikfix angeschaut - der scheint integriert zus ein, nur gehen tut er trotzdem nicht
Werde mal versuchen das BankleitzahlenDingens zu aktivieren und wohl oder übel mal selbst debuggen müssen, ob oder ob nicht die updatePaymentModule aufgerufen wird und die entsprechenden SESSION vars gesetzt werden. Dank Deines Postes, weiß ich ja jetzt grob wo das Modul überall rumpfuscht

hi nochmal,

soll jetzt doch nicht übe Finanzdienstleister gehen, darum wird es doch etwas dringend.
Kleine Zusatzinfo: der Shop nutzt den SinglePage Checkout.

Frage: nutzt irgendwer Lastschrift in der 2.2.2.1 erfolgreich, dann müsste ich mal gucken, was bei mir nicht stimmt

Hi,

wie der Titel schon sagt: beim banktransfer (Lastschrift) Standardmodul werden die KOntodaten nicht richtig in der DB gespeichert.
Habe auch das Problem, daß zwar BLZ und Konto abgeglichen werden, der bankname aber nicht autoausgefüllt wird. Allerdings ist die Option im backend auch "eigentlich" deaktiviert
Zurück zu Thema, sowohl bei mir, als auch bei nem Kunden der per Lastschrift bestellt hat landet im table banktransfer

orders_id banktransfer_owner banktransfer_number banktransfer_bankname banktransfer_blz banktransfer_status banktransfer_prz banktransfer_fax
17 10 NULL

OrderID (17) und Status (10) werden gespeichert, rest bleibt leer, bzw fax ist NULL. Im Backend wird entsprechend auch nirgends irgendwas zu den Kontodaten ausgegeben.
Ist zumindest bei mir nicht dringend, da die Lastschriften mittlerweile eh über nen FInanzdienstleiste rgehen, aber eventuell haben ja andere auch das Problem
Shopversion ist die 2.2.2.1

Gruß
SaHiB

PHP Version 5.3.18-1~dotdeb.0

Hab gerade geschaut:

FSK18 Sperre
Kauf von FSK18 Artikel Sperren? JA

FSK18 Artikel
Anzeige von FSK18 Artikeln? JA

Ist zwar ein Shop für Tuning von Geländewagen, die haben sowas wie FSK18 gar nicht, aber eingestellt haben die es so (oder war's standard?!)

Bei mir ist das Problem jetzt wie gesagt behoben, wäre natürlich schon, wenn das beim nächsten update dann irgendwie mit rein gewurschtelt wäre, wenn ich da mal Update mache, daß ich mir da nicht wieder den Fehler einhandle

ne, bei Dir gehts richtig...
aberr auch bei Dir wird offenbar keine cart_quantity übrtragen, dh Du rutschst in den gleichen else block wie ich. Eventuell hast Du ne andere PHP Version die das gecastete (int) hinterher beim [$i] nicht wie nen string behandelt. hatte das noch nicht. Müsste man ordentlich debuggen um's rauszufinden.

also in dem Shop passiert das immer...
Auch mit dem StabndardTheme. Dachte zuerst ich hätte vergessen irgendwo in der Form das cart_quantity unterzubringen, aber im normalen theme ist das Problem eben auch.
Tritt natürlich nur auf, wenn man mehr als 9 Produkte im Shop hat

Hi,

habe hier bei einem Kunden in der 2.1.2.10 ein problem mit der includes/cart_actions.php

Legt man zB das Produkt Nr. 1045 in den Warenkorb, erscheint es dort nicht, statt dessen erscheint das Produkt mit der ID 1.
Grund liegt in der besagten Datei im switch bei 'add product' zeile 140:

(...)
} elseif ($_POST['cart_quantity'] !=''){
					$_SESSION['cart']->add_cart((int)$_POST['products_id'], $_SESSION['cart']->get_quantity($_POST['products_id']) + $_POST['cart_quantity'], $_SESSION['cart']->get_attributes_from_id ($_POST['products_id']));//FIX-WISHLIST ATTRIBUTES call get_attributes_from_id()
					$_SESSION['wishList']->remove($_POST['products_id']);//FIX LÖSCHEN (int) WEG  
				} else {
					$pids = count($_POST['products_id']);
					for($i = 0; $i < $pids; $i++){
						if ($i == 0) {
							$t_ids = $_POST['id']; 
						} else {
							$t_ids = array();
						}
						$_SESSION['cart']->add_cart((int)$_POST['products_id'][$i], $_SESSION['cart']->get_quantity(xtc_get_uprid($_POST['products_id'][$i], $t_ids)) + xtc_remove_non_numeric($_POST['products_qty']), $t_ids);

					}
				}

hier wird bei mir keine $_POST['cart_quantity'] übermittelt, sondern nur $_POST['products_qty'], dadurch springt er in den else block rein. da $_POST['products_id'] aber kein array ist, wird die pid trotz int cast wie ein ganz normaler string behalndelt: bei einem Produkct wird also das Zeichen an Index 0 ausgegeben --> die 1. Somit landet Produkt Nr 1 im Warenkorb.
Hab das jetzt mit nem is_array check

} else {
				    if(is_array($_POST['products_id'])){ 
						$pids = count($_POST['products_id']);
						for($i = 0; $i < $pids; $i++){
							if ($i == 0) {
								$t_ids = $_POST['id'];
							} else {
								$t_ids = array();
							}
							$_SESSION['cart']->add_cart((int)$_POST['products_id'][$i], $_SESSION['cart']->get_quantity(xtc_get_uprid($_POST['products_id'][$i], $t_ids)) + xtc_remove_non_numeric($_POST['products_qty']), $t_ids);


						}
					}else{
						$_SESSION['cart']->add_cart((int)$_POST['products_id'], $_SESSION['cart']->get_quantity($_POST['products_id']) + $_POST['products_qty'], $_SESSION['cart']->get_attributes_from_id ($_POST['products_id']));//FIX-WISHLIST ATTRIBUTES call get_attributes_from_id()
						$_SESSION['wishList']->remove($_POST['products_id']);//FIX LÖSCHEN (int) WEG
					}
				}

gelöst. Da ich aber ehrlich gesagt nicht weiß, wann man überhaupt einen array von Produkten bestellen kann und eventuell auch andere das Problem haben, dachte ich "post es mal hier rein", vlt kann mir jemand was dazu sagen, der die größeren Zusammenhänge des Warenkorbes kennt (ich kenn das skript ja nicht wirklich gut und kann nur doof die Stelle finden, die mir Ärger macht, es fixen und hoffen, daß es nicht irgendwo anders negative Auswirkungen hat)

Dank und Gruß
SaHiB

wir hatten auch wenig probleme damit...

kleiner Nachtrag: ganz übel ist auch die checkout.php
Gerade sowas wichtiges wie der Checkout sollte nach Möglichkeit nicht hardcodiert sein, sondern über Templates laufen.
Möchte man die Produktdarstellung anpassen, muss man die getProducts() vergewaltigen, nicht wirklich schön. Dabei steckt gerade im Checkout viel Potential, wenn man sich da teilsweise die Abbruchraten anschaut.

weiter Nachtrag: die löschenFunktion unten ind er produktliste removeProduct('id','minus'); entfernt leider nicht das produkt mit der gesamten Zeile, sondern nur deren Inhalt. Bei den .dunkel zeilen bleibt so ein unschöner grauer balken - ich hab noch trenn-linien drin, da siehts noch blöder aus..

und erm - sorry, ich weiß daß ich hier ein wenig aufdringlich bin! Das meiste würde ich mir ja schnell selbst coden, aber die ganzen Fixpacks sind so schon nervig genug einzuspielen, wenn man, wie ich, Kunden mit extravaganten Wünschen hat. Darum wäre es schön wenn einige Sachen es in die offiziellen Versionen schaffen könnten und das kannst halt nur Du...

Hab Dir mal den fertigen Checkout hochgeladen, damit Su siehst was ich meine. Hat mich jetzt 4-5h gekostet - viel zu lange für eigentlich nur ein bissi HTML und hier und da etwas designarbeit (grobDesign stand ja schon), aber man muss sich halt alles irgendwo zurechtbiegen, weil die nötigen wrapper und klassen fehlen...
Wenn ich jetzt dran dene, daß ich auch noch den Warenkorb machen muss, verlier ich richtig die Lust

vorsicht: jetzt wirds unverschämt: bei den gespeichert/fehler meldungen wie zB in #payment_module_error setzt Du die Farbe des divs auf grün / rot.
könntest Du das eventuell gleich mitändern, daß Du dem div statt dessen einfach eine Klasse mitgibst? Nicht in jedem Template sieht das gut aus - mit einer css Klasse kann man so sachen viel felxibler anpassen. Anders muss ich jetzt das original JS Skript anfassen und farbe ändern - das ist beim nächsten Update aber wieder zurück gesetzt wenn man nicht aufpasst -schlecht

Nicht dringend aber mal ein langfristiger Denkanstoß wo wir gerade beim thema sind:
es ist im übrigen noch an vielen vielen anderen Stellen nervig, daß viel output hardcodiert ist und sich nur in den Quelldateien ändern läßt. Bei Sachen wie Preisen oder so, wo man es nicht verhindern kann, würde ich mir hin und wieder lieber ein paar wrapper wünschen als hardcodierten Fließtext. zB wenn ein Sonderpreis mit dem normalen ausgegeben wird dann statt

vorher 19EUR <br /><br />
9,99 EUR

lieber ne ausgabe wie

<div class="price sonderpreis">
  <div class="vorher">vorher 19EUR</div>
  <span class="current_price">9,99 EUR</span>
</div>

Ist etwas mehr HTML-Code, ich weiß, aber das würde das Themen des Shops enorm erleichtern... und auf ein paar byte mehr quellcode kommt es am ende eh nicht an

lieber den radio auch setzen wenn man das modul anklickt - dann wirds noch leichter zu bedienen und ist denke ich weniger zu programmieren vom jetzigen stand aus...
Auf alle Fälle schon mal Danke

Hallo,

habe 2.2.2.1 derzeit installiert. ZahlModule mal testweise Rechnung und Vorkasse.
Der AjaxCheckout ist aktiviert - wähle ich jetzt eine Bezahlart direkt über den Radio aus, erscheint der Text daß gespeichert wurde und ein grüner Rahmen kommt. Klicke ich dann auf das Feld der anderen Zahlart bleibt der grüne Rahmen bei der Bezahlart die via Radio ausgewählt wurde, aber bei der soeben geklickten erscheint er auch - ebenso die "gespeichert" Nachricht.

Dazu wechselt beim klick auf .moduleRow die klasse auf .moduleRowSelected. Das passiert im übrigen auch bei den Versandmodulen.
Das schönste verhalten wäre beim click auf ein modul, daß der Radio selektiert wird und feddisch - Rest könnte dann so bleiben und der Checkout ist auch für Grobmotoriker bedienbar :p

Hab mal nen Screen mit StandardTemplate gemacht damit es klarer wird.
Mag nicht drängeln, aber der Shop soll mitte/ende nächster Woche online, kann das "zeitnah" gefixed werden, oder muss ich da selbst ans JS ran? Weil Checkout sollte schon problemlos gehen...

Gruß und Dank
SaHiB

Zitat von admin

Das Finanzamt hat gern durchgängige Listen!

Rechnungsnummern müssen nicht fortlaufend sein (weitläufiger Irrglaube), es reicht, daß man sicherstellt, daß keine doppelt vor kommt.

das sind bei 3 Produktbilder doch nur 3 sehr einfache querys - ein index ist auf den bildnamen ja sicher schon gesetzt (wenn nicht, ist es ja wenig Aufwand), also kostet das selbst bei 100.000 Artikelbildern pro query wohl kaum mehr als 0.01sek - verschmerzbar, da das ganze ja nur einmalig geprüft wird, wenn man ein Produkt speichert
Bei den URLs machst Du es ja auch schon - da hängst Du sauber hinten noch einen Zähler dran (das ist sogar aufwendiger als die ID ran zu hängen)

schicker wäre natürlich noch eine kleine Abfrage, ob das Produkt doppelt vorkommt und dann nur in dem fall die ID hinten dran klatschen... Ist ja nur 1 query mehr.
Ich weiß - ich bin dreißt

in pseudocode also (boah bin ich heut faul - hab aber auch schon nen langen Tag hinter mir):

$new_products_name = cseo_get_url_friendly_text(xtc_db_prepare_input($products_data['products_name'][(int)$_SESSION['languages_id']]));
query("SELECT pid FROM bilder WHERE pid!={$products_id} AND bildname='{$new_products_name}' ")
if(datensatz gefunden) $new_products_name.='_'.$products_id;

weiß grad nicht wo die seo bildnamen hinterlegt sind, aber sinngemäß passt das oben denk ich mal...

Hallo zusammen,

hat jemand Erfahrungen mit einem Attribut Matrix Modul (also Warenbestände nicht pro Attribut, sondern für Attributkombinationen angeben. zB Tshirt in Größe 38 ist nur noch in weiß und rot lieferbar, 39 dagegen auch in blau) im Zusammenspiel mit commerce:seo?
Welches könnt Ihr da empfehlen?

Hab per Google einige gefunden, aber meistens älteres zeug und auch nichts speziell für c:seo

Dank Euch schon jetzt

Grüße
SaHiB

sorry erst mal - bin im falschen Forum gelandet - sollte natürlich unter "bugs" (kann's leider nicht selbst verschieben)
Ansonsten ist das mit den SeoURLs kein Problem - da wird die pid mit dran gehängt das klappt. Aus SEO-Sicht ist das auch egal, zumindest solange die Produkte in unterschiedlichen Rubriken liegen, weil ja der komplette Pfad durch die Rubriken in der URL steht.
Das Problem ist denke ich mal kein seltenes - ich habe es jetzt im 3. Shop, wo ein Kunde mich deswegen anschreibt - die ersten male habe ich darüber aufgeklärt und auch diesmal umgehen wir es halt, aber auf Dauer wäre eine Lösung schon schön. Selbst basteln möchte ich aber auch nix, damit die FixPacks sauber eingespielt werden können.