Test der neuen CONTENIDO-Version 4.9.13

[Oldperl]

Servus,

und jetzt nochmal!
Bitte mehr Infos wenn man helfen (können) soll. PHP- und MySQL-Version? Logs, sowohl PHP als auch Server? Ansonsten ist das nun wirklich Glaskugel-Beten oder Orakel befragen.

Gruß aus Franken

Ortwin

[Faar]

PHP: 7.1 und zwischendurch auch 5.6 und 7.0 getestet.
MySQL: 5.6

Es ist eine Kopie einer DB von 4.8.20, mit AMR.

Server ist Linux.

PHP läuft prinzipiell, nur ab dieser cregistry::bootstrap nicht mehr.

In Zeile 22 findet sich ein einsames ;

Code: Alles auswählen

// CONTENIDO startup process
include_once('./includes/startup.php');
;

[Seelauer]

Hallo Zusammen !
Es sei nochmals erwähnt, dass die x-fachen Neu-Installationen der 4.9.13 ohne Murren und Knurren abgelaufen sind. Setup-Routine meldet immer "keine Probleme". Keine Updates von Vorgängerversionen. Installationen immer wieder in ein neues Verzeichnis bzw. in eine frische Datenbank.
Trotzdem keine Chance, dass ich ins Backend komme.
Auf dem Server probiert mit u. a. PHP 5.5.35 bis PHP 7.1.10, Datenbank MySql Version 5.6.19.
In data -> logs schlummert nur die index.php.
Frontend ist, wie gewohnt und üblich sofort erreichbar. Backend gibt es für diese Installation für mich nicht mehr.

[frederic.schneider_4fb]

Guten Abend .

Ich glaube Euch das ja. Es ist nur schwierig, etwas nachzuvollziehen, wenn Ihr sagt, die Installation läuft fehlerlos durch, keine Fehlerlogs, und dann geht lediglich das Backend nicht, auch da keine Fehlerlog. Ich wüsste auf Anhieb auch nicht, was wir genau am Sessionmanagement geändert haben sollten.

Ich hatte eben mal eine lokale frische Testinstallation bei mir zuhause getestet (PHP 7.0): Alles super.

Werde mir das am Wochenende noch einmal auf verschiedenen Servern ansehen, auch hinsichtlich der MySQL-Versionen. Vllt. kann ich das Problem ja irgendwie reproduzieren.

Danke Euch schonmal!

[Faar]

Keine Fehlerlogs, auch im Serverlog nicht. Lediglich jede Menge 302 Meldungen im Access Log.

Ein Update von 4.9.12 auf 4.9.13 lief ja schon mal reibungslos, das war kein Problem.
Aber hier war es ein Update von 4.8 auf 4.9.13

Nun habe ich mal alles wieder gelöscht und neu die 4.8 DB und das 4.8 System aufgebaut und zum laufen gebracht, danach das AMR ausgeschaltet und deinstalliert, die 4.8 Seite lief dann immer noch.
Dann eine 4.9.12 Version hochgeladen und das Update gestartet.
Das lief anfangs ohne Fehlermeldung durch (auch keine Warnung wegen Schreibrechte) bis zu dem Punkt, wo es praktisch geupdatet wird und dann war da nur noch eine weiße Seite.

[frederic.schneider_4fb]

Danke, ich teste das am Wochenende durch

[Seelauer]

Guten Morgen,
nachdem ich beim Problem "keine Zugang zum Backend" mit keiner Fehlermeldung etc. dienen kann, noch eine Frage:
Kann ich mit sinnvollen Aktionen bei der Fehlersuche irgendwie helfen oder unterstützen ?

[Faar]

Nun, nachdem ich alles löschte und es mit einer 4.9.12 versuchte, gibt es eine Fehlermeldung beim Backend in /contenido:

Code: Alles auswählen

Fatal Error

Could not open a configuration file config.php or config.clients.php.

Da das Setup mit weißer Seite just beim updaten abgebrochen ist, gibt es natürlich auch keine config.php
Das erklärt leider noch nicht, warum das Setup nicht lief.
Aber vielleicht dieses hier im Erroror-Log von eben diesem Updateversuch:

Code: Alles auswählen

PHP Fatal error:  Class 'gdbDriver' not found in /xyz/www.dddddd.tld/neu/contenido/classes/drivers/mysql/class.gdb.mysql.php on line 36

[Oldperl]

Servus,

@Faar
Die Pfade passen nicht für 4.9 sondern zur 4.8

Code: Alles auswählen

PHP Fatal error:  Class 'gdbDriver' not found in /xyz/www.dddddd.tld/neu/contenido/classes/drivers/mysql/class.gdb.mysql.php on line 36

Kann es sein das Du noch alte Dateien, zum Beispiel bei den Plugins drin hast? Schau auch mal in die Plugintabelle, was dort installiert ist/war.

Gruß aus Franken

Ortwin

[Faar]

