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 Regelsatz mit dem Sourcecode hinsichtlich Richtlinien geprüft werden kann. Der phpBB Ext Check Dienst ist ebenfalls auf CS angewiesen, wobei ich bekannterweise noch weitere Regelsätze 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.