Problem beim Update von GX2 auf GX3

[Franz Bludorf]

Ich kam übrigens noch auf die grandiose Idee, den Cache vor dem Update zu löschen, brachte aber auch nichts. Wie nicht anders zu erwarten übrigens. Das ist so ein Heisenbergscher Quanten-Beobachtereffekt - um den Cache des Shops zu löschen, muss ich eine Seite eben dieses Shops aufrufen, und die legt dann ihre Hinterlassenschaften natürlich wieder im Cache ab...
Ich werde noch versuchen, den Cache-Ordner manuell über SSH zu löschen, obwohl ich das für Ferkelei halte (Oh du mein liebes Ubuntu...)

[BigRib]

Warum löscht du den inhalt der beiden cache ordner nicht per ftp? Lass aber die .htaccess ab leben.

[Franz Bludorf]

Auf die Idee war ich, wie schon gesagt, auch gekommen, hilft aber nicht. Selbst wenn ich nach dem Update beide Ordner noch mal lösche stürzt er ab. Eine Include-Datei will immer noch german.php laden, das (angekündigt) gelöscht war. Abgesehen davon, dass ich solche Ferkeleien, die Gambio nirgends dokumentiert, nicht schätze. Es muss doch mehr straightforward gehen. Schließlich gibt es auch Shopbetreiber, die keine Computer-Cracks sind. Trotzdem - danke für den Hinweis. Muss weiter gucken.

[BigRib]

werden denn logs geschrieben? Wenn ja zeig mal.

[Franz Bludorf]

Es kommt im Grunde immer das selbe, ich gebe mal den Eintrag aus dem Error-Log wieder, das Gleiche in etwa wird auch im Browser angezeigt, wenn man eine Shopseite aufrufen will

[Wed Feb 01 09:27:25.253482 2017] [proxy_fcgi:error] [pid 19699] [client 83.31.99.174:60250] AH01071: Got error 'PHP message: PHP Fatal error: require(): Failed opening required '/var/www/vhosts/h2632858.stratoserver.net/webshop.fosar-bludorf.com/lang/german/german.php' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/vhosts/h2632858.stratoserver.net/webshop.fosar-bludorf.com/includes/application_top.php on line 569\n', referer: https://webshop.fosar-bludorf.com/ga...anguage=german

Er findet also die Datei lang/german/german.php nicht, und das darf er im Grunde auch nicht, denn der Updater sagt ausdrücklich, dass er sie löscht.
application_top.php mit einem Aufruf des Sprachskripts in Zeile 569 ist die alte Version 2.2.0.0, die eigentlich überschrieben sein sollte mit der neuen, die auch ein Sprachskript aufruft, aber in einer anderen Zeile und auch mit anderem Algorithmus.
Das bedeutet, das Kopieren der Update-Dateien in den Shopordner klappt trotz Überschreibe-Option nicht ordnungsgemäß, und das reproduzierbar!

Ich habe dieses Kopieren bislang mit Plesk gemacht, mit dem File-Manager, weil es da eins-fix-drei geht. FileZilla kann nicht von einem Serverordner direkt in den anderen kopieren, sondern muss immer Download und Upload machen, und das dauert natürlich bei den Tausenden kleiner Dateien ewig.

Ich denke, ich muss jetzt mal direkt in die Ubuntu-Shell gehen und die Dateien mit Linux-Befehlen kopieren. Vielleicht ist das zuverlässiger?

[Franz Bludorf]

Jetzt hat er definitiv das neue application_top.php drin, fliegt aber trotzdem raus. Der Browser meldet:

WARNING(2): "require_once(/var/www/vhosts/h2632858.stratoserver.net/webshop.fosar-bludorf.com/inc/country_eu_status_by_country_id.inc.php): failed to open stream: No such file or directory"

