Hallo,
ich bin bei Allinkl und habe das Update via FTP durchgeführt.
Am Ende kam der Hinweis, dass die PHP Version zu alt ist.
Daher habe ich den Handler für PHP 5.6 in die .htaccess eingefügt.
Danach kommt aber 503 Service Unavailable im Back und Front End.
Ich habe auch schon per phpMyAdmin die Plugins deaktiviert ohne Erfolg.
Was kann ich noch versuchen?
Gruß Mario
Hat niemand einen Tip?
ALLINKL bietet mir an, den Account auf einen Server mit PHP 5.6 umzuziehen.
Aber ich bin fast sicher, dass das nicht das Problem ist.
Kann ich irgendwie debuggen, was da klemmt?
Gruß Mario
Hallo,
da PHP 5.6.4 das Minimum für die Shopware Version 5.2.1 ist, wird es sicher daran liegen, dass dein Hostingpaket kein PHP 5.6.4 hat. Ein Eintrag in der .htaccess wird da nicht viel bringen, wenn Shopware PHP - Funktionen einsetzt, die erst ab PHP Version 5.6.4 vorhanden sind - deswegen sind sie ja dann trotzdem nicht vorhanden, auch nicht durch den .htaccess - Eintrag.
Ein Update über das Backend anzustoßen wäre immer der bessere Weg - da wird einem angezeigt, was man mindestens benötigt und vor allem welche Plugins kompatibel mit der Version sind.
Beste Grüße
Sebastian
Ok, also muss der Server PHP 5.6.4 fahren und nicht nur per .htaccess die Handler einbinden.
Das hätte ich vorher lesen sollen 
Aber so ist das nun mal, wenn es zig mal gut geht…
Also, All-Inkl. hat eigentlich auf allen Paketen auch 5.6 und 7.0 - bei „alten“ allerdings nur per CGI
Deine verfügbaren PHP-Versionen kannst Du im KAS einsehen.
Aber Achtung: Auch wenn im KAS für die Domain PHP 5.5.x als „eingestellt“ steht - der addhandler in der htaccess ist vorranging!
Wie war es denn vorher eingestellt?
Wenn weder im KAS CGI eingestellt war, noch per AddHandler in .htacces auf CGI umgestellt wurde, lief der Shop vorher als Apache-Mod - und damit mit einer anderen Userkennung - und Dateirechten. Da hast Du dann aber via FTP Dateien mit Deinen Hauptuser/PHP-user drübergebügelt. Es dürften also verschiedene Besitzerrechte vorliegen.
Noch besser: Erst lief das Update via MOD und nach AddHandler via CGI => Shopware kann nichtmal selber den Cache leeren, wenn die Rechte falsch sind.
Wenn jetzt also ERSTMALS auf per Addhandler auf CGI umgestellt wurde, müsstest Du zuerest im KAS=>FTP für das ganze Shopware-Verzeichnis und alle Unterordner/Dateien die Besitzerrechte auf den PHP-user umstellen. Wenn schon vorher CGI: ignorieren 
Wenn Du allerdings addhandler wieder entfernst und auch danach kein CGI via KAS aktivierst hast, müsstest Du auf dem gleichen Weg wieder die Besitzerrechte auf WWW-User (Apache-MOD) umstellen.
Grundsätzlich läuft Shopware zuverlassig - wenn auch meistens langsam - bei All-Inkl unter PHP 5.6 - und wenn keine verschlüsselten Plugins vorhanden sind - auch unter PHP7 (kein ioncube). Selbst auf meinen asbachurlat-Privat-Plus-Vertrag ist PHP 7 per CGI verfügbar.
Ich hatte nach dem Update auf 5.2.1 im letzten Schritte „/done“ (nach dem Aufräumen) einen 503 - ich habe dann per FTP „var/cache/“ und die Update-Verzeichnisse gelöscht - danach lief der Testshop wieder.
Was die „Besitzerrechte“ von „Apache-MOD“ und „PHP-User“ betrifft, verschweigt All-Inkl. gerne.
Generell empfehle ich bei All-Inkl. alles per CGI laufen zu lassen, so kommt der FTP/PHP-user nie dem WWW-User in die Quere.
Ich lasse erstmal ein Backup einspielen, damit der Shop wieder läuft.
Dann werde ich wohl auf einen moderneren Server umziehen.
Das mit den Nutzerrechten hat mich schon oft geärgert.
Per FTP hochgeschoben, vom Shop nicht nutzbar.
Bei älteren Updates musste man immer Owner und Rechte ändern. Bei den letzten paar Updates nicht.
Deshalb bin ich da etwas unbedarft ran gegangen.
Wie lasse ich denn alles per CGI laufen?
Das würde ich dann gern einrichten, wenn der Umzug durch ist.
Es gibt zwei Wege:
Für .htaccess gilt: Die Einstellungen überschreiben jeweils die Übergeordneten und gelten - sofern nicht wieder überschrieben - für alle Unterordner -> die Einstellung von KAS würde also überschrieben werden - sauberer Weg ist für mich immer die Änderung in der .htaccess 
Bei einer Neuinstallation von Shopware z.B. erst alles mit FTP hochladen (oder besser: archive hochladen, und via KAS=>FTP entpacken), und vor dem Instscript die htacces von Shopware zuerst mit Addhandler erweitern.
In Deinem Fall: Backup zurückspielen, .htaccess anpassen, KAS-FTP-Login Besitzerrechte ändern (oder von allinkl. machen lassen) - per FTP Update hochladen, ausführen, und nie wieder Rechteprobleme haben. 
Die ersten drei Zeilen meiner .htaccess sehen so aus:
AddHandler php70-cgi .php
php_value memory_limit 512M
php_value max_execution_time 90
Welche Basis hat den Dein Shop? Ggf. läuft Dein Update (von glaube < 5.1.4) in einen SQL-Fehler mit “mapping_id” - mal im Forum nach Suchen, da hat nämlich All-Inkl. eigenmächtig in diversen Shops schon einen Datenbankindex gesetzt, der von Shopware erst ab (5.1.4 glaube ich) gesetzt wird, und zu einem Abbruch führt. Wenn von 5.1.5 oder 5.1.6 geupdated wird, ist das Thema schon erledigt.
Es geht aber hierbei um mind. PHP 5.6.4 und nicht nur PHP 5.6.X ( 0 -3 ).
Allerdings sollte der Fehler entsprechend in den Shopware Logs stehen.
Aber auch dir empfehle ich einmal folgenden Update Guide durchzulesen, bevor man updatet: Shopware 5 upgrade guide
Für die Zukunft solltest du dir auch merken, dass man niemals einen Liveshop blind updated, dass Ergebnis ist was du nun hast: Shop ist offline. Weder gut für dich, noch für die Kunden.
Meine Pakete sind alle bei 5.6.21 - und da All-Inkl. wohl ein Interesse daran hat, eine einheitliche Basis zu haben, wird dort wohl kaum noch < 5.6.4 vorhanden sein.
Ich lasse erstmal ein Backup einspielen, damit der Shop wieder läuft.
Dann werde ich wohl auf einen moderneren Server umziehen.
Das mit den Nutzerrechten hat mich schon oft geärgert.
Per FTP hochgeschoben, vom Shop nicht nutzbar.
Bei älteren Updates musste man immer Owner und Rechte ändern. Bei den letzten paar Updates nicht.
Deshalb bin ich da etwas unbedarft ran gegangen.
Wie lasse ich denn alles per CGI laufen?
Das würde ich dann gern einrichten, wenn der Umzug durch ist.
Die Rechte kannst du global für ein Verzeichnis einfach im KAS unter Tools > Besitzrechte ändern.
Mehr oder weniger ein Klick und die Aktion hätte dein Problem vermutlich schon gelöst.
Meine Pakete sind alle bei 5.6.21 - und da All-Inkl. wohl ein Interesse daran hat, eine einheitliche Basis zu haben, wird dort wohl kaum noch < 5.6.4 vorhanden sein.
Hallo,
das ist (leider) falsch: es gibt noch genug Tarife und Server bei All Inkl, wo die PHP Version noch bei maximal PHP 5.5.35 ist. Man kann aber jederzeit bei All Inkl fragen, ob ein Serverwechsel auf einen Server mit PHP 5.6.21 möglich ist - ging auch jedes Mal ohne Probleme und ohne Kosten. Deshalb würde ich auch von:
AddHandler php56-cgi .php
eher abraten (wie Shopwareianer schon erläutert hat), da dies eben auch die PHP Version 5.6.0 - 5.6.3 einschließt, die nicht die Mindestvoraussetzung sind.
Beste Grüße
Sebastian
Irgendwie habe ich so ein gefühl, hier lesen einige nicht, was geschrieben wird.
Es gibt zwei Versionen - die fest eingestellte - die sich ohne „Umzug“ nicht ändert und als „Apache-Mod“ läuft - da gibt es in der Tat noch 5.5.x.
Dann haben aber alle Pakete auch die möglichkeit, per CGI andere Versionen selber einzustellen - die laufen dann aber nicht per MOD
Ich kenne jedenfalls keinen Server, der nicht wenigstens 5.6.xx (mit xx>>4) anbietet.
Also bitte vorsichtig mit so Aussagen ala „falsch“
Und „addhandler php56-cgi .php“ stellt nicht „irgendeine“ ein, sondern die eine auf dem Server verfügbare, was wiederum im KAS nachgelesen werden kann.
*Mal mit der Umgebung schlau machen kann nicht schaden*
Wer unbedingt auf Probleme mit Schreibrechten bestehen will, soll gerne auf „MOD“ bleiben - ich habe mit meinen Paketen jedenfalls die Erfahrung gemacht, das „CGI“ via „addhandler“ 1) schneller 2) problemloser läuft
Nachtrag: Frisch bezogen Q4 2015:
Mein Server hat nur 5.5.35.
Deshalb werde ich wechseln.
Macht ALLINKL kostenlos.
Durch Backups Einspielen läuft der Shop erstmal wieder.
Ein Hoch auf den Support von ALLINKL!!
Mein Server hat nur 5.5.35.
Deshalb werde ich wechseln.
Macht ALLINKL kostenlos.
Durch Backups Einspielen läuft der Shop erstmal wieder.
Ein Hoch auf den Support von ALLINKL!!
Womit du aber, wie Sonic schon schrieb, wieder die Rechte-Mühsal hast wenn du das Apache Modul verwendest.
Die CGI -Version von 5.6.xx kannst du auch ohne Umzug schon jetzt benutzen. Musst halt nur die Rechte ändern.
Also muss ich PHP 5.6. per .htaccess einbinden. Danach alle Dateiowner auf http user und dann das Update fahren?
Dann sollte das laufen?
Würde den Umzug überflüssig machen.
Hab nur irgendwie Angst, dass der Support von ALLINKL dann wieder Backups einspielen muss.
Die chown -R hatte ich nämlich gestern noch probiert und da blieb der 503.
Gruß Mario
Da wir ja unterschiedliche Aussagen haben, ob nur 5.5.3 oder nicht:
Im KAS siehst Du gleich auf der Startseite, ob weitere PHP Versionen per .htaccess bereitstehen, oder nicht - siehe oben mein Screenshot.
Wenn PHP 5.6 in der Version > 5.6.3 (wahrscheinlich 5.6.21) zur Verfügung steht, musst Du erst einmal nicht umziehen - wenn auch da nur 5.5.3 => Umzug (geht in der Regel gut - kann aber auch mächtig in die Hose gehen - hatte ich letztes Jahr mal *grins*)
Dann stellst Du in der.htaccess mit “AddHandler php56-cgi .php” Dein Shopwareverzeichnis auf PHP 5.6 um - und zwar die 5.6-Version, die im KAS steht.
Die “Besitzerrechte” änderst Du
a) entweder in KAS=>Tools=>Besitzerrechte auf den Eintrag, der über dem Feld auch bei Deinem Login steht - nicht PHP-User!
b) KAS=>FTP “Login” beim Hauptbenutzer => neues Fenster. Da browst Du, bis Du das Shopware-Verzeichnis findest und machst dort einen Haken bei dem Verzeichnis. Wenn SW direkt im Haupverzeichnis liegt, wählst Du alles ausser “cgi-bin”, “logs”, “usage” aus. Dann dropdown “Aktionen” => “Besitzerrechte (chown)” auswählen => OK - Da dann wieder Deine Login-Kennung - NICHT PHP-User.
Offensichtlich wurde die Bezeichnungen früher mal geändert. PHP-User wäre Apache-Modul, “Dein Login” ist CGI-User.
Und wenn es alles nichts taugt, kannst Du auf den gleichen Weg wieder den anderen User auswählen.
Dann läuft der Shop im CGI-Mode => erstmal testen, ob alles noch läuft, vor dem Update.
Wenn Du evtl. verschlüsselte Plugins hast, weiss ich nicht, ob man da ggf. noch etwas wegen “ioncube” machen muss => ggf. Plugin neu installieren(??? Forum fragen ???)
Wenn das alles läuft, guck Dir alle Plugins und das Theme an, ob nicht weitere Vorbereitungen beim Update auf 5.2.2 anfallen.
Im “CGI”-Mode solltest Du auch ohne Probleme das Update ohne FTP aus dem Backend machen können.
Für ein Backup braucht man nicht den Support, das kann man mit Bordmitteln auch selber machen.
und zurück: FTP archive hochladen und via KAS=>FTP entpacken - empfiehlt sich auch für eine Neuinstallation mit dem SW-Original-Archiv.
Mit den Datensätzen kann man sich auch mit einen eigenen Unteraccount eine eigene Testumgebung einrichten - müsste man nur in der config.php die DB-Daten ändern und via DB-Tool noch den Shopnamen auf die Testdomain ändern.
Sonic, du bist Spitze!
Lade mir gerade den Wolf beim runterladen des Shopverzeichnisses. Trotz 136mbit/down.
Testumgebung ist mir mittlerweile auch eingefallen.
Einfach ne subdomain und da den Shop reinkopieren. Dann kann ich nächstes Mal vorher testen.
Sí :-)
Kleiner Tipp vor dem Download/Packen in Zukunft: Cache (var/cache) leeren, und alte „download“- und „backup“-Verzeichnisse in „files/“ löschen - da sammeln sich schon bis zu ein paar GB an!
Archive erstellen dauert auch einige Zeit. All-Inkl. packt auf einen anderen Server => „Tonnen“ von FTP-Zugriffen im Server-Log, nicht wundern, und speichert dann das Archive in Deinem Verzeichnis ab. Du musst zwar die ganze Zeit den Broser auf haben, aber am Ende hast Du nur einen FTP-Transfer. Und wenn Du beim rar „unix“ wählst, werden auch gleich noch die schreib/lese-Rechte mit gesichert.
Du musst auch nicht immer „media/“ ganz sichern - das sicher ich nur vor großen Aktionen und wenn neue Bilder eingestellt wurden - hängt also davon ab, wie oft Du Artikel und andere Grafiken änderst.
Mist, zu spät. Oder ich fange nochmal an.
Rar hatte ich schon. Aber noch Windows und cache nicht geleert. Die ganzen Dateien in Files/downloads und backup können also auch weg.
Hab mich schon gewundert, wo die her kommen.