Was macht FSWP Core Contributor?
Grundlegend (immer angewandt): fswp-developer/references/lean-coding.md (weniger schreiben, zuerst wiederverwenden), fswp-developer/references/coding-standards.md (Codierungsstandards, Dokumentation, i18n, Barrierefreiheit) und fswp-security-engineer (Eingabe, Ausgabe, Autorisierung).
Die hier enthaltenen Workflow-Fakten wurden am 2026-09-28 gegen das Core Contributor Handbook geprüft. Core-Prozesse ändern sich; bestätigen Sie zeitkritische Details in fswp-developer/references/official-docs.md, bevor Sie Ratschläge geben. Nichts hier übermittelt etwas: Der Benutzer erstellt Tickets und Pull Requests selbst (GitHub-Automatisierung ist vorbehalten, siehe fswp-developer/references/github-foundation.md).
Änderung zuerst klassifizieren
| Die Änderung betrifft... | Geht zu |
|---|---|
| Eine Sicherheitslücke | Dem privaten Sicherheitsprozess, der im Core-Handbook verlinkt ist. Niemals ein öffentliches Ticket oder PR. Stoppen und entsprechend kommunizieren. |
| PHP, Admin-Oberflächen, APIs, Tests, den meisten Core-Code | Trac-Ticket plus Patch oder Pull Request gegen WordPress/wordpress-develop (dieser Skill) |
| Den Block-Editor (Gutenberg-Pakete, Editor-UI, Site Editor) | Issues und Pull Requests auf WordPress/gutenberg; Core erhält Aktualisierungen von dort. Lesen Sie den Contributing-Guide dieses Repositories. |
| Einen Plugin- oder Theme-Fehler | Nicht Core; verwenden Sie fswp-maintainer und melden Sie dies an das entsprechende Projekt |
| Dokumentation | Der entsprechende Workflow des Documentation-Teams im relevanten Handbuch |
Zuerst ein Ticket
- Durchsuchen Sie Trac (https://core.trac.wordpress.org/) nach dem Symptom. Lesen Sie die Ticket-Historie und alle Patches.
- Falls kein Ticket existiert, entwerfen Sie eines: präziser Titel, WordPress-/PHP-Versionen, Schritte zur Reproduktion, erwartetes vs. tatsächliches Verhalten und warum es sich um einen Fehler (Bug) und nicht um eine Verbesserung (Enhancement) handelt. Der Benutzer meldet es unter der richtigen Komponente.
- Beachten Sie Workflow-Keywords auf dem Ticket (z. B. eine Anfrage nach Komponententests) und befolgen Sie diese.
Umgebung
Verwenden Sie den Entwicklung-Checkout, nicht eine normale Website:
- Klonen Sie
WordPress/wordpress-develop(Git-Mirror des kanonischen Repositorys, das in Subversion verwaltet wird). - Docker und Node werden für den Standard-Workflow benötigt. Führen Sie vom Wurzelverzeichnis des Checkouts aus:
npm install,npm run build:dev,npm run env:start,npm run env:install. - Führen Sie die PHP-Tests mit
npm run test:phpaus. Übergeben Sie PHPUnit-Argumente nach einem doppelten Bindestrich, z. B.-- --group formatting. Tests, die mit@ticketgekennzeichnet sind, werden als Gruppe nach Ticketnummer ausgeführt. Multisite hat eine eigene Konfiguration (-c tests/phpunit/multisite.xml); AJAX-Tests werden mit--group ajaxausgeführt. - Nicht-Docker-Workflows (Composer, PHPUnit PHAR) sind möglich; siehe die PHPUnit-Seite im Handbuch.
Änderung schreiben
- Branch von trunk; benennen Sie den Branch mit der Ticketnummer (z. B.
12345-short-description. Halten Sie die Änderung auf ein Ticket beschränkt. - Codierungsstandards: WordPress PHP-, JS-, CSS- und HTML-Standards, einschließlich Yoda-Bedingungen, Tabs, Leerzeichen und Escaping-/Sanitization-Regeln. Führen Sie PHPCS auf geänderten Dateien aus.
- Inline-Dokumentation: PHPDoc für neue oder geänderte Funktionen, Hooks und Klassen im Core-Stil, mit
@sinceauf die Version gesetzt, die der Meilenstein des Tickets angibt. - Abwärtskompatibilität: Core bricht fast nie öffentliches Verhalten. Veralten Sie (
_deprecated_function()und Verwandte) statt zu entfernen; halten Sie Filter und Aktionen stabil; bewahren Sie Funktionssignaturen. - Tests: Fügen Sie PHPUnit-Tests hinzu oder aktualisieren Sie sie, die vorher fehlschlagen und nachher bestehen, gekennzeichnet mit
@ticket. Ein Bug-Patch ohne Test wird normalerweise gebeten, einen hinzuzufügen. - Sicherheit und Leistung: dieselben Regeln wie für jeden WordPress-Code (
fswp-security-engineer,fswp-performance-engineer), mit höheren Anforderungen. - Bündeln Sie keine unzusammenhängenden Formatierungen oder Refactorings.
Einreichen (durch den Benutzer)
- Hängen Sie eine
.diff-Datei an das Trac-Ticket an, benannt nach der Ticketnummer, oder eröffnen Sie einen Pull Request gegenWordPress/wordpress-develop, der auf das Ticket verweist. Pull Requests werden zur Überprüfung verwendet; sie werden nicht auf GitHub gemergt, da Committer durch das kanonische Repository committen. - Verfassen Sie einen Ticket-Kommentar: was der Patch tut, wie Sie getestet haben, Schritte, die ein Tester befolgen kann, und offene Fragen. Entwerfen Sie ihn für den Benutzer mithilfe von
references/ticket-comment-template.md. - Rechnen Sie mit Überprüfung, Änderungswünschen und einem langsamen Zyklus. Antworten Sie auf dem Ticket, aktualisieren Sie den Patch und halten Sie ihn auf Basis von trunk rebased.
Vor Übergabe verifizieren
Führen Sie fswp-qa-engineer mit der Core-Checkliste aus: Die Reproduktion schlägt vorher fehl und besteht nachher, die relevante Testgruppe besteht, die Codierungsstandards sind auf den geänderten Zeilen sauber, die Dokumentation ist vorhanden und die Abwärtskompatibilität ist intakt.