カテゴリー: Development

以下は、2010年4月24日に Jane が書いた WordPress.org 公式ブログの記事、「Coming up on Beta 2: Sprint!」を訳したものです。

WordPress 3.0 の最終バージョンへ一段階近づく2つめのベータ版リリースを来週前半に計画しています。まだ 3.0 マイルストーンには200個以上のバグチケットがあり、これらの問題の修正を手伝ってくれる方はすべて歓迎します。開発者の皆さんは、3.0 のまだ修正が必要なバグをチェックしてみてください。そしてパッチを書くか、他の人のパッチのテストを行いフィードバックをしてください。特に、カスタム投稿タイプやタクソノミー関連では多くの協力が必要です。

ちょっとしたことを手伝ってくれるだけでも助かりますので、今まで貢献した事がないという開発者の皆さんにはこれが良い機会かもしれません！WordPress コアへの協力について読んでから、Trac へ行って修正を手伝える問題がないか見てみましょう。分からないことがあったり、一緒にやってくれる人が必要だったり、修正へのアプローチについてアドバイスが必要だったら、irc.freenode.net の #wordpress-dev 開発チャンネルへどうぞ。週末の間、自分たちでもバグ修正作業に取り組んでいるコア貢献者がいるはずですので、協力してくれる方は躊躇せず質問してみてください。皆さんがヘルプしてくれれば、月曜にはバグの数を半分くらいまで減らせるかもしれません。そうなったらかなりすごいですね。

このバグ修正スプリント（追い込み作業）は月曜の午後くらいまで続きます。その時点で開発リーダーとコア貢献者は一旦手を止め、残っているバグレポートを眺めて週末の進み具合を確認します。ですので、急いでがんばりましょう！ありがとうございます！

以下は、2010年4月13日に Matt が書いた WordPress.org 公式ブログの記事、「Secure File Permissions Matter」を訳したものです。

概要: 適切でないサーバー設定を行っていたホスティングサービスの一部のサーバー上で、他のユーザーの設定ファイルを読み取れるようになっていました。一部の「セキュリティ」記者が、これを「WordPress 脆弱性」のストーリーに仕立て上げようと試みました。

WordPress は 他のあらゆる Web アプリケーションと同じように、データベース接続情報を平文でテキストファイルに保存します。暗号化証明書は意味がありません。なぜなら、データを解読するためには暗号解除用のキーも同じく Web サーバーが読み取れる場所に保存しなくてはならないからです。

今回のケースでおそらくそうだったように、悪意あるユーザーがファイルシステムにアクセスできる場合、キーを取得して暗号化を解読するのは容易なことです。ドアノブに鍵を差したままにするのなら、鍵をかけても意味がありませんよね。

正しく設定された Web サーバーでは、ファイルのパーミッションには関係なく他のユーザーのファイルにアクセスできるようなことはありません。Web サーバーの設定は、ホスティング提供者が責任を持つべきことです。これを行う方法（suexec など）は、5年以上前から存在しています。

ここでは問題となる記事にリンクはしません。あまりにも事実と異なる情報だらけで、読めば読むほどバカげているからです。

Web ホスティングサービスを運営している側が、不正なファイルパーミッションの問題を WordPress のせいにするというのは、明らかに間違ったやりかたです。

P.S. Network Solutions さん、「Word Press」ではなくて、正しくは「WordPress」ですよ。

以下は、2010年2月23日に Jane が書いた WordPress.org 公式ブログの記事、「Menus, the Merge, and a Patch Sprint!」を訳したものです。本文内のリンク先はすべて英語ページです。

3.0 開発サイクルからのレポート

メニュー

WooThemes カスタムナビゲーションを WordPress コアに入れる件についてたくさんブログが書かれていますので、公式に告知するべき時期だと思っています。私たちは、バージョン 3.0 のユーザー向けのメイン機能として、サイトのナビゲーションメニュー管理システムの改善を含めたいと考えました。

現在、メニューの取り扱いはとても面倒です。固定ページ ID を使ったり、テーマによってはカテゴリーを使ったりする必要があります。私たちはメニューシステムに、ウィジェット管理画面のように簡単なドラッグ＆ドロップ機能があればいいなと思いました。さらに、固定ページ・カテゴリー・リンクをメニューに含めることができて、並べ替えやサブメニューも利用でき、特定のページやカテゴリーをメニューから除外しやすくできればというように考えました。

