Bug bei Mehrmandanten-Update auf neueste GIT-Version?

[homtata]

Heyho, ich versuche gerade verzweifelt, nach vielen gelungenen Updates von single-client-Installationen mit der neuesten Version aus GitHub nun auch eine multi-Mandanten-Installation upzudaten. Tausche ich einfach nur die Dateien aus (also /contenido) und überschreibe /cms und /data mit den Dateien aus der ZIP, dann läuft Contenido per se, solange ich nicht die Setuproutine drüber laufen lassen.
Sobald ich das tue, sind so gut wie alle Backend-Tabs tot. Ich sehe dann noch die Artikelnamen, aber kann keine Templates konfigurieren, Artikel editieren, SEO - nada. Da ist einfach weiße Seite unter der Tab-Navigation.
Das Setup läuft immer bis zum Ende des ersten Fortschrittsbalkens durch, zeigt dann aber unten nicht den blauen "weiter"-Button.
Die Setup-Routine scheint die Datenbank irgendwie zu ändern, denn wenn ich dann einfach die alte DB-Version zurückspiele (bei aber neuestem Dateienstand), dann funzt alles wieder.
Mein Aufbau ist wie folgt:
root/contenido -> eine Subdomain contenido.xxx.de routet hier hin fürs Backend.
root/client1 -> eine erste Domain routet in diesen Ordner
root/client2 -> eine zweite Domain routet in diesen Ordner
Dazu existieren Subdomains für den Zugriff auf /root, z.B. root.xxx.de

Führe ich das setup aus, so mache ich das von der root.xxx.de aus, denn nur so ist das setup ja auch ansprechbar und findet das /contenido.
Diese Subdomain wird im weiteren Verlauf - gemeinsam mit ihrem Serverpfad - auch als "Contenido-Pfad" verwendet. Das System meldet mir auch, es sei alles in Ordnung, bis es dann wie gesagt nach dem ersten Fortschrittsbalken hängen bleibt, der bis hinten durchläuft.

Ideen? Mach ich einen Denkfehler oder riecht es nach Bug?

[Faar]

Guten Morgen
Also prinzipiell solltest Du vor dem Setup zumindest das /contenido Verzeichnis als _old bezeichnen und dann erst das Setup fahren.
Warum? Weil wenn Du nur überschreibst, werden keine alte Dateien gelöscht. Falsche Scripte könnten dann laufen, ausgesonderte Klassen eingebunden werden, usw.

Das Zweite ist auch interessant, die Verändungen in der Datenbank. Bei mir blieb das Setup meistens stehen, weil in der DB die Tabellen noch MyISAM waren und diese für manche Felder nur 1000 byte platz haben, aber dank UTF8 nun mehr Speicherplatz benötigt wird und die Tabellen vorher zu innoDB werden müssen. Das macht das Setup bei bestimmten Tabellen bereits selbst. Ich habe mir ein kleines Modul geschrieben, das alle Tabellen in InnoDB umwandelt und das Problem ist aus der Welt geschafft.

Als nächstes haben ältere Installationen hin und wieder Probleme mit bereits vorhandenen unique Werten wie beim Primary Key. Es kann sein, dass es auch daran hängt, weil ein "Key" bereits besetzt ist beim aktualisieren der Tabelle und das Setup dann stoppt.
Es gibt ein Setup.log, das im besten Fall Aufschluss darüber gibt.
Den Fehler löst man am besten manuell mit phpmyadmin.
Z.B. hab ich die Zeile mit Primary_Key 0 einfach hinten angehängt und vorne gelöscht.
Das ging darum, weil keine Abfrage nach dem Primary_key suchte, der musste einfach nur unique sein und da spielte es keine Rolle, ob 1 oder 127.

Bei dem /cms bzw. /clientx Verzeichnissen würde ich die configs vorher sichern, was Du ja auch getan hast.
Das Setup überschreibt beim "Updaten" keine Daten wie Templates oder Module, aber bei config.xxx immer sicher gehen.
Ich hatte bei Multimandanten Anfang Sommer das Problem, dass kein /cms vorhanden war, wie bei Dir vermutlich.
Ich weiß nicht mehr genau warum aber mir half es, beim Update die /clientxx Verziechnisse im Contenido Source auf dem PC anzulegen und mit hoch zu laden. Das hatte aber bei mir vielleicht eher auch mit den lokalen Umständen um WebDAV zu tun.
Das war etwas störrisch und wollte nur exakt das /cms hochladen aber nicht von /cms --> /clientx

[xmurrix]

Hallo homtata,

von welcher CONTENIDO Version hast du dabei auf den neuesten Stand von GitHub aktualisiert?

Und stehen irgendwelche Fehlermeldungen in den Dateien im Verzeichnis data/logs drin, die einen Hinweis darauf geben, was da passiert?

Vor Kurzem hatte ich auch eine Aktualisierung von einer CONTENIDO 4.9.12'er Version auf den neuesten Entwicklungsstand in GitHub und hatte keine Probleme, PHP wurde dabei von 7.4 auf 8.1 umgestellt. Die vorhandene Datenbank unter MySQL 5.7 habe ich exportiert und als neue Datenbank unter MariaDB 10.6 importiert.

Bei mir gab es folgendes Szenario, das deinem ähnlich ist:

• CONTENIDO Backend in separatem Verzeichnis und mit eigener Subdomain
• Mandant 1 in separatem Verzeichnis und mit eigener Domain
• Mandant 2 in separatem Verzeichnis und mit eigener Domain

Das Setup ist problemlos durchgelaufen, weder im Frontend der Mandanten noch im Backend gab es Probleme. Ich musste aber vorher vorhandene Plugins und Module auf die Funktionalität unter PHP 8.1 umstellen, damit keine Fehler oder unnötig viele Warnungen erzeugt werden.

Wichtig sind folgende Punkte:

• Du hast vorher alle Sourcen korrekt ausgetauscht
• Die PHP-Version ist nicht größer als 8.1
• Die Kollation der Datenbanktabellen sollte nicht utf8mb4_general_ci sein, falls ja, dann musst du, wie Faar beschrieben hat, die Engine der Tabellen auf InnoDB umstellen
• Das Setup hat alle Datenbankänderungen erfolgreich durchgeführt. Falls nicht, sollten die Fehler in den Log-Dateien im Verzeichnis data/logs zu finden sein.
• Das Setup überschreibt keine Module und keine Plugins, außer du hast die vorhandenen Plugin-Dateien mit neuen Versionen ausgetauscht. Plugins und Module können vor allem nach einem Wechsel der PHP Version Probleme bereiten, die muss man alle prüfen und gegebenenfalls an die neue PHP Version anpassen.

Wenn das alles passt, kann es eigentlich an falschen Werten in den Konfigurationen liegen. Die wichtigsten sind:

• data/config/production/config.php
• data/config/production/config.clients.php

Die kann man zur Not auch manuell anpassen.

Gruß
xmurrix

[homtata]

Danke Euch für den Input! In meinem Fall war es tatsächlich die Kollation der DB, Tabellen und Spalten. Ich habe sie auf utf8_general_ci umgestellt statt "utf8mb4_general_ci" und schon lief das Update wie gewohnt durch. Schräg, hätte ich jetzt nicht erwartet. Das wird mich dann bei einer anderen Installation, in der ich definitiv utf8mb4 brauche, noch vor Herausforderungen stellen, aber schauen wir mal...
Immerhin mal EINE Kuh vom Eis!
DANKE!