diff --git a/core/contribute/design-decisions.md b/core/contribute/design-decisions.md index c7b2f46..43e605b 100644 --- a/core/contribute/design-decisions.md +++ b/core/contribute/design-decisions.md @@ -1,53 +1,131 @@ + +# 設計上の決定事項 + + + +このページでは、頻繁に登場する重要な設計上の決定をリストアップし、その理由を説明したり、相互参照したりすることを意図しています。 + +## 絶対 URL と相対 URL + + + +WordPressは絶対 URL をデータベースに保存します。相対 URL は、さまざまな理由から使用されません。動的に生成されるサイトには永続的な URL (パーマリンク) が必要ですので、絶対 URI の方が理にかなっています。WordPress には、サイトドメインやプラグイン、テーマの各種フォルダーを呼び出す[様々な機能](https://codex.wordpress.org/Function_Reference/site_url#Related)があるので、相対 URL は必要ありません。ドメインを移動する場合、データベース内のドメインを切り替えるための検索・置換ツールがあります。 + +### 相対 URL はなぜ良くないのか + + + +コンテンツは移動するものです。つまり、データベース内にあるコンテンツは、必ずしも「あなたのサイト」のコンテキスト内で表示されるとは限らないということです。コンテンツは、さまざまな場所で表示できます。たとえば、コンテンツの RSS フィードを Google リーダーに取り込み、そこに表示させることができます。あるいは、ユーザーが自分のフィードリーダーを使用できますし、マイクロフォーマットを使ってあなたのサイトから引き出され、どこか別の場所に表示されることもあります。ユーザーは、コンテンツがどこにあるのかを知ることはありません。したがって、コンテンツがどこに表示されるかにかかわらず、常に特定のポイントを指していることを保証するために、そのコンテンツ内では絶対 URL が必要です。 + +パーマリンクは変更可能です。ある記事のコンテンツは、`http://example.com/`、`http://example.com/archive/`、`http://example.com/2012/01/single-post` などで表示できます。相対 URL は、「ルート相対」、つまりサイトのルートを参照するために スラッシュ文字で始まるものでなければ有効ではありません。その場合でも、サイトがあるサブディレクトリから別のサブディレクトリに移動した場合は、ルート相対 URL を変更する必要があり、それに合わせてデータベースのコンテンツを変更する必要があります。 + + + +移動は絶対 URL の方が簡単です。たとえば、あるユーザーが `http://foo.com` から `http://bar.com` に移動するとします。データベースで `"http://foo.com"` を検索して置き換えるのはとても簡単で、問題になることはまずありません。このような場合、ルート相対 URL はまったく変更する必要がないと言われるかもしれませんし、これは事実です。しかし、コンテンツを `http://foo.com/dev/` から `http://bar.com` に移動させる必要がある場合はどうでしょうか。このような場合にもルート相対 URL は変更する必要があり、検索と置換を行うための `"http://foo.com/dev/"` のような簡単に見つけることができる文字列は存在しません。 + +また投稿の内容自体も、絶対 URL の方が管理しやすいでしょう。 + + + +もし WordPress がこのすべてをやり直すことができるのであれば、[私たちは相対 URL を選んだかもしれない](https://core.trac.wordpress.org/ticket/17048#comment:46)と提案されています。これは事実であり、現在のアプローチを調整すること、あるいは全体を見直すことは、将来的にはっきりとした可能性として残されています。[#17048](https://core.trac.wordpress.org/ticket/17048)を参照してください。 + +## HTTPS や IP アドレスの転送ヘッダーをサポートしない + + + +多くのロードバランサーやプロキシサーバーは、HTTPS や IP アドレスなどのために HTTP ヘッダーを転送します。これらは通常、リモート IP アドレスについては HTTP_X_FORWARDED_FOR (X-Forwarded-For)、HTTPS プロトコルでトラフィックが移動しているかどうかについては HTTP_X_FORWARDED_PROTO (X-Forwarded-Proto) という形式になっています。場合によっては、サーバーポートのような他の情報も転送する必要があります。 + + +WordPress がこれらのヘッダーをやみくもに参照すると、特にプロトコルの場合に無限リダイレクトや一般的な破損が発生するリスクがあります。さらに悪いことに、これらは正式な標準ではなく、むしろ自由な形式なのです。その結果、多くの Web サーバーや構成はこれを異なる方法で行います。たとえばある構成では、「HTTP_」を先頭につけて、HTTP_HTTPS となることがあります。代わりに行われるべきことは、サーバーが適切にマッピングされたヘッダーを PHP に渡すか、あるいは `wp-config.php` でマッピングを行うコードが書かれるかです。たとえば、以下のようになります。 ```php if ( - isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && - 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] + isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && + 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) { $_SERVER['HTTPS'] = 'on'; } ``` + + +こちらも参照してください。[#9235](https://core.trac.wordpress.org/ticket/9235)、[#15009](https://core.trac.wordpress.org/ticket/15009)、[#15733](https://core.trac.wordpress.org/ticket/15733)、[#19337](https://core.trac.wordpress.org/ticket/19337)、[#24394](https://core.trac.wordpress.org/ticket/24394)など。 + +## 新しい oEmbed プロバイダの追加 + + + +コアの oEmbed プロバイダには、一定の基準があります。既存の許可リストに新しいものを追加するためには、これらが必要です。 + +* 確立されており、人気がある、主流のサービスであること、 +* [oEmbed の仕様](http://oembed.com/)を適切かつ完全に実装していること、 +* そして、明らかに信頼できるプロバイダであること。 + + + +oEmbed はフィルタリングされていない未加工の HTML を扱うため、セキュリティが重要です。これは、任意の JavaScript やオブジェクトを埋め込むことができるため、本質的に危険です。従って、プロバイダが信頼できることが最も重要です。しかし、信頼とはセキュリティだけではありません。サービスは「永続的に使える」ものでなければなりません。もしプロバイダが oEmbed のサポートを停止した場合、サイトは、以前は永久に埋め込まれていると信じてられていたコンテンツを失い始めます。あるいは、消滅したスタートアップのドメインが期限切れとなったり買収されたりすると、マルウェアの格好の餌食となる可能性もあります。新興のサービスは、コアに追加するにはあまりにも脆弱なのです。 + -* Is the service is popular enough for core developers to have heard of it before? Is it “mainstream?” +定着度や人気度については、次のようなにいろいろと考えられます。 + + + +* コア開発者が聞いたことがあるような人気のあるサービスですか ?「主流」ですか ? +* 同様のサービスがすでにサポートされている場合、このサービスは規模、機能、支持者の面ではどのように比較されますか ? +* このサービスは、Twitter や Facebook などのソーシャルメディアで多くのフォロワーを抱えていますか ? Twitter のアカウントは認証されていますか ? +* その oEmbed エンドポイントは明確に確立され、適切に文書化されていますか ? (時には、開発者の趣味であるプロジェクトに過ぎず、サポートされていない場合もあります)。 +* oEmbed エンドポイントは、WordPress の oEmbed 自動検出で機能しますか ? そうでない場合、HTML タグや属性を許可リストに追加して動作させることは可能ですか ? +* APIを充実させるなど、開発者との関係作りに力を入れていますか ? +* サービスはいつ開始しましたか ? +* ウィキペディアの記事が定着していますか ? (これは真面目な話です。) +* oEmbed プロバイダとして追加したり、ショートコードを作成したり、サービスの他の API を利用したりと、何らかの方法でサービスを活用する WordPress プラグインを作った人はいますか ? これらのプラグインは、使用状況や需要を示すような注目すべき採用実績や活発さがありますか ? +* そのプロバイダは頻繁に提案されていますか ? + + +個別に見れば、これらはすべて裏付けが乏しいものかもしれません。しかし総合的に考えると、理にかなっているでしょう。 + + + +## 編集者、管理者向けのフィルタリングされていない HTML とマルチサイト + +管理者または編集者権限を持つユーザーは、投稿タイトル、投稿コンテンツ、およびコメントにフィルタリングされていない HTML を公開することが許可されています。WordPress は、結局のところパブリッシングツールであり、人々はコミュニケーションに必要なあらゆるマークアップを含めることができるようにする必要があります。より低い権限を持つユーザーは、フィルタリングされていないコンテンツを投稿できません。 + + + +WordPress に対してセキュリティテストを行う場合は、より低い権限のユーザーを使用して、すべてのコンテンツがフィルタリングされるようにしてください。セキュリティに関する問題は、security@wordpress.org に報告できます。詳しくは、[セキュリティ脆弱性の報告](https://make.wordpress.org/core/handbook/reporting-security-vulnerabilities/) をご覧ください。 + +管理者がコンテンツに XSS を入れたり、Cookie を盗んだりすることを心配するかもしれませんが、すべての Cookie は HTTP のみの配信にマークされており、管理者ページで使われる特権的な Cookie と一般向けのページで使われるより低い特権的な Cookie に分けられていることに注意してください。管理画面では、コンテンツがフィルタリングされずに表示されることはありません。とはいえ、管理者には幅広い権限があり、フィルタリングされていない HTML はそのうちの一つです。 + + + +WordPress のマルチサイトでは、特権管理者のみがフィルタリングされていない HTML を公開ができ、それ以外のユーザーは信頼されていないとみなされます。 + +管理者や特権管理者を含むすべてのユーザーに対してフィルタリングされていない HTML を無効にするには、`wp-config.php` に `define( 'DISALLOW_UNFILTERED_HTML', true );` を追加してください。 + + + +## アップグレード時にサポートされるのはオーナー書き込み可能なもののみで、グループ書き込み可能なものはサポートされません + +[#10205](https://core.trac.wordpress.org/ticket/10205)を参照してください。 + + + +## 一部の複雑な MySQL 設定はサポ―トしていません + + -WordPress does not support MySQL strict mode or autocommit = 0. [#8857](https://core.trac.wordpress.org/ticket/8857), [#16821](https://core.trac.wordpress.org/ticket/16821), [#16429](https://core.trac.wordpress.org/ticket/16429). \ No newline at end of file +WordPressは、MySQL の strict モードや autocommit = 0 をサポートしていません。[#8857](https://core.trac.wordpress.org/ticket/8857)、[#16821](https://core.trac.wordpress.org/ticket/16821)、[#16429](https://core.trac.wordpress.org/ticket/16429)。