WordPress コアへのパッチの送信: 変更を作成して共有するプロセス

WordPress を使って生計を立て、自分のストーリーを伝える場合、自分が書いた変更が WordPress のコードベースに追加されるのを見るのはとても楽しいことです。これが私のためであることはわかっています。

このチュートリアルでは、コア ソフトウェアで受け入れられる WordPress パッチを作成するために知っておく必要がある簡単な事柄のいくつかを学びます。

WordPress は誰でもダウンロードして変更できるオープンソース ソフトウェアですが、WordPress 自体に変更をコミットできるのは少数の中心的な貢献者だけです。 WordPress のコア ファイルに変更を加えたい場合は、提案された変更の詳細を記載したチケットを作成してパッチを添付するか、既存のチケットにパッチを添付することで提案を行うことができます。

パッチまたは差分ファイルは、ソース コードに加えた変更の詳細を記述したファイルであり、SVN や GIT などのバージョン管理システムで変更を適用するために使用できます。パッチは、コマンド ラインまたは SourceTree などの GUI ツールから簡単に作成できます。

この記事では、優れた GIT GUI アプリケーション SourceTree を使用して、WordPress の最新バージョンを確認し、パッチ ファイルを作成する方法を詳しく説明します。必要に応じて、選択した GUI ツールまたはコマンド ラインを使用できます。

Core Trac でチケットを検索または作成する

パッチを WordPress コアに送信するときは、WordPress 問題トラッカー (trac と呼ばれる) のチケットにパッチを添付する必要があります。したがって、パッチを送信する最初のステップは、チケットを検索または作成することです。

新しい機能を備えた新しいチケットが受け入れられる可能性はありますが、その可能性は低いです。 WordPress には何百万ものユーザーがおり、大手開発者が新機能の導入に慎重になるのは当然です。現在、ほぼすべての新機能は最初にプラグインとして個別に開発され、広範なテストと開発の後にのみコアにマージされます。

パッチを受け入れてもらうための最良の方法は、既存のチケット用のパッチを作成することです。最近、コア Trac が再設計され、簡単な修正があり、WordPress の次のバージョンとバージョンに含まれる可能性が最も高いチケットを見つけやすくなりました。

エラーを報告

コア Trac で新しいチケットを作成したい場合 (新しいバグが見つかった場合は非常に便利です)、ここで作成できます。新しいチケットを作成する前に、trac で同じ問題のレポートがないか必ず検索し、最新バージョンの WordPress にバグが存在することを確認してください。

ここで言っているのは最新バージョンのことではなく、GIT 用語でのマスター ブランチ、または SVN 用語でのトランクのことです。最新バージョンを入手する方法については、このチュートリアルの後半で詳しく説明します。

少なくとも、[概要] フィールド (チケットのタイトル) と、チケットの内容である [説明] フィールドに入力する必要があります。チケットの説明では、できるだけわかりやすいものにしてください。

私が参加した 2013 WordCamp Orlando コントリビューター ワークショップでは、WordPress の主任開発者である Mark Jaquith と Andrew Nacin が次のような素晴らしいバグ レポートのリストを作成しました。

問題を再現する手順 (最初の手順から開始)
間違った説明
目に見えるものと期待するもの
エラーメッセージまたはエラーコード
PHP エラー (ページ上の警告、ログに表示される内容、JavaScript または Apache/nginx エラーはありますか?)
どのブラウザですか?
環境 (PHP バージョン、MySQL Apache または nginx バージョン)
これはプラグインとデフォルトのテーマがないと発生しますか?
ユーザー インターフェイスの問題のスクリーンショット
明確かつ簡潔な
まず本題に入り、それから詳しく説明しましょう。
関連チケット番号
チケットごとに 1 つのエラー
パーマリンク設定
マルチサイトを有効にしますか?
WP_DEBUG または同等のものは有効ですか?
問題発生時にログインしていたユーザーの役割(またはデータベース内の役割を変更)

これらすべてがすべてのエラーに関連するわけではありませんが、追加できる関連情報が多ければ多いほど良いことに留意してください。

そこで何を設定するかが明確でない場合は、以下で説明するフィールドをそのままにし、コア投稿者がそれらのフィールドを使用してチケットを適切に分類できるようにする必要があります。バグを修正するパッチを添付するかどうかに応じて、「パッチあり」タグまたは「パッチ必要」タグを使用することをお勧めします。

GUI ツールを使用して GitHub から最新の WordPress を表示します

WordPress には毎日多くの変更が加えられるため、チケットのパッチを作成する前に、WordPress を完全に最新バージョンにしておくことが非常に重要です。最新のコードを使用していない限り、修正が機能したかどうか、またはバグがまだ存在しているかどうかを知ることは不可能です。すでに変更されているコードをパッチで修正する場合、そのパッチは受け入れられない可能性があります。

WordPress は SVN で管理されますが、コードは 2 つの場所に 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 番目のパッチである場合は、番号の末尾に .2 を追加し、3 番目である場合は、.3 を追加します。たとえば、チケット #12358 の 5 番目のパッチは #12358.5

と呼ばれます。

パッチを Trac にアップロードする

パッチの準備ができたので、それをコア トラックのチケットにアップロードする必要があります。既存のチケットには、説明の下に「ファイルを添付」ボタンがあり、パッチをアップロードするために使用できます。次の画面で、パッチの機能の説明を必ず追加してください。

辛抱強く理解してください

WordPress は大規模なプロジェクトなので、パッチに対する即時の対応を期待するのは無理があります。また、すべてのユーザーに最適なサービスを提供するには、WordPress に送信されるパッチの基準が非常に高くなければならないことをご理解ください。

パッチを送信した後は、受け取ったフィードバックを十分に理解してお待ちください。主要な開発者は非常に親しみやすいです。パッチについて質問がある場合や、なぜ改善されないのかについては、#wordpress-dev IRC チャネルでお気軽に質問してください。

応答を待って変更を加えなければならないのはイライラするかもしれませんが、パッチが WordPress に送信され、変更セットの説明で認識されれば、それだけの価値があります。