Ich denke, ich habs. Vermutlich dann doch eigene Dummheit. - Leider 
In Kürze mehr.
[quote=„ayurveda“]auch wieder zurück auf 4.1.4 wegen der fehlermeldung URL: import Snippets?offset=0 total Count=0 shopware[/quote] über die console funktioniert das update auf 4.2.1 ohne fehlermeldung …
[quote=„ayurveda“]auch wieder zurück auf 4.1.4 wegen der fehlermeldung URL: import Snippets?offset=0 total Count=0 shopware[/quote] über die console funktioniert das update auf 4.2.1 ohne fehlermeldung …
Also ich habs über den Browser gemacht auch ohne Fehlermeldung lief alles sauber durch 
Gute arbeit an die Entwickler, nur ein schönen Changelog vermisse ich
Hi, Infos gibt es z.B. in der readme, die jeweils dem Paket beiliegt Technisch Neuerungen sind hier noch zu finden http://wiki.shopware.de/Shopware-4.2_de … 2_454.html http://wiki.shopware.de/Shopware-4.2-Up … 6_454.html Generelle Tickets findest du allgemein dann im Tracker http://wiki.shopware.de/Major-Update-4. … 2_454.html http://wiki.shopware.de/Major-Update-4. … 7_454.html Vielleicht helfen dir diese Infos weiter Sebastian
Hmm bei mir kommt das hier: Datenbank Update durchführen Error Received an error message. URL: importSnippets?offset=0&totalCount=0 Message: Gateway Time-out Please try to fix this error and restart the update. Response Gateway Time-out The gateway did not receive a timely response from the upstream server or application. Apache/2.2.22 Server at www.xxx.de Port 80 Habe nen Managed Server bei Domainfactory…
Hab ne neu Installation versucht, da kommt das gleiche Und immer beim Schritt 2 des DB Updates… Woran kann das liegen?
[quote=„thinknext“]Hab ne neu Installation versucht, da kommt das gleiche Und immer beim Schritt 2 des DB Updates… Woran kann das liegen?[/quote] Hallo, das Update über die Shell aufrufen. Unter Umständen nicht mit php update, sondern mit dem CLI von php. Das hängt vom Hostinganbieter ab und der kann auch sagen, wie man php-CLI aufrufen muss. Bei dem Webinstaller liegt es wahrscheinlich an Skriptlimitierungen, in der Shell stehen oft mehr Reesourcen für die Programme zur Verfügung. Viele Grüße HTH EDIT: Ich habe 4.2.1 gerade auf einem managed hosting paket von df installiert und es lief ohne Probleme. Wenn für den managed server keine zusätzlichen Limitierungen gesetzt wurden, sollte dies dort auch funktionieren. Beim managed server können die Limits auch aufgehoben werden: einfach den Support von df kontaktieren.
Hi thinknext, wir haben die Installation und Updatepakete ein wenig optimiert, sodass diese jetzt auch auf weniger “potenten” Systemen besser funktionieren sollten. Lade dir einfach noch einmal ein Paket herunter und versuche es noch einmal. An der Shopware Version selbst haben wir aber nichts verändert. Viele Grüße, Marcel
Den Fehler hatte ich auch einmal gehabt und hab einfach den Timeout von PHP verändert in der config und gut ist
Hab ich alles gemacht mit der php… DF hat jetzt das Limit hoch gesetzt und oich uppe grad das neue Pack. Ich werde gleich berichten Danke vorab für die Antworten und Hilfeleistungen. lg
Perfekt. Das neue Update Paket lief ganz sauber durch. Vielen Dank!!
Bei mir klappte das Update auch - Shop lief - getestet bis in den Paypal checkout. dann kam ich auf die Idee im Backend den Cache zu löschen. Das dauerte sehr lange und wurde nicht abgeschlossen. Deshalb habe ich es abgebrochen. Nun ist Shop Frontend und Backend tot. [quote]Fatal error: Uncaught exception ‚RuntimeException‘ with message 'Unable to write in the logs directory (/www/htdocs/w00f87e0/logs) ’ in /www/htdocs/w00f87e0/engine/Shopware/Kernel.php:428 Stack trace: #0 /www/htdocs/w00f87e0/engine/Shopware/Kernel.php(314): Shopware\Kernel->buildContainer() #1 /www/htdocs/w00f87e0/engine/Shopware/Kernel.php(235): Shopware\Kernel->initializeContainer() #2 /www/htdocs/w00f87e0/engine/Shopware/Components/HttpCache/AppCache.php(250): Shopware\Kernel->boot() #3 /www/htdocs/w00f87e0/vendor/symfony/http-kernel/Symfony/Component/HttpKernel/HttpCache/HttpCache.php(430): Shopware\Components\HttpCache\AppCache->forward(Object(Symfony\Component\HttpFoundation\Request), true) #4 /www/htdocs/w00f87e0/vendor/symfony/http-kernel/Symfony/Component/HttpKernel/HttpCache/HttpCache.php(330): Symfony\Component\HttpKernel\HttpCache\HttpCache->fetch(Object(Symfony\Component\HttpFoundation\Request), true) #5 /www/htdocs/w00f87e0/engine/Shopware/Components/HttpCache/AppCache.php(178): Symfony\Component\HttpKernel\ in /www/htdocs/w00f87e0/engine/Shopware/Kernel.php on line 428[/quote] -------------------------------------- Update: OK Problem gelöst der /logs stand auf 700 und nicht 777 und dann funktionierte auch das löschen des cache wie gewohnt.
Mir wird mitlerweile immer schlecht wenn ich sehe das Leute die Ordnerstrutkur auf 777 machen
Optimal wäre es wenn es eine Liste gäbe die sagt welche Zugriffseigenschaften die Ordner haben sollen.
[quote=„Feanta“]Mir wird mitlerweile immer schlecht wenn ich sehe das Leute die Ordnerstrutkur auf 777 machen[/quote] Wieso wird Dir da schlecht?
Macht Shopware doch automatisch: wiki.shopware.de/Systeminfo_detail_839_644.html#Shopware-Verzeichnisse Gruss Ken
[quote=„jox“][quote=„Feanta“]Mir wird mitlerweile immer schlecht wenn ich sehe das Leute die Ordnerstrutkur auf 777 machen[/quote] Wieso wird Dir da schlecht?[/quote] Weil man den Besitzer des Ordners einzustellen hat und chmod 644, denn mit 777 gehst du das Risiko ein das fremde deine Daten einsehen und verändern können.
[quote=„kenwood“]Macht Shopware doch automatisch: wiki.shopware.de/Systeminfo_detail_839_644.html#Shopware-Verzeichnisse Gruss Ken[/quote] Wenn das so toll automatisch passieren würde, hätte ich nicht nach dem Update nachbessern müssen. Ganz abgesehen davon das im verlinkten Wiki volle Lese und Schreibrechte steht was nun mal 777 ist. Ob für andere Ordner 755 besser ist weis ich aber nicht. Auch das löschen der nach dem Update überflüssigen Ordner musste ich von Hand durchführen weil das Update-Programm nicht konnte. Vermutlich auch weil nicht alles auf 777 stand. Stellt man aber alles auf 777 ist es angeblich ein Sicherheitsproblem. Deshalb wär hier mal ein vollständige Liste welcher Folder wie eingestellt sein sollen sinnvoll.
Hallo, Automatisch geht das nicht, so war das auch wohl nicht gemeint. Es geht eher darum, dass Shopware abprüft, ob die wichtigen Ordner die korrekte Rechte haben. Sonst funktioniert die Software ggf. einfach nicht mehr. Es gibt einfach Ordner die volle Lese und Schreibzugriffe haben müssen. Sonst wird das mit Cache anlegen, Updates und Installationen von Plugin etc. schwer 
Alle anderen müssen nur ausgeführt werden können. Und es hat kein Update o.ä. gegeben, wo wir in dem Bereich irgendwas nachbessern mussten. Da muss dann eine Fehlinfo vorliegen. An den Bereichen hat sich nichts geändert und einige Ordner gibt es seit Shopware 2 bereits. Die letzte Nachbesserung wurde nur gemacht, damit Installer oder Updater auf weniger performaten Hostingplattformen schneller bzw. überhaupt durchlaufen. Das hatte nichts mit Fehlen zu tun. Nur als allgemeine info Wenn das Updatescript keine Dateien oder Ordner löschen konnte kann das bei dem Hosting verschiedenste Ursachen haben. Beispielsweise “gehören” diese einem anderen Benutzer oder FTP User. Natürlich muss dafür aber kein 0777 überall gesetzt sein! Sebastian