Hallo, ich habe im Backend die Benachrichtigungsmail bei Fehlern eingeschaltet. Nun bekomme ich häufig Mails mit Fehlern bzgl. Zend_Session_Exception. core.ERROR: exception ‘Zend_Session_Exception’ with message ‘The session has already been started. The session id must be set first.’ in /var/www/…/Library/Zend/Session.php:709 Die genaue Meldung bei der letzen Mail war: #0 /var/www/…engine/Library/Zend/Session.php(421): Zend_Session::setId(‘da602f0b162fccb…’) #1 /var/www/…engine/Library/Zend/Session/Namespace.php(143): Zend_Session::start(true) #2 /var/www/…engine/Shopware/Components/DependencyInjection/Bridge/Session.php(81): Zend_Session_Namespace->__construct(‘Shopware’) #3 /var/www/…cache/proxies/Shopware201407011222ProductionProjectContainer.php(275): Shopware\Components\DependencyInjection\Bridge\Session->factory(Object(Shopware201407011222ProductionProjectContainer)) #4 /var/www/…vendor/symfony/dependency-injection/Symfony/Component/DependencyInjection/Container.php(312): Shopware201407011222ProductionProjectContainer->getSessionService() #5 /var/www/…engine/Shopware/Components/DependencyInjection/Container.php(253): Symfony\Component\DependencyInjection\Container->get(‘session’) #6 /var/www/…engine/Shopware/Components/DependencyInjection/Container.php(188): Shopware\Components\DependencyInjection\Container->load(‘session’) #7 /var/www/…engine/Shopware/Bootstrap.php(149): Shopware\Components\DependencyInjection\Container->get(‘Session’) #8 /var/www/…engine/Shopware/Application.php(196): Shopware_Bootstrap->getResource(‘Session’) #9 /var/www/…engine/Shopware/Plugins/Default/Core/ControllerBase/Bootstrap.php(115): Shopware->Session() #10 /var/www/…engine/Library/Enlight/Event/Handler/Plugin.php(149): Shopware_Plugins_Core_ControllerBase_Bootstrap->onPostDispatch(Object(Enlight_Controller_ActionEventArgs)) #11 /var/www/…engine/Library/Enlight/Event/EventManager.php(211): Enlight_Event_Handler_Plugin->execute(Object(Enlight_Controller_ActionEventArgs)) #12 /var/www/…engine/Library/Enlight/Controller/Action.php(202): Enlight_Event_EventManager->notify(‘Enlight_Control…’, Object(Enlight_Controller_ActionEventArgs)) #13 /var/www/…engine/Library/Enlight/Controller/Dispatcher/Default.php(528): Enlight_Controller_Action->dispatch(‘indexAction’) #14 /var/www/…engine/Library/Enlight/Controller/Front.php(228): Enlight_Controller_Dispatcher_Default->dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp)) #15 /var/www/…engine/Shopware/Kernel.php(141): Enlight_Controller_Front->dispatch() #16 /var/www/…vendor/symfony/http-kernel/Symfony/Component/HttpKernel/HttpCache/HttpCache.php(472): Shopware\Kernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #17 /var/www/…engine/Shopware/Components/HttpCache/AppCache.php(256): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL) #18 /var/www/…vendor/symfony/http-kernel/Symfony/Component/HttpKernel/HttpCache/HttpCache.php(429): Shopware\Components\HttpCache\AppCache->forward(Object(Symfony\Component\HttpFoundation\Request), true) #19 /var/www/…vendor/symfony/http-kernel/Symfony/Component/HttpKernel/HttpCache/HttpCache.php(329): Symfony\Component\HttpKernel\HttpCache\HttpCache->fetch(Object(Symfony\Component\HttpFoundation\Request), true) #20 /var/www/…engine/Shopware/Components/HttpCache/AppCache.php(178): Symfony\Component\HttpKernel\HttpCache\HttpCache->lookup(Object(Symfony\Component\HttpFoundation\Request), true) #21 /var/www/…vendor/symfony/http-kernel/Symfony/Component/HttpKernel/HttpCache/HttpCache.php(193): Shopware\Components\HttpCache\AppCache->lookup(Object(Symfony\Component\HttpFoundation\Request), true) #22 /var/www/…engine/Shopware/Components/HttpCache/AppCache.php(113): Symfony\Component\HttpKernel\HttpCache\HttpCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #23 /var/www/…shopware.php(109): Shopware\Components\HttpCache\AppCache->handle(Object(Symfony\Component\HttpFoundation\Request)) #24 {main} Weiß jemand, was da schief läuft? Gruß Mario
Hallo, hat da keiner eine Idee? Die Mail mit dem Fehler kommt ein paar mal am Tag in 5er Packs. Ein anderer Fehler ist core.ERROR: exception ‚Enlight_Controller_Exception‘ with message ‚Unauthorized‘ in /var/www…/engine/Shopware/Plugins/Default/Backend/Auth/Bootstrap.php:203 der kommt aber nur ab und an und einzeln.
Hi, genau die gleichen Fehler bekomme ich auch, aber erst seit 9.9.14…vorher nicht. Jedoch wurde definitiv nichts am Shop geändert…habe nun mal das Update auf 4.3.2 eingespielt, ggf. ändert das ja was… Gruß
Und? Hat das Update geholfen? Kann ich das Update einfach drüber spielen, oder sind dann etliche Plugins weg und meine Änderungen pfutsch? Gruß Mario
Hi, ne hat nichts gebracht…der erste Fehler ist wieder im Log. Wenn Du deine Änderungen in deinen eigenen Templatedateien gemacht hast, bleiben diese ja erhalten. Das Update prüft auch vorher ob deine Plugins kompatibel sind. Bei mir waren Zwei nicht kompatibel, funktionierten aber trotzdem. Gruß
Hallo zusammen, habe den Fehler auch. Wäre für Hilfe dankbar. Grüße Andreas
Hallo, habe nun ebenfalls das Problem. Aber erst seitdem ich von 4.3.0 auf 4.3.2 upgedatet habe. Ich hoffe jemand von Shopware nimmt sich der Sache mal an. Momentan habe ich nämlich keinen „Blassen“, was dieser Fehler evtl. im Frontend bzw. Bestellablauf bewirkt. Beste Grüße, Oliver
Hallo, zuerst einmal kann man mit der Fehlermeldung allein so erstmal nichts anfangen. Im ersten Schritt solltet ihr daher erstmal im Access-Log des Servers nachschauen, bei welchem URL Aufruf der Fehler erzeugt wird. In der Mail die von Shopware kommt steht ein Datum und eine Uhrzeit und im Serverlog steht dann auch welche URL zu dieser Zeit aufgerufen wurde. Wenn man dann weiß um welche URL es sich handelt, kann man auch gezielt ans Debuggen gehen. Lässt sich die Fehlermeldung bei Aufruf der URL reproduzieren? Wenn ja, so kann man gezielt prüfen wann diese URL den Fehler erzeugt bzw. wann diese aufgerufen wird. Wenn nein muss man einen Weg zur Reproduktion finden, beispielsweise indem man die Bestellprozesse im Shop einmal gründlich prüft (Zahlung mit den verschiedenen Zahlungsarten usw.) und dabei auch das Log im Auge behält. Die Funktion “Fehler an Shopbetreiber senden” sollte generell nur zum Debugging genutzt werden, da hier alle Meldungen verschickt werden, auch jene die nur zur Warnung gedacht sind und den Shopablauf nicht beeinflussen. Es gibt immer wieder Meldungen die treten auf und die werdet ihr dann auch per Mail bekommen, obwohl sie keinen Fehler darstellen. Wenn es hier also eine konkrete URL oder eine Anleitung zum Nachstellen gibt, kann man detailliert prüfen wie der Fehler entsteht. Ohne das ist es nur Raten ins blaue. Grüße Moritz
Hallo Moritz, erst mal vielen Dank für Deine ausführliche Anleitung. Also bei mir wird keine konrete Url abgefragt. Ich habe in meinem LOG das hier gefunden: j98429.servers.jiffybox.net - - [07/Oct/2014:18:46:25 +0200] „GET / HTTP/1.1“ 301 923 „-“ „Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36“ j98429.servers.jiffybox.net - - [07/Oct/2014:18:46:25 +0200] „GET / HTTP/1.1“ 200 769 „-“ „Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36“ Damit kann ich nun wirklich gar nichts anfangen. Grüße, Oliver
Hallo, vielleicht noch als Ergänzung: Mit Shopware 4.3.2 werden ausführlichere und detailliertere Fehlermeldungen versendet, wenn der eMail Versand aktiv ist im log-Plugin Da steht z.B. dann sich die Url mit drin. Ein Update wäre daher auch zu empfehlen Sebastian
Hallo Oliver, jetzt war Sebastian etwas schneller 
also diese Log-Einträge deuten ja darauf hin, dass die Startseite aufgerufen wird. Auf Anhieb kann ich so auch keinen Fehler bei Aufruf deiner Startseite feststellen.Bekommst du denn bei jedem Aufruf der Startseite den Fehler? (Müsstest du ja sehen, wenn du deine Startseite aufrufst, ob du dann auch eine Mail bekommst). Der Fehler kann auch entstehen, wenn die PHP-Variable „session.auto_start“ nicht auf „off“ steht. Dies wird im Shopware-Standard über die .htaccess realisiert. (Dort findest du einen Eintrag wie „php_flag session.auto_start off“). Hinweise darauf, findest du auch wenn du nach der Exception googlest. Hier kannst du einmal im Backend deine Systeminfo überprüfen und dort im Bereich „PHP-Info“ mal nach im Bereich „Session“ schaust ob „session.auto_start“ auf off steht. Wenn das alles passt, müsstest du mal versuchen ob du das irgendwie herbeiführen kannst die Meldung. Grüße Moritz
Hallo Moritz, also bis jetzt habe ich den Fehler nicht mehr erhalten. Ich konnte ihn bis dato auch nicht reproduzieren. Bestellungen durchgekaut usw. Wie gesagt…den Fehler auch erst bekommen seitdem ich 4.3.2 am laufen habe. session.auto_start ist auf off gestellt. Ich habe den Fehler gemeinsam mit dem error.log und access.log an den Support von Profihost geschickt. Falls es sich um ein serverseitiges Problem handelt, bekomme ich ja auch eine Antwort. Grüße, Oliver
Hallo Zusammen, jetzt habe ich von Profihost eine Nachricht erhalten. Mal sehen ob dies etwas bezüglich der Fehlermeldung bewirkt. “Der Ioncube Loader wurde falsch in der php5.4.ini-Datei eingebunden. Ich habe dies korrigiert, so dass zumindest die Fehlermeldung aus dem error.log verschwinden sollte. Bitte schauen Sie, ob auch die Shop-Fehlermeldung im Anschluss verschwindet.” Viele Grüße, Oliver
Ich habe diesen „Zend_Session_Exception“-Fehler auch ständig im Log: [2014-10-29 09:51:20] core.ERROR: exception 'Zend\_Session\_Exception' with message 'The session has already been started. The session id must be set first.' in /biotouwh/www.-geheim-.com/engine/Library/Zend/Session.php:709 Access-Log: baiduspider-123-125-71-36.crawl.baidu.com - - [29/Oct/2014:09:51:20 +0100] "GET / HTTP/1.1" 200 758 "-" "Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)" Scheint so, als sei der chinesische Crawler der Suchmaschine Baidu schuld. Habe diesen nun ausgesperrt in der htaccess: RewriteCond %{HTTP\_USER\_AGENT} Baidu RewriteRule ^.\*$ http://127.0.0.1 [R,L]
Hallo, ich habe das Problem auch… Der Fehler ist identisch… gibt es dazu einen Update? Ist das evtl sogar ein Injection-Versuch / Prüfung einer Undichten Stelle / Versuch eine Session-Übernahme? Folgende Details habe ich zusätzlich noch in der eMail: Time: 2014-12-26T07:09:20.457066+0100 Channel: core request: {“uri”:"/en/?show_modal=1",“method”:“GET”,“query”:{“show_modal”:“1”},“post”:} session: No session data available shopId: 2 shopName: Englisch
Hallo, gibt es dazu schon eine Info? Hier nochmal ein Auszug aus dem Fehler-Report… scheint immer auf der root-Seite aufzutreten… bitte um Hilfe / Rückinfo… Time: 2015-01-02T01:00:40.076627+0100 Channel: core request: { „uri“: „/“, „method“: „GET“, „query“: , „post“: } session: No session data available shopId: 1 shopName: Deutsch
Eine Auswertung der Logs ergab auch bei mir einen Hinweis auf den Baiduspider. Der Eintrag in die .htaccess, wie oben beschrieben, brachte hier aber nicht den gewünschten Erfolg. Aussperren konnte ich den Spider mit RewriteCond %{HTTP\_USER\_AGENT} Baiduspider RewriteRule ^.\*$ http://127.0.0.1 [R,L] damit wird er auf localhost umgeleitet oder besser mit RewriteCond %{HTTP\_USER\_AGENT} ^Baiduspider [NC] RewriteRule .\* - [F] Erklärung: Mit dem Flag NC wird zwischen Groß- und Kleinschreibung nicht unterschieden. Da sich der Spider manchmal auch als baiDuspider etc. tarnt, ist das sinnvoll. Mit dem Flag F erhält der Spider den 403 Forbidden status code.