Fatal error: require_once(): Failed opening required '/var/www/vhosts/h2632858.stratoserver.net/webshop.fosar-bludorf.com/inc/country_eu_status_by_country_id.inc.php' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/vhosts/h2632858.stratoserver.net/webshop.fosar-bludorf.com/includes/application_top.php on line 213
COMPILE ERROR(64): "require_once(): Failed opening required '/var/www/vhosts/h2632858.stratoserver.net/webshop.fosar-bludorf.com/inc/country_eu_status_by_country_id.inc.php' (include_path='.:/usr/share/php:/usr/share/pear')"

Ich betone, dass mein Shop keine Codemodifikationen enthält. Alle Einstellungen und Einfügungen wurden ausschließlich über die Admin-Oberfläche gemacht.

[Franz Bludorf]

Ich habe jetzt die Faxen dicke und versuche, direkt den GX3 3.0.0.0 in einem Unterordner zu installieren und später den Import-Assistenten zu benutzen. Das scheint aber auch nicht zu klappen. Der Installer startet und fragt die neue leere Datenbank ab, aber wenn ich dann auf "Shopeinrichtung starten" klicke - still und starr ruht der See. Keine Fehlermeldung, kein Logeintrag. Schon beim Eintragen der Datenbankdaten hat man das Gefühl, mit einem Toten zu kommunizieren. Früher hat er immer gemeckert "Datenbank existiert nicht", wenn man das Feld noch nicht ausgefüllt hatte, und wenn ich SSL-Übertragung ankreuze wird http auch nicht in https geändert.

Mit der allerneuesten Shopversion läuft die Installation problemlos, aber für die kann man den Import-Assistenten nicht aufrufen, und ich will ja nicht die ganzen Artikel und Kunden neu einpflegen.

Ist der 3.0.0.0 irgendwie defekt?

[KlausK]

@Franz

Auf die Idee war ich, wie schon gesagt, auch gekommen, hilft aber nicht.

wie schon gesagt?? Ich habe hier noch nichts davon gelesen, dass du versucht hast den Cache via FTP zu leeren! Vielleicht bin ich ja auch blind

Die german.php gibt es tatsächlich nicht mehr. Und dass die trotzdem noch aufgerufen wird, liegt daran, das die Caches nicht ordnungsgemäß geleert sind!

1. Gehe mit deinem FileZilla (oder was auch immer) in das Verzeichnis /cache deines Shops und lösche dort alles außer .htaccess und index.html
2. Das gleiche machst du mit dem Verzeichnis /templates_c
3. Danach nimmst du einen Browser der deinen Shop noch nie gesehen hat. M.E. funktioniert der Chrome mit einem Inkognito-Tab für sowas cacham besten!
4. Damit wirst du dich dann problemlos anmelden können.
5. Dann gehst du in deinem Adminbereich >>> Toolbox >>> Cache leeren und löschst dort nochmal sämtliche Caches.
6. Dann sollte alles wie gewohnt funktionieren und du kannst mit dem nächsten Update fortfahren.

Übrigens:
Ich kann problemlos in deinem Shop rumspazieren ohne auch nur eine einzige Fehlermeldung zu sehen!

[Franz Bludorf]

@Franz
Übrigens:
Ich kann problemlos in deinem Shop rumspazieren ohne auch nur eine einzige Fehlermeldung zu sehen!

Na klar - immer wenn ein Update nicht klappte und der Shop danach abstürzte, habe ich natürlich den Backup des alten Shops zurückgeladen. Der ist ja im Einsatz für die Kunden und kann nicht tagelang offline sein. Während der Denkpausen war der immer aktiv!

