WordPress.org

日本語

WordPress を入手
WordPress.org

Japanese Team

一般的な課題

一般的な課題

この投稿内

↑ ページの先頭へ戻る

これはプラグイン・レビューチームがプラグインをレビューする際に遭遇する、最も一般的な課題の集録です。

このリストは、チームの E メールメッセージからの抜粋であり、完全または網羅的なリストとみなしてはいけません; レビューの結果は、チームによる手動レビューに依存します。

セキュリティ

サニタイズ

入力データは、サニタイズ、バリデーション、および出力時にエスケープしなければなりません

POST/GET/REQUEST/FILE 呼び出しをプラグインに搭載する場合、それらをサニタイズ、検証、エスケープすることが重要です。ここでの目的は、ユーザーが誤ってシステムを通しての不要なデータを送信するのを防ぐことと、潜在的なセキュリティの課題からユーザーを守ることです。

SANITIZE: (ユーザーによって、あるいは自動的に) 入力されたデータは、できるだけ早くサニタイズされなければなりません。これにより、XSS 脆弱性や、投稿されたデータが改竄される MITM 攻撃の可能性を減らすことができます。

VALIDATE: すべてのデータは、何があっても、検証される必要があります。サニタイズする場合でも、有効な値が数字だけなのに、誰かが「dog」と入力しないようにすることを忘れないでください。

ESCAPE: 出力するデータは echo する際に適切にエスケープして管理画面の乗っ取りを防がなければなりません。間違ったデータを表示しないために利用できる、多くの esc_*() 関数があります。

そのために、WordPress には多くのサニタイズ機能とエスケープ機能が用意されています。これらについては、こちらをご覧ください:

https://developer.wordpress.org/apis/security/sanitizing/ https://developer.wordpress.org/apis/security/escaping/

覚えておいてください: コンテキストに最も適した関数を使う必要があります。電子メールをサニタイズするなら sanitize_email() を、HTML を出力するなら wp_kses_post() を、といった感じです。

簡単な真言は、以下の通りです:

早めにサニタイズ 遅れてエスケープ
常にバリデート

すべてをクリーニングし、すべてをチェックし、すべてをエスケープし、そして、ユーザーが常に適切なデータを入力していると信じてはいけません。結局のところ、ユーザーにはいろいろな人がいるものですから。

サニタイズ: エスケープ関数とサニタイズ関数に関する混乱

メモ: エスケープ関数は、サニタイズには利用できません。これらには異なる目的があります。たとえエスケープ関数がサニタイズの目的に完璧であるように見えても、ほとんどのエスケープ関数はフィルターで変更可能であり、エスケープのための使用が期待されています。別のプラグインが自身のために悪意なくエスケープ関数を変更することで、あなたのプラグインが危険にさらされ、悪用される可能性があります。

変数を echo しようとする場合は、まず変数をサニタイズしてからエスケープしなければなりません。たとえば:

echo esc_html(sanitize_text_field($_POST['example']));

サニタイズ: フィルター関数を使ったサニタイズ

メモ: filter_var、filter_var_array、filter_input および/または filter_input_array のような関数を使用する場合は、入力をサニタイズする任意の種類のフィルタに、パラメータ FILTER を設定する必要があります。

パラメータ filter を空にすると、PHP はデフォルトでフィルター「FILTER_DEFAULT」を適用し、これはまったくサニタイズされていません。

$post_id = filter_input(INPUT_GET, 'post_id', FILTER_SANITIZE_NUMBER_INT);

サニタイズ: nonce

メモ: wp_verify_nonce を使用して nonce をチェックする際には、wp_unslash と sanitize_text_field を使用して入力をサニタイズする必要があります。なぜなら、この関数は差し替え可能であり、エクステンダーはその入力値を信用すべきではないからです。

例:

if ( ! isset( $_POST['prefix_nonce'] ) || ! wp_verify_nonce( sanitize_text_field( wp_unslash ( $_POST['prefix_nonce'] ) ) , 'prefix_nonce' ) )

入力全体の処理

$_POST/$_REQUEST/$_GET スタック全体を処理することを 決して 試みないことを、私たちは強く推奨します。これは、必要のないデータを無駄に循環させることになり、プラグインを遅くします。その代わりに、プラグインが機能するために必要な項目だけを処理するようにしましょう。

エスケープ

変数とオプションは、echo する際にエスケープしなければなりません

すべてのサニタイズに関連しますが、ユーザーや (さらに最悪) 管理画面をハイジャックされないよう、echo する変数はすべて、echo する際にエスケープしてください。間違ったデータを人に見せないようにするために使える esc_*() 関数はたくさんありますし、HTML を安全に echo できるものもあります。

