Checklisten für PHP-Entwickler #

Diese Seite richtet sich an PHP-Entwickler, die ihre Arbeit in einem Durchgang prüfen möchten. Jede Liste verweist auf die Seite, die sie erklärt. Kopieren Sie eine Liste in die Beschreibung Ihres Pull Requests oder in Ihre Review-Notizen.

Inhalt #

1. Bevor Sie schreiben
2. Jede PHP-Datei
3. Eine neue Klasse
4. Eine Modul-View
5. Ein Befehl oder Cronjob-Teil
6. Ein Datentyp oder Workflow-Ereignistyp
7. Sicherheit
8. Velocity und lange Läufe
9. Tests
10. Commit und Pull Request
11. Deployment

Bevor Sie schreiben #

• To do: Gibt es eine Einstellung, eine mitgelieferte Erweiterung oder einen Erweiterungspunkt, der es bereits tut? (Erweiterungspunkte aus PHP)
• To do: Kernel-Änderung oder Erweiterung? (PHP-Änderungen beitragen)
• To do: Das Präfix der neuen Namen ist gewählt (Klassenbenennung und das Präfix exp)

Jede PHP-Datei #

• To do: Beginnt mit <?php, Unix-Zeilenenden, Leerzeichen, keine Leerzeichen am Zeilenende
• To do: php -l besteht unter dem neuesten PHP und unter PHP 8.0 (make lint80)
• To do: Keine ungeschützte Syntax oder Funktion, die neuer als PHP 8.0 ist (Code schreiben, der unter PHP 8.0 läuft)
• To do: array( ... ), Leerzeichen innerhalb von Klammern, geschweifte Klammern von Funktionen in eigener Zeile (Der Coding-Standard)
• To do: Keine skalaren, Rückgabe- oder Eigenschafts-Typdeklarationen; Docblocks mit @param und @return
• To do: make phpcs fügt keine Verstöße hinzu; make phpstan fügt keine Befunde hinzu

Eine neue Klasse #

• To do: Eine Klasse pro Datei, Dateiname ist der Klassenname in Kleinbuchstaben
• To do: Eigenschaften deklariert (keine dynamischen Eigenschaften)
• To do: php bin/php/ezpgenerateautoloads.php -e ausgeführt (Autoloads und Klassen-Maps)
• To do: Keine statische Klasseneigenschaft außerhalb des Klassenrumpfs zugewiesen
• To do: Eine Einstellung, die die Klasse nennt, geht erst live, nachdem die Klasse bereitgestellt ist

Eine Modul-View #

• To do: module.php nennt die functions der View (Richtlinie) (Schreiben Sie Ihre erste Modul-View)
• To do: Als Klasse geschrieben, die Exponential\Runnable\ModuleView erweitert, die View-Datei eine Zeile
• To do: $Params gecastet und validiert
• To do: Datenänderungen nur per POST, über Modulaktionen
• To do: HTML in einem Template, jeder Wert durch |wash
• To do: POST, Weiterleitung, GET nach einem erfolgreichen Speichern; Weiterleitungsziele aus der Anfrage geprüft

Ein Befehl oder Cronjob-Teil #

• To do: Eine Klasse, die Exponential\Runnable\Command oder CronjobPart erweitert (Einen Konsolenbefehl schreiben, Einen Cronjob-Teil schreiben)
• To do: Tag @description in der Einstiegsdatei
• To do: Exit-Code 0 bei Erfolg, ein anderer bei einem Fehlschlag; still mit -q
• To do: --dry-run für alles, was Daten ändert
• To do: Begrenzte Arbeit pro Lauf, kurze Transaktionen, In-Memory-Caches zwischen Stapeln geleert
• To do: Die Arbeit in einer Dienstklasse, die View, Befehl und Cronjob-Teil gemeinsam nutzen

Ein Datentyp oder Workflow-Ereignistyp #

• To do: Methodensignaturen exakt wie in eZDataType / eZWorkflowEventType (Einen Datentyp schreiben)
• To do: Registriert mit eZDataType::register() oder eZWorkflowEventType::registerEventType() und in der INI-Datei
• To do: Hin- und Rückweg von toString()/fromString() getestet
• To do: execute() schnell, gibt einen Status zurück, wirft nie (Einen Workflow-Ereignistyp schreiben)

Sicherheit #

• To do: Eingaben über eZHTTPTool, $Params oder Modulaktionen gelesen; Zahlen gecastet, Auswahlwerte in Allow-Listen (Eingaben validieren und casten)
• To do: SQL: Strings durch escapeString(), Zahlen gecastet, oder Bedingungen persistenter Objekte (SQL mit eZDB, sicher)
• To do: Ausgaben für ihren Kontext maskiert; htmlspecialchars() mit ausdrücklichen Flags (Ausgaben aus PHP maskieren)
• To do: Berechtigungen in Views, Fetch-Funktionen, Serverfunktionen, REST-Aktionen und Befehlen geprüft (Sicherheit in PHP-Code)
• To do: POSTs tragen das Formular-Token (CSRF-Schutz und ezformtoken)
• To do: Keine Geheimnisse in Code, URLs oder Logs
• To do: Keine Inline-Skripte und kein style="" in erzeugtem Markup

Velocity und lange Läufe #

• To do: Keine statischen Variablen in Funktionen, keine true-Flags für einmaliges Registrieren (Fallen durch statischen Zustand)
• To do: Caches nach Siteaccess, Sprache und Benutzer geschlüsselt, wo sie davon abhängen
• To do: eZExecution::cleanExit() nicht innerhalb von catch ( Exception )
• To do: Pfade aus EXP_ROOT_DIR oder eZSys, nicht aus __DIR__ einer Kernel-Datei
• To do: Zweimal hintereinander auf demselben Worker getestet, als zwei Benutzer

Tests #

• To do: Ein Test ohne Datenbank für die Logik (PHPUnit ohne Datenbank)
• To do: Datenbanktests mit @group database markiert (Datenbank- und Live-Tests)
• To do: In einem Test gesetzte INI-Werte werden in tearDown() wiederhergestellt
• To do: Funktioniert mit PHPUnit 10.5 bis 13
• To do: Eintrag in tests/test-map.json, wenn der Test die Quelldatei nicht wörtlich nennt

Commit und Pull Request #

• To do: Betreff beginnt mit Added: , Updated: , Fixed: , Removed: oder Renamed: ; der Text sagt, warum
• To do: Das Produkt wird in der Nachricht Exponential geschrieben
• To do: share/filelist.md5 aktualisiert (make manifest-fix) und committet
• To do: make check besteht
• To do: CLA hinterlegt; Pull Request klein und fokussiert; gesquasht und auf main rebased (PHP-Änderungen beitragen)

Deployment #

• To do: Autoloads neu generiert, INI-Cache geleert (--clear-tag=ini)
• To do: PHP-FPM neu geladen, Velocity-Worker neu gestartet (exp:velocity deploy)
• To do: Caches mit gerenderter Ausgabe nach dem Neuladen geleert
• To do: Caches vorgewärmt (OPcache und Cache-Vorladen)
• To do: Startseite und die geänderten Seiten geprüft; Logs gelesen

Verwandte Seiten #

• Die Checkliste für das Upgrade
• Die Checkliste für das Release
• FAQ für PHP-Entwickler
• Freie Dokumentation: diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.