Hi, wir sind dabei unseren Online-Shop durch eine neue Lösung zu ersetzen. Wollte erst mal aber mein Kompliment an die Leute hinter Shopware aussprechen: wir sind in unserer Abteilung alle ziemlich angetan von Shopware. Davor setzten wir Prestashop ein. Und ich will nur soviel sagen, daß wir alle froh sind nun Shopware zu verwenden. Nunja, genug Honig um Mund geschmiert. Mit geht’s um folgendes. Uns ist letztens aufgefallen, daß es im neuen Shop nicht möglich ist Artikel über den Internet Explorer in den Warenkorb zu legen. Mit allen anderen Browsern unter Win und OSX funktioniert’s dagegen. Getestet haben wir Chrome, Firefox, Opera und Safari. Das Problem ist unter Win XP mit dem IE8 und unter Win 7 mit IE8 und IE9 reproduzierbar. Beim Hinzufügen eines Artikels kann ich diese beiden Requests am Server sehen: /checkout/addArticle?callback=jQuery17203502569393467299_1363685436248&sActionIdentifier=&sAddAccessories=&sAdd=HS+018&sQuantity=1&_=1363685462856 /checkout?callback=jQuery17203502569393467299_1363685436249&sAction=ajaxAmount&_=1363685463419 Wir setzen Shopware in Version 4.0.6 Rev 7316 ein. Unter “Systeminformationen” haben wir überall einen Haken, bis auf “allow_url_fopen”, um Code-Injections zu vermeiden. Bei den Verzeichnissen die Schreibrechte benötigen ist ebenfalls überall ein Haken gesetzt. Steck leider nicht wirklich tief in Shopware drin und bin auf Eure Hilfe angewiesen. Danke schonma & viele Grüße Fabian
Das kann ich für IE9 (64bit-Version) nicht bestätigen. Sowohl bei lokal installierter 4.0.6 als auch im demoshop lassen sich fehlerlos Artikel in den Warenkorb legen.
Hi muwi, die Frage ist jetzt, wo unterscheidet sich unser Shop von Deinem. Ich glaub kaum, daß die Qualitätssicherung von der shopware AG den IE nicht getestet hat 
Wo könnte das Problem zu finden sein? Angepasst haben wir nur ein Template. Dieses ist ne Kopie von emotion_red und erbt die Eigenschaften von emotion. Andere Anpassungen an den Quellcodes haben wir keine vorgenommen. Auch möglich, daß bei uns irgend ne Option gesetzt ist, die dem IE nicht gefällt. Bin für weitere Tipps dankbar. Viele Grüße Fabian
Noch ein paar Infos, die ich eben recherchiert hab: Im IE10 unter Win8 existiert das Problem ebenfalls. Und im Backend kann man sich mit dem IE ebenfalls nicht anmelden. Beim Backend fällt auf, daß bei einem falschen Loginversuch, eine Fehlermeldung aufpoppt. Bei korrektem Login per IE erhält man kein Popup. Man sieht erst den Ladebalken und danach wieder den Loginbildschirm.
Hi Fabian, Probleme, ins backend zu kommen, hab ich auch. Jetzt gerade zum Beispiel wieder, wo ich versuchen wollte, mich mit dem IE einzuloggen. Es erscheint zwar das Hintergrundbild (und auch der Quelltext ist vollkommen richtig), aber die Eingabemaske erscheint einfach nicht. Das gilt aber für alle Browser bei mir! Und ist heute bereits das 2. Mal. Dieses Problem tauchte direkt nach Installation zum ersten Mal auf. Erst nach zig Versuchen kam dann mal die Maske - keine Ahnung, woran es liegt. Wegen frontend und IE weiß ich leider auch nicht weiter. Ich hab ebenfalls nicht viel am template gemacht, benutze ebenfalls emotion_red oder _orange, kaum Einstellungen verändert. Beim IE muss man auf den Browsercache achten, wenn ich mich recht erinnere, verwenden sogar mehrere unterschiedliche Versionen den selben Cache.
Hallo, wenn das Problem noch besteht, schaue mal ob du SSL im Backend aktiviert hast, wenn ja, ob dein Zertifikat richtig installiert ist und ob es nicht vom Browser blockiert wird. Der IE ist da etwas störrisch. Wenn kein Zertifikat gekauft wurde, musst du es einfach im Backend wieder deaktivieren.
Hi Moin, ne an SSL lag’s nicht. Konnte das Problem mittlerweile eingrenzen und lösen. Das Cookie wird vom Internetexplorer nicht ausgelesen, wenn die Subdomain der FQDN nicht www ist! Shopware ließen wir zu Testzwecken nämlich auf einer eigenen Subdomain laufen. Deswegen funktionierte es bei uns nicht. Nachdem ich den Shop per Hostspoofing [1] über ne www-Domain angesprochen hab, gingen Bestellungen im der IE nämlich. Gut, daß der IE mittlerweile nen JavaScript Debugger hat. Sonst wär’s wohl nie aufgefallen ;). In der Funktion `jQuery(document).ready(function($)’ liefert im IE der Aufruf von var cok = document.cookie.match(/session-1=([^;])+/g) ein null zurück. Auf einer www-Domain dagegen, wird das Cookie korrekt ausgelesen. Ich halte das ganze für ein Bug. Schön wär, wen mann im Error-Log des Webservers auf die fehlende Session-ID hingewiesen würde. Immerhin ist diese für den Bestellprozess zwingend notwendig. Das Fehlen wird dennoch schweigend zur Kenntnis genommen. Viele Grüße Fabian [1] Die Datei %WINDOWS%\System32\driver\etc\hosts die IP des Webservers, sowie www-Domain eintragen. Diese auch in den Grundeinstellungen vom Shop eintragen. Und nicht zu vergessen in der Apache-Config nen ServerAlias für die neue Domain. Zumindest, wenn man VHosts aktiviert hat. Ansonsten kann man den letzten Schritt weg lassen.
Ach nochwas. Wenn man den Shop im IE über die IP-Adresse des Webservers anspricht, funktioniert’s es auch. Problem existiert wirklich nur bei Subdomains die nicht www lauten.
Hi, welche Shopware-Version hast du im Einsatz und kann du mir einmal die Adresse des Shops zukommen lassen, damit ich mir das einmal anschauen kann? 
Heiner
Zwar bin ich ein paar Stunden zu spät, aber du hast den Fehler ja auch selbst gefunden. Wenn im Warenkorb oder Kundenkonto nichts passiert, sind Cookies mit hoher Wahrscheinlichkeit die Ursache. Wir suchen selbst noch nach einer Lösung, dem Kunden zumindest eine Info anzuzeigen, wenn er Cookies deaktiviert hat. Das Backend funktioniert nicht unter IE8 oder kleiner. Das ist normal. Im IE10 sollte es aber eigentlich gehen, wobei ich das selbst nicht getestet habe. Der Subdomain-Fehler klingt ja eigentlich so, als wenn der Cookie für die falsche Domain angelegt wird?! Kann das sein? War das direkt nach der Standardinstallation so? Oder seid ihr umgezogen oder dergleichen?
Hallo Ade, ihr könnt doch per Javascript testen, ob Cookies erlaubt sind und falls nicht, eine Fehlermeldung ausgeben lassen.
@hth da Offtopic nur kurz: eine Abfrage per JS hatten wir auch kurz überlegt, aber schöner wäre es natürlich serverseitig - denn ein Nutzer, der aus irgendeinem Grund Cookies aus hat, hat eventuell auch JS deaktiviert
Moin Heiner, Version 4.0.6 Rev 7316. Wir hatten wegen dem Problem auch schon Euren Support im Einsatz. Die kamen allerdings zu einem ganz anderen Schluss. Angeblich sollte die PHP-Einstellung allow_url_fopen = false der Grund dafür gewesen sein. BTW. was für eine bodenlose Behauptung Egal. Die Adresse des Shops würd Dir recht wenig nützen, da ich den VHost, den ich per Host-Spoofing angesprochen hab, wieder entfernt hab. Weiter unten hab ich ne Beschreibung, wie Du’s selbst auf einem Server testen kannst [1]. Und Ade: wir haben pingeligst drauf geachtet nix anzufassen, außer unserem eigenen Template [2]. Wie dem auch sei. Das Problem konnten wir sowohl bei unserer, als auch einer Standardinstallation (4.0.6) nachvollziehen. Beste Grüße Fabian [1] Unter OSX oder Linux: Host-Spoofing auf Deinem Client einrichten cat /etc/hosts … 192.168.x.x www.irgendeinedomain.de hierlaeuftsfalsch.irgendeinedomain.de … Unter Windows ist’s statt /etc/hosts %WINDOWS\SYSTEM32\driver\etc\hosts VHost auf dem Server einrichten (Unter Debian): cat /etc/apache2/sites-enabled/100_irgendeinedomain.de
ServerAdmin ne@email-adresse.de
DocumentRoot /var/www/www.irgendeinedomain.de
ServerName http://www.irgendeinedomain.de
ServerAlias hierlaeuftsfalsch.irgendeinedomain.de # Diesen Eintrag einfügen
ErrorLog /var/log/apache2/error_log_www.irgendeinedomain.de.log
CustomLog /var/log/apache2/access_log_www.irgendeinedomain.de combined
Options +FollowSymLinks
Unter OpenSuse ist die VHost-Config, je nach Admin, unter /etc/apache2/vhosts/irgendeinedomain.de.conf zu finden. [2] das mit der Verebung bei Templates find ich ja richtig geil. Fühl mich schwer an OOP erinnert. Kompliment an die Entwickler.