个人工具
名字空间
变换
操作

WordPress:Submitting Bugs

来自站长百科
跳转到: 导航, 搜索

导航: 上一级 | WordPress | 首页 | WordPress中文论坛 | WordPress主机 | CMS程序 | 论坛程序 | ECShop | ShopNC | PowerEasy

每种软件都有错误 – 只要是人写代码,软件中就会有错误,有些错误是微不足道的,但是有些是非常严重的。开源项目如 WordPress 需要使用者的参与来找出软件中的错误,同样也包括新功能的开发。 所有类型的反馈— 不管是真正的错误还是有用的请求— 都在WordPress 中用同样的方法提交。阅读WordPress关于如何提交错误和问题的信息... 你可能会想要阅读为WordPress做贡献来找出如何为文档资料和WordPress其他方面做贡献。

目录

提交安全问题

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

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

提交插件和主题中的错误

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

WordPress插件库中的插件有一个来自 WordPress 核心的单独的错误跟踪系统。有一个如何使用这个系统的 单独的说明

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


错误提交和解决总览

提交和解决WordPress错误的过程有几步,这里是一个总的概括,下面可以找到更多细节。

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

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

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

报告错误之前

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

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

提交错误

Trac是官方WordPress错误跟踪器的名字。它使用开发源码跟踪软件Trac,它是 Edgewall Software的产品。安装下面的步骤在Trac建立一个好的错误报告:

  1. 阅读 [[WordPress:#Before You Report a Bug|提交错误之前(上面)]], 然后验证你有一个新的可以提交的错误。
  2. 阅读如何有效的提交错误这个文章,和Trac Ticket 文档.
  3. 使用你的 using your 支持论坛的用户名和密码登陆WordPress Trac。如果你没有帐户, 注册 一个这样才可以登陆Trac。这队伍你错误的交流是必需的。因为开发人员可能需要更多的信息(而你不能创建ticket 如果不登陆的话).
在新的ticket页面上填写如下信息:
  1. 简单摘要
    让摘要简短但是要包含信息并且准确,因为这是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信息的目的。
  2. 点击 提交Ticket (预览之后). 然后返回。

找到错误修正

如果你想修正WordPress核心部分的错误,但是不知道修正哪个,这里是一些关于如何找到修正的错误的建议:


打补丁

如果你熟悉PHPMySQL,并且想帮助WordPress发展,那么我们鼓励你为WordPress 的错误打上补丁。如下是打补丁的步骤:

  1. 阅读 找到错误修正(上面), 然后在Trac中找到错误并修正
  2. 使用你注册的用户名和密码连接到WordPress Subversion (SVN) Repository,阅读 使用子版本,如果你对SVN不熟悉的话。所有的补丁都会被提交的SVN,而不考虑最新的代码。
  3. 找出如何通过修改WordPress核心文件修正错误。你可能想在结束之前在wp-hackers 邮件列表上讨论你的解决方案。
  4. 测试你的修改,验证错误已经被修正,而且在此过程中没有其他的WordPress内的东西被破坏。
  5. 创建一个包含你的修改的补丁文件。这完全与修正文件和SVN中的源文件不同。参见如何为WordPress打补丁 by Owen Winkler获得详细说明。有Linux/Mac 的说明,Mark Jaquith 的工具书中的命令行使用者,和Westi的Blog中Windows Tortoise SVN 的使用者.
  6. 使用TracAttach file 按钮上传到ticket,添加 has-patch到关键词中。如果补丁需要测试,你可以把needs-testing也添加上,或者其他的Trac 关键词; 参见 Trac 关键词 (下面) 获得更多信息。

Trac 关键词

有很多有固定意思的关键词经常在Trac中使用; 一些可以通过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做出的贡献!
  1. 点击Trac中 New Ticket 打开错误提交页面。
  2. 在ticket页面的如下区域填写:
  3. 简短概要:使概要简短的但是很具有信息化和准确性,象这个是在搜索结果中将被展示的ticket标题
  4. 全部描述:填写

留言