O que Contribuidor Principal do FSWP faz?
Fundamental (sempre aplicado): fswp-developer/references/lean-coding.md (escreva menos, reutilize primeiro), fswp-developer/references/coding-standards.md (padrões de codificação, docs, i18n, acessibilidade) e fswp-security-engineer (entrada, saída, autorização).
Os fatos do fluxo de trabalho aqui foram verificados em relação ao Manual do Contribuidor Principal em 2026-09-28. Os processos do Core mudam; confirme qualquer coisa sensível ao tempo em fswp-developer/references/official-docs.md antes de aconselhar. Nada aqui envia nada: o usuário arquiva tickets e abre pull requests por conta própria (a automação do GitHub é reservada, veja fswp-developer/references/github-foundation.md).
Roteie a mudança primeiro
| A mudança está em... | Vai para |
|---|---|
| Uma vulnerabilidade | O processo de segurança privado vinculado no manual do Core. Nunca um ticket público ou PR. Pare e diga isso. |
| PHP, telas administrativas, APIs, testes, a maioria do código do Core | Ticket no Trac mais patch ou pull request contra WordPress/wordpress-develop (esta skill) |
| O bloco-editor (pacotes Gutenberg, interface do editor, Editor do Site) | Issues e pull requests em WordPress/gutenberg; o Core recebe atualizações de lá. Leia o guia de contribuição desse repositório. |
| Um bug de plugin ou tema | Não é Core; use fswp-maintainer e relate para aquele projeto |
| Documentação | O processo da equipe de docs do manual relevante |
Ticket primeiro
- Pesquise no Trac (https://core.trac.wordpress.org/) pelo sintoma. Leia o histórico do ticket e quaisquer patches.
- Se não existir ticket, elabore um: título preciso, versões do WordPress/PHP, passos para reproduzir, esperado vs real, e por que é um defeito (um bug) versus uma melhoria. O usuário o arquiva no componente correto.
- Observe palavras-chave de fluxo de trabalho no ticket (por exemplo, uma solicitação de testes unitários) e siga-as.
Ambiente
Use o checkout de desenvolvimento, não um site normal:
- Clone
WordPress/wordpress-develop(espelho Git do repositório canônico, que é gerenciado em Subversion). - Docker e Node são necessários para o fluxo de trabalho padrão. A partir da raiz do checkout:
npm install,npm run build:dev,npm run env:start,npm run env:install. - Execute os testes PHP com
npm run test:php. Passe argumentos do PHPUnit após travessão duplo, por exemplo-- --group formatting. Testes marcados com@ticketsão executados por número do ticket como um grupo. Multisite tem sua própria configuração (-c tests/phpunit/multisite.xml); testes AJAX executam com--group ajax. - Fluxos de trabalho sem Docker (Composer, PHAR do PHPUnit) existem; veja a página do PHPUnit no manual.
Escrevendo a mudança
- Crie um branch a partir do trunk; nomeie o branch com o número do ticket (por exemplo
12345-short-description). Mantenha a mudança focada em um ticket. - Padrões de codificação: Padrões WordPress PHP, JS, CSS e HTML, incluindo condições Yoda, tabs, espaçamento e regras de escape/sanitização. Execute o PHPCS nos arquivos alterados.
- Documentação inline: PHPDoc para funções, hooks e classes novos ou alterados no estilo do Core, com
@sincedefinido para a versão que o marco do ticket nomeia. - Compatibilidade retroativa: O Core quase nunca quebra comportamento público. Deprecie (
_deprecated_function()e similares) em vez de remover; mantenha filtros e actions estáveis; preserve assinaturas de funções. - Testes: adicione ou atualize testes PHPUnit que falham antes e passam depois, marcados com
@ticket. Um patch de bug sem teste geralmente é solicitado a adicionar um. - Segurança e desempenho: mesmas regras de qualquer código WordPress (
fswp-security-engineer,fswp-performance-engineer), com um padrão mais elevado. - Não inclua formatação ou refatoração não relacionada.
Submissão (feita pelo usuário)
- Anexe um arquivo
.diffao ticket do Trac nomeado com o número do ticket, ou abra um pull request contraWordPress/wordpress-developque referencie o ticket. Pull requests são usados para revisão; eles não são mesclados no GitHub, porque os committers fazem commit através do repositório canônico. - Poste um comentário no ticket: o que o patch faz, como você testou, passos que um testador pode seguir e quaisquer perguntas em aberto. Elabore-o para o usuário usando
references/ticket-comment-template.md. - Espere revisão, solicitações de alterações e um ciclo lento. Responda no ticket, atualize o patch e mantenha-o rebaseado no trunk.
Verifique antes de entregar
Execute fswp-qa-engineer com o checklist do Core: a reprodução falha antes e passa depois, o grupo de teste relevante passa, os padrões de codificação estão limpos nas linhas alteradas, a documentação está presente e a BC está intacta.