Klar sind da alte Dateien, denn beim ersten Update hatte ich nur die Datenbank und ansonsten ein 4.9.13 ohne Altdateien im Verzeichnis.
Jetzt hatte ich ein laufendes 4.8.20 und darüber das 4.9.12 installiert.

[Oldperl]

Servus,

es scheint so, als seien da noch "alte" Item und ItemCollection Klassen, bzw. abgeleitete Klassen, in Verwendung. Daher solltest Du nachschauen, ob entweder ein Plugin oder ein Modul entsprechende Instanzen mit Ableitung von diesen Klassen nutzt oder irgendwo ein Include gesetzt ist/wird.

Gruß aus Franken

Ortwin

[Faar]

Erklärt das auch, weshalb das Setup beim Beginn des Updaten mit einer weißen Seite stehen blieb?
Es gibt in 4.9 dieses Verzeichnis /drivers gar nicht mehr.
Aber es war nur das Setup, das darauf zu dieser Zeit zugegriffen hat.

[Faar]

So, jetzt hat es geklappt und ich muss schauen, was ich alles gemacht habe ...

Edit:
Ich habe das /drivers Verzeichnis gelöscht, das gibt es in 4.9 nicht.
Das /setup gelöscht und neu wieder hochgeladen.
Noch ein paar Dinge wie /pear und /conlib, was es in 4.9 nicht mehr gibt.

Danach lief es durch, das Setup.
Dieses hat vorher vermutlich auf alte 4.8 Dateien zugegriffen, die noch im Verzeichnis waren.
Nun läuft das Backend und ich muss nur noch die Module anpassen, die sind ja noch so 4.8

[Faar]

Das erklärt noch nicht, warum eine saubere 4.9.13 Installation (nur mit 4.8 DB) einen Umleitungsfehler produziert. Möglich, dass das AMR schuld daran ist, das ich zuvor nicht deinstalliert hatte. Aber dazu musste ich am Freitagf erstmal die 4.8.20 Kopie zum laufen kriegen um das deinstallieren zu können. In der DB rumwerkeln wollte ich nicht.
Wäre noch der Versuch übrig, was passiert, wenn man eine 4.8.20 Installation ohne AMR mit 4.9.13 updatet.
Jedenfalls muss das alte Setup gelöscht werden und sicherheitshalber auch /pear und /conlib

Nun müssen nur noch Module angepasst, werden, weil Content und Menü natürlich nicht mehr angezeigt werden.
Aber das Frontend läuft, HTML-Aufbau und Grafiken werden angezeigt.
Ein Fehler steht im Errorlog:

Code: Alles auswählen

[18-Dec-2017 12:42:20 Europe/Berlin] PHP Fatal error:  Class 'FrontendPermissionCollection' not found in /xyz/www.ddddd.tld/neu/cms/includes/functions.navigation.php on line 43

Das ist vermutlich noch der alte Code aus 4.8, der von Modulen her kommt und diesen Fehler produziert.

[Oldperl]

Servus,

nochmal zur Vorgehensweise bei Updates/Upgrades von Contenido.

Vor allem beim Upgrade sollte darauf geachtet werden

• Machen Sie ein Update von allen Dateien und von der Datenbank
• Verschieben Sie alle Dateien und Verzeichnisse im root-Verzeichnis Ihrer Contenido-Installation in ein Backup-Verzeichnis
• Entpacken Sie lokal das Contenido-Archiv und laden Sie alle Dateien per FTP in das root-Verzeichnis
• Kopieren Sie die alte config.php in das Verzeichnis data/config/production, wobei der Name des Verzeichnis production sich nach ihrer Konfiguration richtet
• Rufen Sie im Browser das Setup auf (www.ihredomain.de/setup) und wählen Sie nach der Sprachauswahl das Upgrade-Setup

Bei Updates innerhalb 4.9 kommt noch dazu

• Kopieren Sie vor dem Setup alle "alten" Dateien aus dem/den Mandantenverzeichnis(sen) (Standard: cms/) zurück, ausgenommen die Core-Dateien, die bereits im neuen CMS-Verzeichnis liegen.

Bei Upgrades von 4.8

• Machen Sie zuerst ein Update auf die aktuellste Version 4.8.20, wenn nicht bereits geschehen
• Deaktivieren bzw. Deinstallieren Sie alle vorhandenen Plugins, insbesondere das AMR-Plugin

Nach Durchlauf des Setup

• Kopieren Sie nun stückweise alle Inhalte Ihres Mandanten in das neue Mandanten-Verzeichnis
• Prüfen Sie während diesen Arbeiten, und in der nächsten Zeit, fortwährend Ihre errorlogs. Dort werden in der Regel zuerst Fehler die durch ältere Module, Plugins etc. auftreten angezeigt.

Das Ganze ist immer noch analog meiner schon älteren Update/Upgrade Anleitung zu machen http://www.ortwinpinke.de/2009/05/18/co ... mandanten/ (sollte ich wohl mal aktualisieren! )

Gruß aus Franken

Ortwin

PS: Falls ich nun aus dem Stegreif was vergessen haben sollte, bitte gerne Korrekturen an mich.