このとき、echo する際、すべての$変数、オプション、生成されたあらゆる種類のデータ をエスケープしてください。つまり、変数を構築するときにエスケープするのではなく、最後に出力するときにエスケープしてください。これを「遅れてエスケープする」と表現します。

XSS 脆弱性の可能性から身を守るだけでなく、遅れてエスケープすることで、将来のあなたの安全を確保できます。現在、あなたのコードはハードコードした内容しか出力しないかもしれませんが、将来はそうでなくなるかもしれません。echo する 際に 適切なタイミングでエスケープすることで、重大なセキュリティ課題になる将来のミスを防ぐことができます。

これは、データベースに保存したオプションについても同様です。保存時に適切にサニタイズした場合でも、サニタイズとエスケープのツールは互換性がありません。サニタイズは、処理とデータベースへの格納が安全であることを確認します。エスケープは、出力する際の安全性を確保します。

また、本当はコンテンツを返すべきなのに、関数が echo していることもあることを覚えておいてほしい。これは、JSON エンコードされたコンテンツを返す際によくある間違いです。実際に echo すべき内容であることはほとんどありません。echo するのは、それが画面上に表示され、人間が読む必要があるからです。(API で行うような) 返却は、json エンコードできますが、json オブジェクトに保存する際には、サニタイズ することを忘れずに !

あらゆるタイプのコンテンツ (html、e-mail など) をセキュアにするためのオプションはいくつもあります。そう、HTML でさえも適切にエスケープする必要があるのです。

https://developer.wordpress.org/apis/security/escaping/

覚えておいてください: その文脈に最も適した関数を使う必要があります。echo できるものすべてに最適なオプションがあります。HTML を安全に echo することさえも。

エスケープ: esc_url_raw の使用

まぎらわしいとは思いますが、esc_url_raw 関数はエスケープ関数ではなく、sanitize_url と同様のサニタイズ関数です。具体的には、データベースやリダイレクトで使用する URL をサニタイズするために使用されます。

URL をエスケープする適切な関数は、esc_url です。

エスケープ: __ の使用

関数 __ は、エスケープせずに翻訳を取得します。以下のどちらかを使用してください:

  • esc_html__ や esc_attr__ のように、結果の値をエスケープする代替関数を使用する。
  • または、__ 関数を esc_html、esc_attr、wp_kses_post などの、適切なエスケープ関数でラップする。

例:

<h2><?php echo esc_html__('Settings page', 'plugin-slug'); ?></h2>
<h2><?php echo esc_html(__('Settings page', 'plugin-slug')); ?></h2>

エスケープ: _e および _ex の使用

関数 _e と _ex は、エスケープせずに翻訳を出力します。出力をエスケープする代替関数を使用してください。

  • _e の代替としては、esc_html_e、esc_attr_e、あるいは単に、エスケープ関数でラップして echo の中に記述する __ を使うこともできる。
  • _ex の代替としては、エスケープ関数でラップして、echo の中に記述する _x を使うこともできる。

例:

<h2><?php esc_html_e('Settings page', 'plugin-slug'); ?></h2>
<h2><?php echo esc_html(__('Settings page', 'plugin-slug')); ?></h2>
<h2><?php echo esc_html(_x('Settings page', 'Settings page title', 'plugin-slug')); ?></h2>

エスケープ: json_encode の使用

JSON を echo する必要がある場合は、関数 wp_json_encode を使用するほうが良いでしょう。また、第2パラメータに渡されるオプションでエスケープを回避していないか確認してください。

echo wp_json_encode($array_or_object);

エスケープ: HTML

エスケープする際、プラグインが HTML を出力する必要がある場合があります。これには、wp_kses_post または wp_kses 関数を使います。wp_kses_post 関数は、投稿コンテンツの中に入れる一般的な HTML を許可します。wp_kses は、2番目と3番目のパラメータを使って設定した HTML を許可します。ドキュメントを参照してください。

よくある間違いは、esc_html を使って HTML をエスケープすることです。この関数はそのためのものではありません。この関数は、HTML タグ 内部 に入る出力をエスケープするためのものであり、したがって HTML タグは、すべて取り除かれることになります。

例:

echo wp_kses_post($html_content);
echo wp_kses($html_content, array( 'a', 'div', 'span' ));

エスケープ: サニタイジング関数の使用