Das ganze Problem hat sich mittlerweile erledigt. Als gestern sogar die Neuinstallation in einem neuen Unterverzeichnis gx3 auch nicht ging, ist mir endgültig der Kragen geplatzt. Ein böser Verdacht kam in mir hoch. Vielleicht war bei dem ersten Update von 2.1.2.0 (meine ursprüngliche Version) auf 2.2.0.0 (bei dem mich der Updater mit "Glückwunsch" verabschiedet hatte), etwas schief gegangen, was nicht gemeldet wurde.
Auf jeden Fall ging ich zurück auf die ursprüngliche Version 2.1.2.0 - und zwar nicht aus dem Backup, sondern komplette Neuinstallation - die auch funktionierte - dann Datenbank und Ordner Download, Images und Media aus dem Backup geholt sowie die configure-Dateien, Shop kurz getestet, dass alles lief, dann 2.2.0.0 neu reingeschmissen, Glückwunsch empfangen. Dann der spannende Moment 2.4.0.1 noch mal probiert - Bimmeldibammeldibumm - funktioniert jetzt auch... Mission accomplished, ich werde mich jetzt den nächsten Updates vertrauensvoll zuwenden.

Im Grunde ein Mysterium das Ganze. Wie ich schon in einer Antwort sagte - ich habe nirgends im Shop im PHP-Code rumgeschmiert, alle Einstellungen nur über die Admin-Oberfläche vorgenommen, die sollten also säuberlich abgegrenzt in den drei oben genannten Ordnern oder in der Datenbank stehen. Aber ich weiß aus Erfahrung, dass sich in einer laufenden Software mit der Zeit allerhand Müll ansammeln kann.

Vorerst vielen Dank an alle User, die sich Mühe gegeben haben, mit Rat und Tat mitzuhelfen. Wenn es mir tatsächlich gelingen sollte, mich mit den Updates bis zur aktuellen Version durchzuwursteln, sage ich noch mal Bescheid. Versprochen.

Zumal ich ja dann das Vergnügen habe, noch unseren zweiten Shop upzudaten - und der ist noch wichtiger, weil erstens frequentierter und zweitens, nicht mein privater, sondern der von der Redaktion, für die ich arbeite...

[Franz Bludorf]

So ganz problemlos weitergehen tut es übrigens nicht. Wenn ich jetzt MU 2.6.0.0 aufrufe, komme ich bis zum Moment, wo man "Update starten" klicken muss, und dann tut sich nix mehr. Nicht, dass meine Internetleitung zu langsam wäre. Ich erkenne, dass der Update-Button auf der Seite überhaupt deaktiviert wird und daher gar kein Ereignis zum Server überträgt. So erscheint z. B. im Browser-Tab oben keine Eieruhr, und in der Statuszeile unten zeigt er auch nichts an, dass er auf eine Serverantwort wartet. Es geschieht ganz einfach gar nichts, so als ob ich auf den blauen Hintergrund geklickt hätte.

Meines Wissens nach muss das an falsch gesetzten Dateizugriffsrechten liegen (ich liebe Linux!!! ), und in der Tat, in meinem Error-Log finde ich Folgendes:
[Thu Feb 02 11:02:36.353010 2017] [core:error] [pid 28620] (13)Permission denied: [client 83.24.213.35:54964] AH00132: file permissions deny server access: /var/www/vhosts/h2632858.stratoserver.net/webshop.fosar-bludorf.com/gm/javascript/jquery/jquery.min.js, referer: https://webshop.fosar-bludorf.com/ga...anguage=german

Die Installationsanleitung für MU 2.6.0.0 enthält keine Hinweise auf irgendwelche Dateirechte, die manuell anzupassen wären. Die beanstandete Datei ist Teil des Updates (das ich für die Zeit der Fehlersuche natürlich wieder rausgeschmissen habe). Im Original-MU-Ordner sah ich, dass die Datei die Rechte 660 hat. Da ich auch Typo3 benutze weiß ich, dass damals bei der Portierung meiner Typo3-Installation auf den jetzigen Server solche Dateien tatsächlich nicht funktionierten - hängt irgendwie mit der Apache-Config zusammen, und daran will ich lieber nicht drehen, sondern auf 666 gesetzt werden mussten. Für diese JS-Datei will ich es gerne manuell tun, nur die Frage ist - gibt es im Updater noch mehr von dem Zeug? Ich will mich jetzt auch nicht aufs Geratewohl durch diesen Wust von Update-Ordnern durchklicken.