久久精品水蜜桃av综合天堂,久久精品丝袜高跟鞋,精品国产肉丝袜久久,国产一区二区三区色噜噜,黑人video粗暴亚裔

WordPress: Submitting Bugs：修訂間差異

來自站長百科
跳轉(zhuǎn)至： 導航、? 搜索
（新頁面: Every application has bugs -- as long as humans write code, there will continue to be errors in software. Some errors are trivial, while others are cr...）
?
小無編輯摘要
?
（未顯示3個用戶的10個中間版本）
第1行： 第1行：
Every application has [[WordPress:Wikipedia:Computer bug|bugs]] -- as long as humans write code, there will continue to be errors in software. Some errors are trivial, while others are critical. Open-source projects like [[WordPress:WordPress]] need the participation of their user communities to identify bugs in their software, as well as to plan for new features.
<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]] 需要使用者的參與來找出軟件中的錯誤，同樣也包括新功能的開發(fā)。
所有類型的反饋&mdash; 不管是真正的錯誤還是有用的請求&mdash; 都在WordPress 中用同樣的方法提交。閱讀WordPress關于如何提交錯誤和問題的信息... 你可能會想要閱讀[[WordPress:Contributing to WordPress|為WordPress做貢獻]]來找出如何為文檔資料和WordPress其他方面做貢獻。


All types of feedback &mdash; whether they're genuine bugs or feature requests &mdash; are reported the same way in the WordPress project. Read on to learn how to report bugs and issues for WordPress... you may also want to read [[WordPress:Contributing to WordPress]] to find out how to contribute to the documentation and other areas of the WordPress project.
== 提交安全問題 ==


== Reporting security issues ==
當我們試著防止出現(xiàn)安全問題時，我們不能認為它們不會出現(xiàn)。如果你相信你在WordPress某個版本中找到了安全問題，發(fā)郵件到<tt>WordPress.org</tt>上的<tt>security</tt> 區(qū)域，我們將盡力盡快解決。


While we try to be proactive in preventing security problems, we do not assume they'll never come up. If you believe you've found a security problem in a release of WordPress please send mail to <tt>security</tt> at the <tt>WordPress.org</tt> domain and we'll do our best to address it as soon as possible.
通知賣主(這里是指WordPress開發(fā)人員)是在發(fā)布之前的安全問題的標準練習，這樣可以準備好修正版本，這造成的損失可以降低到最小。


It is standard practice to notify the vendor (the WordPress developers, in this case) of a security problem before publicizing so a fix can be prepared and public damage due to the vulnerability minimized.
== 提交插件和主題中的錯誤 ==


== Reporting Bugs in Plugins and Themes ==
如果你在使用時插件或者主題中發(fā)現(xiàn)了錯誤，'''不要''' 使用本文中的方法進行提交! 本文提供的方法只適用于WordPress核心文件的錯誤，不適合于插件和主題中的錯誤。


