编辑“WordPress:Submitting Bugs”

<span style="border:1px solid #000; text-align:center; float:right; padding:6px;"><strong>导航:</strong> [[WordPress:WordPress文档|上一级]] | [[WordPress]] | {{Template:WordPress导航}}</span>
<div style="clear:both;"></div>
每种软件都有[[WordPress:Wikipedia:Computer bug|错误]] – 只要是人写代码，软件中就会有错误，有些错误是微不足道的，但是有些是非常严重的。开源项目如 [[WordPress:WordPress| WordPress]] 需要使用者的参与来找出软件中的错误，同样也包括新功能的开发。
所有类型的反馈&mdash; 不管是真正的错误还是有用的请求&mdash; 都在WordPress 中用同样的方法提交。阅读WordPress关于如何提交错误和问题的信息... 你可能会想要阅读[[WordPress:Contributing to WordPress|为WordPress做贡献]]来找出如何为文档资料和WordPress其他方面做贡献。

== 提交安全问题 ==

当我们试着防止出现安全问题时，我们不能认为它们不会出现。如果你相信你在WordPress某个版本中找到了安全问题，发邮件到<tt>WordPress.org</tt>上的<tt>security</tt> 区域，我们将尽力尽快解决。

通知卖主(这里是指WordPress开发人员)是在发布之前的安全问题的标准练习，这样可以准备好修正版本，这造成的损失可以降低到最小。

== 提交插件和主题中的错误 ==

如果你在使用时插件或者主题中发现了错误，'''不要''' 使用本文中的方法进行提交! 本文提供的方法只适用于WordPress核心文件的错误，不适合于插件和主题中的错误。

