phpBB Ext Check - Diskussion bezüglich Prozedur und Reports

[LukeWCS]

Der Autor von VA ist auf meinen Vorschlag eingegangen, den Fix auch noch bei 2.x zu integrieren und hat vorgestern VA 2.8.2-beta.1 veröffentlicht. Das Update habe ich natürlich auch gleich in EC geholt und während der letzten 2 Tage bereits Erfahrungen mit VA 2.8.2 gesammelt, bislang sieht alles gut aus. Wundert euch also nicht, wenn VA jetzt mehr meldet wie bisher, das hängt natürlich mit dem Fix zusammen. VA meldet jetzt genau das, was es eigentlich melden sollte.

Thank you Payton.

EC 1.2.2 und VA 2.8.2 gingen gerade online: EC kann jetzt auch mit riesigen Erweiterungen umgehen, bislang gab es bei der Log-Verarbeitung gewisse Limits. Des Weiteren werden jetzt bei allen Prüfmodulen - mit Ausnahme von EPV - die Logs noch weiter unterteilt und zwar nach Dateien. Das ist inbesondere bei sehr grossen Erweiterungen sinnvoll in Bezug auf Übersichtlichkeit.

Im Startbeitrag gibt es neben den Bildern noch Links zu gespeicherte Berichte, die als Demo nützlicher sind, als statische Screenshots.

[Mike-on-Tour]

Habe das gerade mal ausprobiert, sieht sehr gut, insbesondere die Unterteilung der einzelnen Prüfergebnisse nach Dateien ist sehr übersichtlich und erleichtert die Auswertung deutlich. Und das der VA jetzt mehr findet, hat sich auch bestätigt, bisher hat er ja bei Variablen, die in der Funktion (also in der Klammer hinter der Funktions-Deklaration) aufgeführt, aber nicht mehr verwendet wurden, nichts gemeldet, jetzt tut er das.
Vielen Dank für deine tolle Arbeit, das erleichtert das Schreiben von Extensions ungemein.

[Kirk]

Kann mich den Lob nur anschließen, funktioniert sehr gut, sehr übersichtlich.

[Dr.Death]

Ich reihe mich mal ein..... hab durch die neue Version tatsächlich ein paar weitere, ungenutzte Variablen eliminieren können.


Vielen Dank..... auch im GitHub Log vermerkt

[LukeWCS]

Danke euch!

@Kirk
@Mike-on-Tour

Bezüglich VA und $event im Listener: da das im WWH Testforum gerade auch wieder ein Punkt ist, habe ich mir das jetzt mal direkt im Source von phpBB angeschaut, also da wo die Events erzeugt werden.

• In der Doku finde ich bei "The event listener" den Namen $event und das wird auch in jeder Ext die ich bisher gesehen habe so verwendet. Aber rein technisch gesehen, ist der Name völlig frei wählbar. Das wird klar wenn man sich anschaut wie das Ganze unter der Haube funktioniert. Bei einem Event wird grundsätzlich ein assoziatives Array an die verknüpfte Listener-Funktion geliefert und wie dieses Array heisst, ist irrelevant. Da könnte genauso gut $emmelbroessel in der Funktionsdeklaration stehen, solange auch die Referenzen darauf den gleichen Namen nutzen. Abgesehen davon das $emmelbroessel nicht erlaubt ist, da englische Variablennamen benutzt werden müssen. Der Name $event ist einfach passend und hat sich so etabliert, egal ob das von den phpBB Devs so gewollt war oder nicht. Ist also sehr sinnvoll das bei der eigenen Ext genauso zu machen.
• Dann gabs die Frage, ob $event prinzipiell angegeben sein muss, egal ob es benötigt wird oder nicht. Rein technisch gesehen: nein, muss es nicht. Ich habe etliche Tests mit LFWWH unternommen und es gibt nicht die geringsten Probleme, wenn an eine Funktion Daten übergeben werden, die in der Funktion selbst gar nicht angenommen werden, sprich wenn eine Variable in der Funktionsdeklaration fehlt, die die Daten aufnehmen könnte. Des Weiteren habe ich festgestellt, dass auch andere Ext Coder $event weglassen, wenn es nicht benötigt wird. Prominente Beispiele: "Recent Topics" und "mChat", beide sind validiert und in der CDB zu finden. Und so nebenbei ist mChat von einem der Validatoren.

Zusammengefasst:

Muss die Variable zwingend $event heissen? -> Technisch gesehen nein, aber es hat sich schlicht so etabliert.
Muss $event auch dann angegeben werden, wenn es in der Listener-Funktion gar nicht benötigt wird? -> Nein

[LukeWCS]

Ich habe eben erfahren, dass ein schlechtes Ergebnis bei EPV keine sofortige Ablehnung der Erweiterung beim Upload in der CDB zur Folge hat. Ich habe den betreffenden Satz mit meiner falschen Aussage im Startbeitrag gelöscht.

[LukeWCS]

Ein Epic Fail in mehreren Akten:

Erster Akt
Nach dem Update 1.2.3 auf dem Server gestern Abend, ging zuerst gar nichts mehr. Sprich, nur noch YAMLcheck wurde ausgeführt, sonst kein anderes Modul. In den Logs von allen Prüfmodulen war nur noch das zu finden (Beispiel CS):

Code: Alles auswählen

Ruleset       : phpBB PHP Strict Standard Extensions
Extensions    : php,js,css

Parse error: syntax error, unexpected ':', expecting '{' in /vendor/symfony/polyfill-php80/bootstrap.php on line 23

