Kompatibilität mit PHP 8.1

[j3nsch]

Der Entwicklungs-Branch 4.7.2 ist jetzt kompatibel mit PHP 7.1 bis 8.1. Dafür musste ein Fork des ZF1-Future Projekts angelegt werden, um durch Anpassung an PHPUnit 8, die Tests von OPUS 4 lauffähig zu bekommen.

https://github.com/OPUS4/application/tree/4.7.2

Der Branch muss jetzt vor dem Release von OPUS 4.7.2 ausführlich mit echten Instanzen und Daten getestet werden, da insbesondere für PHP 8.1 sehr viele Anpassungen gemacht wurden und manche Probleme erst mit richtigen Daten auftreten können. OPUS 4 hat sehr viele Unit Tests, aber es kann trotzdem Bereiche geben, die nicht ausreichend abgedeckt sind.

Falls Probleme gefunden werden, können diese gerne erst einmal als Kommentar hier festgehalten werden.

[alw-bsz]

Erste Testergebnisse:

Schwerwiegend:

• es kann kein neuer Datensatz über das Publish-Formular eingebracht werden; das Einbringen schlägt am Ende des Publish-Vorgangs fehl
  • Meldung GUI: Anwendungsfehler - "Es ist ein unerwarteter Fehler aufgetreten. Ihre Eingaben sind gelöscht. Bitte versuchen Sie es erneut oder wenden Sie sich an den Administrator. "
  • Logfile opus.log: Document could not be stored successfully: SQLSTATE[HY000]: General error: 1364 Field 'language' doesn't have a default value, query was: INSERT INTO `document_title_abstracts` (`document_id`, `type`, `value`) VALUES (?, ?, ?)
  • Bei eingeschaltetem Testing-Mode fehlt bei 4.7.2 der Eintrag STORE DATA: TitleMainLanguage_1: deu, Typ:Language, Sub:1 im Logfile, bei 4.7.1 ist er vorhanden

Weitere:

• Auswahl in hierarchischen Pull-Down-Menüs im Publish-Formular buggy (z.B. bei DDC-Klassen): Beim Anklicken des "runter"-Buttons springt die Auswahl auf den ersten Eintrag zurück, manche DDC-Klassen sind dadurch nicht auswählbar (z.B. die Unterklasse "914.3 Geografie, Reisen (Deutschland)" zu "910 Geographie, Reise")
• Auf der Übersichtsseite (/publish/form/check) werden leere relationale Elemente (z.B. wenn die Auswahl von Schriftenreihen im Publish-Formular möglich, in OPUS aber keine Schriftenreihen hinterlegt sind) sowie die Benennungen der Buttons ("Einträge ändern", "Dokument abspeichern") in der Metadaten-Übersicht angezeigt
• Bei der Rückkehr zum Publish-Formular über den Button "Einträge ändern" gehen die ausgewählten Einträge aus non-hierarchischen Pull-Down-Menüs meist verloren (Veröffentlichende Institution, Institut, Lizenz); die Sprachangabe bleibt hier aber interessanterweise erhalten

[j3nsch]

Danke. Das sind also Sachen, die nicht durch automatische Tests abgedeckt sind. Ich werde schauen, ob ich dafür Tests schreiben kann und die Probleme dann fixen. Beim kann es sein Publish-Modul, dass der Aufwand für neue Tests im Augenblick zu groß ist und sich nicht lohnt, weil das Modul möglichst noch in diesem Jahr komplett ersetzt werden soll.

Die Ursachen sind vermutlich Vergleichsoperationen, die mit PHP 8.1 weniger Typen-tolerant sind und dadurch nicht mehr funktionieren.

[j3nsch]

Issue OPUS4/application#1004 wurde angelegt für die Behebung der Probleme im Publish-Modul.

[j3nsch]

Die meisten der gemeldeten Probleme sind behoben (Branch 4.7.2), insbesondere der Fehler beim Speichern. Die mehrstufige Auswahl von Sammlungen, z.B. für DDC, ist noch gebrochen. Die Ursachen waren bisher alles Vergleichsoperationen, die jetzt für PHP 8.1 strikt sind und nicht mehr das erwartete Ergebnis liefern. Für die Up/Down-Funktionen für Sammlung bin ich noch dabei den Code zu analysieren, um herauszufinden wo das überhaupt umgesetzt ist.

Tests für diese Fehler zu schreiben, ist, ohne Umbauten im alten Code, leider sehr schwierig. Der Aufwand lohnt sich nicht, ohne alles wirklich gleich komplett umzukrempeln. Deshalb wird es da jetzt erst einmal keine neuen automatischen Tests geben.

[j3nsch]

Alle gemeldeten Probleme sollten gefixt sein. Der Branch 4.7.2 wurde aktualisiert.

[alw-bsz]

