Entgegen dem Themen-Präfix geht's hier nicht um Gerüchte, sondern um Fakten bezüglich kommender und relevanter Änderungen, die auch Erweiterungen Entwickler betreffen werden. Laut UPGRADE Doc von PHP 8.4-rc3 dürften Probleme bei den meisten Erweiterungen die schon für 8.3 geeignet sind, eher unwahrscheinlich sein. Es gibt jedoch 2 Änderungen die mir aufgefallen sind, die zukünftig relevant werden für uns, dazu ein Auszug aus dem besagten Dokument:
Quelle: https://github.com/php/php-src/blob/98c ... #L477-L481- Core:
. Implicitly nullable parameter types are now deprecated.
RFC: https://wiki.php.net/rfc/deprecate-impl ... able-types
. Passing E_USER_ERROR to trigger_error() is now deprecated.
RFC: https://wiki.php.net/rfc/deprecations_p ... gger_error
Um die Hintergründe besser verstehen zu können, einfach dem jeweiligen Link im Zitat folgen. Laut meiner Suche in meinem lokalen Erweiterungen Archiv, sind davon viele Erweiterungen betroffen, auch hier bei uns. Was
E_USER_ERROR betrifft, so wird es auch bei phpBB selbst Änderungen geben müssen, da der Error Handler von phpBB direkt damit zu tun hat. Der Error Handler ist z.Z. sehr präsent für mich, wegen EMP 2.1.0, daher wusste ich das auch sofort.Beides wird ab 8.4 erstmal nur DEPRECATED Meldungen triggern, aber es ist durchaus sinnvoll, wenn man das frühzeitig anpasst. Solche Meldungen bekommt man nur, wenn der Debug Modus aktiv ist, was bei Entwickler aber ohnehin Standard ist bzw. sein sollte. Als "veraltet" eingestufte Features werden üblicherweise dann bei der nächsten Minor oder Major Version entfernt oder geändert und würden dann
E_ERROR verursachen, mindestens aber E_WARNING.edit 9.11.24: Das
trigger_error Problem sollte klar sein, das andere ist aber nicht unbedingt selbsterklärend, darum hier meine Erklärung aus einem anderen Forum:
Nähere Erklärung zu "Implicitly nullable"
Der betroffene Code Block ist dieser hier:
Das Problem hier ist der Parameter
Implizit heisst hier, dass quasi angenommen wird, dass der Parameter auch
Hier haben wir definiert, dass der letzte Parameter optional ist und als Default
Jetzt geben wir explizit die Variablen-Typen vor und ab jetzt haben wir es auch mit dem implicite-nullable-Problem zu tun. Jetzt wird beim optionalen Parameter explizit ein
Jetzt haben wir EXPLIZIT folgendes für den optionalen Parameter definiert: Darf entweder ein
Die Lösung für das Problem im Konstruktor wäre also:
Ein simples ? direkt vor dem Variablentyp/Klasse und schon ist das Problem erledigt.
Siehe auch: Nullable-Typen
Code: Alles auswählen
public function __construct(
\phpbb\template\template $template,
\phpbb\collapsiblecategories\operator\operator $operator = null,
\phpbb\language\language $language
)
$operator und dessen Default = null. Das ist hier eine implicite nullable (implizit Null-bar) Deklaration. Das heisst, der Parameter darf entweder das Klassen-Objekt \phpbb\collapsiblecategories\operator\operator enthalten, oder null. Und genau diese implizite Deklaration ist ab 8.4 als veraltet eingestuft.Implizit heisst hier, dass quasi angenommen wird, dass der Parameter auch
null sein darf. Und genau diese "Annahme" muss stattdessen durch eine explicite-nullable Deklaration ersetzt werden. Dazu erst ein kompakteres Beispiel:Code: Alles auswählen
function test($param_a, $param_b, $param_c = null)
{
// Hier machen wir irgendwas sinnvolles... oder auch nicht. ;-)
}
null enthält. Bei diesem Code betrifft uns das implicite-nullable-Problem nicht, da hier keine strikte Typdeklaration vorhanden ist. Das heisst $param_c kann "irgendeinen" Typ haben. Ganz anders sähe es so aus:Code: Alles auswählen
function test(string $param_a, bool $param_b, array $param_c = null)
{
// Hier machen wir irgendwas sinnvolles... oder auch nicht. ;-)
}
array erwartet, aber es wird ausserdem implizit (indirekt) auch null akzeptiert. Und genau das (implizit) mag PHP ab 8.4 nicht mehr und möchte es zukünftig (frühestens bei 8.5) ganz genau wissen. Um ein Variablentyp also auch als "nullable" (darf auch null sein) deklarieren zu können, wird ein simples Fragezeichen (?) direkt vor der Typdeklaration benötigt. Das gibt es seit PHP 7.1. Demnach sähe die Lösung bei unserem kompakten Beispiel so aus:Code: Alles auswählen
function test(string $param_a, bool $param_b, ?array $param_c = null)
{
// Hier machen wir irgendwas sinnvolles... oder auch nicht. ;-)
}
array oder null sein, was anderes wird hier nicht akzeptiert. Und als Default wird auch gleich ein null definiert.Die Lösung für das Problem im Konstruktor wäre also:
Code: Alles auswählen
public function __construct(
\phpbb\template\template $template,
?\phpbb\collapsiblecategories\operator\operator $operator = null,
\phpbb\language\language $language
)
Siehe auch: Nullable-Typen
Scheinbar hat man die SuFu auf die Mitglieder limitiert, was doppelt clever ist, weil man so die Anzahl derjenigen die die SuFu nutzen dürfen/können drastisch reduziert und man so das Ganze auch erheblich besser steuern und kontrollieren kann.