If you find a bug in a Plugin or Theme you are using with WordPress, do '''NOT''' report it using the procedures in this article! Instructions in this article apply only to bugs in the WordPress core, and do not apply to bugs in plugins and themes.
[http://dev.wp-plugins.org/ WordPress插件庫]中的插件有一個來自 WordPress 核心的[http://dev.wp-plugins.org/report 單獨的錯誤跟蹤系統(tǒng)]。有一個如何使用這個系統(tǒng)的 [http://dev.wp-plugins.org/wiki/TracTickets 單獨的說明]。


Plugins which reside in the [http://dev.wp-plugins.org/ WordPress Plugin Repository] have a [http://dev.wp-plugins.org/report separate bug tracking system] from the WordPress core. [http://dev.wp-plugins.org/wiki/TracTickets Separate instructions] are available for using that system.
對于不在官方庫中的插件和主題，查看其附帶的文檔資料作為關于如何提交錯誤的說明。如果沒有錯誤提交信息，你需要直接聯(lián)系作者。


For plugins which do not reside in the official repository, and for themes, check the documentation that came with the plugin or theme for instructions on where to report bugs. If no bug reporting information came with your plugin or theme, you'll need to contact the author directly.


==Overview of Bug Reporting and Resolution==
==錯誤提交和解決總覽==


There are several steps in the process of reporting and resolving a WordPress bug. Here is an overview; more details are in sections below. ?
提交和解決WordPress錯誤的過程有幾步，這里是一個總的概括，下面可以找到更多細節(jié)。
# 用戶發(fā)現(xiàn)了錯誤，出現(xiàn)在WordPress核心文件中 (不在主題或者插件中).
# 用戶嘗試著確認這確實是一個錯誤。參見 [[#WordPress:Before You Report a Bug|提交錯誤之前(下面)]].
# 如果確定它是一個錯誤，用戶提交錯誤報告到[http://trac.wordpress.org/ Trac]，叫做''ticket''，WordPress錯誤跟蹤系統(tǒng)。參見[[#WordPress:Reporting a Bug|提交錯誤 (下面)]].
# WordPress 開發(fā)人員 (可能也是象你一樣的志愿者) 確認錯誤的確存在，然后它應該被修正。然后象在票上做記號那樣標記出來。參見[[#WordPress:Trac Keywords|Trac 關鍵詞列表(下面)]] 和 [[#WordPress:Bug Resolutions|錯誤解決方案(下面)]].
# WordPress 開發(fā)人員 (可能是你)決定修復這個錯誤。開發(fā)者可能選擇通過點擊ticket底部附近的 ''Accept ticket''操作來負責這個錯誤，盡管這不是必須的。然后開發(fā)人員指出如何修復這個錯誤，創(chuàng)建一個或者多個補丁，上傳到Trac. 參見 [[#WordPress:Patching Bugs|錯誤補丁(下面)]]。同樣的，如果你想要幫助修復錯誤，但是不知道需要修復哪個錯誤，參見[[#WordPress:Finding Bugs to Fix|找到錯誤并修復 (下面)]].
# WordPress開發(fā)小組成員(包括志愿者)測試補丁，查看是否錯誤被修復了而沒有影響到其他東西。它們添加評論和關鍵詞到ticket，顯示出它們的結(jié)果。參見 [[#WordPress:Trac Keywords|Trac 關鍵詞列表(下面)]].
# WordPress 開發(fā)員中的一個擁有修改官方WordPress源代碼權(quán)限的人(Matt Mullenweg, Ryan Boren, Mark Jaquith or Peter Westwood) ''提交'' 補丁給SVN庫中的核心代碼。如果錯誤和補丁被他們所信任的某人驗證過后，他們會這樣做的。
# 最后，提交補丁的這個人設定ticket狀態(tài)為''closed''，結(jié)論是''fixed''。參見 [[#WordPress:Bug Resolutions|錯誤結(jié)論(下面)]].


# A user finds a bug that appears to be in the core of WordPress (not in a Theme or Plugin).
==錯誤報告和解決方案的詳細內(nèi)容==
# The user tries to make sure it is actually a bug.? See [[WordPress:#Before You Report a Bug|Before You Report a Bug (below)]].
# If it is determined to be a bug, the user submits the bug report, called a ''ticket'', to [http://trac.wordpress.org/ Trac], the WordPress bug tracking system.? See? [[WordPress:#Reporting a Bug|Reporting a Bug (below)]].
# A WordPress developer (who could be a volunteer like you) confirms that the bug does actually exist, and that it should be fixed, and marks it as such in the ticket. See [[WordPress:#Trac Keywords|Trac Keywords list (below)]] and [[WordPress:#Bug Resolutions|Bug Resolutions (below)]].
# A WordPress developer (which could be you) decides to fix the bug. The developer may choose to take responsibility for the bug by clicking on the ''Accept ticket'' option near the bottom of the ticket, though this is not required. Then the developer figures out how to fix the bug, creates one or more patch files, and uploads them to Trac. See [[WordPress:#Patching Bugs|Patching Bugs (below)]]. Also, if you want to help with fixing bugs, but don't know what bugs to fix, see [[WordPress:#Finding Bugs to Fix|Finding Bugs to Fix (below)]].
# Members of the WordPress development group (including volunteers) test the patch, to see if it fixes the bug and doesn't break anything else. They add comments and keywords to the ticket to indicate their results. See [[WordPress:#Trac Keywords|Trac Keywords list (below)]].
# One of the WordPress developers with authority to modify the official WordPress source code (Matt Mullenweg, Ryan Boren, Mark Jaquith or Peter Westwood) ''commits'' the patch to the core code in the SVN repository. They are more likely to do this if the bug and patch has been verified by someone they trust.
# Finally, the person who commits the patch sets the bug ticket status? to ''closed'' and the resolution to ''fixed''. See [[WordPress:#Bug Resolutions|Bug Resolutions (below)]].


==Details of Bug Reporting and Resolution==
下面的部分給上述的提綱添加了詳細內(nèi)容。


The sections below add details to some of the steps outlined above.
=== 報告錯誤之前 ===


=== Before You Report a Bug ===
如WordPress這么大的項目，如此多的使用者提交錯誤報告，很有可能你的錯誤已經(jīng)被提交過了，正因為這樣，檢查并確定系統(tǒng)中它還沒有被提交過是很重要的。如果你剛開始在WordPress中使用提交錯誤，在提交之前和有經(jīng)驗的開發(fā)人員討論這個問題是個好辦法。請按照下面的步驟。


With large projects like WordPress, so many users report bugs that there's a good chance your bug has already been reported. Because of this, it's very important to check to be sure it's not already in the system before you submit it. If you are new to reporting bugs in WordPress, it is also a good idea to discuss the issue with more experienced developers before reporting it. Please follow the steps below.
# 在Trac中通過使用[http://trac.wordpress.org/search 搜索]或者是[http://trac.wordpress.org/query 查詢]來查找你的錯誤或者是功能請求。
#* 如果你的問題已經(jīng)被提交過了，請不要重復提交。如果你有更深入的信息，登陸并添加信息記錄到已存在的錯誤中。
#* 如果你的問題相似，但是不完全和另一個問題相同，你可以決定是否添加一個記錄到相似問題中，或者是重新提交。很難決定是否你的問題可以作為一個新的問題提交，但是通常情況下，如果你只是有更多信息來提交的話，打開問題，簡單的添加一個記錄就可以了。 如果你有個完全不同的問題，或者如果你正經(jīng)歷了一個重復的以前解決過的問題，可以提交一個新錯誤。
#* 如果你的問題最近提交了也關閉了，但是你不同意這樣的解決方法，你可以重新打開ticket添加注釋，寫明你的理由。
# 想在Trac上在提交之前討論一個錯誤， (如判斷它是否是一個WordPress核心的而不是插件或者主題的錯誤)，你可以在[http://wordpress.org/support/ WordPress 支持論壇]上發(fā)個帖子，在[[WordPress:WordPress IRC Live Help|#wordpress IRC 頻道]] 討論你的問題，或者在[[WordPress:Mailing Lists#Testers|檢測器]] 或[[WordPress:Mailing Lists#hackers|Hackers]]郵件列表上參與郵件討論。
=== 提交錯誤 ===


# Search for your bug or feature request in Trac by using [http://trac.wordpress.org/search Search] or a [http://trac.wordpress.org/query Query].
[http://trac.wordpress.org/ Trac]是官方WordPress錯誤跟蹤器的名字。它使用開發(fā)源碼跟蹤軟件[http://projects.edgewall.com/trac/ Trac]，它是 [http://www.edgewall.com/ Edgewall Software]的產(chǎn)品。安裝下面的步驟在Trac建立一個好的錯誤報告:
#* If your issue has already been reported, please do not report a duplicate bug. If you have further information to contribute, log in and add a note to the existing bug.
#* If your issue is similar, but not quite the same as another issue, you may decide whether to add a note to the similar issue, or report a new one. It can be difficult to decide whether your issue warrants a new submission, but in general if you just have more information to contribute to a current, open issue, simply add a note to that issue. If you have a different enough issue, or if you are experiencing a recurrence of an issue that was previously resolved, report a new bug.
#* If your issue was recently reported and then closed, and you do not agree with the resolution, you can also reopen the ticket and add a comment as to your reasoning.
# To discuss a bug before reporting it in Trac (e.g. to figure out if it is really a bug in the core of WordPress and not in a plugin or theme), you can post a question on the [http://wordpress.org/support/ WordPress Support Forum], discuss your issue on the [[WordPress:WordPress IRC Live Help|#wordpress IRC channel]], or have an email discussion on the [[WordPress:Mailing Lists#Testers|Testers]] or [[WordPress:Mailing Lists#hackers|Hackers]] mailing list.


=== Reporting a Bug ===
# 閱讀 [[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。這隊伍你錯誤的交流是必需的。因為開發(fā)人員可能需要更多的信息(而你不能創(chuàng)建ticket 如果不登陸的話).
在新的ticket頁面上填寫如下信息:
#; 簡單摘要: 讓摘要簡短但是要包含信息并且準確，因為這是ticket的標題，將會顯示在搜索結(jié)果中。
#; 完整的描述: 填寫你的錯誤或者是功能要求的完整的描述。包括一個問題的描述，別人可以重復這個問題的步驟，也可以是一個錯誤的運轉(zhuǎn)的例子 (如 URL), 或者是一個為什么問題值得更正的描述。同樣包括關于你的平臺的信息，如操作系統(tǒng)，網(wǎng)絡服務器軟件，PHP 版本, MySQL 版本, WordPress 版本。你描述的越好，解決錯誤的可能性就越大。
#; Ticket 屬性:
#:; 優(yōu)先級: 你需要確定這個問題的優(yōu)先權(quán) – 這個錯誤有多緊急。除非它是一個致命的錯誤，最好是讓它保持默認狀態(tài)，因為開發(fā)人員通常都是按照錯誤優(yōu)先級的排序來的。
#:; 組件: 選擇發(fā)現(xiàn)問題所在的WordPress組件
#:; 嚴重 : 這個問題的''重要性''。選擇一個severity基于你認為這個問題有多嚴重，如果有疑問，就保持默認的''Normal''.
#:; 分配: 如果你知道有負責存在錯誤的代碼的開發(fā)人員，把他們的Trac用戶名放在這里。你也可以自己為這個錯誤負責，把你自己的Trac用戶名放在這里就可以了。這是可以選擇的，這可以讓開發(fā)人員更快的注意到這個錯誤。
#:; 里程表: 最遲在哪個版本這個問題會被解決。不要更改它。這是WordPress 開發(fā)人員設置的。
#:; 版本: 錯誤發(fā)現(xiàn)的WordPress 版本。你可以在管理面板的頁腳找到WordPress版本號。
#:; 關鍵詞: 關鍵詞讓開發(fā)人員更容易的找到錯誤所在，確定它的影響范圍。例如'posting'， 一個涉及到WordPress發(fā)表文章機制的錯誤的關鍵詞。同樣，有標準關鍵詞用來標記你的錯誤的狀態(tài)(參見 [[WordPress:#Trac Keywords|Trac 關鍵詞]] 下面).
#:; CC: 錯誤信息和更新信息發(fā)送的對象。如果你想保持可以被通知到，把你自己的Trac名字寫上。 當這個報告有任何更改的時候，你將會被郵件通知。不要忽視這些郵件; 做出任何改動后，確定查看一下報告更新。開發(fā)人員可能需要從你這里獲得更多的信息，這是他們與你聯(lián)系的唯一的方法。 '''注意''': 你需要進入Trac ''設置''頁面來設置你的email地址。把他放到你的支持論壇個人資料里并不能讓你的資料進入Trac以達到接收CC信息的目的。
# 點擊 '''提交Ticket''' (預覽之后). 然后返回。


[http://trac.wordpress.org/ Trac] is the name of the official WordPress bug tracker. It uses the open source bug tracking software [http://projects.edgewall.com/trac/ Trac] which is a product from [http://www.edgewall.com/ Edgewall Software]. Follow these steps to create a good bug report in Trac:
=== 找到錯誤修正 ===


# Read [[WordPress:#Before You Report a Bug|Before You Report a Bug (above)]], and verify that you have a new bug that is appropriate to report.
如果你想修正WordPress核心部分的錯誤，但是不知道修正哪個，這里是一些關于如何找到修正的錯誤的建議:
# Read this article on [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively], and the [http://trac.wordpress.org/wiki/TracTickets Trac Ticket documentation].
* 仔細閱讀 [http://trac.wordpress.org/report/13 需要關于Trac的補丁報告] (列出了沒有標出"has_patch"關鍵詞的錯誤)， [http://trac.wordpress.org/report/18 缺乏關于Trac的附件報告] (列出了沒有補丁文件的錯誤)，或者是其他對于看起來比較有趣的錯誤的 [http://trac.wordpress.org/report Trac 報告].
# Log into [http://trac.wordpress.org/ WordPress Trac] using your [http://wordpress.org/support/ support forum] username and password. If you don't have an account at the support forums, [http://wordpress.org/support/register.php register] so that you can login to Trac. This is essential for communication about your bug, since the developers may need more information (and you cannot create a ticket without logging in).
* 發(fā)送郵件信息到[[WordPress:Mailing_Lists#Hackers|wp-hackers 郵件列表]] 詢問你能幫什么忙. ?
# Click '''[http://trac.wordpress.org/newticket New Ticket]''' in Trac to reach the bug reporting page. ?
* 有時也有一些錯誤幫助在 <tt>#wordpress-dev</tt> [[WordPress:IRC|IRC]] 頻道。
# Fill in the following fields on the new ticket page:
* 偶然在<tt>#wordpress-bugs</tt>上有錯誤日。你可以在[[WordPress:WordPress Bug Hunts|錯誤搜尋]]上閱讀關于什么錯誤日發(fā)生了什么，并且預定[[WordPress:Mailing_Lists#Hackers|wp-hackers]]或者是 [[WordPress:Mailing_Lists#Testers|wp-testers]] 郵件列表來找出它們是什么時候出現(xiàn)的。
#; Short Summary: Make the summary short but informative and accurate, as this is the ticket title that will be displayed in search results.
* 考慮加入[http://lists.automattic.com/mailman/listinfo/wp-trac wp-trac 郵件列表] 來參與關于每個[http://trac.wordpress.org/report Trac Ticket]的討論。
#; Full Description: Fill in a full description of your bug or feature request. Include a description of the problem, steps someone else would have to take to reproduce the problem, maybe an example of the bug in action (i.e. a URL), and a description of why it is a problem worthy of being corrected. Also include information about your platform, such as operating system, web server software, PHP version, MySQL version, and WordPress version. The better your description, the better the chances of having the bug resolved promptly.
#; Ticket Properties:
#:; Priority: You will need to decide on a priority for the issue -- this is how urgent the bug is. Unless it is a critical bug, this is best left to the default as developers will usually rank the bug's priority.
#:; Component: Select the component of WordPress where the bug was found
#:; Severity : The ''significance'' of the issue. Select a severity based on how critical you consider the issue to be. If in doubt, leave this option as ''Normal''.
#:; Assign to: If you know of the developer who is responsible for the code that the bug is in, place their Trac username here. You can also take responsibility for the bug yourself, by putting your own Trac user name here. This is optional and could speed up developer attention to the bug.
#:; Milestone: By what version this issue should be resolved, at the latest. Do not change this. This is an option that WordPress developers will set.
#:; Version: The version of WordPress where the bug was found. You can find the version number of WordPress in the footer of the admin panel.
#:; Keywords: Keywords that will make it easier for developers to find the bug, and identify the areas it affects. An example might be 'posting' for a bug involving the posting mechanism in WordPress. Also, there are some standard keywords used to flag your bug's status (see [[WordPress:#Trac Keywords|Trac Keywords]] below).
#:; CC: Who bug information and updates should be sent to. If you want to be kept informed, enter your own Trac user name here. You will then? be notified by email any time a change is made to this report, or a note to the bug is added. Don't ignore these emails; any time a change is made, be sure to check the report for updates. Developers may need further information from you, and this is their only way of getting in contact with you. '''Note''': you need to go to the Trac ''Settings'' page to set your email address. Putting it into your Support Forum profile will not get it into Trac for purposes of CC messages.
# Click '''Submit Ticket''' (after previewing it). Then pat yourself on the back.


=== Finding Bugs to Fix ===


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 [http://trac.wordpress.org/report/13 Needs Patch Report on Trac] (which lists bugs that have not been marked with the "has_patch" keyword), the [http://trac.wordpress.org/report/18 Lacks Attachment Report on Trac] (which lists bugs that do not have a patch file attached), or other [http://trac.wordpress.org/report Trac reports] for bugs that look interesting.
* Send an email message to the [[WordPress:Mailing_Lists#Hackers|wp-hackers mailing list]] and ask how you can help.
* There is also sometimes bug triage on the <tt>#wordpress-dev</tt> [[WordPress:IRC]] channel
* Occasionally there are bug days on <tt>#wordpress-bugs</tt>. You can read about what happens in a bug day in [[WordPress:WordPress Bug Hunts]], and subscribe to either the [[WordPress:Mailing_Lists#Hackers|wp-hackers]] or [[WordPress:Mailing_Lists#Testers|wp-testers]] mailing list to find out when they happen.
* Consider joining the [http://lists.automattic.com/mailman/listinfo/wp-trac wp-trac email list] to follow the discussions about each [http://trac.wordpress.org/report Trac Ticket].


=== Patching Bugs ===
如果你熟悉[[WordPress:Glossary#PHP|PHP]]和 [[WordPress:Glossary#MySQL|MySQL]]，并且想幫助WordPress發(fā)展，那么我們鼓勵你為WordPress 的錯誤打上補丁。如下是打補丁的步驟:


If you and are familiar with [[WordPress:Glossary#PHP|PHP]] and [[WordPress:Glossary#MySQL|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:
#閱讀 [[#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核心文件修正錯誤。你可能想在結(jié)束之前在[[WordPress:Mailing_Lists#Hackers|wp-hackers 郵件列表]]上討論你的解決方案。
# 測試你的修改，驗證錯誤已經(jīng)被修正，而且在此過程中沒有其他的WordPress內(nèi)的東西被破壞。
# 創(chuàng)建一個包含你的修改的''補丁文件''。這完全與修正文件和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 關鍵詞 (下面)]] 獲得更多信息。


#Read [[WordPress:#Finding Bugs to Fix|Finding Bugs to Fix (above)]], and find a bug to fix in [http://trac.wordpress.org Trac].
=== Trac 關鍵詞 ===
#Connect to the [http://wordpress.org/download/svn/ WordPress Subversion (SVN) Repository] using the username and password you acquired when [http://wordpress.org/support/register.php registering]. Read [[WordPress:Using Subversion]] if you are unfamiliar with SVN.? All patches should be submitted against the latest code in the SVN repository.
# Figure out how to fix the bug, by modifying WordPress core files. You may want to discuss your proposed solution on the [[WordPress:Mailing_Lists#Hackers|wp-hackers mailing list]] before finalizing it.
# Test your fix, verifying that the bug has been fixed, and that nothing else in WordPress is broken in the process.
# 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 [http://asymptomatic.net/2005/12/03/586/how-to-patch-wordpress How to Patch WordPress by Owen Winkler] for detailed instructions. There are also instructions for Linux/Mac command-line users in [http://markjaquith.wordpress.com/2005/11/02/my-wordpress-toolbox/ Mark Jaquith's Toolbox] and Windows Tortoise SVN users in [http://blog.ftwr.co.uk/archives/2005/11/03/windows-wordpress-toolbox/ Westi's Blog].
# Upload it to the ticket using the [http://trac.wordpress.org/ 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 [[WordPress:#Trac Keywords|Trac Keywords (below)]] for more information.


=== Trac Keywords ===
有很多有固定意思的關鍵詞經(jīng)常在[http://trac.wordpress.org Trac]中使用; 一些可以通過[http://trac.wordpress.org/report Trac Reports]搜索。


There are a number of keywords with defined meaning used in [http://trac.wordpress.org Trac] that are commonly used; some are also searched for by [http://trac.wordpress.org/report Trac Reports].
;reporter-feedback : 提交人的回復是必需的。深入的調(diào)查如果沒有經(jīng)歷過問題本身的人的回復的話是靠不住的。


;reporter-feedback : A response is needed from the reporter. Further investigation is unlikely without a response to the questions from someone experiencing the problem.
;has-patch : 已經(jīng)附上ticket的解決方法，準備好再次檢查或者是提交。


;has-patch : A solution to the ticket has been attached, and it is ready for review and/or committing.
;needs-testing : 某人需要測試這個解決方案


;needs-testing : Someone needs to test the solution.
;2nd-opinion : 需要另外一個人來傳遞一個關于問題或者解決方案的觀點


;2nd-opinion : Another person is needed to express an opinion about the problem or the solution.
;dev-feedback : 需要開發(fā)人員的回復 (不常用)


;dev-feedback : A response is wanted from a developer (not commonly used)
;tested : 補丁測試過了. 當添加這個標簽時請加入測試的文件名字，補丁如何測試的，和使用了哪個WordPress版本(包括SVN版本號，如果不是官方發(fā)布的版本的話).


;tested : The patch has been tested. When adding this tag 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).
;commit : 補丁已經(jīng)被某個開發(fā)團體中可以信任的人檢查過，測試過; 這樣這個補丁就已經(jīng)準備添加到WordPress核心文件中了.


;commit : The patch has been reviewed and tested by a trusted member of the development community; therefore the patch is ready to be added to the WordPress core files.
;needs-patch : ticket已經(jīng)被檢查過，發(fā)現(xiàn)描述為解決，但是標記為特別需要一個補丁，或者提交的補丁不能使用需要重新做


;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-unit-tests : ticket已經(jīng)通過檢查，發(fā)現(xiàn)描述為解決，我們希望一個聯(lián)合測試，來測試功能性，因為提交前各種補丁的存在造成導致其他問題的風險很高。


;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-doc : 需要代碼的內(nèi)嵌文檔。這可以是在它們被提交之前保存ticket單獨文件或者是帶有新函數(shù)補丁需要的文檔資料。


;needs-doc : 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.
=== 錯誤解決方案===


=== Bug Resolutions ===
Trac 中的ticket 在''open''狀態(tài)下開始，最終到''closed''。當一個ticket關閉后，它會被以下某個狀態(tài)之一標記:


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:
* 如果你的錯誤已經(jīng)提交到別的地方，它將以''duplicate''結(jié)束.
* 如果錯誤在最新的版本代碼中已經(jīng)修正(可能不是你在運行的版本除非你有一個本地測試的blog)，標記為''fixed''.
* 如果確定你的錯誤事實上不是錯誤，而是你故意的行為，會標記為''invalid''.
* 如果沒有其他人可以重現(xiàn)你所描述的現(xiàn)象，會以''worksforme''結(jié)束。
* 如果你的錯誤是一個功能請求，而開發(fā)人員不想讓它出現(xiàn)在核心代碼中，標記為 ''wontfix''.


* 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), then it will be closed with ''fixed''.
* 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.


== Notes ==
== 注 ==


* The processing of your bug may require your participation. Please be willing and prepared to aid the developers in resolving the issue.
* 你的錯誤的處理過程可能需要你的參與，希望你自愿并準備好幫助開發(fā)人員解決問題。
* 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.
* 如果你的問題被解決為"Not a bug" 或者 "Won't fix"時不要生氣，看起來對你是錯誤的東西很可能是一種"功能". 這些解決方法只是意味這"現(xiàn)在不能解決", 可能將來會被解決的.
* Thank you for contributing to the development of WordPress!
* 感謝為WordPress做出的貢獻!
# 點擊Trac中 '''[http://trac.wordpress.org/newticket New Ticket]''' 打開錯誤提交頁面。
# 在ticket頁面的如下區(qū)域填寫：
# 簡短概要：使概要簡短的但是很具有信息化和準確性，象這個是在搜索結(jié)果中將被展示的ticket標題
# 全部描述：填寫

2008年5月27日 (二) 10:59的最新版本

導航: 上一級 | WordPress | 首頁 | WordPress中文論壇 | WordPress主機 | CMS程序 | 論壇程序 | ECShop | ShopNC | PowerEasy

每種軟件都有錯誤 – 只要是人寫代碼，軟件中就會有錯誤，有些錯誤是微不足道的，但是有些是非常嚴重的。開源項目如 WordPress 需要使用者的參與來找出軟件中的錯誤，同樣也包括新功能的開發(fā)。 所有類型的反饋— 不管是真正的錯誤還是有用的請求— 都在WordPress 中用同樣的方法提交。閱讀WordPress關于如何提交錯誤和問題的信息... 你可能會想要閱讀為WordPress做貢獻來找出如何為文檔資料和WordPress其他方面做貢獻。

提交安全問題[ ]

當我們試著防止出現(xiàn)安全問題時，我們不能認為它們不會出現(xiàn)。如果你相信你在WordPress某個版本中找到了安全問題，發(fā)郵件到WordPress.org上的security 區(qū)域，我們將盡力盡快解決。

通知賣主(這里是指WordPress開發(fā)人員)是在發(fā)布之前的安全問題的標準練習，這樣可以準備好修正版本，這造成的損失可以降低到最小。

提交插件和主題中的錯誤[ ]

如果你在使用時插件或者主題中發(fā)現(xiàn)了錯誤，不要 使用本文中的方法進行提交! 本文提供的方法只適用于WordPress核心文件的錯誤，不適合于插件和主題中的錯誤。

WordPress插件庫中的插件有一個來自 WordPress 核心的單獨的錯誤跟蹤系統(tǒng)。有一個如何使用這個系統(tǒng)的 單獨的說明。

對于不在官方庫中的插件和主題，查看其附帶的文檔資料作為關于如何提交錯誤的說明。如果沒有錯誤提交信息，你需要直接聯(lián)系作者。


錯誤提交和解決總覽[ ]

提交和解決WordPress錯誤的過程有幾步，這里是一個總的概括，下面可以找到更多細節(jié)。

  1. 用戶發(fā)現(xiàn)了錯誤，出現(xiàn)在WordPress核心文件中 (不在主題或者插件中).
  2. 用戶嘗試著確認這確實是一個錯誤。參見 提交錯誤之前(下面).
  3. 如果確定它是一個錯誤，用戶提交錯誤報告到Trac，叫做ticket，WordPress錯誤跟蹤系統(tǒng)。參見提交錯誤 (下面).
  4. WordPress 開發(fā)人員 (可能也是象你一樣的志愿者) 確認錯誤的確存在，然后它應該被修正。然后象在票上做記號那樣標記出來。參見Trac 關鍵詞列表(下面) 和 錯誤解決方案(下面).
  5. WordPress 開發(fā)人員 (可能是你)決定修復這個錯誤。開發(fā)者可能選擇通過點擊ticket底部附近的 Accept ticket操作來負責這個錯誤，盡管這不是必須的。然后開發(fā)人員指出如何修復這個錯誤，創(chuàng)建一個或者多個補丁，上傳到Trac. 參見 錯誤補丁(下面)。同樣的，如果你想要幫助修復錯誤，但是不知道需要修復哪個錯誤，參見找到錯誤并修復 (下面).
  6. WordPress開發(fā)小組成員(包括志愿者)測試補丁，查看是否錯誤被修復了而沒有影響到其他東西。它們添加評論和關鍵詞到ticket，顯示出它們的結(jié)果。參見 Trac 關鍵詞列表(下面).
  7. WordPress 開發(fā)員中的一個擁有修改官方WordPress源代碼權(quán)限的人(Matt Mullenweg, Ryan Boren, Mark Jaquith or Peter Westwood) 提交 補丁給SVN庫中的核心代碼。如果錯誤和補丁被他們所信任的某人驗證過后，他們會這樣做的。
  8. 最后，提交補丁的這個人設定ticket狀態(tài)為closed，結(jié)論是fixed。參見 錯誤結(jié)論(下面).

錯誤報告和解決方案的詳細內(nèi)容[ ]

下面的部分給上述的提綱添加了詳細內(nèi)容。

報告錯誤之前[ ]

如WordPress這么大的項目，如此多的使用者提交錯誤報告，很有可能你的錯誤已經(jīng)被提交過了，正因為這樣，檢查并確定系統(tǒng)中它還沒有被提交過是很重要的。如果你剛開始在WordPress中使用提交錯誤，在提交之前和有經(jīng)驗的開發(fā)人員討論這個問題是個好辦法。請按照下面的步驟。

  1. 在Trac中通過使用搜索或者是查詢來查找你的錯誤或者是功能請求。
    • 如果你的問題已經(jīng)被提交過了，請不要重復提交。如果你有更深入的信息，登陸并添加信息記錄到已存在的錯誤中。
    • 如果你的問題相似，但是不完全和另一個問題相同，你可以決定是否添加一個記錄到相似問題中，或者是重新提交。很難決定是否你的問題可以作為一個新的問題提交，但是通常情況下，如果你只是有更多信息來提交的話，打開問題，簡單的添加一個記錄就可以了。 如果你有個完全不同的問題，或者如果你正經(jīng)歷了一個重復的以前解決過的問題，可以提交一個新錯誤。
    • 如果你的問題最近提交了也關閉了，但是你不同意這樣的解決方法，你可以重新打開ticket添加注釋，寫明你的理由。
  2. 想在Trac上在提交之前討論一個錯誤， (如判斷它是否是一個WordPress核心的而不是插件或者主題的錯誤)，你可以在WordPress 支持論壇上發(fā)個帖子，在#wordpress IRC 頻道 討論你的問題，或者在檢測器 或Hackers郵件列表上參與郵件討論。

提交錯誤[ ]

Trac是官方WordPress錯誤跟蹤器的名字。它使用開發(fā)源碼跟蹤軟件Trac，它是 Edgewall Software的產(chǎn)品。安裝下面的步驟在Trac建立一個好的錯誤報告:

  1. 閱讀 [[WordPress:#Before You Report a Bug|提交錯誤之前(上面)]], 然后驗證你有一個新的可以提交的錯誤。
  2. 閱讀如何有效的提交錯誤這個文章，和Trac Ticket 文檔.
  3. 使用你的 using your 支持論壇的用戶名和密碼登陸WordPress Trac。如果你沒有帳戶， 注冊 一個這樣才可以登陸Trac。這隊伍你錯誤的交流是必需的。因為開發(fā)人員可能需要更多的信息(而你不能創(chuàng)建ticket 如果不登陸的話).
在新的ticket頁面上填寫如下信息:
  1. 簡單摘要
    讓摘要簡短但是要包含信息并且準確，因為這是ticket的標題，將會顯示在搜索結(jié)果中。
    完整的描述
    填寫你的錯誤或者是功能要求的完整的描述。包括一個問題的描述，別人可以重復這個問題的步驟，也可以是一個錯誤的運轉(zhuǎn)的例子 (如 URL), 或者是一個為什么問題值得更正的描述。同樣包括關于你的平臺的信息，如操作系統(tǒng)，網(wǎng)絡服務器軟件，PHP 版本, MySQL 版本, WordPress 版本。你描述的越好，解決錯誤的可能性就越大。
    Ticket 屬性
    優(yōu)先級
    你需要確定這個問題的優(yōu)先權(quán) – 這個錯誤有多緊急。除非它是一個致命的錯誤，最好是讓它保持默認狀態(tài)，因為開發(fā)人員通常都是按照錯誤優(yōu)先級的排序來的。
    組件
    選擇發(fā)現(xiàn)問題所在的WordPress組件
    嚴重
    這個問題的重要性。選擇一個severity基于你認為這個問題有多嚴重，如果有疑問，就保持默認的Normal.
    分配
    如果你知道有負責存在錯誤的代碼的開發(fā)人員，把他們的Trac用戶名放在這里。你也可以自己為這個錯誤負責，把你自己的Trac用戶名放在這里就可以了。這是可以選擇的，這可以讓開發(fā)人員更快的注意到這個錯誤。
    里程表
    最遲在哪個版本這個問題會被解決。不要更改它。這是WordPress 開發(fā)人員設置的。
    版本
    錯誤發(fā)現(xiàn)的WordPress 版本。你可以在管理面板的頁腳找到WordPress版本號。
    關鍵詞
    關鍵詞讓開發(fā)人員更容易的找到錯誤所在，確定它的影響范圍。例如'posting'， 一個涉及到WordPress發(fā)表文章機制的錯誤的關鍵詞。同樣，有標準關鍵詞用來標記你的錯誤的狀態(tài)(參見 [[WordPress:#Trac Keywords|Trac 關鍵詞]] 下面).
    CC
    錯誤信息和更新信息發(fā)送的對象。如果你想保持可以被通知到，把你自己的Trac名字寫上。 當這個報告有任何更改的時候，你將會被郵件通知。不要忽視這些郵件; 做出任何改動后，確定查看一下報告更新。開發(fā)人員可能需要從你這里獲得更多的信息，這是他們與你聯(lián)系的唯一的方法。 注意: 你需要進入Trac 設置頁面來設置你的email地址。把他放到你的支持論壇個人資料里并不能讓你的資料進入Trac以達到接收CC信息的目的。
  2. 點擊 提交Ticket (預覽之后). 然后返回。

找到錯誤修正[ ]

如果你想修正WordPress核心部分的錯誤，但是不知道修正哪個，這里是一些關于如何找到修正的錯誤的建議:


打補丁[ ]

如果你熟悉PHP和 MySQL，并且想幫助WordPress發(fā)展，那么我們鼓勵你為WordPress 的錯誤打上補丁。如下是打補丁的步驟:

  1. 閱讀 找到錯誤修正(上面), 然后在Trac中找到錯誤并修正
  2. 使用你注冊的用戶名和密碼連接到WordPress Subversion (SVN) Repository，閱讀 使用子版本，如果你對SVN不熟悉的話。所有的補丁都會被提交的SVN，而不考慮最新的代碼。
  3. 找出如何通過修改WordPress核心文件修正錯誤。你可能想在結(jié)束之前在wp-hackers 郵件列表上討論你的解決方案。
  4. 測試你的修改，驗證錯誤已經(jīng)被修正，而且在此過程中沒有其他的WordPress內(nèi)的東西被破壞。
  5. 創(chuàng)建一個包含你的修改的補丁文件。這完全與修正文件和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 關鍵詞[ ]

有很多有固定意思的關鍵詞經(jīng)常在Trac中使用; 一些可以通過Trac Reports搜索。

reporter-feedback
提交人的回復是必需的。深入的調(diào)查如果沒有經(jīng)歷過問題本身的人的回復的話是靠不住的。
has-patch
已經(jīng)附上ticket的解決方法，準備好再次檢查或者是提交。
needs-testing
某人需要測試這個解決方案
2nd-opinion
需要另外一個人來傳遞一個關于問題或者解決方案的觀點
dev-feedback
需要開發(fā)人員的回復 (不常用)
tested
補丁測試過了. 當添加這個標簽時請加入測試的文件名字，補丁如何測試的，和使用了哪個WordPress版本(包括SVN版本號，如果不是官方發(fā)布的版本的話).
commit
補丁已經(jīng)被某個開發(fā)團體中可以信任的人檢查過，測試過; 這樣這個補丁就已經(jīng)準備添加到WordPress核心文件中了.
needs-patch
ticket已經(jīng)被檢查過，發(fā)現(xiàn)描述為解決，但是標記為特別需要一個補丁，或者提交的補丁不能使用需要重新做
needs-unit-tests
ticket已經(jīng)通過檢查，發(fā)現(xiàn)描述為解決，我們希望一個聯(lián)合測試，來測試功能性，因為提交前各種補丁的存在造成導致其他問題的風險很高。
needs-doc
需要代碼的內(nèi)嵌文檔。這可以是在它們被提交之前保存ticket單獨文件或者是帶有新函數(shù)補丁需要的文檔資料。

錯誤解決方案[ ]

Trac 中的ticket 在open狀態(tài)下開始，最終到closed。當一個ticket關閉后，它會被以下某個狀態(tài)之一標記:

  • 如果你的錯誤已經(jīng)提交到別的地方，它將以duplicate結(jié)束.
  • 如果錯誤在最新的版本代碼中已經(jīng)修正(可能不是你在運行的版本除非你有一個本地測試的blog)，標記為fixed.
  • 如果確定你的錯誤事實上不是錯誤，而是你故意的行為，會標記為invalid.
  • 如果沒有其他人可以重現(xiàn)你所描述的現(xiàn)象，會以worksforme結(jié)束。
  • 如果你的錯誤是一個功能請求，而開發(fā)人員不想讓它出現(xiàn)在核心代碼中，標記為 wontfix.

請驗證你的錯誤在提交時不屬于其中任何一種。


注[ ]

  • 你的錯誤的處理過程可能需要你的參與，希望你自愿并準備好幫助開發(fā)人員解決問題。
  • 如果你的問題被解決為"Not a bug" 或者 "Won't fix"時不要生氣，看起來對你是錯誤的東西很可能是一種"功能". 這些解決方法只是意味這"現(xiàn)在不能解決", 可能將來會被解決的.
  • 感謝為WordPress做出的貢獻!
  1. 點擊Trac中 New Ticket 打開錯誤提交頁面。
  2. 在ticket頁面的如下區(qū)域填寫：
  3. 簡短概要：使概要簡短的但是很具有信息化和準確性，象這個是在搜索結(jié)果中將被展示的ticket標題
  4. 全部描述：填寫