phpBB.de

Danke euch beiden und auch allen anderen die hier im Thema oder auf anderen Wegen konstruktives und/oder motivierendes Feedback gegeben haben.

In der Zwischenzeit habe ich beim Entwickler (nikic) des PHP Parsers 4.x (der in EPV verwendet wird) in Erfahrung gebracht, mit welcher PHP Code Version EPV nun maximal umgehen kann: 8.3. Diese Info ist jetzt auch im Startbeitrag unter Punkt 5.1.a als blaue Infobox verfügbar.

Ausserdem im Punkt 5.1.c ebenfalls in einer blauen Infobox explizit darauf hingewiesen, dass PHP 5 keine Relevanz mehr hat und nicht mehr geprüft wird.

Hello, nur am Rande mag ich erwähnen:
Heut am Morgen zwei oder drei meiner Ext´s inhaltlich auch aus Vorzeiten erneut "gegengeprüft" (frühere Protokolle sind hier vor Ort extern vorhanden). Klar, wenn eine EXT kein PHP mitbringt, da nicht erforderlich, werden im Prüfprotokoll PHP-Versionen in der neuen Farbe "Grau" mit einem Haken versehen.
Dann in jener EXT in der Composer einen Fehler eingebaut mit dem Fazit, dass quasi keine Prüfung möglich ist.

In derselben EXT die Anforderung für PHP-Version auf 7.0 gesetzt und den absichtlichen Fehler eliminiert. Prüfung möglich und alle PHP-Versionen sind mit dem graufarbenen Haken versehen.

Erneut aktuelle andere EXT´s, wie z. B. u. a. die VL geprüft, alles ist schick ... (Grün).

Nur eine von vielen meinerseits abgegebene EXT dem Check zugeführt. Diese "eine" erzeugt allerdings Warnungen - keine Fehler. Gleichwohl das Protokoll zuvor in der "Alles-Okay-Farbe" Grün protokolliert war. Diese wenigen Warnungen sind augenscheinlich nunmehr auf ein neues Konzept zurückzuführen.

LG

P.S.
Ich denke, der Check macht eine gute Arbeit. Vielen Dank!

Danke fürs Feedback. Habe gerade die Berichte gesichtet, sieht von der technischen Seite (EC) alles gut aus.

Talk19zehn hat geschrieben: 11.05.2025 15:23 Dann in jener EXT in der Composer einen Fehler eingebaut mit dem Fazit, dass quasi keine Prüfung möglich ist.

Ja, composer.json gehört zu den Grundvoraussetzungen. Das ist quasi die "wichtigste" Datei, sowohl bei phpBB als auch bei EC. Wenn deren technische Struktur ungültig ist, lehnt EC das ZIP direkt ab. Dann würde auch phpBB die Ext nicht erkennen. Diese Datei wird zwingend benötigt, um die Eckdaten der Ext auslesen zu können. Ohne die geht gar nichts. Wenn die technische Struktur gültig ist, wird die Datei schlussendlich von EPV auf gültige inhaltliche Struktur/Daten geprüft.

Bedenke auch bitte; bei EC hat sich beim letzten Update nur EPV geändert, der Fokus liegt beim Testen also auf EPV.

Gleichwohl das Protokoll zuvor in der "Alles-Okay-Farbe" Grün protokolliert war. Diese wenigen Warnungen sind augenscheinlich nunmehr auf ein neues Konzept zurückzuführen.

Auf welche Meldungen bei welcher Ext beziehst du dich dabei genau? Also was wird jetzt neu gemeldet, was vorher nicht gemeldet wurde?

Hi, eine "uralte" EXT Schneefall mit allen möglichen Deko-Elementen im Board (quasi versteckt ). Wahrscheinlich habe ich das genau das falsche Paketchen hochgeladen. Ich habe nachgesehen: XHTML - selfclosing - TAGs ...

Sorry!

Edit:
Es tut *mir leid, ungern wollte ich Irritationen hervorrufen.

Grüße

Edit 2:
*) Tippfehler "mit" anstatt "mir". Sachen gibt´s ...

Talk19zehn hat geschrieben: 12.05.2025 12:25 Ich habe nachgesehen: XHTML - selfclosing - TAGs ...

Ah okay, das XHTMLcheck Modul gibt es bei EC erst seit v1.8.0 (2023-12-26). Dieses Modul habe ich für EC entwickelt, als mir 3D-I und Marc im Rahmen eines meiner phpBB Pull Requests indirekt den Hinweis gegeben haben, dass XHTML keine Relevanz mehr hat: phpBB #6393

Es tut mit leid, ungern wollte ich Irritationen hervorrufen.

Du musst dich nicht entschuldigen, man muss das einfach nur klären, was ja jetzt geschehen ist.

