OPUS-Update bricht beim utf8mb4-Skript ab

[kzimmermannfhms]

Liebes OPUS-Team,

ich versuche in meiner Testinstallation ein Update von OPUS 4.6.3 auf 4.8.4 zu machen. Das Skript bin/update.sh bricht immer beim Schritt "008-Convert-database-to-utf8mb4.php" ab.

Updating database ...
Current version of database: 9
(...)
Database update finished

Running update scripts ...
Running '008-Convert-database-to-utf8mb4.php' ...
/var/local/opus4/scripts/update/008-Convert-database-to-utf8mb4.php: 1: cannot open ?PHP: No such file
/var/local/opus4/scripts/update/008-Convert-database-to-utf8mb4.php: 3: /bin: Permission denied
/var/local/opus4/scripts/update/008-Convert-database-to-utf8mb4.php: 4: CHANGES.md: not found
(...)
ERROR - An error occured during updating!
Error (2) running '008-Convert-database-to-utf8mb4.php'!
Update aborted!

Aber wenn ich das php-Skript "008-Convert-database-to-utf8mb4.php" manuell starte:

php scripts/update/008-Convert-database-to-utf8mb4.php

dann läuft es durch und konvertiert die Tabellen in utf8mb4. Die PHP-Version ist 7.1, ich habe es aber auch schon mit 7.4 probiert, mit gleichem Ergebnis.

Haben Sie eine Idee, woran es liegen könnte? Ich würde mich über Hinweise freuen.

[j3nsch]

Ich habe eine Vermutung woran es liegen könnte. Wenn man sich die Update-Skripte anschaut, sieht man, dass in allen anderen Skripten, die verwendeten Klassen Teil der Application sind. In Update-Skript 008-Convert-database-to-utf8mb4.php wird eine Klasse aus dem Framework verwendet. Anscheinend stimmt das Setup für das Class-Loading bzw, der Include-Path für PHP nicht, wenn das Skript im Kontext des allgemeinen Update-Skripts verwendet wird.

Wenn das Utf8mb4-Skript direkt ausgeführt wird, findet das Setup nur in scripts/common/update.php statt. Wenn das Update-Skript verwendet wird, kommt vorher scripts/update/update.php zum tragen. Woran es aber nun genau liegt, kann ich nicht sagen und ich habe leider nicht die Zeit deswegen noch mal eine alte 4.6.3 Instanz aufzusetzen, um das Problem debuggen zu können. Die Fehlermeldungen nach "Running ...", u.a. zu "CHANGES.md", sind mir so völlig unklar. Fallen Ihnen dazu lokal noch weitere Unterschiede zwischen den Skripten, also z.B. 007 und 008 auf?

Mit der Option --confirm-steps, beim Update, müssen die einzelnen Schritte manuell bestätigt werden. Das wäre vielleicht ein Weg, um beim Update diesen Schritt zu überspringen und manuell auszuführen. Es kann natürlich sein, dass nachfolgende Skripte von diesem Schritt abhängig sind. Es sollte möglich sein das Update-Skript bei der Bestätigung für Schritt 008 oder 009 warten zu lassen, das Skript 008 im Hintergrund manuell auszuführen, und dann erst mit Schritt 009 und dem Rest des Updates normal weiter zu machen.

Alternativ könnte man versuchen zuerst auf OPUS 4.7 zu aktualisieren und dann erst auf 4.8.0.5 zu gehen. Wenn das funktioniert, liegt es wohl definitiv an irgend einer Änderung aus den letzten fünf Jahren.

Wir werden irgendwann einen Bruch machen müssen, wo keine direkten Updates von älteren Versionen mehr möglich sind, weil es mit der verfügbaren Entwicklungskapazität einfach zu teuer ist, den Update-Prozess lauffähig zu halten, egal wie sich OPUS 4 ändert. Es sieht so aus, als ob uns hier die Entscheidung abgenommen wurde.

[j3nsch]

Beim Update über den Zwischenschritt OPUS 4.7, müsste auf jeden Fall PHP 7.1 verwendet werden, weil erst OPUS 4.8 mit PHP 8.1 läuft.

[kzimmermannfhms]

Mit einem Zwischenschritt über die Version OPUS 4.7.1.2 und PHP 7.1 hat es funktioniert, das Updateskript ist ohne Fehler durchgelaufen. Vielen Dank, der Tipp war sehr hilfreich!