Contributeur Core FSWP
Fondamental (toujours appliqué) : fswp-developer/references/lean-coding.md (écrire moins, réutiliser d'abord), fswp-developer/references/coding-standards.md (standards de codage, documentation, i18n, accessibilité), et fswp-security-engineer (entrée, sortie, autorisation).
Les faits de workflow ci-dessous ont été vérifiés par rapport au manuel du contributeur Core le 28/09/2026. Les processus Core évoluent ; confirmez tout élément sensible au facteur temps dans fswp-developer/references/official-docs.md avant de conseiller. Rien ici ne soumet quoi que ce soit : l'utilisateur dépose lui-même les tickets et ouvre les pull requests (l'automatisation GitHub est réservée, voir fswp-developer/references/github-foundation.md).
Acheminer d'abord la modification
| La modification concerne... | Va vers |
|---|---|
| Une vulnérabilité | Le processus de sécurité privé lié depuis le manuel Core. Jamais un ticket public ou une PR. Arrêtez-vous et dites-le. |
| PHP, écrans d'administration, API, tests, la plupart du code Core | Ticket Trac plus patch ou pull request contre WordPress/wordpress-develop (cette compétence) |
| L'éditeur de blocs (paquets Gutenberg, interface de l'éditeur, Éditeur de site) | Issues et pull requests sur WordPress/gutenberg ; Core reçoit les mises à jour depuis là. Lisez le guide de contribution de ce dépôt. |
| Un bug d'extension ou de thème | Pas Core ; utilisez fswp-maintainer et signalez-le à ce projet |
| La documentation | Le processus de l'équipe documentation du manuel concerné |
Ticket d'abord
- Recherchez sur Trac (https://core.trac.wordpress.org/) le symptôme. Lisez l'historique du ticket et les éventuels patches.
- Si aucun ticket n'existe, rédigez-en un : titre précis, versions de WordPress/PHP, étapes de reproduction, résultat attendu vs réel, et pourquoi il s'agit d'un défaut (bug) plutôt que d'une amélioration. L'utilisateur le dépose sous le composant approprié.
- Notez les mots-clés de workflow sur le ticket (par exemple une demande de tests unitaires) et suivez-les.
Environnement
Utilisez le répertoire de développement, pas un site normal :
- Clonez
WordPress/wordpress-develop(miroir Git du dépôt canonique, géré en Subversion). - Docker et Node sont nécessaires pour le workflow standard. Depuis la racine du répertoire :
npm install,npm run build:dev,npm run env:start,npm run env:install. - Exécutez les tests PHP avec
npm run test:php. Passez les arguments PHPUnit après un double tiret, par exemple-- --group formatting. Les tests étiquetés@tickets'exécutent par numéro de ticket comme groupe. Le multisite a sa propre configuration (-c tests/phpunit/multisite.xml) ; les tests AJAX s'exécutent avec--group ajax. - Des workflows sans Docker (Composer, PHAR PHPUnit) existent ; consultez la page PHPUnit du manuel.
Rédaction de la modification
- Créez une branche à partir de trunk ; nommez la branche avec le numéro du ticket (par exemple
12345-short-description). Limitez la modification à un seul ticket. - Standards de codage : standards WordPress PHP, JS, CSS et HTML, y compris les conditions Yoda, les tabulations, l'espacement et les règles d'échappement/assainissement. Exécutez PHPCS sur les fichiers modifiés.
- Documentation en ligne : PHPDoc pour les nouvelles fonctions, hooks et classes modifiés dans le style Core, avec
@sincedéfini sur la version que le jalon du ticket nomme. - Rétrocompatibilité : Core ne brise presque jamais le comportement public. Déprécier (
_deprecated_function()et autres) plutôt que supprimer ; maintenir les filtres et actions stables ; préserver les signatures des fonctions. - Tests : ajoutez ou mettez à jour les tests PHPUnit qui échouent avant et réussissent après, étiquetés avec
@ticket. Un patch de bug sans test se voit généralement demander d'en ajouter un. - Sécurité et performance : mêmes règles que tout code WordPress (
fswp-security-engineer,fswp-performance-engineer), avec une exigence plus élevée. - Ne regroupez pas de formatage ou de refactorisation sans rapport.
Soumission (effectuée par l'utilisateur)
- Attachez un fichier
.diffau ticket Trac nommé d'après le numéro du ticket, ou ouvrez une pull request contreWordPress/wordpress-developqui référence le ticket. Les pull requests servent à la revue ; elles ne sont pas fusionnées sur GitHub, car les commiteurs commitent via le dépôt canonique. - Publiez un commentaire sur le ticket : ce que fait le patch, comment vous l'avez testé, les étapes qu'un testeur peut suivre, et les éventuelles questions ouvertes. Rédigez-le pour l'utilisateur en utilisant
references/ticket-comment-template.md. - Attendez-vous à une revue, des demandes de modifications et un cycle lent. Répondez sur le ticket, mettez à jour le patch et maintenez-le rebasé sur trunk.
Vérifier avant de passer la main
Exécutez fswp-qa-engineer avec la liste de contrôle Core : la reproduction échoue avant et réussit après, le groupe de test pertinent réussit, les standards de codage sont propres sur les lignes modifiées, la documentation est présente, et la rétrocompatibilité est intacte.