Setup läuft nicht auf PHP 8.2

[Faar]

Hallo,
ich wollte die neueste DEV-Version auf PHP 8.2.8 und Maria DB 10.5.x installieren aber da erschien nur eine weiße Seite im Setup, keine Fehlermeldung, nichts.
Es wurde an dieser Stelle auch noch nichts in das Error Logfile geschrieben.
Das Server Logfile zeigt mir nichts an.

Mit PHP 8.1 lief es dann einwandfrei durch.

edit sagt:
Nachdem es mit dem Beispielmandanten installiert war, und ich auf PHP 8.2.8 hochgeschaltet hatte, lief es immer noch einwandfrei weiter.
Ledigliche diese Meldung taucht nun massiv im errorlog auf:
PHP Deprecated: Function utf8_decode() is deprecated in contenido/classes/class.i18n.php on line 141

Also läuft erstmal nur das Setup nicht an, wie ich das sehe.

edit 2: Falls Xmurrix hier mitliest, alle Tabellen sind nun InnoDB und Kollation alle utf8mb4_general_ci

[Faar]

Den Deprecated in class.i18n.php Zeile 141 kann man so lösen:

Code: Alles auswählen

$ret = htmlspecialchars_decode(mb_convert_encoding(conHtmlentities($ret, ENT_COMPAT, 'utf-8', false), 'UTF-8', mb_list_encodings()));

In der Folge der Reparatur tauchen dann jede Menge neuer Deprecated Meldungen im Smarty auf.

[xmurrix]

Hallo Faar,

CONTENIDO ist nicht auf PHP 8.2 angepasst worden, daher sollte man es nicht unter PHP 8.2 verwenden.
Momentan unterstützt CONTENIDO PHP 8.1.
Das Thema wurde mehrmals angesprochen und es wurde auch angemerkt, dass CONTENIDO unter PHP 8.2 Probleme bereiten kann.

...PHP Deprecated: Function utf8_decode() is deprecated in contenido/classes/class.i18n.php on line 141...

Die Funktion `utf8_decode()` ist z. B. seit PHP 8.2 als veraltet markiert, deshalb wird dessen Aufruf immer eine "PHP Deprecated" Warnung erzeugen.

Die "PHP Deprecated" Warnung kann man mit folgender PHP-Einstellung unterbinden:

Code: Alles auswählen

error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED

Wir wissen aber nicht, ob es unter PHP 8.2 auch woanders Probleme geben kann. Du schreibst zum Beispiel, dass das Setup nicht läuft. Das müsste man prüfen, wie auch andere Bereiche und den CONTENIDO Quellcode.

Auf der PHP-Webseite ist die Migration von PHP 8.1.x auf PHP 8.2.x beschrieben:
https://www.php.net/manual/de/migration82.php

Wichtig dabei sind folgende zwei Bereiche.

Nicht abwärtskompatible Änderungen:
https://www.php.net/manual/en/migration ... atible.php

Veraltete Features:
https://www.php.net/manual/de/migration ... ecated.php

VG
xmurrix

[xmurrix]

...

Code: Alles auswählen

$ret = htmlspecialchars_decode(mb_convert_encoding(conHtmlentities($ret, ENT_COMPAT, 'utf-8', false), 'UTF-8', mb_list_encodings()));

In der Folge der Reparatur tauchen dann jede Menge neuer Deprecated Meldungen im Smarty auf...

In CONTENIDO wird Smarty mit der Version 3.1.47 verwendet und diese Version ist nicht kompatibel mit PHP 8.2.
Wir müssten da auf die aktuelle 4'er Version von Smarty wechseln und wenn wir das machen, müssen wir die in CONTENIDO die Minimalanforderung für PHP von Version 7.0 auf 7.1 hochschrauben, was mich persönlich nicht stört, bestimmt aber einige andere aus der Community, die noch irgendwo einen Server mit PHP 7.0 am Laufen haben..

https://smarty-php.github.io/smarty/4.x ... g-started/