[http://dev.wp-plugins.org/ WordPress插件库]中的插件有一个来自 WordPress 核心的[http://dev.wp-plugins.org/report 单独的错误跟踪系统]。有一个如何使用这个系统的 [http://dev.wp-plugins.org/wiki/TracTickets 单独的说明]。

对于不在官方库中的插件和主题，查看其附带的文档资料作为关于如何提交错误的说明。如果没有错误提交信息，你需要直接联系作者。


==错误提交和解决总览==

提交和解决WordPress错误的过程有几步，这里是一个总的概括，下面可以找到更多细节。 
# 用户发现了错误，出现在WordPress核心文件中 (不在主题或者插件中).
# 用户尝试着确认这确实是一个错误。参见 [[#WordPress:Before You Report a Bug|提交错误之前(下面)]].
# 如果确定它是一个错误，用户提交错误报告到[http://trac.wordpress.org/ Trac]，叫做''ticket''，WordPress错误跟踪系统。参见[[#WordPress:Reporting a Bug|提交错误 (下面)]]. 
# WordPress 开发人员 (可能也是象你一样的志愿者) 确认错误的确存在，然后它应该被修正。然后象在票上做记号那样标记出来。参见[[#WordPress:Trac Keywords|Trac 关键词列表(下面)]] 和 [[#WordPress:Bug Resolutions|错误解决方案(下面)]].
# WordPress 开发人员 (可能是你)决定修复这个错误。开发者可能选择通过点击ticket底部附近的 ''Accept ticket''操作来负责这个错误，尽管这不是必须的。然后开发人员指出如何修复这个错误，创建一个或者多个补丁，上传到Trac. 参见 [[#WordPress:Patching Bugs|错误补丁(下面)]]。同样的，如果你想要帮助修复错误，但是不知道需要修复哪个错误，参见[[#WordPress:Finding Bugs to Fix|找到错误并修复 (下面)]].
# WordPress开发小组成员(包括志愿者)测试补丁，查看是否错误被修复了而没有影响到其他东西。它们添加评论和关键词到ticket，显示出它们的结果。参见 [[#WordPress:Trac Keywords|Trac 关键词列表(下面)]].
# WordPress 开发员中的一个拥有修改官方WordPress源代码权限的人(Matt Mullenweg, Ryan Boren, Mark Jaquith or Peter Westwood) ''提交'' 补丁给SVN库中的核心代码。如果错误和补丁被他们所信任的某人验证过后，他们会这样做的。
# 最后，提交补丁的这个人设定ticket状态为''closed''，结论是''fixed''。参见 [[#WordPress:Bug Resolutions|错误结论(下面)]].

==错误报告和解决方案的详细内容==

下面的部分给上述的提纲添加了详细内容。

=== 报告错误之前 ===

如WordPress这么大的项目，如此多的使用者提交错误报告，很有可能你的错误已经被提交过了，正因为这样，检查并确定系统中它还没有被提交过是很重要的。如果你刚开始在WordPress中使用提交错误，在提交之前和有经验的开发人员讨论这个问题是个好办法。请按照下面的步骤。

# 在Trac中通过使用[http://trac.wordpress.org/search 搜索]或者是[http://trac.wordpress.org/query 查询]来查找你的错误或者是功能请求。
#* 如果你的问题已经被提交过了，请不要重复提交。如果你有更深入的信息，登陆并添加信息记录到已存在的错误中。
#* 如果你的问题相似，但是不完全和另一个问题相同，你可以决定是否添加一个记录到相似问题中，或者是重新提交。很难决定是否你的问题可以作为一个新的问题提交，但是通常情况下，如果你只是有更多信息来提交的话，打开问题，简单的添加一个记录就可以了。 如果你有个完全不同的问题，或者如果你正经历了一个重复的以前解决过的问题，可以提交一个新错误。
#* 如果你的问题最近提交了也关闭了，但是你不同意这样的解决方法，你可以重新打开ticket添加注释，写明你的理由。
# 想在Trac上在提交之前讨论一个错误， (如判断它是否是一个WordPress核心的而不是插件或者主题的错误)，你可以在[http://wordpress.org/support/ WordPress 支持论坛]上发个帖子，在[[WordPress:WordPress IRC Live Help|#wordpress IRC 频道]] 讨论你的问题，或者在[[WordPress:Mailing Lists#Testers|检测器]] 或[[WordPress:Mailing Lists#hackers|Hackers]]邮件列表上参与邮件讨论。
=== 提交错误 ===

[http://trac.wordpress.org/ Trac]是官方WordPress错误跟踪器的名字。它使用开发源码跟踪软件[http://projects.edgewall.com/trac/ Trac]，它是 [http://www.edgewall.com/ Edgewall Software]的产品。安装下面的步骤在Trac建立一个好的错误报告:

# 阅读 [[WordPress:#Before You Report a Bug|提交错误之前(上面)]], 然后验证你有一个新的可以提交的错误。
# 阅读[http://www.chiark.greenend.org.uk/~sgtatham/bugs.html 如何有效的提交错误]这个文章，和[http://trac.wordpress.org/wiki/TracTickets Trac Ticket 文档].
#使用你的 using your [http://wordpress.org/support/ 支持论坛]的用户名和密码登陆[http://trac.wordpress.org/ WordPress Trac]。如果你没有帐户， [http://wordpress.org/support/register.php 注册] 一个这样才可以登陆Trac。这队伍你错误的交流是必需的。因为开发人员可能需要更多的信息(而你不能创建ticket 如果不登陆的话).
 在新的ticket页面上填写如下信息:
#; 简单摘要: 让摘要简短但是要包含信息并且准确，因为这是ticket的标题，将会显示在搜索结果中。
#; 完整的描述: 填写你的错误或者是功能要求的完整的描述。包括一个问题的描述，别人可以重复这个问题的步骤，也可以是一个错误的运转的例子 (如 URL), 或者是一个为什么问题值得更正的描述。同样包括关于你的平台的信息，如操作系统，网络服务器软件，PHP 版本, MySQL 版本, WordPress 版本。你描述的越好，解决错误的可能性就越大。
#; Ticket 属性:
#:; 优先级: 你需要确定这个问题的优先权 – 这个错误有多紧急。除非它是一个致命的错误，最好是让它保持默认状态，因为开发人员通常都是按照错误优先级的排序来的。
#:; 组件: 选择发现问题所在的WordPress组件
#:; 严重 : 这个问题的''重要性''。选择一个severity基于你认为这个问题有多严重，如果有疑问，就保持默认的''Normal''.
#:; 分配: 如果你知道有负责存在错误的代码的开发人员，把他们的Trac用户名放在这里。你也可以自己为这个错误负责，把你自己的Trac用户名放在这里就可以了。这是可以选择的，这可以让开发人员更快的注意到这个错误。
#:; 里程表: 最迟在哪个版本这个问题会被解决。不要更改它。这是WordPress 开发人员设置的。
#:; 版本: 错误发现的WordPress 版本。你可以在管理面板的页脚找到WordPress版本号。
#:; 关键词: 关键词让开发人员更容易的找到错误所在，确定它的影响范围。例如'posting'， 一个涉及到WordPress发表文章机制的错误的关键词。同样，有标准关键词用来标记你的错误的状态(参见 [[WordPress:#Trac Keywords|Trac 关键词]] 下面).
#:; CC: 错误信息和更新信息发送的对象。如果你想保持可以被通知到，把你自己的Trac名字写上。 当这个报告有任何更改的时候，你将会被邮件通知。不要忽视这些邮件; 做出任何改动后，确定查看一下报告更新。开发人员可能需要从你这里获得更多的信息，这是他们与你联系的唯一的方法。 '''注意''': 你需要进入Trac ''设置''页面来设置你的email地址。把他放到你的支持论坛个人资料里并不能让你的资料进入Trac以达到接收CC信息的目的。
# 点击 '''提交Ticket''' (预览之后). 然后返回。

=== 找到错误修正 ===

如果你想修正WordPress核心部分的错误，但是不知道修正哪个，这里是一些关于如何找到修正的错误的建议:
* 仔细阅读 [http://trac.wordpress.org/report/13 需要关于Trac的补丁报告] (列出了没有标出"has_patch"关键词的错误)， [http://trac.wordpress.org/report/18 缺乏关于Trac的附件报告] (列出了没有补丁文件的错误)，或者是其他对于看起来比较有趣的错误的 [http://trac.wordpress.org/report Trac 报告].
* 发送邮件信息到[[WordPress:Mailing_Lists#Hackers|wp-hackers 邮件列表]] 询问你能帮什么忙. 
* 有时也有一些错误帮助在 <tt>#wordpress-dev</tt> [[WordPress:IRC|IRC]] 频道。
* 偶然在<tt>#wordpress-bugs</tt>上有错误日。你可以在[[WordPress:WordPress Bug Hunts|错误搜寻]]上阅读关于什么错误日发生了什么，并且预定[[WordPress:Mailing_Lists#Hackers|wp-hackers]]或者是 [[WordPress:Mailing_Lists#Testers|wp-testers]] 邮件列表来找出它们是什么时候出现的。
* 考虑加入[http://lists.automattic.com/mailman/listinfo/wp-trac wp-trac 邮件列表] 来参与关于每个[http://trac.wordpress.org/report Trac Ticket]的讨论。


=== 打补丁 ===

如果你熟悉[[WordPress:Glossary#PHP|PHP]]和 [[WordPress:Glossary#MySQL|MySQL]]，并且想帮助WordPress发展，那么我们鼓励你为WordPress 的错误打上补丁。如下是打补丁的步骤:

#阅读 [[#WordPress:Finding Bugs to Fix|找到错误修正(上面)]], 然后在[http://trac.wordpress.org Trac]中找到错误并修正
#使用你[http://wordpress.org/support/register.php 注册]的用户名和密码连接到[http://wordpress.org/download/svn/ WordPress Subversion (SVN) Repository]，阅读 [[WordPress:Using Subversion|使用子版本]]，如果你对SVN不熟悉的话。所有的补丁都会被提交的SVN，而不考虑最新的代码。
# 找出如何通过修改WordPress核心文件修正错误。你可能想在结束之前在[[WordPress:Mailing_Lists#Hackers|wp-hackers 邮件列表]]上讨论你的解决方案。
# 测试你的修改，验证错误已经被修正，而且在此过程中没有其他的WordPress内的东西被破坏。
# 创建一个包含你的修改的''补丁文件''。这完全与修正文件和SVN中的源文件''不同''。参见[http://asymptomatic.net/2005/12/03/586/how-to-patch-wordpress 如何为WordPress打补丁 by Owen Winkler]获得详细说明。有Linux/Mac 的说明，[http://markjaquith.wordpress.com/2005/11/02/my-wordpress-toolbox/ Mark Jaquith 的工具书]中的命令行使用者，和[http://blog.ftwr.co.uk/archives/2005/11/03/windows-wordpress-toolbox/ Westi的Blog]中Windows Tortoise SVN 的使用者.
# 使用[http://trac.wordpress.org/ Trac]的 ''Attach file'' 按钮上传到ticket，添加 ''has-patch''到关键词中。如果补丁需要测试，你可以把''needs-testing''也添加上，或者其他的Trac 关键词; 参见 [[#WordPress:Trac Keywords|Trac 关键词 (下面)]] 获得更多信息。

=== Trac 关键词 ===

有很多有固定意思的关键词经常在[http://trac.wordpress.org Trac]中使用; 一些可以通过[http://trac.wordpress.org/report Trac Reports]搜索。

;reporter-feedback : 提交人的回复是必需的。深入的调查如果没有经历过问题本身的人的回复的话是靠不住的。

;has-patch : 已经附上ticket的解决方法，准备好再次检查或者是提交。

;needs-testing : 某人需要测试这个解决方案

;2nd-opinion : 需要另外一个人来传递一个关于问题或者解决方案的观点

;dev-feedback : 需要开发人员的回复 (不常用)

;tested : 补丁测试过了. 当添加这个标签时请加入测试的文件名字，补丁如何测试的，和使用了哪个WordPress版本(包括SVN版本号，如果不是官方发布的版本的话).

;commit : 补丁已经被某个开发团体中可以信任的人检查过，测试过; 这样这个补丁就已经准备添加到WordPress核心文件中了.

;needs-patch : ticket已经被检查过，发现描述为解决，但是标记为特别需要一个补丁，或者提交的补丁不能使用需要重新做

;needs-unit-tests : ticket已经通过检查，发现描述为解决，我们希望一个联合测试，来测试功能性，因为提交前各种补丁的存在造成导致其他问题的风险很高。

;needs-doc : 需要代码的内嵌文档。这可以是在它们被提交之前保存ticket单独文件或者是带有新函数补丁需要的文档资料。 

=== 错误解决方案===

Trac 中的ticket 在''open''状态下开始，最终到''closed''。当一个ticket关闭后，它会被以下某个状态之一标记:

* 如果你的错误已经提交到别的地方，它将以''duplicate''结束. 
* 如果错误在最新的版本代码中已经修正(可能不是你在运行的版本除非你有一个本地测试的blog)，标记为''fixed''.
* 如果确定你的错误事实上不是错误，而是你故意的行为，会标记为''invalid''.
* 如果没有其他人可以重现你所描述的现象，会以''worksforme''结束。
* 如果你的错误是一个功能请求，而开发人员不想让它出现在核心代码中，标记为 ''wontfix''.

请验证你的错误在提交时不属于其中任何一种。


== 注 ==

* 你的错误的处理过程可能需要你的参与，希望你自愿并准备好帮助开发人员解决问题。
* 如果你的问题被解决为"Not a bug" 或者 "Won't fix"时不要生气，看起来对你是错误的东西很可能是一种"功能". 这些解决方法只是意味这"现在不能解决", 可能将来会被解决的.
* 感谢为WordPress做出的贡献!
# 点击Trac中 '''[http://trac.wordpress.org/newticket New Ticket]''' 打开错误提交页面。
# 在ticket页面的如下区域填写：
# 简短概要：使概要简短的但是很具有信息化和准确性，象这个是在搜索结果中将被展示的ticket标题
# 全部描述：填写