Bekomme im Reiter „Update durchführen“ folgende Meldungen. Achtung: Für das Update werden für folgende Verzeichnisse/Dateien Schreibrechte benötigt. . (Shopware-Verzeichnis) Die Konfiguration kann nicht übernommen werden. Die Datei „config.php“ ist nicht schreibbar. Ich kann dies nicht nachvollziehen, da alle Schreibrechte auf 777 gesetzt sind.
Das Problem habe ich auch gerade, gibt es da eine Lösung für?
Hab die config.php mal umbenannt, zumindest startet das Update dann, mal sehen
Umbenennen bringt nix, Update läuft sich tot 
Irgendwelche Ideen?
Ich habe jetzt alles Mögliche versucht, habe die config.php mal komplett gelöscht und neu angelegt und 777 gegeben, nix zu machen. Der Updater bemängelt immer wieder fehlende Schreibrechte. Niemand ne Idee und wenn ein noch so kleine ?
Hallo, für alle die das Problem auch haben. Ich konnte es umgehen, in dem ich dem “root” Ordner per SSH 0777 rechte vergeben habe. Nachträglich unbedingt wieder rückgängig machen! Viel Erfolg.
Hängt sich bei mir ebenfalls auf. Leider bringt aber auch das mit den generellen Schreibrechten auf Root-Ebene nichts. Ich habe bereits zum dritten Mal das Backup zurückgespielt…jedes mal aufs neue alle Dateien auf dem FTP markiert und alles (inkl. Unterordner) auf 777 gesetzt. Ich bekomm nen ausraster mit diesem Update!!! :x :x :shopware: :thumbdown:
Hallo, wurden die die Tipps beachtet? Wenn du schreibst es läuft immer weiter, dann gab es entweder einen Fehler im Hintergrund, es gab eine Zeitüberschreitung (max_execution_time soll ja nicht begrenzt sein!) oder es dauer halt wirklich so lange. Das Update sollte ja immer in einer Testumgebung gemacht werden (im ersten Test), damit man überhaupt feststellen kann, ob es zu Problemen kommen kann. Viele Systeme haben über die Zeit doch schon die eine oder andere Anpassung erlebt. Das kann so ein Standard-Updater einfach nicht abfangen! Da muss man, wenn es beim Test Probleme gibt, einfach detaillierter ran gehen, z.B. Debug Ausgaben aktivieren und z.B. Firebug dabei öffnen. So kann man auch erkennen, wenn das Script nicht mehr arbeitet. Im Allgemeinen sind uns bei Erfüllung der Voraussetzungen so keine Probleme bekannt. Wir nutzen das Update-Script ja selber. Ohne genaue Info, z.B. aus Firebug, kann man auch so keinen Tipp geben. Sebastian
Hallo Sebastian, danke für deine Antwort. [quote]wurden die die Tipps beachtet?[/quote] Ja. [quote]Wenn du schreibst es läuft immer weiter, dann gab es entweder einen Fehler im Hintergrund, es gab eine Zeitüberschreitung (max_execution_time soll ja nicht begrenzt sein!) oder es dauer halt wirklich so lange.[/quote] Dann muss es der Fehler im Hintergrund sein denn max_execution_time ist unbegrenzt und die DB hört ab einer gewissen Größe auf weiter zu “wachsen”. [quote]Das Update sollte ja immer in einer Testumgebung gemacht werden (im ersten Test), damit man überhaupt feststellen kann, ob es zu Problemen kommen kann.[/quote] Das ist quasi eine Testumgebung… [quote]Viele Systeme haben über die Zeit doch schon die eine oder andere Anpassung erlebt. Das kann so ein Standard-Updater einfach nicht abfangen![/quote] Ist das erste Update! [quote]Da muss man, wenn es beim Test Probleme gibt, einfach detaillierter ran gehen, z.B. Debug Ausgaben aktivieren und z.B. Firebug dabei öffnen. So kann man auch erkennen, wenn das Script nicht mehr arbeitet.[/quote] Ich habe mit Firebug nichts gesehen…kann man da was falsch machen? Hoffe du kannst mir weiter helfen!
Hallo, wenn du während des Updates Firebug offen hast, so kannst du genau verfolgen, ob Prozesse noch laufen oder nicht. Ansonsten kommt irgendwann ein Fehler, der wiederrum aufschluss geben sollte, was evtl. passiert ist. Das kann z.B. irgendwo am Ende auf eine angepasste Datenbank zurückzuführen sein Sebastian
Hallo Sebastian, hier die Fehlerreport aus Firebug: [code]
Slim Application Error body{margin:0;padding:30px;font:12px/1.5 Helvetica,Arial,Verdana,sans-serif;}h1{margin:0;font-size:48px;font-weight:normal;line-height:48px;}strong{display:inline-block;width:65px;}Slim Application Error
The application could not run because of the following error:
Details
Type: ErrorException
Code: 2
Message: natsort() expects parameter 1 to be array, boolean given
File: /var/customers/webs/web7/update/libs/Shopware/Update.php
Line: 938
Trace
#0 [internal function]: Slim\Slim-\>handleErrors(2, 'natsort() expec...', '/var/customers/...', 938, Array) #1 /var/customers/webs/web7/update/libs/Shopware/Update.php(938): natsort(false) #2 /var/customers/webs/web7/update/libs/Shopware/Update.php(425): Shopware\_Update-\>databaseAction() #3 [internal function]: {closure}('database') #4 /var/customers/webs/web7/update/libs/Slim/Router.php(172): call\_user\_func\_array(Object(Closure), Array) #5 /var/customers/webs/web7/update/libs/Slim/Slim.php(1222): Slim\Router-\>dispatch(Object(Slim\Route)) #6 /var/customers/webs/web7/update/libs/Slim/Middleware/Flash.php(86): Slim\Slim-\>call() #7 /var/customers/webs/web7/update/libs/Slim/Middleware/MethodOverride.php(94): Slim\Middleware\Flash-\>call() #8 /var/customers/webs/web7/update/libs/Slim/Middleware/PrettyExceptions.php(67): Slim\Middleware\MethodOverride-\>call() #9 /var/customers/webs/web7/update/libs/Slim/Slim.php(1174): Slim\Middleware\PrettyExceptions-\>call() #10 /var/customers/webs/web7/update/index.php(65): Slim\Slim-\>run() #11 {main}
[/code]
Hallo zusammen, führe ebenfalls gerade ein Update von SW 3 auf SW 4 durch. Habe hier das gleiche Problem. Komisch an der Sache ist, dass nach dem Update in der Application.php die 4.2.1 als Version hinterlegt ist: class Shopware extends Enlight_Application { const VERSION = ‚4.2.1‘; Führt der Downloadlink ggf. zur falschen Version? Das Update dürfte ja nicht auf die 4.2.1 gehen, oder?
Wir haben das Problem jetzt gelöst, indem wir das Update manuell durchgeführt haben. Die Probleme beim Udate haben wir „einfach“ d.h. per SQL-Befehl ignoriert.
Habe ich ähnlich gemacht. Habe mir hier einen eigenen Updater geschrieben. So haben ich dann jedenfalls Einfluss darauf was passiert. 
Aber trotzdem danke!