私たちがこの機能について話しあっている頃、WooThemes がカスタムナビゲーションシステムの告知をしました。彼らのサイトの紹介動画を見ていたら、このシステムがコアに求めていることをほとんどカバーしていることに気づきました。そこで、WooThemes の制作者にコアへの貢献をしてくれないかと連絡しました。

もう耳にしたかもしれませんが、これはうまくいって、最初のパッチが投稿されました。まだコードの編集が少し必要ですが、これは現在実装中です。Woo のメニューをコアに導入するという決断は、もともと計画していた 3.0 の機能フリーズ期限の直前に起こりました。そこで、この追加を可能にするため期限を2週間先に延ばすことにしたのです。現時点では、3.0 のリリースは5月前半を予定しています。2週間延びたぶんだけの価値はあると思っています。

個人的に、この件がうまくいったことについてとても嬉しく思っています。なぜなら、これは商用テーマやプラグイン作者がコアに貢献することによってお互いにメリットがあるということの証明となるからです。コアへの導入により、さらに多くの人が基本的な機能のコードへの貢献や改善を行うことができるようになりました。WooThemes はその成果を利用し、商用テーマのお客さんのために引き続きイノベーションを行えます。WooThemes にとっては非常に大きな自慢の種になりますし (これで、もっと多くの利用者を獲得できることは間違いないでしょう)、コア開発者は車輪の再生産を行うことなく、よくできたメニューシステムを取り入れられます。そして、世界中の WordPress ユーザーはみんなその恩恵を受けられます。他のプラグインやテーマ開発者もこういった Woo の行動をきっかけに、コア開発を競争の場ではなくコラボレーションの場として見てくれるようになればと願っています。

MU 統合

昨年の WordCamp サンフランシスコで告知された通り、WordPress と WordPress MU のコードベースが統合される予定です。これは 3.0-alpha バージョンですでに実装されており、現在バグ修正や画面の整理を行っています。

現在シングルインストール版の WordPress を使っている場合、バージョン 3.0 へのアップグレードを行っても複数サイトのネットワークを運営するための新しい画面が表示されることはありません。WordPress MU を使っている場合、アップグレード後には一部のインターフェースのラベルが変わったことに気づくかもしれませんが、アップグレードは通常通り、大変ではないはずです。もし新規に WordPress をインストールする場合は、設定時に一つのサイトを作るか複数のサイトができるようにするか選択するだけなので、とてもシンプルです。シングルインストール版を複数サイト対応版に変更したい場合は、そのためのツールを用意します。

ということで、統合について不安だった方はカモミールティーでも飲んでリラックスしてくださいね。ご心配なく、大丈夫です。

パッチスプリント！

では、これからは？新しい機能フリーズの期限は、2010年3月1日 (月) です。つまり、この日以降は改善項目や機能を新しく追加することはありません。そして、気持ちを切り替えてバグをつぶし、すでにコアにある機能を修正することだけに集中していきたいと思います。

これが何を意味しているかというと、3.0 マイルストーンの Trac チケットでパッチやパッチのテストが必要なものをできるだけ早くクローズするにはそれまでしか時間がないということです。みなさんの協力をお待ちしています！これから UTC (協定世界時) 3月1日午後5時 (日本時間3月2日午前2時) までに、Trac へ行って手を貸してください。もしわからないことがあったら、irc.freenode.net の #wordpress-dev コア開発チャンネルに入れば、他のフレンドリーなコア貢献者が答えてくれるかもしれません。

以下は、2009年12月25日に書かれた WordPress.org 公式ブログの記事、「Setting Scope」を訳したものです。リンク先は英語ページです。

先日行ったコアコミッターのミーティングで話し合った話題の一つに、リリース要件定義（およびその変更、「スコープクリープ」）がありました。現在 WordPress は 2.9 のリリースが済んで、3.0 について考え始める時期に入っています。そこで、一気に取りかかる代わりにここで立ち止まって一息つき、事前計画を立てるのが良いのではないかと思っています。今までの場合、各リリースサイクルの間にいくつか新機能を含める選択をした後も、機能フリーズ（またはベータサイクル）の直前まで機能リクエスト、改善用パッチ、継続的なバグリポートが投稿され続けていました。これにより各リリースを計画よりも遅く公開することになり、あまりにもたくさんのことが起こっているため、新しいバグをとらえるのがどんどん難しくなってしまっていました。

