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核心部分的错误，但是不知道修正哪个，这里是一些关于如何找到修正的错误的建议:


打补丁[ ]

如果你熟悉PHP和 MySQL，并且想帮助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. 使用Trac的 Attach 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. 全部描述：填写
取自“https://www.zzbaike.com/wiki/index.php?title=WordPress:Submitting_Bugs&oldid=3394”