サニタイズ関数は、エスケープには利用できません。これらには異なる目的があります。たとえサニタイズ関数がエスケープの目的に完璧であるように見えても、ほとんどのサニタイズ関数はフィルターで変更可能であり、サニタイズのための使用が期待されています。別のプラグインが自身のために悪意なくサニタイズ関数を変更することで、あなたのプラグインが危険にさらされ、悪用される可能性があります。

変数を echo しようとする場合は、まず変数をサニタイズしてからエスケープしなければなりません。たとえば:

echo esc_html(sanitize_text_field($_POST['example']));

ファイル

ファイル: WordPress ファイル・アップローダーの使用

WordPress ファイル・アップローダーをご利用ください

プラグインで move_uploaded_file() を使用すると、アップロードは組込みチェック機能や、WordPress 関数とのバランスが取られません。代わりに、組み込み関数を使用してください:

https://developer.wordpress.org/reference/functions/wp_handle_upload/

ファイル: フィルタリングされていないアップロード

ALLOW_UNFILTERED_UPLOADS は、許可されていません。

この定数を true に設定すると、ユーザーは (PHP やその他の実行可能ファイルを含む) あらゆるタイプのファイルをアップロードできるようになり、深刻な潜在的なセキュリティリスクが発生します。開発者としては、この定数をいかなるロジックでも、条件付きでも使用したり 許可したりすべきではありません。

WordPress には、関数 wp_get_mime_types で見ることができるように、安全なファイルのリストが含まれています。

リストにない特定のファイルを追加する必要があり、セキュリティのリスクがない場合は、フィルター upload_mimes を使用して追加できます。

ファイル: リモートでファイルを呼び出す

画像、js、css、その他のスクリプトをあなたのサーバーやリモートサービス (Google、MaxCDN、jQuery.com など) にオフロードすることは禁止されています。リモートのデータを呼び出すと、他のサイトへの不必要な依存が生じます。呼び出しているファイルが WordPress コアの一部でない場合は、リモートではなく -ローカルで- プラグインに含める必要があります。そのファイルが WordPress コアに含まれているなら、代わりにそれを呼び出してください。

このルールの例外は、プラグインがサービスを提供している場合です。この場合、ケースバイケースで許可します。混乱しやすいので、許可されない例をいくつか挙げておきます:

  • jquery の CSS ファイルを Google にオフロード – プラグインに CSS を含める必要があります。
  • iframe にヘルプドキュメントを挿入 – リンクを貼るか、プラグインにドキュメントを含めるのが望ましいでしょう。
  • 独自ドメインから画像の呼び出し – プラグインに含める必要があります。

以下に、許可する例をいくつか挙げておきます:

  • (GPL 互換の場合) Google またはその承認された CDN からフォントファミリーの呼び出し
  • (Akismet のように) スパムコメントを処理するため、あなたのサーバーに API がコールバック
  • (Disqus のように) 独自サーバーにコメントをオフロード
  • (Twitter や YouTube のように) サービスプロバイダへの oEmbed 呼び出し

プラグインから外部の依存関係を削除し、可能であれば、プラグイン内に (リモートから呼び出されない) すべてのファイルを搭載してください。代わりにサービスを提供していると思われる場合は、readme.txt を書き直し、サービス、呼び出されるサーバー、接続に必要なアカウントについて説明してください。

ライブラリ

ライブラリ: 開発版の使用

ライブラリのベータ版/アルファ版/開発版の使用

あなたのプラグインに必要な機能がない限り、ライブラリのベータ版を使用することはおすすめしません。代わりに、そのライブラリの最も安定したリリースを使うべきです。

技術的な理由でベータ版を使用しなければならない場合は、その理由を説明してください。そうでなければ、あなたのライブラリを安定版リリースに変更してください。

ライブラリ: メンテナンスされていない

メンテナンスが行われなくなったライブラリは、許可されません

開発者によるサポートやメンテナンスが終了したライブラリの使用は、重大なセキュリティリスクをもたらすため、我々は受け付けておりません。他の選択肢をご検討ください。

ライブラリ: 期限切れ

サードパーティ・ライブラリが期限切れの場合は、より良いサポートとセキュリティのために、最新の安定版にアップグレードしてください。ベータリリースの使用は、おすすめしません。

WPDB: 安全でない SQL 呼び出し

データベースを呼び出す際には、SQL インジェクションの脆弱性からコードを保護することが非常に重要です。wpdb 呼び出しを使用するようにコードを更新し、クエリーで prepare() を使用して保護する必要があります。

以下をご確認ください:

WPDB: プレースホルダーの配列

