提交WordPress核心文件中的BUG
每个程序都会有BUG——人为编写的软件难免会存在各种各样的错误。有些错误很小，有些却可能很严重。WordPress之类的开源平台在查找软件BUG、开发新功能时，都需要用户共同参与。
WordPress中所有用户反馈——无论是报告发现BUG还是提出开发新功能——其提交方式都是相同的。下面就为大家介绍如何在WordPress中提交BUG。
安全漏洞
WordPress开发人员致力于为用户打造安全放心的运行环境，但这并不表示WordPress中没有安全隐患。如果用户自认在WordPress公开发布版本中发现安全漏洞，请以电子邮件的方式通知security@WordPress.org，WordPress会尽最大努力及时修复漏洞。
按照规定，用户将所发现的安全漏洞通知软件供应商（此处即WordPress开发人员）后才能向其他人公开这一漏洞，以便供应商及时作出补救措施，将损失减少到最低限度。
插件和主题中的BUG
如果用户在使用过程中发现插件或主题中的BUG，请不要按照本文中的程度提交BUG！文中的提交说明只适用于WordPress核心文件中的BUG，请不要根据这些说明来提交插件和主题中的BUG。
WordPress插件目录中每个插件都有独立的BUG跟踪系统，使用跟踪系统时也配有相应的操作说明。
如果用户发现某个插件或主题的BUG，而该插件或主题不在WordPress官方目录上，用户可以在该插件或主题的安装文件下查找该如何报告BUG。如果找不到相关信息，请直接和该插件/主题开发者联系。
提交BUG与BUG解决方案概述
在WordPress中提交并解决一个BUG步骤如下：
1. 用户在WordPress核心文件中发现BUG（插件和主题BUG不包括在内）
2. 用户尽量确保所发现的的确是BUG（详细信息见下文）。
3. 如果用户认为自己发现的的确是BUG，可以将BUG提交到Trac，Trac是WordPress的BUG跟踪系统，而Trac中的BUG报告被称为ticket（详细信息见下文）。
4. WordPress开发人员（也可能是志愿开发人员）确认这是一个需要修复的BUG后，会在ticket中做相应记号（详细信息见下文）。
5. WordPress开发人员（也可能是志愿开发人员）修复BUG。开发人员首先点击ticket下方的Accept ticket选项，表示自己将负责修复该BUG（该操作可以省略）。然后开发人员考虑该如何修复BUG，创建补丁文件，上传到Trac中（详细信息见下文）。希望成为志愿开发人员但又不知道如何修复BUG的用户也可以参照本文稍后的介绍。
6. WordPress开发团队的成员（包括志愿开发人员）测试补丁文件，检查BUG是否确实被修复，是否影响到其它功能。开发团队成员在ticket上添加注释和关键字，表明测试结果（详细信息见下文）。
7. 具有WordPress官方源代码修改权限的WordPress开发者（Matt Mullenweg, Ryan Boren, Mark Jaquith 以及 Peter Westwood）之一将补丁文件提交到SVN资料库的核心代码中，如果他们信任的开发人员验证了BUG和补丁文件的可靠性，这些WordPress开发者（Matt Mullenweg, Ryan Boren, Mark Jaquith 或者Peter Westwood）会更乐意提交补丁文件。
8. 最后，创建补丁文件的开发人员将BUG ticket状态和解决状态分别标记为closed和fixed（详细信息参见下文）。
提交BUG与BUG解决方案具体步骤
报告BUG前
WordPress拥有众多用户，大家都可能报告自己发现的BUG，因此你报告的BUG别人可能已经报告过。为了避免这一情况发生，一定要在报告BUG前确保系统中没有人报告这个BUG。如果是第一次在WordPress中报告BUG，请先与经验丰富的开发人员进行沟通，参考以下步骤：
1. 通过Trac中的搜索或查询功能，查找自己发现的BUG是否已经被报告。
- 如果已经有其他用户报告该BUG，那么你没有必要再报告同样的BUG。如果你有关于该BUG的其它信息要说明，请登录WordPress然后添加对该BUG的说明。
- 如果你发现的BUG和某个已经提交的BUG类似但不完全相同，可以考虑为原有BUG添加说明，也可以考虑重新提交一个BUG。这时很难断定是否需要重新提交BUG，但总的来说如果你需要说明已有BUG的更多信息，可以直接添加说明；如果发现的问题和已有问题并不相似，或者开发人员已经解决的问题又重新出现，可以提交新BUG。
- 如果近期已经有人报告了用户自己发现的BUG，而且该BUG已经被标记为closed，但你对该解决方案不满意，可以打开ticket，在下面说明原因。
2. 用户将BUG提交到Trac前，可以先在WordPress Support Forum和论坛会员进行交流（例如你发现的BUG是否的确是WordPress核心文件中的BUG而不是插件或主题BUG），也可以在 #wordpress IRC channel上进行交流，或者发送电子邮件到Testers以及Hackers邮件列表。
报告BUG
Trac是WordPress官方BUG跟踪系统的名称，使用开源BUG跟踪软件Trac进行BUG追踪。该软件是 Edgewall Software的产品。下面是在Trac上报告BUG的具体步骤：
1. 阅读上文中的“报告BUG前”，确定这是一个需要提交的新BUG。
2. 阅读How to Report Bugs Effectively以及 Trac Ticket documentation
3. 用support forum（支持论坛）的用户名和密码登陆WordPress Trac。没有支持论坛账号的用户需要注册一个以进入Trac，不登录Trac便无法提交BUG。
4. 在Trac上点击New Ticket 进入BUG提交界面
5. 在提交界面中填写以下内容：
Short Summary（简要描述）
对BUG情况做个实际且准确的简单描述，这个描述将作为ticket标题在搜索结果中显示
Full Description（详细描述）
详细描述你发现的BUG或者你希望WordPress具备的新功能。描述时请说明BUG的相关情况，例如BUG相关实例的链接、用户的操作系统、web服务器软件、PHP版本、MySQL版本、WordPress版本等信息。描述越详细，BUG得到恰当修复的可能性就越大。
Ticket Properties（Ticket属性）
Priority（优先级）
用户需要决定所提交BUG的优先级，也就是BUG的紧急程度。一般情况下如果BUG不是特别关键，优先级可以设为Trac中的默认值，之后开发人员会决定不同BUG之间的优先级。
Component（BUG所处位置）
用户在WordPress的哪一区域发现BUG
Severity （严重性）
BUG（或者用户要求的功能）的重要性。如果不确定，severity选项将默认为Normal。
Assign to （指定某个开发人员修复BUG）
如果用户知道该由哪位开发人员来负责该BUG区域的代码，可以在这里填上他们的Trac用户名。用户也可以填上自己的用户名，表示自己将负责修复该BUG。本项选填，填写后可以加速开发人员修复BUG的速度。
Milestone （应修复版本）
应该在哪些WordPress版本中修复该BUG（开发人员填写项目，用户无须填写）。
Version （版本）
用户发现BUG时所运行的WordPress版本信息。可以在管理栏的页脚部分查看WordPress版本号。
Keywords （关键字）
关键字可以帮助开发人员更好地查找BUG并标注BUG影响区域。本文稍后会介绍一些编辑BUG状态的标准关键字。
CC （抄送）
BUG更新信息的接收者。如果用户希望了解某个BUG的更新信息，请在这里填上自己的Trac用户名。之后一旦该BUG报告有任何变化，Trac系统就会以电子邮件的方式通知用户。请不要忽略这些电子邮件，开发人员有可能需要用户提供进一步信息，而用户填写的Trac用户名则是开发人员与用户唯一的联系方式。注意：请在Trac的Settings页面设置自己的电子邮件地址。支持论坛里的电子邮件无法自动接收Trac中的CC信息。注意：BUG更新信息会自动发送给BUG提交者（如果BUG提交者填写了自己的电子邮件地址），因此BUG提交者本人无需填写此项。
6. 预览报告后点击"Submit Ticket"，完成！
查找需要修复的BUG
如果用户希望帮助修复WordPress核心文件中的BUG但又不知该从哪个BUG入手，下面有一些小建议：
- 在 Needs Patch Report on Trac （其中的BUGs尚未标注“has_path”关键字）、 Lacks Attachment Report on Trac （其中的BUGs没有附带补丁文件）以及其它Trac reports中查找有意思的BUGs。
- 发送电子邮件到wp-hackers邮件列表，询问对方是否需要帮助
- #wordpress-dev IRC channel 中可能也需要BUG修复
- #wordpress-bugs可能有BUG日，请在WordPress Bug Hunts 中阅读BUG日的相关信息，订阅 wp-hackers 或 wp-testers 邮件列表，其中会有BUG日的举办时间。
- 用户可以考虑加入wp-trac email list，参加关于Trac Ticket的讨论。
修复BUG
熟悉 PHP 以及 MySQL操作的用户并且希望为WordPress贡献自己力量的用户可以帮助修复WordPressBUG，给BUG制作补丁文件，步骤如下：
1. 阅读上文中的“查找需要修复的BUG”，在Trac中找到自己希望修复的BUG
2. 不熟悉SVN（版本管理器）的用户可以用注册时的用户名和密码进入WordPress Subversion (SVN) Repository （WordPress版本管理库），阅读Using Subversion这一部分内容。根据SVN库中的最新代码提交补丁文件。
3. 了解如何通过更改WordPress核心文件来修复BUG。在最终提交补丁文件前，用户可以在wp-hackers邮件列表上与邮件列表成员讨论自己的解决方法。
4. 测试修复结果，确保BUG已经被修复且没有对WordPress其他部分产生不良影响。
5. 创建补丁文件，文件中须包含BUG修复方法。补丁文件是对SVN中的原始代码与修复文件的比较文件。
6. 通过Trac的Attach file（附件）选项将补丁文件上传到该BUG的ticket中，在ticket的关键字中加上has-patch。如果补丁文件需要测试，也可以在关键字中加上needs-testing。
Trac关键字
Trac中有若干具有固定含义的常用关键字；Trac Reports也可能使用这些关键字。
reporter-feedback
需要BUG报告者对此作出反应。如果BUG报告者（或遭遇过该BUG问题的用户）不做出响应，开发人员无法对BUG进行进一步研究。
has-patch
该ticket的解决方法已经被上传，其他用户可以进行评论
needs-testing
需要有人来测试该ticket的解决方法。
2nd-opinion
征求其他用户对该问题/解决方法的意见
dev-feedback
希望获得开发人员的意见（该关键字不常用）
tested
补丁文件已经经过测试，添加tested关键字时请注明所测试的补丁文件名、测试方法以及测试时使用的WordPress版本（如果不是WordPress正式发布版本，请注明SVN版本号）
commit
补丁文件由值得信赖的开发团队成员审查和测试，补丁随时可以提交到WordPress核心文件中
needs-patch
审查结果决定修复该ticket，于是ticket需要有人为它创建补丁文件，或者所提交的补丁文件无法运行，需要重新创建补丁文件
needs-unit-tests
审查结果决定修复该ticket，但由于可能造成其他不良影响，需要在提交修复方案前编写进行一些单元测试来测试相关功能和补丁文件。
needs-doc
ticket需要代码内置文档。单个文件的位置标志符ticket、申请新功能的带有补丁文件的ticket在提交前，都需要制作文档。
BUG解决方案
Trac中的ticket诞生于open状态，结束于closed状态。ticket关闭后，其状态描述包括以下几种：
- 如果用户提交的BUG之前已经有其他用户报告过，该BUG会被关闭，关闭状态为duplicate（重复）
- 如果用户提交的BUG已经在最新的SVN代码中修复（不是每个用户运行的都是最新的SVN代码；本地测试博客会运行最新SVN代码），该BUG会被关闭，关闭状态为fixed（已修复）
- 如果开发人员认为用户所提交的BUG实际上并不是BUG，而是用户的恶意扰乱行为，该BUG会被关闭，关闭状态为invalid（无效/无适当根据）
- 如果除BUG提交者本人外，没有其它用户遭遇过该BUG，该BUG会被关闭，关闭状态为worksforme（无法重现）
- 如果用户提交的BUG是增加新功能的要求，而开发人员认为该功能不适合出现在WordPress核心文件中，该BUG会被关闭，关闭状态为wontfix（不必修复）
提交BUG前请确定BUG不属于以上任何一种情况。
附注
- 开发人员在修复用户提交的BUG时，可能需要用户参与。用户应随时做好帮助开发人员的准备。
- 如果提交的BUG被标记为“不是BUG”或“不必修复”，不要担心。这些标记只是表明该BUG“目前不需要修复”，说不定不久后就成为需要优先解决的问题了。
- 感谢大家对WordPress的支持。
分类：中文手册