phpBB Ext Check - Diskussion bezüglich Prozedur und Reports

[IMC]

Wenn du interessiert bist, würde ich das hier darlegen. Dafür gibt es CodeSniffer-spezifische Anweisungen die man direkt als Kommentar im Source einfügen kann.

Hi Patrick,

ich bin sehr interessiert. Ich lerne immer wieder gern dazu.

[LukeWCS]

Der Kniff besteht darin, in derjenigen Datei, in der die reale PHP Funktion aufgerufen wird, den zugehörigen Sniff zu deaktivieren. Da du beide Funktionen in derselben Datei definiert hast, muss auch nur eine Datei berücksichtigt werden.

main_listener.php

Code: Alles auswählen

/**
 * External Links listener
 */
class main_listener implements EventSubscriberInterface
{
	# phpcs:disable PHPCompatibility.FunctionUse.NewFunctions.str_starts_withFound, PHPCompatibility.FunctionUse.NewFunctions.str_containsFound

Falls dir eine vertikale Notation lieber ist, auch kein Problem:

Code: Alles auswählen

/**
 * External Links listener
 */
class main_listener implements EventSubscriberInterface
{
	# phpcs:disable PHPCompatibility.FunctionUse.NewFunctions.str_starts_withFound
	# phpcs:disable PHPCompatibility.FunctionUse.NewFunctions.str_containsFound

Im Gegensatz zur DL Ext, wo wir eine globale VA Variable mit Werten bestücken, wird hier der Sniff lokal (pro Datei) deaktiviert. Sobald von CodeSniffer beim Parsen also das Dateiende erreicht wurde, werden alle bis dahin deaktivierten Sniffs automatisch wieder reaktiviert, das musst du also am Ende der Datei nicht selbst machen.

Bei solchen CS Kommentare bin ich seit einiger Zeit dazu übergegangen, diese nicht mit // einzuleiten, sondern mit #. Aus dem einfachen Grund, weil sich das dann optisch ein wenig von den gewohnten Kommentaren abhebt. Das kannst du also frei entscheiden. Wichtig ist bei den CS Anweisungen nur, dass diese sich immer innerhalb der Klasse befinden müssen, weil sonst EPV Fehler meldet (völlig grundlos übrigens), wie Karsten festgestellt hat.

[IMC]

Danke Patrick,

jetzt ist steht alles auf grün.
Zum Auskommentieren habe ich zur besseren Abgrenzung zum php-Code ebenfalls das hash genutzt.

[LukeWCS]

Zum Auskommentieren habe ich zur besseren Abgrenzung zum php-Code ebenfalls das hash genutzt.

So war auch meine Intention. Immerhin ist es nur aus PHP Sicht ein gewöhnlicher Kommentar, jedoch nicht aus PHPCS Sicht.

[LukeWCS]

Info: Im Startbeitrag eine gelbe Infobox hinzugefügt, deren Text die Natur von EC klar benennt. Mir ist gestern aufgefallen, dass ein solcher Passus fehlte.

[LukeWCS]

Am 1 Dezember hat Juliette auf dem CodeSniffer GitHub Repository offiziell verkündet, dass Greg Sherwood, der bisherige Hauptentwickler, sich aus beruflichen Gründen von dem Projekt zurückzieht und dieses aufgibt. Juliette, Hauptentwicklerin bei PHPCompatibility, hat ebenfalls verkündet, das CS Projekt übernommen zu haben. Bei der Fortführung des Projekts ist es jedoch eine Bedingung, das sich genügend Unterstützer/Sponsoren finden, die das Projekt finanziell unterstützen.

Nachfolgend die offizielle Bekanntgabe: The Future of PHP_CodeSniffer

Von CS gibt es eine beachtliche Anzahl von Installationen und ebenfalls eine beachtliche Anzahl davon abhängiger Projekte. Auch phpBB.com setzt CS ein; für "phpBB PHP Strict Standard Extensions", dem Regelwerk mit dem Sourcecode hinsichtlich Richtlinien geprüft werden kann. Der phpBB Ext Check Dienst ist ebenfalls auf CS angewiesen, wobei ich bekannterweise noch weitere Regelwerke einsetze, nämlich PHPCompatibility und VariableAnalysis.

Auf der technischen Seite wurde der Besitzerwechsel auch bereits vollzogen und zwar so, das man bestehende Composer Projekte mit Abhängigkeiten zu CS nahtlos weiterführen kann, inklusive Updates. So zumindest bei EC, ich weiss nicht, ob das für alle Composer Projekte gilt, wo CS eingesetzt wird. Ich konnte jedenfalls problemlos das Update auf CS 3.8.0 ausführen, welches bereits unter neuer Federführung (von Juliette) veröffentlicht wurde.

Des Weiteren wird der Prüfumfang bei EC 1.8.0 (in Arbeit) nochmals erweitert, es wird dann auch nach XHTML gesucht in den Dateitypen *.html, *.php und *.js. Hilfreich beim modernisieren älterer Exts um gezielt alten XHTML Code entfernen zu können, welcher nicht mehr relevant ist. Dazu wurde ein neues CLI Tool geschaffen sowie ein neues Prüfmodul in EC eingerichtet, mit dem das CLI Tool gesteuert wird. Dazu baue ich das bereits bestehende CLI Tool YAMLcheck zu einem universell nutzbaren Prüf-Tool um, damit dessen Basis für weitere Tools (wie XHTMLcheck) genutzt werden kann. Das Tool prüft dann auf folgende Codes und meldet Funde diesbezüglich:

1. <![CDATA[
2. ]]>
3. checked="checked"
4. selected="selected"
5. />

Zwischenzeitlich (November) wurde auch das Upload Limit von 5mb auf 10mb erhöht, das sollte für die meisten Exts ausreichen. Falls eine Ext grosse Mediendateien hat, dann sollten diese vor dem Upload aus dem ZIP entfernt werden, da diese für EC ohnehin irrelevant sind.

[IMC]

Hallo Patrick,

eben ist mit aufgefallen das ich beim XHTML Check falsche Warnmeldungen bekomme.
Diese werden von XSL-Code für das Template des TextFormatter ausgelöst.
Beispiel: <xsl:value-of select="string($L_BEISPIEL)"/>

Die verschiedenen Funktionen/Elemente die eine Warnung auslösen können beginnen immer mit <xsl: und schließen mit />.

[LukeWCS]

Hallo Thorsten

Danke für die Meldung. Mit XSL habe ich mich noch gar nicht beschäftigt. Hast du ein Ext Beispiel mit dem ich das direkt testen kann? Ich müsste dann das RegEx so gestalten, dass XSL ignoriert wird. Kann aber dauern, Grippe. Neuronen sind langsamer als ne Schildkröte auf Baldrian.

[IMC]

Hast du ein Ext Beispiel mit dem ich das direkt testen kann?

External Links

Kann aber dauern, Grippe.

Mach langsam. Hat alles Zeit und ist nicht eilig.
Ich höre immer wieder, dass Leute in unserem Alter Herzmuskelentzündungen bekommen, weil sie sich nicht auskurieren.

Ich wünsche gute Besserung.

[LukeWCS]

Danke und danke Thorsten.

Eine Änderung des RegEx war in dem Fall nicht möglich, weil ein XSL Block ja über mehrere physische Zeilen gehen kann, aber die YAML und XHTML Tools Zeilenorientiert arbeiten. Deswegen maskiere ich jetzt einfach in der gesamten Datei vorab sämtlichen XSL Code, damit die verschiedenen bestehenden RegEx Regeln nicht auf den XSL Code reagieren. Update am EC Server heute oder morgen, ich geb dann nochmal hier Bescheid.