Skouat und ich hatten uns im Rahmen der EPV Modernisierung über EPV und EC unterhalten und dabei war auch von Titania die Rede. Nach unserem Gespräch haben wir beide unabhängig voneinander festgestellt, dass EPV nicht in der Lage ist Titania prüfen zu können und direkt mit einem FATAL abstürzt. Das führte dann zu einem neuen EPV Issue, worauf dann eine aufwendige Fehlersuche seitens MattF erfolgte, wo Skouat und ich die jeweiligen Commits getestet und Rückmeldungen gegeben haben.

Fatal error when testing Titania #125 -> Fix issues with PHPParser in PHP 8 #126

Schlussendlich konnte MattF das Problem dann lösen und EPV ist nun auch in der Lage Titania prüfen zu können. Dadurch ist EPV robuster geworden und wie ich bereits im EPV Repo kommentierte: Wenn EPV Titania prüfen kann, kann es auch alles andere prüfen. ^^ Im weiteren Verlauf hat MattF dann noch weitere Dinge verbessert, wodurch unter anderem auch weitere EPV Issues geschlossen werden konnten.

Als ich dann am 13.5 in der lokalen Entwicklungsumgebung von EC ein Composer Update ausgeführt habe, um den neuesten EPV in EC zu integrieren, wurde auch CodeSniffer auf 3.13.0 aktualisiert und dabei entdeckte ich die nächste Baustelle. CS 3.13.0 hat bei "phpBB PHP Strict Standard Extensions" oberhalb des normalen Berichts eine Reihe von internen DEPRECATED Meldungen bezüglich veralteter Strukturen und Sniff's eingefügt. Diese sind insofern dringlich, weil ab CS 4.0 die veralteten Eigenschaften entfernt werden und somit PPSSE nicht länger ausführbar wäre.

PHPBB-17510 CodeSniffer ruleset is reported as DEPRECATED -> [ticket/17510] Fix Code Sniffer deprecations #6814

Auch diese notwendige Aktualisierung des PPSSE Regelwerks für phpBB 3.3 wurde von MattF sehr schnell realisiert. Dabei hat sich nebenbei herausgestellt, dass ich bei EC eigentlich das falsche PPSSE Regelwerk benutze, nämlich das für phpBB 4.0. Mir war schlicht nicht bewusst, dass es für 3.3 und 4.0 separate Versionen davon gibt. Das ist aber kein Problem, wie sich nach einem Gespräch mit MattF gezeigt hat. So entsprechen die Erweiterungen die in der Vergangenheit mit EC geprüft und ggf. aufgrund von PPSSE Meldungen bereits angepasst wurden, eben schon seit 2021 den neuen Richtlinien, die eigentlich erst ab phpBB 4.0 bindend sind.

Bei EC ist nun der neueste EPV aktiv, also inklusive aller 24 Updates seit dem letzten Composer Update (2025-05-05). Was die Überarbeitung von PPSSE für phpBB 4.0 angeht (welches bei EC verwendet wird), so wird das erst später nachgereicht. Damit wir bis dahin im PPSSE Bericht nicht die ganzen DEPRECATED Meldungen von CS am Anfang stehen haben, habe ich die automatische CS Log Nachbearbeitung so erweitert, dass diese Meldungen aus dem Bericht herausgefiltert werden. Das und noch weitere Details wurden im neuen EC 1.9.1 realisiert.

Vielen Dank für deine Arbeit. Dann war eigentlich PPSSE seiner Zeit voraus.

Könnte man so sagen. Wobei die Unterschiede minimal sind. Beim 3.3 PPSSE wird eine bestimmte Meldung unterdrückt, die wir beim 4.0 PPSSE aber schon seit 2021 kennen und damals ja auch unsere Exts alle entsprechend angepasst hatten. Geht um die Meldung hier:

viewtopic.php?p=1411190#p1411190

Ich muss nun doch PPSSE von Version 4.0 auf 3.3 zurückstufen. Es gibt jetzt bevorstehende Änderungen bei PPSSE 4.0, die uns bereits betreffen würden:

[ticket/17512] Add PHP Sniffer coding standard for union types

Diese Änderungen habe ich mir im Detail angeschaut und dabei schnell gemerkt, dass diese Richtlinien für 4.0 effektiv mit einer notwendigen Änderung bezüglich PHP 8.4 kollidieren würden, nämlich mit dem Implicitly-nullable Problem bzw. dessen Behebung:

Buschtrommel: PHP 8.4 und relevante Änderungen

Das würde jede Ext betreffen, bei der das besagte Problem bereits behoben wurde, deren Codebase aber noch <PHP 8.0 ist.

EIn kurzes Gespräch mit MattF hat das dann auch bestätigt. Das heisst ich ändere in EC jetzt PPSSE von 4.0 auf 3.3 und bereite das schon so vor, das zu einem späteren Zeitpunkt PPSSE 4.0 noch dazu genommen werden kann. Denn in der Übergangszeit von 3.3 auf 4.0 werden wir einige Zeit beide Versionen benötigen.

Ist es jetzt so zu verstehen dass wenn man zwecks Implicitly-nullable die notwendigen Änderungen gemacht hat aber der Code <PHP 8.0 ist, das PPSSE dann einen Fehler meldet?