Languages: English • 日本語 Português do Brasil • (Add your language)

Artigo ou Seção com explicações avançadas A seguir, estão explicações ou instruções para usuários avançados, o que pode exigir o conhecimento de termos e ferramentas não comuns a todas as pessoas. Adicione {{Avançado}} para usar esta caixa.

Todo aplicativo tem bugs - desde que os seres humanos escrevem o código, sempre continuará a haver erros em softwares. Alguns erros são triviais, enquanto outros são críticos. Projetos Código aberto como o WordPress necessitam da participação de suas comunidades de usuários para identificar erros no software, bem como para planejar novas funcionalidades.

Todos os tipos de feedback - sejam bugs genuínos ou pedidos de funcionalidades - são relatados da mesma forma no projeto WordPress. Leia para aprender como reportar bugs e problemas para a equipe do WordPress. você também pode querer ler Contributing to WordPress (em inglês) para saber como contribuir para as áreas de documentação e outros do projetos WordPress.

Relatar Problemas de Segurança

Enquanto tentamos ser pró-ativos na prevenção de problemas de segurança, não assumimos que conseguimos resolver tudo. Se você acredita ter encontrado um problema de segurança em uma versão do WordPress, por favor, veja o FAQ Segurança para obter informações sobre como reportar o problema.

É uma prática padrão notificar o comerciante (neste caso os desenvolvedores do WordPress) sobre problemas de segurança ANTES de qualquer divulgação, para que assim se possa jpa ter a solução disponível e evitar danos e prejuízos aos usuários.

Relatando Bugs em Plugins e Temas

Se você encontrar um bug em um plugin ou tema que está usando no WordPress, NÃO relate usando os procedimentos neste artigo! Instruções contidas neste artigo aplicam-se apenas a erros no núcleo do WordPress e não se aplicam a erros em plugins e temas.

Plugins que residem no WordPress Plugin Repository tem um sistema de rastreio de bug separado do núcleo do WordPress. instructions separadas (em inglês) estão disponíveis para utilizar esse sistema.

Para plugins que não residem no repositório oficial assim como temas, consulte a documentação que veio com o plugin ou tema para obter instruções sobre onde denunciar erros. Se nenhuma informações de comunicação são fornecidas com o seu tema ou plugin, você vai precisar manter contato com o autor diretamente.

Resumo dos Relatórios de Bugs e Resolução

Há várias etapas no processo de comunicação e resolução de um bug do WordPress. Aqui está uma visão geral, mais detalhes estão nas seções abaixo.

1. Um usuário encontra um erro que parece estar no núcleo do WordPress (e não em um tema ou plugin).
2. O usuário tenta se certificar de que é realmente um bug. Veja Antes de relatar um erro.
3. Se for determinado que se trata de um bug, o usuário envia o relatório de erros, chamado de ticket para Trac, que é o Sistema de Rastreio de Bugs do WordPress. Veja como reportar um erro.
4. Um desenvolvedor do WordPress (que pode ser um voluntário como você) confirma que o bug realmente existe e que deve ser corrigido então marca o ticket como tal . Veja a lista de palavras-chave.
5. Um desenvolvedor do WordPress (que pode ser você) decide consertar o bug. O desenvolvedor pode optar por assumir a responsabilidade pelo erro, clicando em Accept ticket na parte de baixo da tela, embora isso não seja necessário. Em seguida, o desenvolvedor descobre como corrigir o bug, cria um ou mais arquivos de patch e os transfere para o Trac. Veja Corrigindo Bugs. Além disso, se você quiser ajudar com a correção de erros, mas não sabe onde começar , veja Encontrando Bugs para Corrigir.
6. Membros do grupo de desenvolvimento do WordPress (incluindo voluntários) testam o patch, para ver se ele corrige o bug e não prejudica nada em outros códigos. Eles adicionam comentários e palavras-chave para o ticket para indicar os seus resultados. Veja a lista de palavras-chave.
7. Um dos desenvolvedores do WordPress, com autoridade para modificar o código fonte oficial do WordPress (Matt Mullenweg, Ryan Boren, Mark Jaquith ou Peter Westwood) commit o patch para o código do núcleo no repositório SVN. Eles são mais propensos a fazê-lo se o bug e patch foram verificados por alguém de confiança.
8. Por fim, a pessoa que comete o patch define o status do ticket do bug para fechado e a resolução para closed . Veja Corrigindo Bugs

