Warenkorb bleibt leer

[Fry]

Das Problem liegt nicht an Veyton, das Problem liegt an den Konfigurationen des Servers wo Veyton drauf läuft

Bei den Mengen an Konfigurationsmöglichkeiten, die es gibt.... wie soll Veyton die denn alle abdecken können? Das wäre fast so wie die Eierlegende Wollmilchsau

[FloM]

Hallo David,

ich habe die Einstellung session.save_path = "/tmp" heute morgen um 9:23 Uhr ebenfalls vorgenommen und hatte soeben wieder einen Kunden mit dem gleichen Problem:

ID 15405 - Herr CCCCC
----------------------------------
- Kann sich nicht einloggen (hat um 15:03 Uhr ein Konto angelegt)
- War mit seinem PC heute morgen noch nicht auf unserer Website - erst ab Nachmittags - also nach meiner Änderung. Lediglich ein Kollege war an einem anderen PC auf unserer Website.
- Kann das gewünschte Produkt (einen Grill) nicht in den Warenkorb legen

Es scheint also leider nicht daran zu liegen. Ich warte allerdings noch auf Rückmeldung von 1und1, ob "/tmp" der richtige Wert ist und ob man z.B. das Verzeichnis manuell anlegen muss. Denn wenn ich per FTP nachsehe existiert weder "/tmp" noch "/veyton/tmp" bei mir. Allerdings finde ich ein solches Verzeichnis per SSH in /kunden/homepages:

lrwxrwxrwx 1 root root 11 May 4 2010 tmp -> /kunden/tmp/

Das ganze verlinkt also auf /kunden/tmp

Wenn ich tmp öffne, erscheint folgender Inhalt:

(uiserver):uxxxxxxxx:/kunden/tmp > l
total 92
drwxrwxrwt  2 root      root      4096 Nov 23 17:12 ./
drwxr-xr-x 22 root      root      4096 Jul  5 12:18 ../
lrwxrwxrwx  1 root      root        23 Nov  6 18:16 mysql.sock -> /kunden/tmp/mysqld.sock=
lrwxrwxrwx  1 root      root        24 Nov  6 18:16 mysql5.sock -> /kunden/tmp/mysql5d.sock=
srwxrwxrwx  1 mysql     crontab      0 Nov  6 18:16 mysql5d.sock=
srwxrwxrwx  1 mysql     crontab      0 Oct 31 02:01 mysqld.sock=
-rw-------  1 u38774383 ftpusers    31 Nov 23 16:52 sess_0f35cd80f6f17edb52cde6157808ce47
-rw-------  1 u38774383 ftpusers 27955 Nov 23 15:57 sess_4c668ccce431bb1db8d6ca9dd57b7f5c073f8251
-rw-------  1 u38774383 ftpusers    15 Nov 23 17:08 sess_918d2f17c3dc9e24b0be0d06b35783b5
-rw-------  1 u38774383 ftpusers    31 Nov 23 16:59 sess_e6b669b27c06267f8e3e9d42f0641116
-rw-r--r--  1 u38774383 ftpusers 19479 Nov 22 16:17 wsdl-0e15628294e97b54693007ea573331cf
-rw-r--r--  1 u38774383 ftpusers 19479 Nov 23 15:02 wsdl-35a5524a9113f5d2ea8982856d6d2be6
-rw-r--r--  1 u38774383 ftpusers  2348 Nov 22 22:10 wsdl-934804935dc3e8af28fc01ce2c25c6a1

Es gibt auch das Verzeichnis /tmp, allerdings scheint dieses den gleichen Inhalt zu haben:

(uiserver):uxxxxxxxx:/tmp > l
total 92
drwxrwxrwt  2 root      root      4096 Nov 23 17:11 ./
drwxr-xr-x 22 root      root      4096 Jul  5 12:18 ../
lrwxrwxrwx  1 root      root        23 Nov  6 18:16 mysql.sock -> /kunden/tmp/mysqld.sock=
lrwxrwxrwx  1 root      root        24 Nov  6 18:16 mysql5.sock -> /kunden/tmp/mysql5d.sock=
srwxrwxrwx  1 mysql     crontab      0 Nov  6 18:16 mysql5d.sock=
srwxrwxrwx  1 mysql     crontab      0 Oct 31 02:01 mysqld.sock=
-rw-------  1 u38774383 ftpusers    31 Nov 23 16:52 sess_0f35cd80f6f17edb52cde6157808ce47
-rw-------  1 u38774383 ftpusers 27955 Nov 23 15:57 sess_4c668ccce431bb1db8d6ca9dd57b7f5c073f8251
-rw-------  1 u38774383 ftpusers    15 Nov 23 17:08 sess_918d2f17c3dc9e24b0be0d06b35783b5
-rw-------  1 u38774383 ftpusers    31 Nov 23 16:59 sess_e6b669b27c06267f8e3e9d42f0641116
-rw-r--r--  1 u38774383 ftpusers 19479 Nov 22 16:17 wsdl-0e15628294e97b54693007ea573331cf
-rw-r--r--  1 u38774383 ftpusers 19479 Nov 23 15:02 wsdl-35a5524a9113f5d2ea8982856d6d2be6
-rw-r--r--  1 u38774383 ftpusers  2348 Nov 22 22:10 wsdl-934804935dc3e8af28fc01ce2c25c6a1

Da dort auch eine Datei von gestern (22.11.2011) liegt, gehe ich davon aus, dass dieses Verzeichnis auch bereits vor meiner Änderung an der php.ini verwendet wurde.

Gruß
FloM

[FloM]

Ich hatte direkt am gleichen Tag wieder einen Kunden mit diesem Problem. Wir haben uns bei diesem gestern per Teamviewer aufgeschaltet, um es dort zu beobachten. Da ging es jedoch wieder. Das Problem scheint also zusätzlich auch noch temporär zu sein.

Heute hatte ich dann einen weiteren Kunden mit dem Problem. Allerdings wollte dieser trotz dem angebotenen Rabatt nicht, dass wir uns auf seinen PC "hacken".

[ripley_one]

Gibts hier schon etwas neues? Bei uns treten verhäuft Bestellungen auf, die im Backend lediglich Versandkosten enthalten, ohne Artikel, bzw. Bestellungen, die nicht abgeschlossen sind. Am 28.01. war JEDE Bestellung offen und nicht abgeschlossen. Dabei ist die Zahlart nebensächlich.

Ein Kunde rief an und beschwerte sich. Wir legen die Bestellungen dann von Hand in unserer Verkaufsabwicklung an, wenn sich Kunden melden. Da gehen mit Sicherheit viele Euros in den Müll... Wer greift schon zum Telefonhörer?!

Einziger Hinweis: Internet Explorer bei dem Kunden genutzt. Wir können den Fehler auch nicht reproduzieren.

Zudem kommt eine extrem eigenartige Ansich in den Bestellung an sich:


Mal sehen, ob es da ne Lösung gibt.