WordPress 核心补丁提交：打造共享改变的流程

如果您使用 WordPress 谋生并讲述您的故事，那么看到您编写的更改添加到 WordPress 代码库中是一件非常令人兴奋的事情。我知道这是给我的。

在本教程中，您将学习创建可被核心软件接受的 WordPress 补丁所需了解的一些简单知识。

虽然 WordPress 是任何人都可以下载和修改的开源软件，但只有少数核心贡献者能够将他们的更改提交到 WordPress 本身。如果您想对 WordPress 的核心文件进行更改，您可以通过创建详细说明提议的更改并附加补丁的票证或将补丁附加到现有票证来提出建议。

补丁或 diff 文件是一个详细说明您对源代码所做的更改的文件，SVN 或 GIT 等版本控制系统可以使用该文件来应用您的更改。通过命令行或通过 SourceTree 等 GUI 工具可以轻松创建补丁。

在本文中，我将详细介绍如何使用优秀的 GIT GUI 应用程序 SourceTree 来检查最新版本的 WordPress 并创建补丁文件。如果您愿意，可以使用您选择的 GUI 工具或命令行。

在 Core Trac 中查找或创建票证

当您将补丁提交到 WordPress 核心时，它必须附加到 WordPress 问题跟踪器（称为 trac）中的票证中。因此，提交补丁的第一步是查找或创建票证。

虽然具有新功能的新票证有可能被接受，但可能性不大。 WordPress 拥有数百万用户，主要开发人员对于引入新功能非常谨慎是有道理的。现在几乎所有新功能都首先作为插件单独开发，只有经过广泛的测试和开发后才合并到核心中。

要让补丁被接受，最好的办法是为现有票证创建补丁。最近，核心 trac 进行了重新设计，以便更轻松地查找具有简单修复的票证以及最有可能包含在下一版本和下一版本 WordPress 中的票证。

报告错误

如果您想在 core trac 中创建新票证（如果您发现了新错误，这是一件很棒的事情），您可以在此处执行此操作。只需确保您在创建新票证之前已在 trac 中搜索了同一问题的任何报告，并且已验证最新版本的 WordPress 中是否存在该错误。

我指的并不是最新版本，而是 GIT 术语中的 master 分支或 SVN 术语中的 trunk。我将在本教程稍后详细介绍如何获取最新版本。

您至少必须填写摘要字段（工单的标题）和描述字段，这是票证的内容。在票证描述中，请尽可能具有描述性。

在我参加的 2013 年 WordCamp 奥兰多贡献者研讨会上，WordPress 首席开发人员 Mark Jaquith 和 Andrew Nacin 创建了这份优秀错误报告的列表：

• 重现问题的步骤（从最早的步骤开始）
• 错误描述
• 您所看到的与您所期望的
• 错误消息或错误代码
• PHP 错误（页面上的警告是什么、日志中出现了什么内容、是否有任何 JavaScript 或 Apache/nginx 错误？）
• 什么浏览器？
• 环境（您的 PHP 版本、MySQL Apache 或 nginx 版本）
• 在没有插件和默认主题的情况下会发生这种情况吗？
• 用户界面问题的屏幕截图
• 清晰简洁
• 先切入主题，然后再详细说明。
• 相关票号
• 每张票一个错误
• 固定链接设置
• 是否启用多站点？
• WP_DEBUG 或同等功能已启用？
• 问题发生时登录的用户角色（或更改数据库中的角色）

请记住，并非所有这些都与每个错误相关，但您可以添加更多相关信息，效果更好。

除非您确定要在其中设置什么内容，否则您应该保留下面描述的字段，让核心贡献者使用它们对工单进行相应的分类。我建议您根据是否附加补丁来修复错误而使用“Has Patch”或“Needs Patch”标签。

使用 GUI 工具从 GitHub 查看最新的 WordPress

在为任何票证创建补丁之前，拥有绝对最新版本的 WordPress 非常重要，因为每天都会对其进行许多更改。除非您使用最新的代码，否则不可能知道您的修复是否有效或错误是否仍然存在。如果您的补丁修改了已经更改的代码，则它可能不会被接受。

WordPress 在 SVN 中管理，但该代码在两个位置镜像为 GIT 存储库：

1. git://core.git.wordpress.org/
2. https://github.com/WordPress/WordPress

GitHub 存储库是最容易使用的。请记住，即使它是官方 GitHub 存储库，它仍然不用于问题跟踪，并且您不应向其提交拉取请求。

有多种方法可以通过 SVN 或 Git 获取最新版本的 WordPress。就我个人而言，我发现最简单的方法是使用出色的 GIT GUI 工具 SourceTree 来克隆 GitHub 镜像。这就像从文件菜单中选择“新建/克隆”一样简单，在“源路径/ URL”字段中输入 Git 存储库的地址，然后指定用于克隆的本地路径，该路径位于您的 XAMMP 或 Vagrant 内部测试环境。

说到 Vagrant，流行的 WordPress Vagrant 配置 VVV 已经为 WordPress 核心预配置了测试环境，包括最新代码和单元测试。

创建补丁文件

对 WordPress 进行了解决您尝试修复的问题所需的更改并测试了修复后，您需要创建一个补丁文件以上传到工单。 SourceTree 包含一种创建补丁文件的方法，或者您也可以使用命令行。

在 SourceTree 中，您可以通过转到工作副本并右键单击已更改的文件来创建补丁文件。从右键菜单中选择“创建补丁”。

或者，在终端中导航到 WordPress 存储库的根目录，然后使用以下命令创建差异：

git diff —非前缀 ~/name.path

无论您如何创建补丁文件，都应该以它的目标票号来命名它。如果这是上传到票证的第二个补丁，请在数字末尾附加 .2，如果是第三个，则附加 .3，依此类推。例如，票号 #12358 的第五个补丁将被称为 #12358.5

将补丁上传到 Trac

现在您的补丁已准备就绪，您需要将其上传到 core trac 中的票证中。在任何现有的票证上，说明下方都有一个“附加文件”按钮，您可以使用该按钮上传补丁。在下一个屏幕上，请务必添加补丁功能的描述。

要有耐心并理解

WordPress 是一个庞大的项目，因此期望您的补丁立即得到响应是不合理的。另外，请了解，提交给 WordPress 的补丁的标准必须非常高，才能最好地服务所有用户。

提交补丁后，请保持耐心并理解您收到的任何反馈。主要开发人员非常平易近人，如果您对补丁有疑问或为什么没有改进，请随时在 #wordpress-dev IRC 频道中询问其中一位。

虽然等待响应并必须进行更改可能会令人沮丧，但当您的补丁已提交到 WordPress 并且变更集描述认可您时，这是值得的。