Detalhes de Relatório de Bug e Resolução

As seções abaixo adicionam detalhes de alguns dos passos descritos acima.

Antes de Relatar um Bug

Em grandes projetos como o WordPress, muitos usuários reportam bugs então há uma boa chance do bug que quer relatar já ter sido relatado. Devido a isso, é muito importante verificar se o relato já não está no sistema. Se você novato em reportar bugs no WordPress, também é uma boa idéia discturi o assunto com desenvolvedores mais experientes antes de reportá-lo. Por favor, siga os passos abaixo.

1. Antes de tudo, procure pelo erro ou pedido de recurso no Trac, usando a Pesquisa ou a Consulta.
   • Se o seu problema já foi relatado, por favor não relate novamente. Se você tiver mais informações para contribuir, faça login e adicione uma nota ao bug existente!
   • Se o seu problema é semelhante, mas não completamente o mesmo que outro problema, você pode decidir se deseja adicionar uma nota ao problema semelhante, ou um novo relatório. Pode ser difícil decidir se a questão merece uma nova apresentação, mas em geral se você tem mais informação que contribuem para um problema atual, basta adicionar uma nota a essa questão. Se você tem um problema diferente o suficiente, ou se você está enfrentando uma recorrência de um problema que foi resolvido anteriormente, relate um bug novo.
   • Se o seu problema foi relatado recentemente,em seguida fechado, e você não concorda com a resolução, você também pode reabrir o ticket e adicionar um comentário quanto ao seu raciocínio.
   • É melhor não reabrir bugs que foram fechados por algum tempo (por exemplo, um marco relativas a uma versão mais do que uma versão antiga) - nesse caso, considere um novo bilhete.
   • Por favor não altere o número de versão sobre bugs que já foram relatados. O número da versão diz respeito à versão em que o erro foi descoberto. Se você está vendo o mesmo erro em uma versão mais recente, destaque em um comentário.
2. Para discutir um bug antes de reportá-lo no Trac (por exemplo, para descobrir se é realmente uma falha no núcleo do WordPress e não em no plugin ou tema), você pode postar uma pergunta no Forum de Suporte Brasileiro WordPress

Relatando um Erro

Trac é o nome do rastreador de bugs oficial do WordPress. Ele usa o software código aberto de monitoramento Trac, que é um produto da Edgewall Software. Siga estes passos para criar um bom relatório de bugs no Trac:

1. Leia Antes de relatar um Bug(acima) e verifique se você tem um novo bug apropriado para relatório.
2. Leia este artigo em How to Report Bugs Effectively (em inglês) e aDocumentação do Trac Ticket(em inglês).
3. Entrar no sistema em WordPress Trac com o nome de usuário e senha do Forum de Suporte. Se você não tiver uma conta nos fóruns de suporte, inscrever-se de modo que você possa fazer o login para Trac. Isto é essencial para a comunicação sobre o seu erro, já que os desenvolvedores podem precisar de mais informações (e você não pode criar um bilhete, sem registro).
4. Clique em New Ticket no Trac para ir até à página de relatórios de bugs.
5. Preencha os seguintes campos na página de novo bilhete:

   Breve Resumo

   Um resumo curto, mas informativo e preciso, pois este é o título que será exibido nos resultados de busca.

   Descrição Completa

   Preencha uma descrição completa do seu erro ou solicitação de recurso. Incluia uma descrição do problema e como alguém pode reproduzir o problema, talvez um exemplo do bug em ação (ou seja, uma URL), e uma descrição de por que é um problema digno de ser corrigido. Também incluia informações sobre sua plataforma, como o sistema operacional, software de servidor web, a versão PHP, MySQL versão e a versão do WordPress. A melhor descrição, aumenta as chances de ter o bug resolvido prontamente.

   Propriedades de Ticket

   Priority

   Este é o quanto urgente é o bug. O núcleo de desenvolvedores geralmente procuram por prioridade do bug, por isso esta opção pode ser somente leitura.

   Component

   Selecione o componente do WordPress, onde o erro foi encontrado

   Gravity

   A significância da questão. Selecione uma severidade crítica com base em como você considera a questão de ser. Em caso de dúvida, deixe esta opção como normal.

   Assign to

   Se você sabe quem é o desenvolvedor responsável pelo código onde o erro está, coloque seu nome de usuário aqui. Você também pode assumir a responsabilidade por um bug, colocando seu próprio nome de usuário Trac. Isto é opcional e poderá acelerar a atenção do desenvolvedor ao erro.

   Milestone

   Em qual versão esta questão deve ser resolvida, o mais tardar. Os desenvolvedores geralmente definir isso, então esta opção pode ser somente leitura.

   Version

   A versão do WordPress, onde o erro foi encontrado. Você pode encontrar o número da versão do WordPress no rodapé do painel de administração. (Não mudar a versão sobre os bilhetes pré-existentes).