Wenn bei einer Sammlung Name oder Nummer nicht belegt sind, erscheint in der Anzeige im Admin-Bereich (z.B. bei den institutes unter admin/collection/show/id/20054) die Meldung
[Deprecated: trim(): Passing null to parameter #1 ($string) of type string is deprecated in /opt/opus/test472/opus4/vendor/opus4-repo/framework/library/Opus/Collection.php on line 497] (wenn keine Nummer angegeben ist; ist kein Name angegeben,, lautet die Zeilen-Nr. 496)

[j3nsch]

Ja, danke. Fix ich. Nach den strikten Vergleichoperationen sind diese Meldungen das zweite große Problem. Das betrifft eine ganze Reihe von Funktionen, die früher "null" einfach toleriert und z.B. als leeren String interpretiert haben. Diese Funktionen tauchen an tausenden von Stellen im Code auf. Alles was in Unit Tests aufgefallen ist, ist schon gefixt.

[j3nsch]

Problem wurde in OPUS4/framework#324 gefixt. In OPUS4/application#1011 wurden die Aufruf von trim() auch noch mal für die Application geprüft. Der Änderungen sind auf Branch 4.7.2.

[alw-bsz]

Die Volltextindexierung funktionert nicht, im Solr-Index gibt es keine fulltext-Einträge.

Solarium 6.2.8 wurde über den Composer geladen. Getestet mit solr 7.7.x, schema.xml und solrconfig.xml sind unverändert.
Tests mit solr 8.x funktionierten ebenfalls nicht.

[j3nsch]

Vielen Dank, ich schau mir das an.

[j3nsch]

Issue OPUS4/opus4-search#103 wurde angelegt. Das Problem war wieder eine strikte Vergleichsoperation. OPUS 4 mit Solr 8 wurde bisher nicht getestet und ist im Augenblick nicht für die nächste Version geplant.

[j3nsch]

Das Problem ist jetzt für PHP 7 und PHP 8 behoben.

[alw-bsz]

Vielen Dank, die Indexierung funktioniert bei unseren Tests jetzt einwandfrei.

[alw-bsz]

Unter PHP 7 kommt am Ende des Publish-Vorgangs die Fehlermeldung

In opus.log findet sich dazu

2023-03-29T12:01:17+02:00 ERR (ID 64240c6ced861): Document could not be stored successfully: RoleId must be set when storing Collection! Model: Opus\Document Field: Collection.
Thrown in /opt/opus/test8/opus4/vendor/opus4-repo/framework/library/Opus/Collection.php:890
2023-03-29T12:01:17+02:00 ERR (ID 64240c6ced861): Request '/test8/publish/deposit/deposit'
2023-03-29T12:01:17+02:00 ERR (ID 64240c6ced861): ErrorController: error type = EXCEPTION_OTHER
2023-03-29T12:01:17+02:00 ERR (ID 64240c6ced861): ErrorController: exception = Application_Exception: publish_error_unexpected in /opt/opus/test8/opus4/modules/publish/controllers/DepositController.php:141
Stack trace:
#0 /opt/opus/test8/opus4/vendor/opus4/zf1-future/library/Zend/Controller/Action.php(516): Publish_DepositController->depositAction()
#1 /opt/opus/test8/opus4/vendor/opus4/zf1-future/library/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('depositAction')
#2 /opt/opus/test8/opus4/vendor/opus4/zf1-future/library/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#3 /opt/opus/test8/opus4/vendor/opus4/zf1-future/library/Zend/Application/Bootstrap/Bootstrap.php(105): Zend_Controller_Front->dispatch()
#4 /opt/opus/test8/opus4/vendor/opus4/zf1-future/library/Zend/Application.php(400): Zend_Application_Bootstrap_Bootstrap->run()
#5 /opt/opus/test8/opus4/public/index.php(86): Zend_Application->run()
#6 {main}

In der Datenbank bleiben rudimentäre "temporary"-Datensätze erhalten.

Unter PHP 8 tritt der Fehler nicht auf.

[j3nsch]

In der internen Testinstanz im Hosting beim KOBV tritt das Problem auf, wenn Klassifikationen ausgeblendet sind. Im Metadaten-Formular für den "All Fields"-Testtyp tauchen dann für diese Klassifikationen Meldungen auf, dass keine Einträge gefunden wurden. Blendet man diese Klassifikationen in der Sammlungsverwaltung wieder ein, verschwindet das Problem. @alw-bsz Könnt Ihr diese Beobachtungen bestätigen? Ich nehme an Ihr testet mit den Daten und der Konfiguration einer echten Instanz. Sind dort Klassifikationen ausgeblendet?

Das Publish-Modul muss in diesem Jahr noch neu geschrieben werden. Auch eine neue Implementation kann Bugs haben, aber die Diagnose der Probleme in dem alten Modul verschlingt sehr viel Zeit, weil der Code unübersichtlich ist und die wenigen Klassen viel zu viele unterschiedliche Verantwortungen haben.

[j3nsch]

Mit dieser Erkenntnis, den ausgeblendeten Klassifikationen, kann ich das Problem jetzt lokal reproduzieren.

[j3nsch]

@alw-bsz Das Problem tritt auch mit PHP 8 auf, wenn Klassifikationen ausgeblendet werden. Ich nehme an Eure PHP 8.1 Testinstanz war nicht identisch konfiguriert.

[alw-bsz]

@j3nsch Du hast Recht, der Fehler tritt auch unter PHP 8 auf; wir konnten das reproduzieren. Wir haben sowohl mit leeren Instanzen als auch mit Echt-Daten getestet. Bei uns ist es ebenfalls so, dass ausgeblendete Klassifikationen oder leere Klassifikationen (z.B. wenn 'institutes' eingeblendet ist, aber keine Einträge enthält) zu dem Fehler führen. Wir haben zudem festgestellt, dass ein ähnlicher Fehler auftritt, wenn es keinen ThesisPublisher zur Auswahl gibt:

2023-03-30T11:15:19+02:00 ERR (ID 64255327d38c0): Document could not be stored successfully: Attempt to store model with invalid data.
Name    Value is required and can't be empty
2023-03-30T11:15:19+02:00 ERR (ID 64255327d38c0): Request '/test8/publish/deposit/deposit'
2023-03-30T11:15:19+02:00 ERR (ID 64255327d38c0): ErrorController: error type = EXCEPTION_OTHER
2023-03-30T11:15:19+02:00 ERR (ID 64255327d38c0): ErrorController: exception = Application_Exception: publish_error_unexpected in /opt/opus/test8/opus4/modules/publish/controllers/DepositController.php:141
Stack trace:
#0 /opt/opus/test8/opus4/vendor/opus4/zf1-future/library/Zend/Controller/Action.php(516): Publish_DepositController->depositAction()
#1 /opt/opus/test8/opus4/vendor/opus4/zf1-future/library/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('depositAction')
#2 /opt/opus/test8/opus4/vendor/opus4/zf1-future/library/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#3 /opt/opus/test8/opus4/vendor/opus4/zf1-future/library/Zend/Application/Bootstrap/Bootstrap.php(105): Zend_Controller_Front->dispatch()
#4 /opt/opus/test8/opus4/vendor/opus4/zf1-future/library/Zend/Application.php(400): Zend_Application_Bootstrap_Bootstrap->run()
#5 /opt/opus/test8/opus4/public/index.php(86): Zend_Application->run()
#6 {main}

[j3nsch]

Das Problem sollte für alle Felder behoben sein. Die Aufwand die Ursache zu finden war beträchtlich. Der Fix ist eine zusätzliche Zeile (Siehe: OPUS4/application#1019).

[alw-bsz]

Wenn man das Feld IdentifierDoi ins Veröffentlichungsformular einbaut und eine DOI eingegeben wird, erscheint beim Speichern der Fehler "Die eingegebene DOI existiert bereits. Bitte wählen Sie eine andere DOI." - auch wenn die DOI nicht in der DB vorhanden ist. Das passiert sowohl mit PHP7 als auch PHP8.

[j3nsch]

Danke. Wann wird der Fehler ausgegeben? Beim Wechsel vom Metadaten-Formular zum Check oder erst beim Speichern des Dokuments im Check?

[j3nsch]

Der "All Fields" Testtyp enthält ja auch das IdentifierDOI-Feld. Bei meiner 4.7.2 Instanz kann ich das Problem bisher nicht nachvollziehen. Ich kann neue DOIs eintragen. Versuche ich eine vorhandene DOI einzutragen und "Weiter" zum Check zu gehen, bekomme ich die Fehlermeldung.

In der 4.7.2 Testinstanz des Hostings tritt das Problem allerdings auch auf. Mir ist noch nicht klar, welcher Unterschied zwischen den Instanzen bestehen könnte.

[j3nsch]

Die Datenbankabfrage zur Prüfung, ob eine DOI bereits existiert, liefert die Anzahl zurück, also 0, wenn die DOI in der Datenbank nicht vorhanden ist. Im Code wird mit 0 verglichen. Bei mir funktioniert das, aber auf dem Hosting-System liefert die Datenbank anscheinend einen String "0" zurück. Bei einem strikten Vergleich ist 0 nicht gleich "0". Es sind also wieder eine Vergleichsoperation und ein fehlender Unit Test. Welcher Unterschied zwischen den Systemen dafür sorgt, dass die Ergebnisse unterschiedlich zurück geliefert werden, kann ich nicht sagen.

[j3nsch]

Das Problem musste im Framework behoben werden (OPUS4/framework#326). Es muss also composer update ausgeführt werden, um den Fix zu übernehmen.

[j3nsch]

Wenn man in der Facette "Erscheinungsjahr" einen Wert auswählt, wird dieser nicht als ausgewählter Wert angezeigt und kann damit auch nicht mehr abgewählt werden. Die Facette erscheint nur mit ihrer Überschrift? @alw-bsz Könnt Ihr das bestätigen?

[j3nsch]

Auch wieder eine Vergleichsoperation (OPUS4/application#1020). Der Jahr-Werte werden jetzt auch als Strings verglichen und damit funktioniert das wieder.

[j3nsch]

Das sollte auch wieder funktionieren. Es hätte in opus4-search gefixt werden können, aber ich habe jetzt erst einmal in der Application dafür gesorgt, dass Strings miteinander verglichen werden, auch bei den Jahreszahlen.