メモ: プレースホルダを使用して wpdb::prepare に個々の値を渡すのは非常に簡単ですが、値の配列を渡す必要がある場合はどうするのでしょうか ?

配列の各項目にプレースホルダーを作成し、対応するすべての値をそのプレースホルダーに渡す必要があります。これはトリッキーに見えますが、ここにそのためのスニペットがあります。

$wordcamp_id_placeholders = implode( ', ', array_fill( 0, count( $wordcamp_ids ), '%d' ) );
$prepare_values = array_merge( array( $new_status ), $wordcamp_ids );
$wpdb->query( $wpdb->prepare( "
    UPDATE `$table_name`
    SET `post_status` = %s
    WHERE ID IN ( $wordcamp_id_placeholders )",
    $prepare_values
) );

将来的にこれを容易にするコアチケットがあります: https://core.trac.wordpress.org/ticket/54042

HEREDOC-NOWDOC の不使用

プラグインで HEREDOC または NOWDOC 構文を使用しないでください

どちらもまったく有効であり、コンテンツを出力するための PHP の機能としては、多くの点で望ましいものですが、ほとんどのプラグインにとって高すぎるコストを伴います。

主な課題は、HEREDOC や NOWDOC を使用した場合、ほとんどの (すべてではないにせよ) codesniffer がコード内のエスケープの欠如を検出しないことです。これを回避する方法はありますが、せっかくの可読性を台なしにする、正しくスキャンできないゴチャゴチャしたものに、最終的になってしまいます。

私たちは、このリスクはメリットよりもはるかに高いと考え、使用を許可していません。

直接ファイル・アクセス

プラグインファイルへの直接ファイル・アクセスの許可

ファイルへの直接アクセスは、誰かが直接 PHP ファイルに問い合わせることで発生します。これは、ブラウザーの URL バーにファイルへの完全なパスを入力するか、ファイルに直接 POST リクエストを送信することで行います。

クラスや関数の定義のみを含むファイルについては、直接アクセスした場合に何かおかしなことが起こる危険性はほとんどありません。しかし、実行可能なコード (関数コール、クラスインスタンスの生成、クラスメソッドのコール、他の PHP ファイルのインクルード、等) を含むファイルについては、セキュリティの問題が発生するリスクは特定のケースに依存するため、予測が困難ですが、それは存在する可能性があり、高くなる可能性もあります。

直接アクセスするとコードを実行する可能性のあるすべての PHP ファイルの先頭に、以下のコードを記述することで、簡単にこれを回避できます:

if ( ! defined( 'ABSPATH' ) ) exit; // Exit if accessed directly

互換性

接頭辞

一般的な関数名/クラス名/定義名/名前空間名/オプション名

すべてのプラグインは、固有の関数名、名前空間、定義、クラス名、オプション名を持つ必要があります。これはプラグインが他のプラグインやテーマと衝突するのを防ぐためです。よりユニークで明確な名前を使用するようにプラグインを更新する必要があります。

これを行う良い方法は、接頭辞を使うことです。たとえば、あなたのプラグインが「Easy Custom Post Types」という名前なら、以下のような名前を使うことができます:

  • function ecpt_save_post()
  • class ECPT_Admin{}
  • namespace ECPT;
  • update_option( 'ecpt_settings', $settings );
  • define( 'ECPT_LICENSE', true );
  • global $ecpt_options;

2文字や3文字の接頭辞を、使用しようと思わないでください。私たちは WordPress.org だけで10万近いプラグインをホストしています。私たちのサーバーの外には、さらに何万ものプラグインがあります。WordPress.org だけを見ていると、あなたは衝突することになるでしょう。

また、接頭辞として、__ (ダブル・アンダースコア)、wp_、_ (シングル・アンダースコア) の使用も避ける必要があります。これらは WordPress 自身のために予約されています。クラスの中で使うことはできますが、独立した関数として使うことはできません。

翻訳のために _n() や __() を使っているのであれば、それはそれでかまわないので、覚えておいてください。WordPress のコア機能ではなく、プラグイン用に作成した機能について だけ 話しています。実際、そのようなコア機能があるからこそ、独自のプラグインではそのような接頭辞を使わないようにする必要があるのです ! ユーザーのために WordPress を壊したくはないでしょう。