1. Keywords

   Há algumas palavras-chave padrão usadas para sinalizar o status do seu relato de buf (veja Trac-chave).

   , CC: Quem informações de bugs e atualizações devem ser enviadas. Se você quiser ser informado, o seu próprio nome de usuário Trac aqui. Em seguida, será notificado por e-mail a qualquer momento é feita uma alteração a este relatório, ou uma nota para o bug é adicionado. Não ignore esses e-mails; qualquer momento, uma alteração é feita, não se esqueça de verificar o relatório de atualizações. Desenvolvedores podem precisar de mais informações de você, e esta é a sua única forma de entrar em contato com você. Nota: você precisa ir para o TracConfiguraçõespágina para definir o seu endereço de e-mail. Colocá-lo em seu perfil Suporte Fórum [1] não obtê-lo no Trac para fins de mensagens CC. Nota: Se você é repórter do erro, você já recebe mensagens (se o seu e-mail é conhecido), então não há necessidade de CC.

2. Clique em Enviar Ticket (depois de visualizá-lo).

Encontrando Bugs para Corrigir

If you want to fix bugs in the core parts of WordPress, but don't know which ones to fix, here are some suggestions on how to find bugs to fix:

• Look through the Needs Patch Report on Trac (which lists bugs that have not been marked with the "has_patch" keyword), the Lacks Attachment Report on Trac (which lists bugs that do not have a patch file attached), or other Trac reports for bugs that look interesting.
• Send an email message to the wp-hackers mailing list and ask how you can help.
• There is also sometimes bug triage on the #wordpress-dev IRC channel
• Occasionally there are bug days on #wordpress-dev. You can read about what happens in a bug day in WordPress Bug Hunts, and subscribe to either the wp-hackers or wp-testers mailing list to find out when they happen.
• Consider joining the wp-trac email list to follow the discussions about each Trac Ticket.

Corrigindo Bugs

If you are familiar with PHP and MySQL, and would like to help in the development of WordPress, then you are encouraged to patch WordPress bugs. Here are the steps to follow:

1. Read Finding Bugs to Fix (above), and find a bug to fix in Trac.
2. Connect to the WordPress Subversion (SVN) Repository using the username and password you acquired when registering. Read Using Subversion if you are unfamiliar with SVN.
3. Figure out how to fix the bug, by modifying WordPress core files. You may want to discuss your proposed solution on the wp-hackers mailing list before finalizing it.
4. Test your fix, verifying that the bug has been fixed, and that nothing else in WordPress is broken in the process.
5. Create a patch file (or files) containing your fix. This is basically a diff of the fixed file(s) and the originals from SVN. See How to Patch WordPress by Owen Winkler for detailed instructions. There are also instructions for Linux/Mac command-line users in Mark Jaquith's Toolbox and Windows Tortoise SVN users in Westi's Blog.
6. Upload it to the ticket using the Trac Attach file button, and add has-patch to the keywords. If the patch needs testing, you might also put needs-testing, or one of the other Trac keywords; see Trac Keywords (below) for more information.

Guia para Criar Patchs

All patches should:

• be made against the latest code in the SVN repository.
• be made against the root WordPress directory and not against a subfolder.
• adhere to the coding standards.

Palavras-chavez no Trac

There are a number of keywords with defined meaning used in Trac that are commonly used; some are also searched for by Trac Reports. Keywords should not be thought of as generic 'tags,' which are not necessary.

reporter-feedback 

A response is needed from the reporter. Further investigation is unlikely without a response to the questions from someone experiencing the problem.

dev-feedback 

A response is wanted from a core developer or trusted members of the development community.

ux-feedback and ui-feedback 

A response is needed from the core team with regards to the desired user experience or interface.

rtl-feedback 

Feedback is needed with regards to RTL support or a patch for RTL support is needed.

2nd-opinion 

Another person is needed to express an opinion about the problem or the solution.

has-patch 

A proposed solution to the ticket has been attached, and it is ready for review.

needs-patch 

The ticket has been reviewed, found to be desirable to solve, and marked as especially needing a patch, or the submitted patch doesn't work and needs to be redone.

needs-refresh 

A submitted patch no longer applies cleanly to the WordPress core files, usually because nearby code has been modified since the patch was submitted. The patch needs to be merged and re-submitted.

needs-testing 

One or more people are needed to test the solution. When testing a patch, please comment with the patch filename that was tested, how the patch was tested, and which version of WordPress was used (including the SVN revision number, if it is not an officially released version).

needs-unit-tests 

The ticket has been reviewed, found to be desirable to solve and we would like some unit tests written to test the functionality and any patch that may exist before committing a change as the risk of causing other issues is high.

needs-docs 

Inline documentation for the code is needed. These are either place holder tickets for individual files or tickets with patches for new functions which need documenting before they are committed. A ticket created specifically for inline documentation should be added to the Inline Docs component instead.

needs-codex 

Documentation in codex needs updating or expanding. Remove the keyword from the ticket once the codex is updated.

commit 

The patch has been reviewed and tested by a trusted member of the development community; therefore the patch should be considered a commit candidate and is ready to be added to the WordPress core files.

early 

This keyword should only be applied by committers. The keyword signals that the ticket is a priority and should be handled early in the next release cycle.

i18n-change 

Only used late in the development cycle (after string freeze) to track potential string changes, as translators need to be notified.

close 

The ticket is a candidate for closure with a disposition other than fixed (i.e. wontfix, worksforme, invalid, or duplicate). Often seen with reporter-feedback or 2nd-opinion, otherwise the ticket would have been closed in lieu of the close keyword.

Corrigindo Bugs

A ticket in Trac starts its life in the open status, and (hopefully) is eventually closed. When a ticket is closed, it is marked with one of the following status designations:

• If your bug has been reported elsewhere, it will likely be closed with duplicate. If the bug has already been fixed in the latest subversion code (which is probably not what you're running unless you have a local test blog), it will likely be closed as a duplicate of the orignial ticket.
• If it is decided that your bug isn't in fact a bug, but is the intended behaviour, it will be closed with invalid.
• If no one else can replicate the symptoms you describe, it will be closed with worksforme.
• If your bug is a feature request that the developers don't want in the core, it will be marked as wontfix.

Please verify that your bug doesn't fall into one of these categories before submission.

If the bug is fixed in the core subversion repository by a core committer, then it will be closed with fixed.

Notas

• The processing of your bug may require your participation. Please be willing and prepared to aid the developers in resolving the issue.
• Don't be upset if your bug gets resolved as "Not a bug" or "Won't fix". What seems like a bug to you may very well be a "feature". These resolutions just mean "not going to fix now", maybe in the future it will be a priority to solve.
• Thank you for contributing to the development of WordPress!

"Níveis" de Desenvolvedores

• lead developer: one of the commiters that have the final word on important technical decisions. See Development Team.
• core commiter: a developer that has permanent commit access
• guest commiter: a developer granted commit access temporarily, usually for a specific feature
• core contributor: a person actively involved in Core development, but without commit access

Codex WordPress Brasil A documentação do WordPress em Português do Brasil. Todas as comunidades lusófonas também são bem-vindas! Adicione {{Codex-pt}} em seus artigos.