Und wie komme ich da ran?
Da hört mein Wissen über Shopware auf…Im Browser debuggen hat nichts mit Shopware zu tun. Bei Chrome Rechte Maustaste drücken und „untersuchen“ auswählen.
Achso ja das kenne ich aber wo soll ich denn da in dem ganzen Kauderwelsch nach was suchen???
So sieht das ganze dann mit dem UNtersuchen in Chrome aus:
Also wenn es bei mir mit updates aus dem backend heraus hürden gab, war ausschließlich die server konfig schuld. Dabei hat es sich aber immer nur um rechte der ordner gehandelt.
Der server ist mittlerweile so konfiguriert worden, dass das update komplett im backend von beginn bis ende in ca. 20 sec. Erledigt ist.
Ich muss lediglich nur noch den ordner update assets am server manuell löschen.
Das klappt bei 2 sw shops gleichermassen.
Ich glaube nicht dass dein hoster recht hat.
Dein server wird nicht richtig eingestellt sein auch wenn die das behaupten. Das liegt deinem problem am nächsten.
Kann natürlich auch sein dass du selber anfangs im sw irgendwo was unwissentlich kaputt gemacht hast.
Aber so schnell und sauber wie sw momentan updatet habe ich das noch bei keiner einzigen shopsoftware gesehen.
Im gegenteil könnte ich dir da sachen mit anderer software erzählen dass du meinst ich habs nicht mehr alle 
Schnapp dir dein hoster und hake nach.
wenn du nicht weiterkommst solltest du den fall an einen profi hier aus dem forum kostenpflichtig übergeben. Das ist bei weitem nicht so teuer wie man anfangs meint weil die stundensätze so hoch sind. Weil der profi diese fehler oftmals schon nach wenigen minuten gefunden hat.
Gerne empfehle ich dir einen per pm
Wenn dann dein shop oder server repariert ist werden die updates in zukunft dann auch so schnell gehen wie bei mir.
Viele Grüße
Matthias
Also die Rechte der Ordner habe ich alle im Kundenbereich des Hosters geändert weil das über FileZilla keine Änderung brachte. Das war aber auch schon immer so.
Trotzdem tut sich nach klick auf Update straten nichts.
So da es immer noch nicht per BAQckand mit dem Update klappt, habe ich jetzt mal wieder per FTP des Hosters das Update hochgeladen und auf dem Server dann entpackt.
Ich musste nun bei etlichen Dateien die Besitzreche ändern was aber dann irgendwann ok war.
Dann habe ich im Browser meine Domain mit dem Zusatz laut Anleitung von SW http(s)://www.mein-shop.de/recovery/update aufgerufen.
Darauf hin kam dann auch Datenbankupdate durchführen und dann kam die Seite AUFRÄUMEN dort zeigte er verschiedene Dateien an die er löshen wollte weil sie ja nicht mehr benötigt werden.
Daraufhin erhalte ich jetzt folgende Fehlermeldung (auch ein ändern der Besitzrechte und setzen auf 777 brachte keine Änderung):
Slim Application Error
The application could not run because of the following error:
Details
Type: UnexpectedValueException
Message: RecursiveDirectoryIterator::__construct(/www/htdocs/w0144b89/korallenzucht-wolfs.de/logs): failed to open dir: Permission denied
File: /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/update/src/Utils.php
Line: 256
Trace
#0 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/update/src/Utils.php(256): RecursiveDirectoryIterator->__construct(’/www/htdocs/w01…’, 4096)#1 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/update/src/Controller/CleanupController.php(143): Shopware\Recovery\Update\Utils::cleanPath(’/www/htdocs/w01…’)#2 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/update/src/app.php(158): Shopware\Recovery\Update\Controller\CleanupController->cleanupOldFiles()#3 [internal function]: {closure}()#4 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/common/vendor/slim/slim/Slim/Route.php(462): call_user_func_array(Object(Closure), Array)#5 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/common/vendor/slim/slim/Slim/Slim.php(1326): Slim\Route->dispatch()#6 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/common/vendor/slim/slim/Slim/Middleware/Flash.php(85): Slim\Slim->call()#7 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/common/vendor/slim/slim/Slim/Middleware/MethodOverride.php(92): Slim\Middleware\Flash->call()#8 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/common/vendor/slim/slim/Slim/Middleware/PrettyExceptions.php(67): Slim\Middleware\MethodOverride->call()#9 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/common/vendor/slim/slim/Slim/Slim.php(1271): Slim\Middleware\PrettyExceptions->call()#10 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/update/index.php(69): Slim\Slim->run()
#11 {main}
NAch erneutem Aufrufen des Backups erhalte ich jetzt immer folgenden Fehler:
Slim Application Error
The application could not run because of the following error:
Details
Type: ErrorException
Code: 2
Message: chmod(): Operation not permitted
File: /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/update/src/FilePermissionChanger.php
Line: 59
Trace
#0 [internal function]: Slim\Slim::handleErrors(2, ‘chmod(): Operat…’, ‘/www/htdocs/w01…’, 59, Array)#1 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/update/src/FilePermissionChanger.php(59): chmod(’/www/htdocs/w01…’, 509)#2 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/update/src/app.php(166): Shopware\Recovery\Update\FilePermissionChanger->changePermissions()#3 [internal function]: {closure}()#4 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/common/vendor/slim/slim/Slim/Route.php(462): call_user_func_array(Object(Closure), Array)#5 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/common/vendor/slim/slim/Slim/Slim.php(1326): Slim\Route->dispatch()#6 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/common/vendor/slim/slim/Slim/Middleware/Flash.php(85): Slim\Slim->call()#7 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/common/vendor/slim/slim/Slim/Middleware/MethodOverride.php(92): Slim\Middleware\Flash->call()#8 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/common/vendor/slim/slim/Slim/Middleware/PrettyExceptions.php(67): Slim\Middleware\MethodOverride->call()#9 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/common/vendor/slim/slim/Slim/Slim.php(1271): Slim\Middleware\PrettyExceptions->call()#10 /www/htdocs/w0144b89/korallenzucht-wolfs.de/recovery/update/index.php(69): Slim\Slim->run()
#11 {main}
Da stimmen definitiv Verzeichnisrechte nicht, aber ohne deine genaue Ordnerstruktur zu kennen kann man hier schlecht helfen…
Was willste wissen?
Kann dir alles nennen oder Screenshots machen.
Denn ich bin echt am Ende meines mikrigen Wissens hierzu angelangt und recht genervt das ein simples Upadte ständig solche Probleme macht.
Ich bin grad nicht vor nem computer aber zuhause schreib ich mal ausführlich. Wichtig ist dass der Besitzer aller Dateien der gleiche ist der auch als PHP User eingetragen ist. Bei fast-cgi ist das meistens dein ftp user, bei mod-php ist es der www-data. chmod kann nur der besitzer durchführen!
all-inkl premium ist gut. den kenn ich. schick mal screenshots von der php einstellung im kas. außerdem mal einen ss-account anlegen und mit ‘ls -laR > files.txt’ ne liste aller dateien und ordner samt besitzer machen.
achtung: könnte sensitive informationen beinhalten!
es könnte auch reichen wenn du im kas die besitzrechte auf den gleichen user stellst wie php ausgeführt wird!
Also screenshot vom kas kann ich gerne machen aber was du mit „ss-account anlegen und mit ‚ls -laR > files.txt‘ ne liste aller dateien und ordner samt besitzer machen“ meinst da habe ich keinen Plan 
Ich bin grad nicht vor nem computer aber zuhause schreib ich mal ausführlich. Wichtig ist dass der Besitzer aller Dateien der gleiche ist der auch als PHP User eingetragen ist. Bei fast-cgi ist das meistens dein ftp user, bei mod-php ist es der www-data. chmod kann nur der besitzer durchführen!
Das habe ich gerade gecheckt Besitzer ist der selbe wie im FTP im KAS angezeigt wird, also doch eigentlich richtig.
ich meinte ssh, sorry.
und wie wird php ausgeführt? mod-apache oder fastcgi?
Ich bin grad nicht vor nem computer aber zuhause schreib ich mal ausführlich. Wichtig ist dass der Besitzer aller Dateien der gleiche ist der auch als PHP User eingetragen ist. Bei fast-cgi ist das meistens dein ftp user, bei mod-php ist es der www-data. chmod kann nur der besitzer durchführen!
Das habe ich gerade gecheckt Besitzer ist der selbe wie im FTP im KAS angezeigt wird, also doch eigentlich richtig.
Hast du TeamViewer, da könnte ich mal nach den Rechten schaue und gegebenfalls den Eintrag in die htaccess machen. Wenn du willst als PM
Uwe
Ich bin grad nicht vor nem computer aber zuhause schreib ich mal ausführlich. Wichtig ist dass der Besitzer aller Dateien der gleiche ist der auch als PHP User eingetragen ist. Bei fast-cgi ist das meistens dein ftp user, bei mod-php ist es der www-data. chmod kann nur der besitzer durchführen!
Das habe ich gerade gecheckt Besitzer ist der selbe wie im FTP im KAS angezeigt wird, also doch eigentlich richtig.
Hast du TeamViewer, da könnte ich mal nach den Rechten schaue und gegebenfalls den Eintrag in die htaccess machen. Wenn du willst als PM
Uwe
Habe dir eine Nachricht geschickt
Und, konntet ihr das Problem beheben?
Nein aber wir konnten es evtl. auf ein oder mehrere Plugins schieben, leider ist der FTP Server sowie die Datenbank nun dermasen zerschossen, dass diese erst mal wieder vom Backup aufgespielt werden muss.
Uwe hat sich aber wirklich sehr intensiv und verdammt lange versucht per Telefon und Teamviewer der Sache Herr zu werden, leider halt ohne Erfolg.
Sobald das Backup aufgespielt ist werde ich die Plugins löschen (obwohl eigentlich im Backend bei der Plugin-Prüfung keine Fehler angezeigt wurden.) und dann halt wieder mein Glück versuchen.
Weiterhin viel Glück. Kannst dich gerne melden wenn du Hilfe brauchst!
Thomas
So,
habe es eben durch ZUFALL geschafft das Update zu machen.
Kurrios aber es ging wie folgt:
Update im Backend gestartet, nichts passiert.
Bei All-Ink.com im KAS eingeloggt in der htacces AddHandler php70-cgi .php eingetragen dann startete das Update ABER ich bekam nach dem AUFRÄUMEN den Fehler 500 wie sonst auch. (Die Dopmain habe ich auch auf PHP 7.0 per CGI eingestellt)
DANN wieder in der hatacces auf AddHandler php56-cgi .php umgestellt und das Update wieder ausgeführt NUR im BROWSER in der Befehlszeile das DONE entfernt, dann fängt er wieder beim Upadate der Datenbank an , dann kommt aufräumen und PENG LOGIN IM FRONTEND ODER BACKEND
Schnell auf Backend geklickt und das BAckend lädt sich neu und siehe da, Shop ist jetzt 5.2.22
Frontend aktualisiert nach ner weile verschindet DER SHOP IST IM WARTUNGSMODUS und die Seite lädt wie sie soll.
Sehr kurriose Sache.
Jetzt vermute ich aber mal, weil ja als PHP in der htacces AddHandler php56-cgi .php steht, dass ich dann beim nächsten Upüdate wieder Probleme bekomme, stelle ich es um auf AddHandler php70-cgi .php und ich aktualisiere das Frontend wird mir da die Menüleiste und alles was darunter ist NICHT angezeigt. (Die Domain läuft jetzt trotzdem noch als php 7.0 (cgi)
Jemand ne Idee wie ich das frontend auch unter PHP 7.0 ans laufen kriege OHNE das die Hälfte der Seite fehlt?
Bekommst Du Fehlermeldungen im Error-Log der Website oder im Shopware-Log, wenn Du testweise kurz auf PHP 7 umstellst? Ich vermute, daß Du Plugins nutzt, die nicht mit PHP 7 kompatibel sind.
Timme Hosting - schnelles nginx-Hosting