これに関連して、すべての関数やクラスで if (!function_exists('NAME')) { を使うのは、致命的な欠点に気付くまでは、すばらしいアイデアのように聞こえます。もし他が同じ名前の関数を持っていて、そのコードが先にロードされると、あなたのプラグインは壊れてしまいます。if-exists を使うのは、共有ライブラリだけにしましょう。

覚えておいてください: 良い接頭辞名は、あなたのプラグインに固有のものです。これは、あなたや次の人のデバッグに役立ちますし、競合を防ぐこともできます。

PHP

PHP: ショートタグを使用しない

PHP のショートタグの主な課題は、PHP が他の構文 (つまり、XML) で使われているタグ (<?) を選んでしまったことです。これは、XML の解析や管理がいかに一般的であるかを考えると大きな課題です。

PHP 5.4では、ショートタグの設定にかかわらず、<?= ... ?> タグがサポートされています。これは、移植可能なコード内で使用しても安全であることを意味するはずですが、現実にはそうではないことが証明されています。さらに、多くの codesniffer は、ショートタグを使用している場合、コード内のエスケープの欠如を検出しないという事実も加わり、誰にとっても頭痛の種になります。

基本的に、ここでのリスクはメリットよりもはるかに高いのです。それが、私たちが使用を許可しない理由です。

PHP: グローバルに設定の変更

PHP の設定をグローバルに強制設定しない

多くのプラグインは PHP に最適な設定を必要としますが、グローバルなデフォルト設定にしないようお願いします。

(init またはコードの __construct() 部分のように) ini_set('memory_limit', '-1'); のような定義をグローバルに実行することは、サイト上のすべてのものに対してそれを実行することを意味します。これは、あなたのユーザーが、そのホストの制限や制約のコンプライアンスから外れてしまう可能性があります。

どうしても使いたいのであれば、それを必要とする機能だけに限定する必要があります。

PHP: デフォルト・タイムゾーンの設定

これはほとんど良いアイデアとは言えません。人々は WordPress で独自のタイムゾーンを定義できるはずです。

また、WordPress は、デフォルトのタイムゾーンを明示的に UTC に設定しており (settings.php 内)、日付/時刻関数は、デフォルトのタイムゾーンが UTC であることに依存していることがあります。たとえば、date_default_timezone_set(get_option('timezone_string')) と入力した後に、get_post_time() や get_post_modified_time() から GMT タイムスタンプを取得しようとすると、正しい日付を取得できません。

PHP: エラー・レポート

プロダクション・コードで、エラー・レポートを使用しない

error_reporting() は、PHP のすばらしいツールです ( https://www.php.net/manual/ja/function.error-reporting.php ) が、これをプラグインに恒久的に設定すると、あなたのコードを使うすべての人に迷惑をかけることになります。仮に、あなたのコードが使われているサイトをデバッグしようとしても、余計なものが出力されるためにクリーンなテストを実行できません。プラグインの日常的な利用で error_reportig() を使用する場面はありません。

プラグイン標準

メインファイル規約

プラグインのメイン・ファイルには、慣例に従わない名前がついています。

メインプラグインファイル (プラグインヘッダーを含むファイル) は、プラグインフォルダーと同じ名前であることを期待され、それはプラグインのスラッグ/パーマリンクと同じ名前でもあります。

たとえば、プラグインのスラッグが ecpt-social-manager であれば、メイン・プラグインのファイル名は ecpt-social-manager.php になるでしょう。

メインのプラグインファイルのファイル名として、一般的な名前を使用すると、構成によっては課題が発生する可能性があることに注意してください。

プラグイン内のファイルやフォルダの構造化の方法についてのヒントをご覧ください。

不完全なヘッダー

ヘッダーが欠けているか、不完全です。

ヘッダーの必要条件を確認し、それに従ってプラグインを更新して、ヘッダーをメインファイルだけに置いてください。

不完全な Readme

Readme が欠けているか、不完全です。

最初のプラグイン、依存関係のあるプラグイン、外部サービスを呼び出すプラグインなど、場合によっては、完全な Readme を提供する必要があります。つまり、Readme には、ヘッダーだけでなく、どのように動作し、どのように使用できるのかについての適切な説明やドキュメントが必要です。

私たちのこうしたゴールは、インストールする前に、「インストールするもの」と「するべきもの」を皆さんに知ってもらうことです。サプライズはありません。あなたのプラグインが他のサーバーを呼び出す場合、これは特に重要です。プラグインをインストールする前に、ユーザーに必要なすべての情報を提供することが求められます。

あなたの Readme も Validator に従って検証されなければなりません。さもなければ、リジェクトします。私たちは readme.md を見たくないことを覚えておいてください。readme.md は機能しますが、readme.txt が常に優先されます。また、すべての Markdown が期待通りに機能するわけではありません。

Readme はこちらを参考に作成してください: https://ja.wordpress.org/plugins/readme.txt

GPL 互換ライセンスの宣言なし

このプラグインのライセンスを宣言する必要があります。これは、プラグインの readme とプラグインヘッダーの両方で利用可能なフィールドを使用して行うことができます。

すべてのコード、データ、画像 – WordPress.org でホストされているプラグイン・ディレクトリに登録されているもの – は、GPL または GPL 互換ライセンスに準拠しなければならないことを覚えておいてください。搭載されるサードパーティのライブラリ、コード、画像、その他も、互換性がなければなりません。

互換性のあるライセンスの具体的なリストについては、gnu.orgのGPL互換ライセンス・リストをご覧ください。

不正確な Stable Tag

Readme にある「Stable Tag」が、メインプラグインファイルに記載されているプラグインバージョンと一致していません。

Stable Tag は、WordPress の安定版ではなく、あなたのプラグインの安定版を意味します。あなたのプラグインが WordPress.org から適切にダウンロードされるためには、これらの値が同じである必要があります。これらの値が同期されていないと、ユーザーは正しいバージョンのコードを取得できません。

バージョン管理には、Semantic Versioning (別名 SemVer) を使用することをおすすめします:

ご注意ください: 現在のところ trunk の stable タグを使用してもプラグインディレクトリで動作しますが、新しいバージョンを示す方法としてはサポートも推奨もされておらず、自動アップデートで問題を引き起こすことが知られています。

プラグインの新バージョンをリリースする際には、メインファイルでプラグインのバージョンを更新するように、タグを適切に使用し、インクリメントしてください。タグを一致させることが、完全なフォワード・サポートであるための最善の方法です。

宣言ライセンスの不一致

このプラグインのライセンスを宣言する際には、同じでなければなりません。

readme ファイルとプラグインヘッダーの両方で、同じライセンスを宣言していることを確認してください。

GPL または GPL 互換ライセンス下で、きちんとドキュメント化されている限り、このプラグインが他ライセンス下で他ソースからのコードを含むことは問題ありませんが、あなたのコードは唯一のライセンスを宣言する必要があります。

HTTP API の使用

HTTP API の代わりに CURL の使用

WordPress には、独自の curl コールを作成する代わりに使用すべき、広範な HTTP API が付属しています。より高速で、より広範囲にわたります。必要であれば curl にフォールバックしますが、WordPress のネイティブ機能の多くを最初に使用します。

https://developer.wordpress.org/plugins/http-api/

必要であれば、https://developer.wordpress.org/reference/hooks/http_api_curl/ で setopt を使うことができます。

ご注意ください: サードパーティ・ベンダーのライブラリで CURL を使用している場合、それは許可されています。修正が必要なのは、このプラグイン独自のコード (または任意の WordPress 専用ライブラリ) です。

wp_enqueue コマンドの使用

プラグインが JS や CSS を正しくインクルードしていません。これには内蔵関数を使用する必要があります:

JavaScript コード をインクルードする場合は、以下のように使います:

  • wp_register_script() と wp_enqueue_script() で、ファイルから JavaScript コードを追加します。
  • wp_add_inline_script() で、以前に宣言されたスクリプトにインライン JavaScript コードを追加します。

CSS をインクルードする場合は、以下のように使います:

  • wp_register_style() と wp_enqueue_style() で、ファイルから CSS を追加します。
  • wp_add_inline_style() で、以前に宣言された CSS にインライン CSS を追加します。

WordPress 5.7では、新しい関数やフィルターを使うことで、async、nonce、type などの属性を渡すことができる様になりました: WordPress 5.7 のスクリプト属性関連関数

管理者ページでエンキューしようとする場合、管理者エンキューを使いたいでしょう。

すでにコアに含まれているライブラリのインクルード

あなたのプラグインは、WordPress がすでに搭載しているライブラリのコピーを含んでいます。

WordPress には、jQuery、Atom Lib、SimplePie、PHPMailer、PHPass などの便利なライブラリが多数搭載されています。セキュリティと安定性の理由から、プラグインはこれらのライブラリを独自のコードにインクルードできませんが、代わりに、WordPress に同梱されているバージョンのライブラリを使用する必要があります。

JavaScript ライブラリのリストは、こちらでご覧いただけます:

WordPress にインクルードされ登録されている、デフォルトのスクリプトと JavaScript ライブラリ

これらすべてのライブラリをリストアップした、きちんとした一般向けのページはまだありませんが、ここにはリストがあります:

コアクレジット

コアにないアドオンをローカルにインクルードするのはかまいませんが、追加するファイルはそのファイルだけにしてください。たとえば、1つのファイルに対して jQuery UI ライブラリ全体は必要ないでしょう。あなたのコードが jQuery の内蔵バージョンで動作しない場合、それは noConflict の課題である可能性が高いです。

国際化

国際化: 変数の使用

国際化: テキスト、コンテキスト、テキスト・ドメインのパラメータとして、変数や define を使用しないでください。

プラグインで文字列を翻訳可能にするには、特別な関数のセットを使います。これらの関数を総称して「gettext」と呼びます。

WordPress コア、プラグイン、テーマの文字列の、他の言語への翻訳を支援する WordPress コミュニティの専任チーム があります。

このプラグインを翻訳できるようにするには、gettext 関数の text、context、または text domain のパラメータには 変数や関数呼び出しを使わないでください。これらはすべて 文字列でなければなりません。翻訳パーサーはコードを実行せずに読み込むため、これらの関数内で非文字列を読み取ることはできないことに注意してください。

たとえば、gettext 関数が次のようなものだとすると…

esc_html__( $greetings , 'plugin-slug' );

…$greetings は文字列ではないので、翻訳者は翻訳されるものを見ることができず、翻訳できるようなものは何もありません。翻訳する文字列を伝える必要があります。そうすれば、翻訳者は翻訳システムでそれを見ることができ、翻訳できます。正しくは次のようになります…

esc_html__( 'Hello, how are you?' , 'plugin-slug' );

これは翻訳ドメインにも当て嵌まります。こちらは、悪い呼び出し:

esc_html__( 'Hello, how are you?' , $plugin_slug );

この修正は、次のようなものでしょう:

esc_html__( 'Hello, how are you?' , 'plugin-slug' );

また、翻訳ドメインは、プラグインのスラッグと同じである必要があることに注意してください。

翻訳文の中に動的な値を含めたい場合は、どうすればいいのでしょう ? 簡単です。文字列の一部となるプレースホルダを追加し、gettext 関数が魔法をかけた後にそれを変更する必要があります。そのためには、次のように printf を使います:

printf(
    /* translators: %s: First name of the user */
    esc_html__( 'Hello %s, how are you?', 'plugin-slug' ),
    esc_html( $user_firstname )
);

詳しくはこちらをご覧ください。

遵守

アクティブ・プラグインの変更

プラグインが他のプラグインの有効化ステータスを変更することは許可されていません。これはユーザーが行うべき行為です。

また、エラーを防ぐために行われる場合を除き、プラグインを有効化または無効化する際に、ユーザーの操作を妨害することも禁じられています (たとえば: 自分のプラグインが他のプラグインに依存している場合、他のプラグインが有効でないときに自分のプラグインを無効にする)。

WordPress 6.5で Plugin Dependencies が導入され、依存関係の管理に使えるようになりました (ただし、機能や性能を制限して動かすフォールバックとして利用する分にはかまいません)。

更新チェッカー

更新チェッカーの搭載 / アップデート機能の変更

アップデートを提供するためにプラグインで行っているチェックを、削除してください。

私たちは WordPress.org ホスティングでサービスを提供しているため、プラグインがアップデートのために他のサーバーに接続することを許可していません。私たちのガイドラインの一つは、あなたが実際に私たちのホスティングを使用することですので、あなたはそのコードを削除する必要があります。

また、プラグインが内蔵アップデータを妨害しないようにお願いします。WordPress 5.5以上で、予期せぬ結果を引き起こす可能性があります。

ドキュメント化されていないサードパーティ

サードパーティまたは外部サービスの、ドキュメント化されていない使用

私たちは、プラグインがサードパーティ (つまり外部) のサービスの利用を要求することを許可しています。ただし、それらが明確な方法で適切にドキュメント化されている場合に限ります。

私たちは、データがどこに送信されるかをユーザーが認識できるように、他のサービスにアクセスするプラグインには、明確でわかりやすい言葉でこれを開示するよう要求しています。これにより、データ送信に関するあらゆる法的課題を確実にカバーできます。これは、あなたがサードパーティのサービスであっても同じです。

そのためには、readme を以下のように更新する必要があります:

  • あなたのプラグインがサービスとしてサードパーティに依存していること、そしてどのような状況下にあるのかの、明確な説明。
  • サービスへのリンクの提供。
  • サービスの利用規約および/またはプライバシーポリシーへのリンクの提供。

これはあなた自身の法的保護のためであることを忘れないでください。サービスの利用は、前もって、しっかりとドキュメント化されなければなりません。

不必要フォルダーを含む

このプラグインには、プラグインの実行には必要ないと思われるフォルダーやファイルが含まれています。例としては:

  • 開発ツール
  • 製品用に不要なベンダーフォルダー (bower、node、Grunt など)
  • デモ
  • ユニットテスト

(私たちのガイドラインに準拠するために) 独自コードの人間が読めるバージョンを含めようとしているのであれば、それはかまいません。Readme にリンクを貼ることも許可していることを忘れないでください。

また、たとえば、composer.json ファイルのような構成ファイルを保管したりリンクしたりして、他の人がこのコードをレビューしたり、研究したり、フォークしたりできるようにしておく必要があります。

詳細なプラグインガイドライン

しかし、プラグインから他の不要なフォルダーを安全に削除できるし、そうするべきです。

未許可ファイル

プラグインは通常、プラグインの機能に関連するファイル (php、js、css、txt、md) と、マルチメディアファイル (png、svg、jpg)、および/またはデータファイル (json、xml) で構成されます。

プラグインに通常含まれないファイルを検出しました。それらは必要ですか ? でなければ、それらは許可されません。

「プレミアム」ソースのコード搭載

一部のプレミアムライブラリは、無償 (WordPress.org ホスト) プラグインに含めることを、特に許可されていません。それらは削除しなければなりません。

GPL

GPL: 非 GPL 互換コードの搭載

私たちのディレクトリに収録されるためには、すべてのコードが GPLv2 (またはそれ以降) ライセンスと互換性があることが要求されます。

互換性のないコードは削除し、プラグインを変更する必要があります。GPL 互換のコードを見つけて、それを代わりに使うことをおすすめします。どのような種類のライセンスが GPL 互換なのかについては、以下のリンクをご覧ください:

GPL: 一般に開示されたリソースがない

圧縮コンテンツについて、公的にドキュメント化されたリソースがない

プラグインをレビューしたところ、未コンパイル版の javascript および/または css 関連のソースコードが見つかりませんでした。

私たちのガイドラインである「人間が読めるコード」に準拠するために、あなたのプラグインに搭載される非圧縮の開発者ライブラリへのソースコードやリンクを含めることを要求します。リンクを含める場合、ソースコードに書いてもかまいませんが、必ず readme にも書いてください。

詳細なプラグインガイドライン

私たちは、オープンソースの強みの一つは、コードをレビューし、観察し、適応させる能力であると強く感じています。自由に利用できるコードの公開ディレクトリを維持することで、私たちは将来の開発者が WordPress に関わり、WordPress を前進させることを奨励し、歓迎します。

とはいえ、より大規模なプラグインが登場し、より複雑なライブラリが使われるようになり、人々は (Composer や npm のような) ビルドツールをうまく利用して、分散されたプロダクションコードを生成しています。プラグインのサイズを小さく保つ必要性と、オープンソースの開発を奨励する必要性とのバランスをとるため、私たちはプラグインに、圧縮ファイルのソースコードを readme でドキュメント化し、見つけやすい場所で公開することを要求します。

たとえば、Gutenberg プラグインを作成し、npm と webpack を使って圧縮と最小化した場合、公開プラグイン内のソースコードをインクルードするか、レビュー可能で、研究可能で、そしてフォーク可能な、公開メンテナンスされたソースへのアクセスを提供する必要があります。

将来の開発者を奨励するため、ビルドツールの使用方法を記載することを強くおすすめします。

GPL: Composer の使用で composer.json ファイルがない

あなたのプラグインが Composer を使ってライブラリの依存関係を処理していることに気付きました。同じライブラリを使用している他のプラグインとの衝突を避けながら、将来あなたのプラグインを保守・更新するのに役立つので、それはすばらしいことです。

composer.json ファイルには、プロジェクトの依存関係が記述されており、その他のメタデータも含まれている場合があります。これは小さなファイルで、通常はプラグインの一番上のディレクトリに存在します。

オープンソースの強みの一つは、コードをレビューし、観察し、適応させる能力であるため、たとえそれが開発目的にのみ使用されるとしても、そのファイルをあなたのプラグインに含めるようお願いします。そうすることで、私たち全員が恩恵を受けているオープンソースの自由を、他の人たちも行使できます。

原文 / 日本語訳

First published

Last updated

WordPress.org
WordPress.org

日本語

Code is Poetry.
s
検索
c
新規投稿を作成する
r
返信
e
編集
t
ページのトップへ
j
次の投稿やコメントに移動
k
前の投稿やコメントに移動
o
コメントの表示を切替
esc
投稿やコメントの編集をキャンセル