Der verwendete SwiftMailer 5.4.6 ist auch nicht kompatibel mit PHP 8.2 und der SwiftMailer wird auch nicht mehr weiterentwickelt. Hier müssten wir überlegen, ob wir auf Symfony Mailer umsteigen.
Eventuell kann man auch folgende Version des SwiftMailers aus GitHub verwenden, die jeand auf PHP 8.2 adaptiert hat:
https://github.com/viaaurea/swiftmailer-legacy

Es ist also nicht einfach, CONTENIDO auf PHP 8.2 zu adaptieren, da muss man alle verwendeten Fremdbibliotheken nachziehen und das ist einiges an Aufwand.

[lunsen_de]

Hallo zusammen,

ich will mich hier mal einklinken und meine Erfahrung teilen.

Ich habe derzeit mehrere aktive Webseiten mit der aktuellen DEV-Version und PHP 8.2.13 laufen.

Aktuell (weil auch noch veraltete Systeme auf dem Server sind) mit der Datenbankserver Version 5.5.68-MariaDB.
Hier musste ich in 3 Setup Dateien "CURRENT_TIMESTAMP" durch "0000-00-00 00:00:00" ersetzen, damit das Setup durchläuft, was ja bestätigt an der Datenbankserver Version liegt.

Bei mir läuft das Setup mit 8.0, 8.1 und auch 8.2 sauber durch.
Ich hatte nur einen Fall bei einem anderen Server, daß das Setup ewig dauerte und kurz vor Ende nicht abschloss, da der Server so langsam war, daß sicher ein Timeout für die unvollständige Fertigstellung sorgte (Hier lief allerdings PHP 8.0).
Ansonsten habe ich mit dem Setup keine Probleme gehabt (PHP 8.2) und eine weiße Seite auch nicht.

Natürlich schalte ich dann das Error Reporting extremer, damit die Deprecated und Warning die Errorlog nicht massiv vollmüllen.

Des weiteren habe ich dann noch wegen des srftime Problems die eine Anpassung in der class.date.php Zeile 346 gemacht.

Die Seiten laufen bei mir mit den Standardmodulen, AMR, den MPdevTools und der neuen Article List reloaded nahezu fehlerfrei.
Sie laufen stabil und auch der Mailversand (mit dem Beispielformular) etc. klappt fehlerfrei (Bis auf das Problem mit dem Senden Button bei neuen Formularen).

Abschliesend: ich kann das Setupproblem nicht nachstellen und kann, bis auf das Formularproblem, das System derzeit mit leichten Anpassungen gut einsetzen.

Grüße Lars

[Faar]

In CONTENIDO wird Smarty mit der Version 3.1.47 verwendet und diese Version ist nicht kompatibel mit PHP 8.2.
Wir müssten da auf die aktuelle 4'er Version von Smarty wechseln und wenn wir das machen, müssen wir die in CONTENIDO die Minimalanforderung für PHP von Version 7.0 auf 7.1 hochschrauben, was mich persönlich nicht stört, bestimmt aber einige andere aus der Community, die noch irgendwo einen Server mit PHP 7.0 am Laufen haben..

PHP 7.0 wird aber auslaufen, zwangsweise.
Folglich muss man dann auch Smarty auf die aktuellere Version adaptieren.
Ich habe noch PHP 5.6 Installationen am laufen und ohne Probleme, die werde ich nicht mehr updaten, sondern neu aufziehen.
Manche Hoster finden 8.1 schon für zu alt und manche haben mit PHP 5.6 keinerlei Probleme ohne Mehrkosten für den Kunden.
Daran aber die Entwicklung von Contenido festzumachen, halte ich für falsch.
Drum PHP 8.2 Fähigkeit herstellen.

Der verwendete SwiftMailer 5.4.6 ist auch nicht kompatibel mit PHP 8.2 und der SwiftMailer wird auch nicht mehr weiterentwickelt.

Der früher werwendete PHPMailer ist aktuell und wird hier und da verwendet, auch in Plugins für Wordpress und natürlich von mir.
Warum nicht wieder den da nehmen?
https://github.com/PHPMailer/PHPMailer

da muss man alle verwendeten Fremdbibliotheken nachziehen und das ist einiges an Aufwand.