Auf WampServer war natürlich alles okay als ich das Update hochgeladen habe. Nur auf dem Server dann nicht mehr. Darum zuerst wieder das Paket von 1.2.2 installiert, bis klar ist, was die Ursache ist.

Zweiter Akt
Nach einiger Suche fand ich dann heraus, dass es an der neuen Version von "symfony/debug" 4.4.9 lag, genauer gesagt an dessen neuer Abhängigkeit "symfony/polyfill-php80" welches automatisch installiert wurde. Nach einem Downgrade auf "symfony/debug" 4.4.8 mit automatischer Deinstallation von "symfony/polyfill-php80" ging wieder alles. So hab ich wenigstens auch mal "conflict" in composer.json kennengelernt, mit dem man gezielt die Installation spezifischer Versionen unterbinden kann. ^^ Aber okay, das war ja nur Symptom-Bekämpfung.

Dritter Akt
Dann schaute ich mir die betreffende Stelle im Code von "symfony/polyfill-php80" an. Dort wurden explizite Typdeklarationen für Rückgabewerte bei Funktionen definiert. Das ist etwas, was erst bei PHP 7.0 eingeführt wurde. Aber laut der Fehlermeldung konnte PHP damit nichts anfangen, was mich stutzig machte "weil ja PHP 7.2 läuft". Theorie und Praxis. Also baute ich einige Debug Anzeigen in YAMLcheck ein, unter anderem auch für die PHP Version und traute meinen Augen nicht, als ich bei der PHP Version "5.6.38-nmm2" sah.

Des Rätsels Lösung nach vielen Stunden Fehlersuche war also schlicht eine falsche PHP Version. EC lief zwar wie beabsichtigt mit PHP 7.2, aber alle Analysetools liefen bisher mit PHP 5.6.38, weil diese mit der PHP CLI Version ausgeführt werden. Darum wurden jetzt nach dem neuesten Composer Update alle von Composer abhängigen Tools nicht mehr korrekt ausgeführt, weil sich dadurch auch die Abhängigkeit der PHP Version geändert hat. Nach Untersuchung der verschiedenen Composer Pakete stellte sich dann heraus, das die Abhängigkeit bezüglich PHP schon von Anfang an bei mindestens 7.1.3 lag. Dass EC seit der Umstellung auf ein Composer Projekt bei Version 1.2.0 also überhaupt noch funktioniert hat, war einfach nur Zufall, weil vermutlich keine Funktion/Codestelle der Analysetools/Abhängigkeiten angesprochen wurde, die zwingend 7.1.3 vorausgesetzt hätte. Bis jetzt.

Letzter Akt
Von WampServer wusste ich zwar, dass es 2 Versionen von PHP gibt, eine für Web und eine für CLI. Aber ich wusste nicht, das auf dem Server meines Hosters eine andere Version für CLI lief als für Web, weil ich in der Domain-Verwaltung nur eine einzige PHP Version einstellen kann. Darum ging ich bisher davon aus, dass das automatisch auch für CLI gilt. Erst nach einer kurzen Suche in der Onlinehilfe meines Hosters wurde klar, dass man andere CLI Versionen explizit per Pfadangaben ansprechen muss.

1.2.3 online... uff...

Epilog
Neben der reinen Fehlerbehebung mit Lerneffekt hat mein Epic Fail aber auch einen praktischen Nutzen: Bisher lief EC quasi mit angezogener Handbremse, jetzt hat EC die ganze Power. Das fällt insbesondere bei grösseren Erweiterungen auf. Zum Testen habe ich das überarbeitete Portal Paket von Kirk verwendet und hier die Ergebnisse:

Vorher: TIME=00:00:36.831
Jetzt: TIME=00:00:14.089

Also mehr als doppelt so schnell. Das hängt aber auch von der Erweiterung ab, besonders bei kleineren habe ich auch schon den Faktor 3 ermittelt. EC ist ein gutes Beispiel dafür, dass PHP 7 um einiges mehr Performance hat als PHP 5.

[LukeWCS]

In der nächsten Version wird es die neue Funktion "Meine Berichte" geben. Damit kann jeder eine Liste seiner eigenen Berichte anzeigen lassen, die noch auf dem Server zwischengespeichert sind, also über den Zeitraum von 24 Stunden. In dieser Liste hat man dann die Möglichkeit sich die gespeicherten Berichte erneut anzeigen zu lassen und auch zu speichern (herunterzuladen). Die Liste wird ungefähr diese Struktur haben:

Code: Alles auswählen

                      Meine Berichte (Zeitraum: 24 Stunden)
2020-06-07  00-40-57  lukewcs_wcsddesign_0-4-2              [Anzeigen] [Speichern]
2020-06-07  00-40-06  lukewcs_statspermissions_1-0-0-beta3  [Anzeigen] [Speichern]
2020-06-05  23-36-05  lukewcs_whowashere_2-0-0-RC2          [Anzeigen] [Speichern]
2020-06-05  22-12-47  lukewcs_whowashere_2-0-0-RC2          [Anzeigen] [Speichern]

[Kirk]

Bei meiner Sidebar EXT bemängelt VA in der ext.php Zeile 28 jenes:

Unused variable $lang.

soweit ich dies noch in Erinnerung habe, benötigt man dies doch unter 3.1 $lang = $user->lang;
Die komplette ext.php kann man sich in Pastebin ansehen.

[Dr.Death]

Hm, in der ext.php die Du verlinkt hast, wird die Variable $lang nach der Defnintion aber nirgends weiter genutzt / aufgerufen / weitergereicht, VA hat recht....

Du kannst Zeile 28 komplett entfernen