このようにフリーズぎりぎりまで色々と追加していく形態は、うまく機能しているとは言えません。メイン機能以外に色々と変更を加えたり、変更をすべてテストする必要があることで、ゴミ箱や画像編集などの新機能が導入されるまでに何ヶ月も余分に待つことになってしまいました。もしリリースごとに含める機能を少なくすれば、新機能をもっとすばやく取り入られるようになるはずです（ゴールは年3回のリリースです）。また、より集中的なベータテストを行うことでリリースをさらに完全なものにできるはずです。

これは簡単なことではありません。皆さんそれぞれお気に入りの機能や修正して欲しいバグがありますし、パッチがあるなら次のリリースを待つよりも今回含めてしまえばいいのに、という考えもあるからです。しかし「パッチが数週間や数ヶ月もコミットされないままだ」という不満を聞くことはあっても、「パッチが新規のバグを引き起こすこともある」という声は耳にしません。また、同時にいくつものパッチを追加することで、様々なプラットフォームの異なるホスティング環境などでのテストを完全に行うのがより難しくなっていきます。そこで、この問題に対する私たちの提案は以下の通りです。

プロジェクトマネジメント界の先例に従い、開発サイクルをスタートする前にプロジェクト計画を立てます。皆さんに機能や改善点を提案してもらい、限定したものを 3.0 に含めます（今回は特に厳しい制限が必要になります。WordPress と WordPress MU の統合は、それだけでかなりの作業量になるからです）。その後、現実的なリリース日を設定し、それまでに必ずリリースを行います。今後2つのリリースに対して暫定的な機能セットを決定し、次回のサイクルの最初に再度評価することで、現在次バージョン以外のチケットすべてにつけている曖昧な「future release（将来のリリース）」ラベルとは異なり、コミュニティとして特定の機能にコミットしていることが皆さんに分かるようになります。

また、ごく一部のケースで発生するバグや、説明不十分だったり再現できないバグにフォーカスする前に、再現性があり多くのユーザーに影響があるバグを修正します。誰かがごねて別の方向性を示したからからといって、みんなで合意したゴールから注意をそらすようなことがないようにします。もちろん、不意に予想しない事態が発生することもあるでしょう。しかし、次回のリリースに予定していなかった変更を滑り込ませないように、私たちはもっと努力しなくてはなりません（もちろん、私自身にも罪はあります… ユーザーエクスペリエンスに関わる一人として、すべてを一度に改善できればいいのにといつも思ってしまうんです！）。

オープンソースプロジェクトとしては、みんながそれぞれ独自の方針に従うよりも、一緒に動いた方がたくさんのことを成し遂げることができます。私たちは一般的かつ合意済みのゴールにフォーカスした状態を保ち、コミュニティのメンバーがプロジェクトを関係ない方向へ誘導していくことを避けなくてはなりません。その方向が、誰もが好むすばらしいアイディアであろうと、個人的な方針に基づいた提案であろうと関係ありません。また、よく状況を知らない新米ユーザーによる意見か、説得力があって声高な貢献者やコミッターからの意見かというのも関係ないのです。問題は、ゴールへのフォーカスを保つのが簡単ではないということです。だからこそ、脱線せずに前に進んでいくことができるシステムを構築していく必要があります。例えば Trac で現在の開発サイクルで確定した機能やバグリポート以外のチケットを除外し、新機能や提案は他のマイルストーンに切り分けるといったことです。

私たちは、こういったこと試すだけの価値はあると思っています。2010年に IRC の開発チャットを再開する際、最初に話し合うのは 3.0 の要件定義です。含める内容についてだいたいの合意が得られたら、適切な Trac チケットを作成し、3.0 向けではない機能リクエスト/改善についてのチケットは将来のリリースへ回します。こうすることで、3.0 の開発に集中できます。現在のマイルストーンに対するバグリポートは引き続き投稿されるはずなので、簡単ではありません。コアに含めたいと思っていながら過去に何度も先延ばしにした機能が最低でも10数個はありますが、今回の試みのためには「プラグインで実現できる」というふうに考え、コアに含めるものは最低限に抑えるよう努力したいと思います。

バージョン 3.0 にリクエストしたい機能を、フォーラムでどうぞ話し合ってください。