Das sehe ich auch so und hab es befürchtet.
Seit einigen Jahren beobachte ich, dass Fremdcode nicht nur Segen ist, sondern oft auch ein Klotz am Bein.
Wie sieht es mit jQuery aus?
Einst schrieb mir mal ein kluger Programmierer, dass es manchmal besser sei, eigenen Javascript Code zu entwickeln statt immer auf Frameworks zurückzugreifen. Zum einen lerne man dadurch Javascript richtig kennen und zum anderen mache man sich nicht abhängig von Fremdcode.
Wie hieß denn diese Programmierer noch mal?

[Faar]

Ich hatte nur einen Fall bei einem anderen Server, daß das Setup ewig dauerte und kurz vor Ende nicht abschloss, da der Server so langsam war, daß sicher ein Timeout für die unvollständige Fertigstellung sorgte (Hier lief allerdings PHP 8.0).

Ein nicht näher genannte Kollege aus Franken hatte so ein Problem auch aber bei mir lief das Setup unter 8.2 erst gar nicht und bei 8.1 aber problemlos durch. Ich hatte allerdings auch keine MySQL 8.x zur Verfügung.
Gab es denn irgendeine Fehlermeldung beim langsamen Setup?

Abschliesend: ich kann das Setupproblem nicht nachstellen und kann, bis auf das Formularproblem, das System derzeit mit leichten Anpassungen gut einsetzen.

Bei mir läuft auch das Kernsystem Contenido unter PHP 8.2 soweit gut aber die Fehler werden in den Details liegen, wie beim Mailer, Smarty und anderem, wie xMurrix beschrieb.

[xmurrix]

...PHP 7.0 wird aber auslaufen, zwangsweise...

Ich würde die Unterstützung für PHP 7 komplett aufgeben und den Fokus auf PHP 8 legen. Das sollte der Verein oder 4fb entscheiden oder wer auch immer das Sagen hat.

...Der früher werwendete PHPMailer ist aktuell und wird hier und da verwendet, auch in Plugins für Wordpress und natürlich von mir.
Warum nicht wieder den da nehmen?...

Das könnte man machen, der SwiftMailer ist auch sehr gut und man hat sich halt irgendwann für SwiftMailer entschieden. Mittlerweile ist aus SwiftMailer der "Symfony Mailer" geworden, also eine Symfony Komponente. Ob man nun PHPMailer oder Symfony Mailer verwendet, spielt nur dann eine Rolle, wenn man weiß, in welche Richtung sich CONTENIDO entwickeln soll. Ich würde Symfony Mailer bevorzugen, das es ein Bestandteil von Symfony ist, Symfony weiterentwickelt wird und sich schon fast zum Standard etabliert hat. Sehr viele PHP-Projekte setzen Symfony Komponenten ein.

...Seit einigen Jahren beobachte ich, dass Fremdcode nicht nur Segen ist, sondern oft auch ein Klotz am Bein...

Sehr oft ist aber auch Fremdcode, das von einer großen Community entwickelt und getestet wird, viel besser als eine Eigenentwicklung, dass man irgendwie erstellt, nicht richtig testet und/oder wenig Zeit für die Weiterentwicklung hat. Um Änderungen, Bugs u. Weiterentwicklung kümmert sich auch die Community. Einziger Nachteil bei Fremdcode kann sein, dass es nich so eine breite PHP-Version unterstützt, wie z. B. CONTENIDO.

...Wie sieht es mit jQuery aus?...

Bei jQuery muss man mit Updates vorsichtig sein, da wir auch an vielen Stellen jQuery UI haben. Wir müssen sicherstellen, dass beide weiterhin kompatibel bleiben und jQuery UI wird nicht mehr weiterentwickelt. Eigentlich sollte man die UI überarbeiten und in diesem Zuge moderneres JS & CSS verwenden, damit brauchen wir aber gar nicht anfangen, dafür haben wir die Kapazitäten nicht. Die letzten Jahre wurde die UI immer wieder überarbeitet und etwas umstrukturiert, das sollte vorerst reichen und das Gute ist, dass es bei HTML, JS & CSS kein End-of-Life wie z.B. bei PHP gibt. Wir können vermutlich auch in 10 Jahren den gleichen Code für die UI verwenden, es sieht halt irgendwann altbacken aus, hat nicht die neuesten Standards, funktioniert aber weiterhin.