Seite 1 von 2

Buschtrommel: PHP 8.4 und relevante Änderungen

Verfasst: 01.11.2024 14:02
von LukeWCS
Hallo Kollegen

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:
- 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
Quelle: https://github.com/php/php-src/blob/98c ... #L477-L481

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:

Code: Alles auswählen

	public function __construct(
		\phpbb\template\template $template,
		\phpbb\collapsiblecategories\operator\operator $operator = null,
		\phpbb\language\language $language
	)
Das Problem hier ist der Parameter $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. ;-)
}
Hier haben wir definiert, dass der letzte Parameter optional ist und als Default 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. ;-)
}
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 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. ;-)
}
Jetzt haben wir EXPLIZIT folgendes für den optionalen Parameter definiert: Darf entweder ein 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
	)
Ein simples ? direkt vor dem Variablentyp/Klasse und schon ist das Problem erledigt.

Siehe auch: Nullable-Typen

Re: Buschtrommel: PHP 8.4 und relevante Änderungen

Verfasst: 01.11.2024 16:41
von Mike-on-Tour
Danke für das Heads up, zumindest den Hinweis bezüglich E_USER_ERROR hatte ich auch schon gefunden und bin tatsächlich im Event-Listener der Usermap betroffen.
Der Ersatz mit E_USER_WARNING scheint da aber zu funktionieren und wird dann in der nächsten Version drin sein.

Re: Buschtrommel: PHP 8.4 und relevante Änderungen

Verfasst: 01.11.2024 16:49
von LukeWCS
Servus Mike

Ja, den Hinweis auf Usermap wollte ich dir noch auf Discord geben, weil das eine der Exts ist, die mir bei meiner kurzen Suche auffielen.

E_USER_WARNING ist ohnehin besser - aus Endbenutzersicht - weil dadurch die Fehlermeldung in einem phpBB Gerüst eingebettet ist, während E_USER_ERROR mehr nach einem "Absturz" aussieht, weil dabei das umgebende phpBB Gerüst fehlt. E_USER_ERROR hat quasi ein "hartes" Beenden von phpBB zur Folge ohne Rücksicht auf das phpBB Gerüst, während E_USER_WARNING mehr in "geordneten/kontrollierten" Bahnen verläuft.

In beiden Fällen wird phpBB beendet, nur der Weg dahin ist anders.

Re: Buschtrommel: PHP 8.4 und relevante Änderungen

Verfasst: 01.11.2024 17:05
von oxpus
Tjoar, E_USER_ERROR wird in der Downloads Extension ebenfalls verwendet, kommt dann auch in der nächsten Version sogleich raus.

Danke für den Hinweis.

Re: Buschtrommel: PHP 8.4 und relevante Änderungen

Verfasst: 01.11.2024 17:10
von LukeWCS
Gerne Karsten, bei DL Ext wird das ja durchaus mehrfach genutzt.

Kirk und chris1278 kennen meine Buschtrommel-Themen schon vom WWH, da teile ich neue Erkenntnisse im phpBB Umfeld auch immer zügig mit, wenn es eine der Erweiterungen von uns dreien betrifft oder mal betreffen könnte.

Re: Buschtrommel: PHP 8.4 und relevante Änderungen

Verfasst: 02.11.2024 17:19
von Talk19zehn
Und wie verhält es sich mit jenem existierenden Lösungsansatz: phpBB, Pull requests ....?
https://github.com/search?q=repo%3Aphpb ... llrequests

Kommt jemand heran? Bei mir klappt es wiederkehrend nicht, undzwar zeitlich (dortige Serverüberlastung).

LG

Re: Buschtrommel: PHP 8.4 und relevante Änderungen

Verfasst: 02.11.2024 17:32
von IMC
Für die suche in einem Repro muss man bei GitHub eingeloggt sein.
Hier das gewünschte Suchergebnis: https://github.com/phpbb/phpbb/pull/6706

Re: Buschtrommel: PHP 8.4 und relevante Änderungen

Verfasst: 02.11.2024 18:58
von LukeWCS
Talk19zehn, ist das, was Thorsten verlinkt hat, das, was du meintest? Wenn ja: da gehts um die "Unit Tests", also das automatische Testverfahren bei phpBB was u.a. dazu dient, Regressionsfehler bei Updates zu vermeiden. Mit dem regulären phpBB Core den wir Admins installieren und aktualisieren, hat das erstmal nichts zu tun.

Bei den besagten beiden Problemen hier im Thema sind sowohl die phpBB Entwickler als auch die Ext Entwickler gefragt. Da besteht also unabhängig Handlungsbedarf auf beiden Seiten.

Thorsten, interessant, wusste ich auch noch nicht, dass man da eingeloggt sein muss damit die SuFu brauchbar ist. Logge ich nicht ein, hab ich das gleiche Problem wie Talk19zehn; sprich da geht schlicht gar nix. Bestenfalls kriege ich dann nur variierende Server Fehlermeldungen. :wink: 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.

Ich hatte vor deinem Beitrag einfach Google benutzt, aber bei "phpBB PHP 8.4" kriege ich sofort dieses Thema hier als erstes Ergebnis. ^^

Re: Buschtrommel: PHP 8.4 und relevante Änderungen

Verfasst: 02.11.2024 20:32
von Talk19zehn
Evtl. zunächst hier ggf. zusammengefasst: Ein kleiner Überblick, mehr habe ich auf die Schnelle nicht gefunden.

https://github.com/phpbb/phpbb/pull/6707

https://github.com/phpbb/phpbb/pull/6706

https://github.com/phpbb/phpbb/pull/6647

https://github.com/phpbb/phpbb/pull/6645

Danke dir für die Buschtrommel (PHP 8.4 und relevante Änderungen), LukeWCS.

Re: Buschtrommel: PHP 8.4 und relevante Änderungen

Verfasst: 09.11.2024 14:20
von LukeWCS
Inzwischen wurde mir klar, dass die RFC Seite zu "Implicitly nullable" nicht unbedingt selbsterklärend ist, auch durch eine Diskussion in einem anderen Forum, wo ich mit Kollegen darüber geplauscht habe. Die Natur einer RFC Seite ist es, über Änderungen abzustimmen, aber nicht unbedingt um den PHP Programmierern zu erklären, was genau sie dann ändern müssen, denn das ist Aufgabe der Migration Guides die immer beim Release einer neuen PHP Minor Version veröffentlicht werden.

Darum habe ich im Startbeitrag kurzerhand meine Erklärung vom anderen Forum als Spoiler hinzugefügt und noch ergänzt.

edit: mich betrifft das Problem ebenfalls oder hat mich betroffen, z.B. bei "Extension Manager Plus" bis einschliesslich 2.0.0, bei "LF who was here" bis einschliesslich 2.2.0.