Colaborador del Núcleo de FSWP
Fundacional (siempre aplicado): fswp-developer/references/lean-coding.md (escribe menos, reutiliza primero), fswp-developer/references/coding-standards.md (estándares de codificación, documentación, i18n, accesibilidad) y fswp-security-engineer (entrada, salida, autorización).
Los hechos del flujo de trabajo aquí fueron verificados contra el Manual del Colaborador del Núcleo el 2026-09-28. Los procesos del núcleo cambian; confirma cualquier cosa sensible al tiempo en fswp-developer/references/official-docs.md antes de asesorar. Nada de esto envía nada: el usuario archiva los tickets y abre los pull requests por sí mismo (la automatización de GitHub está reservada; ver fswp-developer/references/github-foundation.md).
Enrutar el cambio primero
| El cambio está en... | Va a |
|---|---|
| Una vulnerabilidad | El proceso de seguridad privado enlazado desde el manual del núcleo. Nunca un ticket público o PR. Detente y díselo. |
| PHP, pantallas de administración, APIs, tests, la mayoría del código del núcleo | Ticket en Trac más parche o pull request contra WordPress/wordpress-develop (esta skill) |
| El editor de bloques (paquetes de Gutenberg, UI del editor, Editor del Sitio) | Issues y pull requests en WordPress/gutenberg; el núcleo recibe actualizaciones desde allí. Lee la guía de contribución de ese repositorio. |
| Un error de plugin o tema | No es el núcleo; usa fswp-maintainer e informa a ese proyecto |
| Documentación | El proceso del equipo de documentación del manual relevante |
Ticket primero
- Busca en Trac (https://core.trac.wordpress.org/) el síntoma. Lee el historial del ticket y cualquier parche.
- Si no existe un ticket, redacta uno: título preciso, versiones de WordPress/PHP, pasos para reproducir, esperado vs real, y por qué es un defecto (un error) versus una mejora. El usuario lo archiva bajo el componente correcto.
- Nota las palabras clave del flujo de trabajo en el ticket (por ejemplo, una solicitud de pruebas unitarias) y síguelas.
Entorno
Usa el checkout de desarrollo, no un sitio normal:
- Clona
WordPress/wordpress-develop(espejo Git del repositorio canónico, que se gestiona en Subversion). - Docker y Node son necesarios para el flujo de trabajo estándar. Desde la raíz del checkout:
npm install,npm run build:dev,npm run env:start,npm run env:install. - Ejecuta las pruebas PHP con
npm run test:php. Pasa argumentos de PHPUnit después de un doble guión, por ejemplo-- --group formatting. Las pruebas etiquetadas con@ticketse ejecutan por número de ticket como un grupo. Multisitio tiene su propia configuración (-c tests/phpunit/multisite.xml); las pruebas AJAX se ejecutan con--group ajax. - Existen flujos de trabajo sin Docker (Composer, PHPUnit PHAR); consulta la página de PHPUnit en el manual.
Escribir el cambio
- Crea una rama desde trunk; nombra la rama con el número de ticket (por ejemplo
12345-short-description). Mantén el cambio enfocado en un solo ticket. - Estándares de codificación: Estándares de WordPress para PHP, JS, CSS y HTML, incluyendo condiciones Yoda, tabulaciones, espaciado y reglas de escapado/sanitizado. Ejecuta PHPCS en los archivos modificados.
- Documentación inline: PHPDoc para funciones, hooks y clases nuevas o modificadas, en el estilo del núcleo, con
@sinceestablecido a la versión que nombra el hito del ticket. - Compatibilidad hacia atrás: El núcleo casi nunca rompe el comportamiento público. Depreca (
_deprecated_function()y similares) en lugar de eliminar; mantén filtros y acciones estables; preserva las firmas de las funciones. - Pruebas: agrega o actualiza pruebas PHPUnit que fallen antes y pasen después, etiquetadas con
@ticket. A un parche de error sin prueba generalmente se le pide que agregue una. - Seguridad y rendimiento: las mismas reglas que cualquier código de WordPress (
fswp-security-engineer,fswp-performance-engineer), con un estándar más alto. - No incluyas formateo o refactorización no relacionada.
Envío (realizado por el usuario)
- Adjunta un archivo
.diffal ticket de Trac nombrado según el número de ticket, o abre un pull request contraWordPress/wordpress-developque haga referencia al ticket. Los pull requests se usan para revisión; no se fusionan en GitHub, porque los committers confirman a través del repositorio canónico. - Publica un comentario en el ticket: qué hace el parche, cómo lo probaste, pasos que un evaluador puede seguir y cualquier pregunta abierta. Redáctalo para el usuario usando
references/ticket-comment-template.md. - Espera revisión, solicitudes de cambios y un ciclo lento. Responde en el ticket, actualiza el parche y mantenlo rebasado en trunk.
Verificar antes de entregar
Ejecuta fswp-qa-engineer con la lista de verificación del núcleo: la reproducción falla antes y pasa después, el grupo de pruebas relevante pasa, los estándares de codificación están limpios en las líneas modificadas, la documentación está presente y la compatibilidad hacia atrás está intacta.