Archiv verlassen und diese Seite im Standarddesign anzeigen : Problem beim Update von GX2 auf GX3
Franz Bludorf
29.01.2017, 14:24
Master-Updates werden nicht erkannt
Ich habe von meinem Provider die Nachricht bekommen, dass ab 20. 2. nur noch PHP7 verfügbar sein wird, und muss meinen Webshop jetzt auf GX3 updaten. Momentan benutze ich GX2 Version 2.1.2.0. Aus dem Forum habe ich mir alle nötigen Master-Updates geholt: 2.2.0.0, 2.4.0.1, 2.6.0.0, 3.0.0.0 und, wenn man schon dabei ist, auch 3.2.0.1
Heute habe ich versucht, gemäß der Anleitungen die Updates nach und nach zu installieren. Ich habe also zunächst die Dateien aus dem Shopsystem des jeweiligen Updates ins Masterverzeichnis des Shopsystems kopiert, wobei bestehende Dateien überschrieben wurden. Der anschließende Aufruf von gambio_updater brachte jedes Mal die Meldung, dass "keine zu installierenden Updates gefunden" wurden. Wenn ich danach den Shop aufrief, wurde aber im Admin-Bereich die jeweils neue Versionsnummer angezeigt, obwohl außer dem Kopieren der Dateien nichts getan wurde.
Als ich bei 3.2.0.1 angekommen war und er wieder behauptete, es sei nichts zum Updaten da, versuchte ich anschließend den Shop aufzurufen und erhielt eine Fehlermeldung dass gewisse mysql-Funktionen nicht vorhanden seien.
Ich weiß, dass bei PHP 7 die mysql-Funktionen anders heißen und dass dafür vermutlich Code angepasst werden muss, was der gambio_updater vermutlich machen sollte, aber aus mir unbekannten Gründen nicht tat. Selbst wenn ich bei ihm die Option "Update erzwingen" wählte und die derzeitige Version angab, lief es genauso.
Was mache ich falsch? Müssen eventuell vorher Zugriffsrechte in bestimmten Shopdateien anders gesetzt werden? Ich bin im Moment ratlos, und die Uhr tickt.
Wäre es besser, die Vollversion GX3 herunterzuladen und den Shop ganz neu aufzusetzen? Gibt es dafür auch wieder einen Import-Assistenten? Diese Lösung wäre mir nicht so lieb, da eine ganze Reihe von Dingen (z. B. verfügbare Zahlungsarten und Versandarten) nicht mit importiert werden und manuell neu eingestellt werden müssen.
Welche PHP-Version verwendest du denn seit der GX2 Version 2.1.2.0?
Soweit ich das in Erinnerung habe, nehmen fast alle Masterupdates auch eine Änderung an der DB vor. Es hätte beim Update also mehr passieren müssen.
Es macht übrigens keinen Sinn in einem anderen Thema einen Hinweis auf einen neuen Beitrag zu setzen. Diese Art von sicher nicht böse gemeinter Drängelei ist in keinem Forum gerne gesehen.
Wenn du ein neues Thema erstellst, dann sieht das jeder! Es hat aber nicht jeder gleich eine Antwort parat. So kann es passieren, dass ein Thema bzw. Beitrag auch mal eine Zeit lang ohne Antwort bleibt!
Ich habe vor kurzem vom GX2.3 auf 3.2 upgedated und habe beide Varianten durchgespielt. Also sowohl alle Masterupdates nacheinander installieren, wie auch die Variante mit dem Import Assistenten. Das Update über die Masterupdates ist bei mir 2x in die Hose gegangen. Die Variante mit dem Import-Assistenten war die besser Alternative. Es wurde bis auf die Filter alles übernommen. PayPal und Intraship mussten zwar wieder installiert werden, konfiguriert waren sie aber danach automatisch wieder. Wenn du Änderungen an den Texten vorgenommen hast, musst du diese auch wieder ändern. Die Filter kann man einfach durch kopieren der Tabellen wieder hinzufügen, da hat sich seit 2.1 nix mehr geändert.
Wichtig bei den Updates über die Masterupdates: Du darf niemals den "gambio_updater" Ordner löschen oder leeren. Du musst nach jedem Update den Shop testen und ggf. ein Update wiederholen. Leider sind die Masterupdates nicht immer 100%tig aufgespielt, oft fehlen danach Tabellen.
Franz Bludorf
30.01.2017, 08:36
Standardmäßig ist auf dem Server PHP 5.5.9 eingestellt, ich kann aber auch 5.6.30 anwählen und habe jetzt für die ganze Umstiegsaktion noch 7.0.15 installiert. Der GX2-Shop wird unter 5.5.9 betrieben, mit diesem PHP habe ich auch die Master-Updates gestartet. Es ist so seltsam, dass von 5 Updates kein einizges gemeldet hat, dass es etwas zum Updaten gibt. Da muss irgendein systematischer Fehler liegen, der möglicherweise ganz simpel ist, aber ich hab ihn halt noch nicht entdeckt.
Den Post in dem anderen Thema hatte ich übrigens nicht gesetzt, um zu "Drängeln". Das Thema ging um PHP-Upgrade, das nicht funktioniert, also dachte ich, dass da jeder seine Probleme in diesem Dunstkreis schildert. Es ist ja anzunehmen, dass jemand etwas Ähnliches auch schon erfahren hatte.
Franz Bludorf
30.01.2017, 08:41
Ich habe übrigens auch schon mit Neuinstallation und Import-Assistent herumgespielt. Früher klappte das immer gut, man muss dann eben nur ein paar Sachen neu einstellen, und ich habe immer Sorge, dass ich irgendwas vergesse, weil man es nicht sofort sieht. Ich hab da z. T. Bildergalerien als Kategorie-Header drin, die muss ich vermutlich dann auch wieder neu aufbauen, ist halt mühsam.
Wie dem auch sei - ich habe es versucht und im Shop einen Ordner GX3 angelegt, in den ich die neue Version installierte, mit neuer, leerer Datenbank, versteht sich. Der leere GX3-Shop ließ sich auch aufrufen. Der Import-Assistent krepierte dann jedoch mit der Bemerkung, er könne den Zielshop (in dessen Hauptordner GX3 ich den Assistenten-Ordner kopiert hatte) nicht finden. Den Quellshop eine Stufe höher hatte er gefunden.
@Sven
Ich habe meinen 2.4.3.1 kürzlich problemlos auf die aktuelle Version gebracht. Komplett unter PHP Version 5.4.45 und MySQL 5.5.52.
@Franz
Bei den Updates musst du auch die Lauffähigkeit der Updates unter der jeweiligen PHP-Version beachten. Wenn du aber durchgängig PHP 5.5.9 hattest, dann dürften damit keine Probleme auftreten.
Hier nochmal die Liste der unterstützten PHP-Versionen: https://tracker.gambio-server.net/projects/gxdoc/wiki/Unterst%C3%BCtzte_PHP-Versionen
Wahrscheinlich hilft es, wenn du nun wieder zurückgehst auf Version 2.1.2.0 (Dateien und DB) und anschließend nochmal die original Dateien aus dem Software-Paket Version 2.1.2.0 hoch lädst. Die beiden config.php musst du natürlich behalten. Auch eventuell modifizierte Dateien musst du vorher prüfen ob die überschrieben werden dürfen.
Anschliessend solltest du nochmal die Verzeichnis- und Dateirechte prüfen. Anleitung dazu im Handbuch unter Fehlerbehebung
Unter PHP 5.5.9 machst du dann die von dir bereits richtig genannten Updates nochmal. Mit einer Ausnahme (bin mir nicht ganz sicher) sollten alle Updates auch die DB aktualisieren.
Ich habe übrigens auch schon mit Neuinstallation und Import-Assistent herumgespielt.
Der aktuelle hier erhältliche Import-Assistent ist nur für GX Versionen bis 3.0.0.0 geeignet und funktioniert nicht mit den GX-Versionen 3.1.x, 3.2.x und 3.3.x - zumindest nicht offiziell!
Das Thema ging um PHP-Upgrade, das nicht funktioniert, also dachte ich, dass da jeder seine Probleme in diesem Dunstkreis schilder
Alles gut, Franz. Deine Handlung ist durchaus nachvollziehbar. Dennoch ist es als Mod nunmal meine Aufgabe dich daruf hinzuweisen, dass soetwas in einem Forum nicht hilfreich ist! Jedes Problem hat individuelle Ursachen. Deshalb ist es immer besser erstmal ähnliche Probleme im Forum zu finden und zu studieren und erst bei vermeindlicher Unlösbarkeit ein eigenes Thema im passenden Bereich aufzumachen. Das schafft vorallem für zukünftige Leser eine bessere Übersicht! Wenn jeder seine ähnlich gelagerten Probleme in dem selben Thread abkippen würde, dann hätten wir am Ende 20 Themen mit jeweils 5.000 Beiträgen. Welcher Hilfesuchende würde sich später da durchwühlen wollen!?
Franz Bludorf
30.01.2017, 16:17
Danke, Klaus, ich lade jetzt mal GX3 3.0.0.0 runter und versuche, mit dem Import-Assistenten das hinzukriegen. Sollte das klappen, gehe ich auf PHP 7 und mache weitere Updates erst danach, falls überhaupt nötig. Vor vielen Jahren, als ich noch IT-Newbie war, sagte mein Chef mir mal "Korrigiere nie ein System, das läuft". Na gut, damals gab es noch keine Viren-Updates und Sicherheitslücken...
Danke, Klaus, ich lade jetzt mal GX3 3.0.0.0 runter und versuche, mit dem Import-Assistenten das hinzukriegen.
Das setzt aber einen funktionierenden Quellshop voraus!
Sollte das klappen, gehe ich auf PHP 7 und mache weitere Updates erst danach, falls überhaupt nötig.
Das geht ja nicht. Siehe meine Liste aus dem letzten Beitrag zu Unterstützte PHP-Versionen (https://tracker.gambio-server.net/projects/gxdoc/wiki/Unterst%C3%BCtzte_PHP-Versionen). PHP 7 kannst du frühestens mit GX 3.1.x einsetzen. Ich persönlich würde es erst nach dem dem letzten aktuellen Update einsetzen und bis dahin bei deiner 5.5.9 bleiben.
Vor vielen Jahren, als ich noch IT-Newbie war, sagte mein Chef mir mal "Korrigiere nie ein System, das läuft"
Gemeint hat er wahrscheinlich: Never change a running system Der Spruch kommt noch nichtmal aus dem englischen, sondern aus dem deutschen Raum und bedeutet im Grunde nur: Ich habe Angst mein System sicherer und besser zu machen. Angesichts des damals aufstrebenden Micro-Soft war die Angst sicher nicht unbegründet.
Na gut, damals gab es noch keine Viren-Updates ...
Wenn du mit "damals" das Zeitalter bis Ende der 1970er meinst, mag ich dir Recht geben. Gute 10 Jahre später hatte sich das aber grundlegend geändert. Massentauglicher Konsolen und Computer mit enormer Nachfrage sei Dank!
... und Sicherheitslücken...
Einspruch! Es gab und gibt kein System ohne Sicherheitslücken. Es wird immer jemanden geben, der eine Lücke findet und anderen zugänglich macht. Turing (Enigma-Hacker) ist nur ein frühes Beispiel! Holland und Wernéry haben der Post und der Welt gezeigt, was von BTX zu halten ist, und Koch zeigte mit seinen Hacks die gravierenden Lücken in den weltweit vernetzen Großrechnern der Wissenschaftler und Geheimdienste auf. Zu diesem Zeitpunkt wurden auch schon massenhaft Sicherheitslücken in DOS, Macintosh, Unix, TOS, etc. diskutiert - öffentlich an der Uni und geheim in den Teestuben - die ja schließlich von diverser Malware auch genutzt wurde. Für den Atari gab es ja Ende 80 sogar schon einen Viren-Baukasten for Kids!
Franz Bludorf
01.02.2017, 12:02
Ich habe diese Bemerkung auch nicht so ganz ernst gemeint. Ende der siebziger Jahre arbeiteten wir noch ausschließlich auf Mainframes, und wenn die tatsächlich "vernetzt" waren, dann nur mit der Nachbar-Uni, um Batch-Jobs zu übertragen. Von außen kam da keiner rein. Die ersten IBM-PCs bekamen wir Mitte der Achtziger, aber das waren wirklich "Personal Computer", d. h. sie standen einsam und allein im Büro und waren mit nix verbunden. Wenn man Glück hatte, war da eine Festplatte mit 20 MB drin, ansonsten musste man Diskjockey mit den Papp-Disketten spielen. Da waren "Virenscanner" tatsächlich noch überflüssig, auch wenn man schon lesen konnte, wie man Viren schreibt. Die einzige Infektionsquelle war eine Diskette unbekannter Herkunft.
Franz Bludorf
01.02.2017, 12:14
Nun aber zum eigentlichen Problem. Gestern hatte sich mein Webserver entschlossen, plötzlich das Master-Update 2.2.0.0 ordentlich durchzulassen. Das konnte ich inzwischen backupen und festhalten, denn bei MU 2.4.0.1 macht es Rumms!
Ich füge mal ein paar Screenshots ein. Das Update selbst läuft durch, aber dann müssen einige Dateien umbenannt, verschoben und auch gelöscht werden:
571
572
(ich hoffe, die werden später zu sehen sein)
So weit so gut, aber dann meldet er am Schluss, dass alles gut ist, nur die Caches kann er nicht leeren, das möchte ich doch bitte im Admin-Bereich des Shops selbst tun. Leider komme ich da gar nicht rein, da schon die Startseite des Shops abstürzt, weil er sie vermutlich aus dem Cache holt und dann auf eine der inzwischen gelöschten Dateien (lang/german/german.php) zugreifen will.
Ich habe schon alle Webshop-Aufrufe aus dem Browserverlauf gelöscht, das bringt aber nichts, vermutlich hat er noch Top-Secret-geheime Caches, an die man auf diese Weise nicht drankommt.
573
Was tun?
Franz Bludorf
01.02.2017, 12:39
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...)
Warum löscht du den inhalt der beiden cache ordner nicht per ftp? Lass aber die .htaccess ab leben.
Franz Bludorf
01.02.2017, 19:15
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.
werden denn logs geschrieben? Wenn ja zeig mal.
Franz Bludorf
01.02.2017, 20:37
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/gambio_updater/index.php?content=finish&language=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
01.02.2017, 20:50
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
01.02.2017, 21:44
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?
@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 :confused:
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!
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
Das gleiche machst du mit dem Verzeichnis /templates_c
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!
Damit wirst du dich dann problemlos anmelden können.
Dann gehst du in deinem Adminbereich >>> Toolbox >>> Cache leeren und löschst dort nochmal sämtliche Caches.
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
02.02.2017, 09:45
@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
02.02.2017, 10:39
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!!! :mad:), 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/gambio_updater/index.php?content=configure&language=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.
Franz Bludorf
02.02.2017, 11:34
Ergänzung zu eben: Mit der Änderung der Zugriffsrechte der genannten Dateien des Ordners gm/javascript/jquery läuft das Update auf 2.6.0.0 ordnungsgemäss durch, der Shop (Kundenoberfläche) läuft so weit auch.
Allerdings ist in der Version 2.6.0.0. die Admin-Oberfläche geändert, wie im Installationsmanual beschrieben, und wenn ich mich als admin einlogge und "Gambio-Admin" wähle, kriege ich nur einen weißen Schirm. Wenn ich im Browser die Entwicklertools einblende, erhalte ich einen ganzen Rattenschwanz von Zugriffsfehlern:
https://webshop.fosar-bludorf.com/admin/html/assets/styles/gx-admin.min.css Failed to load resource: the server responded with a status of 403 (Forbidden)
https://webshop.fosar-bludorf.com/admin/html/assets/styles/vendor.min.css Failed to load resource: the server responded with a status of 403 (Forbidden)
https://webshop.fosar-bludorf.com/JSEngine/build/vendor.min.css Failed to load resource: the server responded with a status of 403 (Forbidden)
https://webshop.fosar-bludorf.com/JSEngine/build/vendor.min.js Failed to load resource: the server responded with a status of 403 (Forbidden)
https://webshop.fosar-bludorf.com/admin/html/assets/javascript/vendor.min.js Failed to load resource: the server responded with a status of 403 (Forbidden)
https://webshop.fosar-bludorf.com/JSEngine/build/require.min.js Failed to load resource: the server responded with a status of 403 (Forbidden)
https://webshop.fosar-bludorf.com/JSEngine/build/jse.min.js Failed to load resource: the server responded with a status of 403 (Forbidden)
https://webshop.fosar-bludorf.com/admin/html/assets/styles/gx-admin.min.css Failed to load resource: the server responded with a status of 403 (Forbidden)
https://webshop.fosar-bludorf.com/admin/html/assets/styles/vendor.min.css Failed to load resource: the server responded with a status of 403 (Forbidden)
https://webshop.fosar-bludorf.com/JSEngine/build/vendor.min.css Failed to load resource: the server responded with a status of 403 (Forbidden)
https://webshop.fosar-bludorf.com/admin/html/assets/javascript/vendor.min.js Failed to load resource: the server responded with a status of 403 (Forbidden)
https://webshop.fosar-bludorf.com/admin/html/assets/images/gx-admin/gambio-logo-white.png Failed to load resource: the server responded with a status of 403 (Forbidden)
https://webshop.fosar-bludorf.com/JSEngine/build/require.min.js Failed to load resource: the server responded with a status of 403 (Forbidden)
https://webshop.fosar-bludorf.com/JSEngine/build/jse.min.js Failed to load resource: the server responded with a status of 403 (Forbidden)
jquery-ui-datepicker.js:1773 Uncaught ReferenceError: jQuery is not defined
at jquery-ui-datepicker.js:1773
gm_counter.js:18 Uncaught ReferenceError: $ is not defined
at gm_counter.js:18
start.php?v2.6.0.0:1
Uncaught ReferenceError: jQuery is not defined
at eval (eval at <anonymous> (jquery.tooltip.pack.js:15), <anonymous>:1:4340)
at jquery.tooltip.pack.js:15
GMFavMaster.js:20
Uncaught ReferenceError: $ is not defined
at new GMFavMaster (GMFavMaster.js:20)
at start.php?v2.6.0.0:91
start.php?v2.6.0.0:97
Uncaught ReferenceError: $ is not defined
at start.php?v2.6.0.0:97
admin_javascript.js.php:280
Uncaught ReferenceError: jQuery is not defined
at admin_javascript.js.php:280
start.php?v2.6.0.0:254
Uncaught ReferenceError: $ is not defined
at start.php?v2.6.0.0:254
start.php?v2.6.0.0:609
Uncaught ReferenceError: $ is not defined
at start.php?v2.6.0.0:609
https://webshop.fosar-bludorf.com/admin/html/assets/images/gx-admin/gambio-logo-white.png Failed to load resource: the server responded with a status of 403 (Forbidden)
gm_counter.js:59 Uncaught ReferenceError: $ is not defined
at gm_get_content (gm_counter.js:59)
at onload (start.php?v2.6.0.0:10)
https://webshop.fosar-bludorf.com/admin/html/assets/styles/gx-admin.min.css Failed to load resource: the server responded with a status of 403 (Forbidden)
https://webshop.fosar-bludorf.com/admin/html/assets/styles/vendor.min.css Failed to load resource: the server responded with a status of 403 (Forbidden)
https://webshop.fosar-bludorf.com/JSEngine/build/vendor.min.css Failed to load resource: the server responded with a status of 403 (Forbidden)
Ich gehe davon aus, dass das auch wieder das 660 -> 666 - Problem ist, und werde versuchen, die Rechte manuell anzupassen. Nur - welche nächsten Rechte werden dann verletzt sein? So langsam wird das selbst für einen erfahrenen Computerbenutzer nicht nur mühsam, sondern auch undurchschaubar.
Franz Bludorf
02.02.2017, 11:48
Habe gerade in einem anderen Thread gesehen, dass bei Gambio 2.6 die Administratorrechte neu vergeben werden müssen. Nur wie, wenn die Administratoroberfläche gar nicht erscheint? Der 403-Fehler im Browser deutet doch eher auf falsche Dateizugriffsrechte hin als auf fehlende Rechte innerhalb eines Softwarepakets. Ich kann alles auch manuell einstellen, wenn es nötig ist, nur wo und wie?
Franz Bludorf
03.02.2017, 08:45
Also ich denke, ich werde den Rest jetzt einigermaßen hinkriegen. Das MU v2.6.0.0 läuft jetzt so einigermaßen, seit ich die Rechte für den Ordner admin/html und den Ordner JSEngine komplett mit allen Unterordnern auf 755 gesetzt habe. "Einigermaßen" deswegen, weil noch einige Bilder nicht angezeigt werden.
Das Upgrade auf 3.0.0.0 läuft durch (sofern ich wie immer den gambio_updater-Ordner komplett mit allen Unterordnern auf 755 setze), allerdings bringt die Admin-Oberfläche reinen HTML-Text ohne Styles. Angemeckert werden fehlende Rechte im gm-Ordner. Wenn ich den auf 755 setze, wird ein Teil der Formatierungen angezeigt, aber nicht alles. Die Liste der abgelehnten Zugriffe verlängert sich sogar, bis in die tiefsten Tiefen.
Ich schildere das hier alles so genau, nicht weil ich hilflos wäre oder jammern will, sondern in der Hoffnung, dass irgendjemand von den Forum-Usern bei Gambio arbeitet oder Verbindungen dorthin hat und diese Erfahrungen vielleicht weitermeldet. Insgesamt muss ich sagen, dass bei der Lauffähigkeit der Updates einiges im Argen liegt. Was ich bislang festgestellt habe:
1. Die meisten Updates laufen auf meinem Server überhaupt nicht, ohne gambio_updater mit allen Unterordnern manuell auf 755 zu setzen. Der Zugriff wird sonst verweigert.
2. Ab v2.6.0.0 läuft das Update-Skript nicht durch, wenn man nicht im Ordner gm/javascript/jquery die Skripte für die Datenbankzugriffe auf 755 setzt.
3. Um die Admin-Oberfläche in v2.6.0.0 sichtbar zu machen, müssen die Ordner admin/html und JSEngine mit allen Unterordnern auf 755 gesetzt werden.
Hierzu ist mir folgendes aufgefallen: Bei der alten Version 2.1.2, die ich bislang benutzte, war in der Installationsanleitung eine ganze Liste von Ordnern und Dateien angegeben, deren Rechte manuell angepasst werden mussten. Das mag mühsam sein, aber man war auf der sicheren Seite, dass alles berücksichtigt wurde. Als Anwender kann man ja nicht über alle Verzweigungen der Software den totalen Durchblick haben. Damals war die Installation nach diesem Gefummel mit den Rechten problemlos und brachte keine Fehler.
Ich arbeite auf einem Server mit Standardkonfiguration (sofern es so was gibt :confused:), will sagen, ich habe an solchen Dingen wie Rechtevergabe, Apache-Konfiguration etc. meinerseits nichts geändert, sondern arbeite mit dem, was mir der Provider mit dem vorinstallierten Ubuntu zur Verfügung gestellt hat (Ubuntu-Version 14 und ein paar Zerquetschte). Das heißt aber, meine Probleme dürften viele andere Benutzer auch ähnlich treffen.
So weit ich sehe, waren die meisten Ordner, die ich bislang anpassen musste, von Gambio-Seite aus auf 750 gesetzt, und ich brauche 755, um das Update zu machen und damit die Shopseiten hinterher richtig angezeigt werden. Das heißt, Gambio gibt die in den Ordnern enthaltenen Skripte nur für Gruppenmitglieder zur Ausführung frei, ich brauche aber offenbar öffentlichen Zugang. Was das Update-Makro betrifft, mag das gefährlich sein, aber das löscht man ja sowieso, wenn alles fertig installiert ist. Skripte, die für korrekte Shop-Anzeige gebraucht werden, brauchen aber zumindest in meinem Browser den öffentlichen Zugang. Vermutlich verlässt sich Gambio darauf, dass diese Software-Teile nur von anderen Software-Teilen intern aufgerufen werden, so dass die Gruppenzugehörigkeit gewährleistet ist. Aber offenbar ist dem nicht der Fall.
Ich werde weiter meine Erfahrungen hier publizieren, in der Hoffnung, dass es jemand liest, der auf die Weiterentwicklung der Software Einfluss hat. Man kann natürlich auf dem Standpunkt stehen, was kümmern mich Updates von Alt-Versionen, Hauptsache das Aktuelle läuft. Aber erstens - wenn Gambio immer noch Updates für ältere Versionen anbietet, sollten die auch laufen. Zumindest habe ich das als Softwareentwickler mal so gelernt... Zweitens habe ich den Eindruck, je neuer die Updates, desto mehr Ordner, deren Rechte angemeckert werden. Das kann zwei Gründe haben - erstens, dass in den neuen Versionen mehr geändert wurde und daher im lauffähigen Shop mehr ersetzt werden muss. Zweitens, dass sich das Gambio-Entwicklerteam neuerdings auf Serverkonfigurationen bei den Kunden verlässt, die so nicht überall vorliegen (ich habe wie gesagt kein selbstgebasteltes oder veraltetes System. Diesen Server benutze ich erst seit Dezember letzten Jahres, er wurde damals völlig neu vom Provider konfiguriert, und dann verlief die Neuinstallation und Konfiguration von Gambio 2.1.2 völlig ohne Probleme oder auch nur eine Fehlermeldung).
Da ich wie gesagt, außer den Gambio-Shops auch Typo3 nutze, für unsere redaktionellen Inhalte, könnte ich hier eine Anregung geben: Beim Typo3-Installationsskript kann man im Rahmen der Konfiguration des Systems die Standardrechte für bestimmte Dateitypen spezifizieren (oder die angebotene Voreinstellung nutzen). Dort war es so, dass die PHP-Skripte z. T. Schreibzugriff brauchen und standardmäßig auf 660 standen. Ähnlich wie ich hier jetzt vieles von 750 auf 755 setzen muss, lief dort gar nichts, solange ich nicht 660 auf 666 geändert hatte. Nur - das war bequem. Eine einzige Setzung im Installationsskript sorgte dafür, dass die Rechte in der Software - Schnuppdiwupp - bis zum untersten Bodensatz angepasst wurden. Das wäre natürlich toll, wenn die Gambio Installations- und Update-Skripten auch so eine automatische Rechteanpassung hätten, die vom Benutzer bei der Installation anpassbar wäre. Im Moment bleibt mir nichts als weiter zu suchen. Und, was das Unangenehmste ist - wenn alles zu laufen scheint, das mulmige Gefühl, es könnte doch irgendwo noch so ein Schurke auf mich lauern, der dann nicht funktioniert. Diese beiden Shops (von denen ich bislang nur den ersten update), sind seit rund vier Jahren im Einsatz und bieten doch eine ganze Reihe von Sachen an, da kann ich unmöglich jede Seite durchtesten. Da bleibt nur die Hoffnung, dass der Löwenanteil der Inhalte schließlich in der Datenbank liegt, d. h. wenn z. B. ein Artikel richtig angezeigt wird, dann vermutlich alle usw. Was aber z. B. die Admin-Oberfläche betrifft - da gibt es Teile, die man nur alle Jubeljahre mal braucht und natürlich nicht alle mit allen Alternativen, Antwortseiten etc. durchtesten kann. Da kann es immer noch mal Rumms machen.
Übrigens - noch ein Hinweis zum Forum. Wenn man an einem längeren Beitrag schreibt - für diesen hier habe ich etwa eine halbe Stunde gebraucht - kann es passieren, dass man beim Posten am Ende die Meldung bekommt, dass die Sitzung abgelaufen ist. Das ist natürlich blöd, denn es besteht immer die Gefahr, dass man nach dem Login auf irgendeine Startseite geleitet wird und dann alles Getippte weg ist. Da mir so was schon mal passiert ist hier, war ich heute vorsichtig und habe anstelle des Logins sofort die Browser-Rücktaste gedrückt und hatte nur Glück, dass er das Getippte noch im Cache hatte. Sollte man nicht doch die Sitzung aufrechterhalten, solange die Forumsoftware registriert, dass hier jemand regelmäßig was eintippt - also eine Art Keylogger nur zum Abfragen wegen des Timeout einbauen?
Franz Bludorf
03.02.2017, 08:59
Noch zur Ergänzung: ich sagte, "einige Bilder" werden bei v2.6.0.0 bei mir noch nicht angezeigt. So weit ich jetzt gesehen habe, betrifft es nur einen Artikel im Shop, der mehrere Abbildungen hat. Die sind zwar alle da und auch anzeigbar, aber die kleinen Thumbnails unter der Hauptabbildung sind als Fehlerbilder angezeigt. Ich habe prophylaktisch den kompletten Ordner images mit allen Unterordnern und Dateien auf 777 gesetzt und Cache geleert, bringt aber nichts.
Franz Bludorf
03.02.2017, 09:43
Die fehlenden Thumbnail-Bilder konnte ich wieder herstellen, indem ich die Artikelabbildungen gelöscht und neu hochgeladen habe.
Allerdings gibt es in der Admin-Oberfläche weitere Probleme bei der Artikelbearbeitung. Die Artikelbeschreibungen, die von der Vorversion übernommen wurden, werden im Frontend zwar angezeigt, nicht jedoch im Backend bei dem betreffenden Artikel. Unter "Artikelbeschreibung" ist nur ein größerer weißer Bereich, so dass auch der Text nicht geändert werden kann. Schon wieder ein Rechteproblem, das ich beheben konnte, indem ich den Ordner admin/includes/ckeditor komplett auf 755 setzte.
Franz Bludorf
04.02.2017, 08:37
Gestern konnte ich die ganze Aktion abschließen und habe jetzt einen Shop v3.3.2.0, der rundherum ordentlich funktioniert.
Mir war nämlich aufgefallen, dass ab der Version v.3.0.0.0 die Master-Updates keine Rechteanpassungen mehr brauchen, um durchzulaufen. Offenbar hatte Gambio seit dieser Zeit auf die aktuellen Anforderungen von Linux-Servern Rücksicht genommen (bzw. vorher waren die Anforderungen anders, ich weiß es nicht, da ich vor 1-2 Jahren noch keinen selbstverwalteten Linux-Server hatte).
Ich ließ also von nun an alle Master-Updates durchlaufen, ohne mich darum wesentlich zu kümmern, ob die jeweiligen Shopinstallationen laufen oder nicht. Ich wollte nur die Datenbank updaten. Als ich dies zusammen mit den neuesten zwei Service-Packs geschafft hatte bis zu der aktuellen Shopversion, wie sie hier zum Download angeboten wurde, habe ich nach einem gründlichen Backup das ganze Shopverzeichnis gelöscht und die neueste Version von Grund auf neu installiert. Das ging ebenso glatt wie bei den letzten Master-Updates.
Als der Testshop in Frontend und Backend ein wenig durchgetestet war, konnte ich vom Backup die Datenbank, die Ordner Download, Images und Media sowie die vier bekannten Config-Dateien zurückladen. Dann noch die Cache-Ordner löschen, und voilà - da hatte ich einen funktionierenden Shop mit meinen Einstellungen auf neuester Version, der jetzt auch mit PHP 7 funktioniert.
Nochmals vielen Dank für die Ratschläge, die ich hier von den hilfsbereiten Usern erhalten habe.
Ich mache mich jetzt daran, den zweiten Shop genau so umzustellen, wie es mir beim ersten gelungen ist. Dieser zweite ist wie gesagt wichtiger und auch umfangreicher.
Powered by vBulletin® Version 4.2.2 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.