いよいよ今週末にせまったCapital P もくもくコントリビューション #1だが、いきなりコアにコントリビュートをするといっても、具体的になにをするかイメージが固めておく必要があるだろう。そこで本稿では、WordPressのコアにパッチを送る流れをご紹介したい。
コアのコードの管理方法
そもそもだが、WordPressの本体はどこで管理されているのだろうか。それは、WordPress.orgが保有するSubversionリポジトリである。Githubにもクローンがあり、その詳細はmake.handbookにも記されている。なぜ2つあるかというと……歴史的経緯の一語に尽きる。当初のリポジトリであったSubversionを中心としたワークフローが浸透し、なおかつBTS（バグトラッキングシステム）にも様々な資産が残っているたため、途中から隆盛を極めたGitに移行しきれていないのだ。しかし、昨今の共同作業環境ではGithubでのプルリクエストを中心としたワークフローが非常に効率的であるため、GutenbergのようなプラグインはGithubで別途管理されている。
Githubを利用してコアへのパッチを作成する方法もあるのだが、本稿ではスタンダードなSubversionでのパッチ作成を説明する。
基本的なワークフロー
WordPressに限らず、多くの改善は課題管理から始まる。バグ報告・機能改善などなど、様々な「やるべきこと」がチケットという形で登録される。そのチケットが管理される場所はWordPressの場合tracである。ここに上げられた大量のチケットが、対処すべきリストだ。
このチケットの登録は誰でもできるし、チケットの処遇（重複の解消、却下などなど）は定期的なミーティングなどで決定され、その議論には誰でも参加することができる。このチケットシステムを利用し、コントリビューションは次のようなフローをたどる。
- 解決すべき問題を発見する
- 問題をチケットとして登録する
- チケットを解決するコードをパッチとして登録する
- パッチが十分なものであれば、コアに取り込まれる
パッチを作成する
さて、それではパッチの作成方法について説明しよう。コードの修正方法それ自体は説明しないが、パッチをどのように作るかだけを説明しよう。すでに解決すべき課題としては、「wp-login.phpの1127行目の表現をより丁寧なものに変える」だとしよう。
必要な環境
まず、環境設定である。これがおそろしく長くなってしまうのだが、とりあえず開発用PCにインストールされているべきソフトウェアについてまず説明しよう。
- PHP: WordPressはPHPなので、PHPがインストールされている必要がある。
- MySQL: WordPressで利用しているMySQLもインストールされている必要がある。
- node: ビルドツールとしてGrunt(!)を利用しているので、nodeがインストールされている必要がある。nodebrew, nvmなどの複数のバージョンを使い分けられるバージョン管理ツールを入れる方がよいだろう。
- Subversion: コアのソースをチェックアウトするのに必要。WindowsならTortoise SVNという高機能で無料のGUIツールがあるが、Macの場合はCornerStoneという有償のソフトしかない。
- wp-cli: なくても動くが、本稿ではインストールされていることを前提とする。
筆者は最近のWindows事情についてよく知らないのだが、nodeやMySQLのインストールにあまりにも苦戦する場合は、VirtuablBoxやVagrantなどの仮想環境でWindows上にLinuxを建てた方がうまくいくような気がする。この点は読者からの意見を待ちたい。
また、MampやXamppなどのオールインワン環境を使っても、後述するドキュメントルートの設定さえ柔軟にできるソフトウェアなら、同様にコントリビューションに利用できるはずだ。
開発用WordPressのビルドを行う
まずはWordPressのソースコードをチェックアウトする。これは svn コマンドを利用する。GUIツールを使っている場合も同様だ。
# チェックアウト svn co http://develop.svn.wordpress.org/trunk
なお、WordPressのリポジトリは非常に更新頻度が高いため、コードをいじる間隔が開いていると、該当箇所が様変わりしている可能性もある。そのため、都度リポジトリをチェックアウトするような運用にした方がよいだろう。変更を行う前にまっさらな環境を手に入れるべきだ。
ディレクトリは色々あるのだが、srcフォルダがWordPress本体なのだが、実は普段ダウンロードしているWordPressはこれではなく、buildフォルダに展開されるコンパイル済みのものだ。それではさっそく、コンパイルを行ってみよう。
先ほどチェックアウトした trunk フォルダに移動し、npmで必要なライブラリをインストールする。その後、gruntタスクを実行すると、このコンパイル作業を自動的に行ってくれる。ちなみにnpxというコマンドはnpm付属のもので、npm経由でインストールしたライブラリのコマンドを実行してくれるもの。以前は ./node_modules/.bin/command とやっていたが、いまは npx command でよくなった。 グローバルにインストールする必要もない。
# trunkフォルダに移動 cd trunk # ライブラリをインストール npm install # gruntタスクを実行 npx grunt
コマンドが終了すると、buildフォルダが作成され、中にWordPressが展開されている。それでは、このWordPressを動作するようにしよう。データベースの作成があるのだが、この部分はローカルマシンにMySQLがインストールされていることが前提である。MAMPなどを利用している方は、このパートをスキップするか、MAMPのMySQLを利用するなどして対応してほしい。
# データベースの設定ファイルを作成 wp config create --dbname=wordpress --dbuser=root --dbpass=YOUR_PASSWORD # データベースを作成 wp db create # wp-config.phpファイルを１つ上の改装に移動 mv build/wp-config.php ./ # WordPressをインストール wp core install --url="http://localhost:8080" --title=WP --admin_user=admin --admin_email=admin@example.com --admin_password=admin # wp-cli同梱のWebサーバーを立ち上げ wp server --docroot=build/
これで http://localhost:8080 にアクセスすると、WordPressが動いているのがわかる。
ソースコードへの変更とパッチの作成
さて、実際に確認しているWordPressのフォルダはbuildだが、パッチを作成すべきはsrcである。では、どのようにすればよいのだろうか？ 実はそのためのgruntタスクが用意されている。
# watchタスクを実行。変更があるたびにコンパイルしてくれる。 npx grunt watch
これでファイルをいじるたびにbuildへ反映されるようになる。もしscssなどをいじっているのであれば、こちらも自動でコンパイルされるはずだ。今回はサンプルとして、wp-login.phpの1,127行目にあるメッセージ “Lost your password?” に丁寧な”sir”を付け加えてみよう。そうすると、gruntによって自動でコンパイルされ、見栄えも変わる。
それでは、この差分をパッチとして表示してみよう。利用するのは svn diff コマンドだ。この中身をファイルにして保存すればパッチになる。
# リダイレクトを利用すると、出力されるdiffをファイルとして保存できる。 svn diff > 45171.patch
これでWordrPressに送付するパッチの作成は完了だ。あとはアップロードするだけである。なお、パッチファイル名はチケット番号と同じにすることが求められるので、今回は筆者がのちに紹介するビデオで行ったチケットの番号#45171を採用している。
パッチのアップロード
パッチをアップロードするには、trackのチケット詳細ページに移動し、”Attache File”をクリックすればよい。
アップロードしたあとは、コメントを残す必要がある。それが提案なのか、既存パッチの修正なのか、きちんと意味がわかるようにコメントしよう。コメントを残したら、そのうち取り込まれるはずだ。
なお、このパッチ適用のワークフローはgruntタスクによって簡素化することができるので、ハンドブックに目を通してもらいたい。たとえば npx grunt patch:https://core.trac.wordpress.org/ticket/45171 と書くと、該当するチケットのパッチをローカルに適用することができる。
それでは最後になるが、筆者が実際に環境を構築してパッチを送付するところまでを動画に納めたので、ご覧いただきたい。コントリビューションイベントまであと少しなので、ぜひご覧いただきたい。申し込みはもちろん無料。
コメントを残す