• 赤色のリンクは、まだ日本語Codexに存在しないページ・画像です。英語版と併せてご覧ください。(詳細

このWikiはいつでも誰でも編集できます

「プラグインの作成」の版間の差分

提供: WordPress Codex 日本語版
移動先: 案内検索
({{Old}} を挿入)
(最新情報へのリンクを追加。)
 
(8人の利用者による、間の16版が非表示)
1行目: 1行目:
{{Old}}
+
<div class="important">
 +
'''このページは最新情報に追随して更新されていません'''。
 +
最新のプラグイン開発手法については[https://developer.wordpress.org/plugins/ プラグインハンドブック] (英語版) をご確認ください。
 +
</div>
 +
 
 +
{{CheckTrans}}
 
= はじめに =
 
= はじめに =
  
WordPress 1.2 より前では、WordPress の振舞いを変更したいと思ったとき、WordPress のソースコードを編集 (もしくは「いじる」) 必要がありました。ところが、現在の WordPress では、[[プラグイン]]を使用して、コア部分に対して簡単に機能の変更や追加を行うことができます。プラグインという仕掛けの基本的なアイディアは、WordPress のコアを比較的単純に保ち、しかしながらプラグインによって入出力の内容を変更できるぐらい柔軟であるようにすることです。定義は以下の通りです:
+
[[プラグイン|WordPress プラグイン]]を使うと、WordPress サイトの変更、カスタマイズ、機能強化を簡単に行うことができます。WordPress のコアプログラムに手を入れる代わりに、プラグインで機能を付け加えることができるのです。定義は以下の通りです:
  
;WordPress プラグイン : WordPress プラグインは PHP 言語で記述された、プログラムないし1つ以上の関数の集まりであり、WordPress ウェブログに  (WordPress [[プラグイン API|プラグイン・アプリケーション・インターフェース (API)]] で提供されるアクセスポイントやメソッドを使ってウェブログとシームレスに統合された) 特定の機能やサービスを追加します。
+
'''WordPress プラグイン''' : WordPress プラグインは PHP 言語で記述された、プログラムないし1つ以上の関数の集まりであり、WordPress ブログに (WordPress [[プラグイン API|プラグイン・アプリケーション・インターフェース (API)]] で提供されるアクセスポイントやメソッドを使って weblog とシームレスに統合された) 特定の機能やサービスを追加します。
  
この記事は、WordPress の基本的な機能や PHP プログラミングに親しんでいることを前提としています。
+
WordPress にない機能が欲しい場合や、既存の機能を変更したい場合は、まず[https://ja.wordpress.org/plugins/ プラグインリポジトリ]などでを検索してすでに他の人がその機能を実装していないか探してみましょう。もし見つからない場合は、以下の記事で WordPress プラグインの作り方を学びましょう。
 +
 
 +
この記事は、WordPress の基本的な機能や PHP プログラミングを知っていることを前提に書かれています。
  
 
== 資料 ==
 
== 資料 ==
  
* [[プラグイン・リソース]]では、プラグイン開発者のための総合的な記事やリソースの一覧があります。外部サイトの記事や特別なトピックもあります。
+
* WordPress プラグインの基本動作やインストール方法を知るには、[[プラグイン]]ページをご覧ください。
* プラグインについて学ぶ他のよい方法は、上手に書かれたプラグインの PHP ソースコードを眺めることです。例えば、[[プラグイン#Default Plugins|Hello Dolly]] のように WordPress に同梱されているプラグインです。
+
* [[プラグイン・リソース]]には、プラグイン開発者のための総合的な記事やリソースの一覧があります。外部サイトの記事や特別なトピックもあります。
* プラグインを作成したら、[[Plugin Submission and Promotion|プラグインの提出と宣伝]]/[[:en:Plugin Submission and Promotion|en]] を読んで、広く配布する方法を学んでください。
+
* プラグインの書き方の基本について学ぶには、上手に書かれたプラグインの PHP ソースコードを眺めると良いでしょう。例えば、[[プラグイン#Default Plugins|Hello Dolly]] のように WordPress に同梱されているプラグインがその一例です。
 +
* プラグインを作成したら、[[Plugin Submission and Promotion|プラグインの提出と宣伝]]を読んで、広く配布する方法を学んでください。
 +
 
 +
<p class="information">訳注: プラグインを[https://ja.wordpress.org/plugins/ 公式プラグインディレクトリ]でホスティングしたければ、[[Detailed Plugin Guidelines|公式ディレクトリで許されることとそうでないことのガイドライン]]もお読みください。</p>
  
 
= プラグインの作成 =
 
= プラグインの作成 =
24行目: 34行目:
 
プラグイン作成での最初の作業は、プラグインが何を行うかを考えて、プラグインの名前 (できれば唯一の) 名前を生成することです。[[プラグイン]]やプラグインが参照する他の配布サイトをチェックして、考えた名前が他にない唯一のものであることを検証してください。名称案で Google 検索してみるのもいいでしょう。多くのプラグイン開発者は、プラグインの動作を表す名称にしています。例えば、天気 (weather) に関するプラグインは、たいてい名前に「weather」という単語を含むでしょう。プラグイン名は、複数の単語であって構いません。
 
プラグイン作成での最初の作業は、プラグインが何を行うかを考えて、プラグインの名前 (できれば唯一の) 名前を生成することです。[[プラグイン]]やプラグインが参照する他の配布サイトをチェックして、考えた名前が他にない唯一のものであることを検証してください。名称案で Google 検索してみるのもいいでしょう。多くのプラグイン開発者は、プラグインの動作を表す名称にしています。例えば、天気 (weather) に関するプラグインは、たいてい名前に「weather」という単語を含むでしょう。プラグイン名は、複数の単語であって構いません。
  
訳注: プラグインの名称には日本語文字列は使えません。英数字、空白と一部の記号のみとしてください。英単語が好ましいですが、日本語圏専用ならば、日本語をローマ字綴りしたものものでもよいでしょう。
+
<p class="information">訳注: プラグインの名称には日本語文字列は使えません。英数字、空白と一部の記号のみとしてください。英単語が好ましいですが、日本語圏専用ならば、日本語をローマ字綴りしたものものでもよいでしょう。</p>
  
 
=== プラグイン・ファイル ===
 
=== プラグイン・ファイル ===
  
次は、選択したプラグイン名に由来する名前の PHP ファイルを作ります。例えば、プラグインの名前が「Fabulous Functionality」(驚くべき機能) であれば、PHP ファイルは <tt>fabfunc.php</tt> としていいでしょう。ここでも、他にない唯一の名前を選んでください。あなたのプラグインをインストールする人々は、この PHP ファイルを WordPress のプラグインディレクトリー <tt>wp-content/plugins/</tt> に配置しますが、同じファイル名の PHP ファイルであるプラグインは複数存在できないのです。
+
次は、選択したプラグイン名に由来する名前の PHP ファイルを作ります。例えば、プラグインの名前が「Fabulous Functionality」(驚くべき機能) であれば、PHP ファイルは <tt>fabfunc.php</tt> としていいでしょう。ここでも、他にない唯一の名前を選んでください。あなたのプラグインをインストールする人々は、この PHP ファイルを WordPress のプラグインディレクトリ <tt>wp-content/plugins/</tt> に配置しますが、同じファイル名の PHP ファイルであるプラグインは複数存在できないのです。
  
他の選択肢は、プラグインを複数のファイルに分割することです。プラグインは最低でも1つの PHP ファイルが必要です。他には、JavaScript ファイル、CSS ファイル、画像ファイル、言語ファイル等を含むことができます。もし複数のファイルがあれば、ディレクトリーおよび PHP ファイルに対して、他にない唯一の名前を選んでください。この例では  <tt>fabfunc</tt> や <tt>fabfunc.php</tt> でしょう。プラグインの全ファイルをそのディレクトリーに配置し、プラグインの利用者には、ディレクトリー全体を <tt>wp-content/plugins/</tt> 配下にインストールするよう告知してください。
+
他の選択肢は、プラグインを複数のファイルに分割することです。プラグインは最低でも1つの PHP ファイルが必要です。他には、JavaScript ファイル、CSS ファイル、画像ファイル、言語ファイル等を含むことができます。もし複数のファイルがあれば、ディレクトリおよび PHP ファイルに対して、他にない唯一の名前を選んでください。この例では  <tt>fabfunc</tt> や <tt>fabfunc.php</tt> でしょう。プラグインの全ファイルをそのディレクトリに配置し、プラグインの利用者には、ディレクトリ全体を <tt>wp-content/plugins/</tt> 配下にインストールするよう告知してください。<!-- However, an installation can be configured for <tt>wp-content/plugins</tt> to be moved, so you must use [[Function_Reference/plugin_dir_path| plugin_dir_path()]] and [[Function_Reference/plugins_url| plugins_url()]] for absolute paths and URLs. See: http://codex.wordpress.org/Determining_Plugin_and_Content_Directories for more details. -->
  
以後は、「プラグインの PHP ファイル」とは、 <tt>wp-content/plugins/</tt> ディレクトリーまたはサブディレクトリーに置かれた、プラグインの主たる PHP ファイルを示します。
+
以後は、「プラグインの PHP ファイル」とは、ディレクトリ <tt>wp-content/plugins/</tt> またはサブディレクトリに置かれた、プラグインの主たる PHP ファイルを示します。
  
 
=== 説明書 ===
 
=== 説明書 ===
  
もし、プラグインを http://wordpress.org/extend/plugins/ (訳注: 公式プラグインディレクトリー) にホストしたいなら、<tt>readme.txt</tt> ファイルを定められた書式で作成して、プラグインに含める必要があります。書式の説明については http://wordpress.org/extend/plugins/about/readme.txt を参照ください (訳注: 英文です)。
+
もし、プラグインを[https://ja.wordpress.org/plugins/ 公式プラグインディレクトリ] /[http://wordpress.org/extend/plugins/ en] でホスティングしたければ、<tt>readme.txt</tt> ファイルを定められた書式で作成して、プラグインに含める必要があります。書式の説明については https://ja.wordpress.org/plugins/developers/ を参照ください。
 +
 
 +
WordPress プラグインリポジトリは "Requires" および "Tested up to" のバージョンを <tt>readme.txt</tt> ファイルの stable タグから取得します。
 +
 
 +
stable タグの <tt>readme.txt</tt> がプラグインを定義づけるものと見なされることに注意してください。そのため <tt>/trunk/readme.txt</tt> の stable タグが <tt>4.3</tt> であれば、<tt>/tags/4.3/readme.txt</tt> がプラグインの情報として表示されます。この場合、 <tt>/trunk/readme.txt</tt> の内容のうち使われるのは stable タグの指定のみということになります。つまり、 <tt>trunk/readme.txt</tt> の stable タグさえ適切なバージョンを指定していれば、 <tt>trunk</tt> で開発をしている時に、現在の stable バージョンにはない機能を意図せず公表してしまうことなく、開発中の情報を <tt>trunk/readme.txt</tt> に反映することができます。
  
 
=== 紹介ページ ===
 
=== 紹介ページ ===
  
また、プラグインの「紹介ページ」となるウェブページを作成するのも有用です。このページで説明することは、プラグインのインストール方法、プラグインが何をするものか、動作する WordPress バージョン、プラグインのバージョンごとの変更点、プラグインの使い方、です。
+
また、プラグインの「紹介ページ」となるウェブページを作成するのも有用です。このページで説明することは、プラグインのインストール方法、プラグインが何をするものか、動作する WordPress バージョン、プラグインのバージョンごとの変更点、プラグインの使い方です。
  
== ファイル・ヘッダー ==
+
== ファイル・ヘッダー <span id="File_Headers"></span>==
  
 
ここでは、プラグインのメイン PHP ファイルにいくつか情報を記載してみます。
 
ここでは、プラグインのメイン PHP ファイルにいくつか情報を記載してみます。
48行目: 62行目:
 
=== 標準プラグイン情報 ===
 
=== 標準プラグイン情報 ===
  
プラグインの主たる PHP ファイルの先頭には、標準プラグイン情報ヘッダーを含まなければなりません。このヘッダーは、WordPress にプラグインの存在を認識させ、プラグイン管理画面に表示させます。これにより、プラグインを有効化して、読み込んで、機能を走らせることができます。ヘッダーが存在しない場合、プラグインは有効化も実行もできません。以下にヘッダー書式を示します。
+
[https://developer.wordpress.org/plugins/the-basics/header-requirements/ Read this in the plugin developer handbook.]
 +
最新はこちらをお読みください。(英語)
 +
 
 +
プラグインの主たる PHP ファイルの先頭には、標準プラグイン情報[[File Header|ヘッダー]]を含まなければなりません。このヘッダーは、WordPress にプラグインの存在を認識させ、プラグイン管理画面に表示させます。これにより、プラグインを有効化して、読み込んで、機能を走らせることができます。ヘッダーが存在しない場合、プラグインは有効化も実行もできません。以下にヘッダー書式を示します。
 +
 
 +
https://wordpress.org/plugins/about/readme.txt にある description のフォーマット または、自動生成 [http://generatewp.com/plugin-readme/ plugin 'readme.txt' generator]も参照ください。
  
 
<pre>
 
<pre>
59行目: 78行目:
 
Author: (プラグイン作者の名前)
 
Author: (プラグイン作者の名前)
 
Author URI: (プラグイン作者の URI)
 
Author URI: (プラグイン作者の URI)
 +
License: (ライセンス名の「スラッグ」 例: GPL2)
 
*/
 
*/
 
?>
 
?>
65行目: 85行目:
 
WordPress がプラグインを認識するのに必要な最低限の情報は、Plugin Name の行です。もし残りの情報があれば、プラグイン管理画面でプラグインのテーブルを作るのに使われます。各行の順番は不問です。
 
WordPress がプラグインを認識するのに必要な最低限の情報は、Plugin Name の行です。もし残りの情報があれば、プラグイン管理画面でプラグインのテーブルを作るのに使われます。各行の順番は不問です。
  
訳注: 原則として、情報はすべて英文で記載してください。ただし、日本語圏のみ配布するプラグインであれば、日本語でも構いません。
+
License の行にはプラグインのライセンスの短い共通識別子を記入してください。これは、コードのライセンスを明示的に示すための簡単な方法として用意されています。
 +
 
 +
'''重要:''' ファイルは必ず UTF-8 エンコーディングにしてください。
 +
 
 +
<p class="information">訳注: 原則として、情報はすべて英文で記載してください。ただし、日本語圏のみ配布するプラグインであれば、日本語でも構いません。</p>
  
 
=== ライセンス ===
 
=== ライセンス ===
  
慣例として、標準プラグイン情報の次にプラグインのライセンス情報を書きます。多くのプラグインは WordPress と同じ [http://www.gnu.org/copyleft/gpl.html GPL]、ないし [http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses GPL 互換のライセンス (英文)] を用いています。GPL ライセンスを示すには、プラグインに以下の行を含めてください。
+
ライセンスについては[https://developer.wordpress.org/plugins/the-basics/including-a-software-license/ プラグインデベロッパーハンドブックに記載(英語)があります]のでお読みください。
 +
 
 +
慣例として、標準プラグイン情報の次にプラグインのライセンス情報を書きます。多くのプラグインは WordPress と同じ [http://www.gnu.org/licenses/old-licenses/gpl-2.0.html GPL2]、ないし [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses GPL2 互換のライセンス (英文)] を用いています。GPL2 ライセンスを示すには、プラグインに以下の行を含めてください。
  
訳注: GPL は英文でのみ効力を持ちます。このため、翻訳はしておりません。「作成年」は、プラグインの作成年 (西暦; 2008 など) に置き換えてください。プラグイン作者名は、ローマ字での記載を行なってください。
+
<p class="information">訳注: GPL は英文でのみ効力を持ちます。このため、翻訳はしておりません。「作成年」は、プラグインの作成年 (西暦; 2008 など) に置き換えてください。プラグイン作者名は、ローマ字での記載を行なってください。</p>
  
 
<pre>
 
<pre>
78行目: 104行目:
  
 
     This program is free software; you can redistribute it and/or modify
 
     This program is free software; you can redistribute it and/or modify
     it under the terms of the GNU General Public License as published by
+
     it under the terms of the GNU General Public License, version 2, as
    the Free Software Foundation; either version 2 of the License, or
+
published by the Free Software Foundation.
    (at your option) any later version.
+
  
 
     This program is distributed in the hope that it will be useful,
 
     This program is distributed in the hope that it will be useful,
102行目: 127行目:
 
多くのプラグインが、WordPress 用プラグインフックと1つ以上接続することで、目的を果たしています。プラグインフックが動く方法は、WordPress が走る間のさまざまなタイミングで、いずれかのプラグインがその時点で走る関数を登録していないかを WordPress が確認し、もしあればその関数を走らせることによります。これらの関数は、WordPress のデフォルトの振舞いを変更します。
 
多くのプラグインが、WordPress 用プラグインフックと1つ以上接続することで、目的を果たしています。プラグインフックが動く方法は、WordPress が走る間のさまざまなタイミングで、いずれかのプラグインがその時点で走る関数を登録していないかを WordPress が確認し、もしあればその関数を走らせることによります。これらの関数は、WordPress のデフォルトの振舞いを変更します。
  
例えば、WordPress がブラウザーへの出力に投稿タイトルを追加する前に、「the_title」と呼ばれる「フィルター」フックに、いずれかのプラグインが関数を登録していないかを見ます。もしあれば、タイトルのテキストが、登録された各関数に順番に渡され、最後の結果が出力されます。すなわち、プラグインが出力されたタイトルに何か情報を追加したければ、「the_title」フィルター関数を登録すればよいのです。
+
例えば、WordPress がブラウザへの出力に投稿タイトルを追加する前に、「the_title」と呼ばれる「フィルター」フックに、いずれかのプラグインが関数を登録していないかを見ます。もしあれば、タイトルのテキストが、登録された各関数に順番に渡され、最後の結果が出力されます。すなわち、プラグインが出力されたタイトルに何か情報を追加したければ、「the_title」フィルター関数を登録すればよいのです。
  
 
他の例は、「wp_footer」と呼ばれる「アクション」フックです。WordPress が生成する HTML ページのまさに最後の段階で、「wp_footer」アクションフックに、いずれかのプラグインが関数を登録しているかどうかを確認し、順番にそれらを走らせます。
 
他の例は、「wp_footer」と呼ばれる「アクション」フックです。WordPress が生成する HTML ページのまさに最後の段階で、「wp_footer」アクションフックに、いずれかのプラグインが関数を登録しているかどうかを確認し、順番にそれらを走らせます。
120行目: 145行目:
  
 
# WordPress の「設定」機構 (後述) を使います。この手法は、比較的小さくて比較的変化が少ない、名前のついたデータを保管するのに適しています。データの種類としては、サイト所有者がプラグインの最初の設定を行うときに入力すると期待され、今後めったに変化しないという類いのデータです。
 
# WordPress の「設定」機構 (後述) を使います。この手法は、比較的小さくて比較的変化が少ない、名前のついたデータを保管するのに適しています。データの種類としては、サイト所有者がプラグインの最初の設定を行うときに入力すると期待され、今後めったに変化しないという類いのデータです。
# 新しくカスタムのデータベーステーブルを作成します。この手法は、個々の投稿・ページ・添付ファイル・コメントに関連するデータを保管するのに適しています。データの種類としては、時間が経つにつれ大きくなるデータで、名前を持たないデータです。やり方は[[Creating Tables with Plugins|プラグインでのテーブル作成]]/[[:en:Creating Tables with Plugins|en]] を見てください。
+
<!-- # Post Meta (a.k.a. Custom Fields).  Appropriate for data associated with individual posts, pages, or attachments.  See [[Function_Reference/post_meta Function Examples|post_meta Function Examples]], [[Function Reference/add_post_meta|add_post_meta()]], and related functions. -->
 +
# 新しくカスタムのデータベーステーブルを作成します。この手法は、個々の投稿・ページ・添付ファイル・コメントに関連するデータを保管するのに適しています。データの種類としては、時間が経つにつれ大きくなるデータで、名前を持たないデータです。やり方は[[Creating Tables with Plugins|プラグインでのテーブル作成]]を見てください。
  
 
=== WordPress 設定機構 ===
 
=== WordPress 設定機構 ===
  
[[Creating Options Pages|設定ページの作成]]/[[:en:Creating Options Pages|en]] に、自分用の設定値を自動的に保存するようなページの作り方の情報があります。
+
[[Creating Options Pages|設定ページの作成]]に、自分用の設定値を自動的に保存するようなページの作り方の情報があります。
  
 
WordPress には、独立した、名前の付いたデータ (「設定」) を WordPress データベースに保存・更新・読出をする機構があります。設定値の取り得る形式は、文字列 (string)、配列 (array)、もしくは PHP オブジェクトです (オブジェクトは、保管時は「シリアライズ」もしくは文字列に変換され、読出時にオブジェクトに戻されます)。オプション名は文字列で、他にない唯一ものでなければなりません。なぜなら、WordPress や他のプラグインと衝突しないためです。
 
WordPress には、独立した、名前の付いたデータ (「設定」) を WordPress データベースに保存・更新・読出をする機構があります。設定値の取り得る形式は、文字列 (string)、配列 (array)、もしくは PHP オブジェクトです (オブジェクトは、保管時は「シリアライズ」もしくは文字列に変換され、読出時にオブジェクトに戻されます)。オプション名は文字列で、他にない唯一ものでなければなりません。なぜなら、WordPress や他のプラグインと衝突しないためです。
135行目: 161行目:
 
: 新しい設定を作ります。設定が存在すれば何もしません。
 
: 新しい設定を作ります。設定が存在すれば何もしません。
 
;$name: 必須 (string)。追加する設定の名前です。
 
;$name: 必須 (string)。追加する設定の名前です。
;$value: 任意 (string)、デフォルトは空の文字列です。保管する設定値です。
+
;$value: 任意 (mixed)、デフォルトは空の文字列です。保管する設定値です。
 
;$deprecated: 任意 (string)、もはや WordPress で使われていません。次の $autoload パラメータを使いたいならば、この引数に空の文字列もしくは NULL を入れてください。
 
;$deprecated: 任意 (string)、もはや WordPress で使われていません。次の $autoload パラメータを使いたいならば、この引数に空の文字列もしくは NULL を入れてください。
;$autoload: 任意、デフォルトは 'yes' (enum: 'yes' or 'no').  'yes' を入れると、この設定は <tt>get_alloptions</tt> 関数によって自動的に読み出されます。
+
;$autoload: 任意、デフォルトは 'yes' (enum: 'yes' or 'no').  'yes' を入れると、この設定は <tt>wp_load_alloptions</tt> 関数によって自動的に読み出されます。
  
 
<pre>
 
<pre>
143行目: 169行目:
 
</pre>
 
</pre>
 
: データベースから設定値を読み出します。
 
: データベースから設定値を読み出します。
;$option: 必須 (string)。値を返してほしい設定の名前です。WordPress がインストールされたとき時点でのデフォルト設定の一覧は、[[Option Reference|設定リファレンス]]/[[:en:Option Reference|en]]にあります。
+
;$option: 必須 (string)。値を返してほしい設定の名前です。WordPress がインストールされたとき時点でのデフォルト設定の一覧は、[[Option Reference|設定リファレンス]]にあります。
  
 
<pre>
 
<pre>
150行目: 176行目:
 
: データベースで設定値を更新または作成します。(<tt>$deprecated</tt> や <tt>$autoload</tt> パラメータを使わないならば、<tt>add_option</tt> を呼ばなくて構いません)
 
: データベースで設定値を更新または作成します。(<tt>$deprecated</tt> や <tt>$autoload</tt> パラメータを使わないならば、<tt>add_option</tt> を呼ばなくて構いません)
 
;$option_name: 必須 (string)。更新したい設定の名前。
 
;$option_name: 必須 (string)。更新したい設定の名前。
;$newvalue: 必須。設定の新しい値。
+
;$newvalue: 必須 (string|array|object)。設定の新しい値。
  
=== 管理パネル ===
+
=== 管理画面 ===
  
プラグインに、WordPress データベースに保管したい設定があれば (前節を参照)、プラグイン利用者が設定値を閲覧したり編集したりするための管理パネルを持ちたいと思うでしょう。このための手法は、[[Adding Administration Menus|管理メニューの追加]]/[[:en:Adding Administration Menus|en]] で説明します。
+
プラグインに、WordPress データベースに保管したい設定があれば (前節を参照)、プラグイン利用者が設定値を閲覧したり編集したりするための管理画面を持ちたいと思うでしょう。このための手法は、[[Adding Administration Menus|管理メニューの追加]]で説明します。
  
 
== プラグインの多言語化 ==
 
== プラグインの多言語化 ==
  
プラグインのプログラミングを終えたら、(プラグインを配布する計画があれば) 「国際化」について考慮しましょう。国際化は、ソフトウェアを「ローカライズされた」状態にする処理です。ローカライズとは、ソフトウェアによって表示されるテキスト異なる言語に翻訳する処理です。WordPress は世界中で使用されていて、国際化やローカライズの仕掛け (プラグインのローカライズも対象) が組み込まれています。WordPress がローカライズに使用している GNU gettext の背景については[[WordPress の翻訳]]を見てください。
+
プラグインのプログラミングを終えたら、(プラグインを配布する計画があれば) 「国際化」について考慮しましょう。国際化は、ソフトウェアを「ローカライズされた」状態にする処理です。ローカライズとは、ソフトウェアによって表示されるテキスト異なる言語に翻訳する処理です。WordPress は世界中で使用されていて、国際化やローカライズの仕掛け (プラグインのローカライズも対象) が組み込まれています。
  
プラグインを国際化することは強く推奨されています。そうすれば、さまざまな国のユーザーがローカライズできます。処理は以下の順で行なわれます。
+
プラグインの言語ファイルは自動的には'''読み込まれません'''。以下をプラグインのコードに含め、言語ファイルが必ず読み込まれるようにしてください。
  
* プラグインの翻訳に使う「テキスト領域 (text domain)」を決めます。通常、プラグインのファイル名 (<tt>.php</tt>を除く) と同じものとし、インストールされたプラグインの間で唯一のもの (重複なし) としなければなりません。
+
load_plugin_textdomain('your-unique-name', false, basename( dirname( __FILE__ ) ) . '/languages' );
* プラグインがユーザーに表示する文章のテキスト文字列 (「メッセージ」と呼びます) を使うそれぞれにおいて、WordPress の gettext 関数の1つでそれらを囲みます。プラグインでは、第2引数を必要とすることに注意してください。選択した翻訳テキスト領域を渡すことで、WordPress コアの場合 (<tt>$domain</tt> 引数が空) と異なることを示します。
+
; <tt>__($message, $domein)</tt> : <tt>$message</tt> (メッセージ) を現在のロケール (地域) を使って <tt>$domein</tt> (領域) 用に翻訳します。式で使おうとするテキスト文字列をこの関数で囲んでください。
+
; <tt>_e($message, $domain)</tt> : <tt>$message</tt> (メッセージ) を現在のロケールを使って <tt>$domein</tt> (領域) 用に翻訳し、画面に表示します。直接表示するテキスト文字列をこの関数で囲んでください。
+
* プラグイン用の POT ファイル (すべての翻訳可能メッセージを並べた翻訳カタログ) を作成し、プラグインと一緒に配布してください。ユーザーは、翻訳された MO ファイルをプラグインの PHP ファイルと同じディレクトリーに配置し、ファイル名は <tt>domain-ll_CC.mo</tt> とする必要があります。ここで、<tt>ll_CC</tt> はユーザーのロケール名です。POT ファイル、MO ファイル、ロケールについての情報は[[WordPress の翻訳]]を見てください。
+
* 現在のロケールおよび、プラグインのテキスト領域用に翻訳を読み込むには、いずれかの gettext 関数を呼ぶ前に <tt>load_plugin_textdomain</tt> を呼んでください。ただし、セッション内のできるだけ遅い段階で実行します (なぜなら、多言語プラグインがロケールを変更することがあるためです)。考えられる実装の1つとしては、プラグイン内のすべての関数の先頭で呼ばれる初期化関数を定義することです。例えば、テキスト領域が「fabfunc」とすれば以下のようになります:
+
<pre>
+
$fabfunc_domain = 'fabfunc';
+
$fabfunc_is_setup = 0;
+
  
function fabfunc_setup()
+
文字列を取得するには、'''__('String name','your-unique-name');''' を使って翻訳を返すか、'''_e('String name','your-unique-name');''' をつかって翻訳を出力します。翻訳ファイルはプラグインの /languages フォルダに含めてください。
{
+
  global $fabfunc_domain, $fabfunc_is_setup;
+
  
  if($fabfunc_is_setup) {
+
さまざまな国のユーザーがローカライズできるように、プラグインの国際化は強く推奨されています。国際化についての総合的なリファレンスが [[WordPress の翻訳]]ページにあります。
      return;
+
  }
+
 
+
  load_plugin_textdomain($fabfunc_domain,
+
  PLUGINDIR.'/'.dirname(plugin_basename(__FILE__)),
+
  dirname(plugin_basename(__FILE__)));
+
}
+
</pre>
+
もし、プラグインが自前のサブディレクトリーに入っていなければ、<tt>load_plugin_textdomain</tt> の第2引数以降を省略できます。
+
 
+
訳注: 第2引数は、WordPress 2.5 以前への互換用で、第3引数は WordPress 2.6 以降用です。
+
 
+
もし、この節を読んでいる理由が、テーマの国際化をしたいためならば、原則として上記の手順に従った上で、以下のように読み変えてください:
+
* MO ファイルはテーマのディレクトリーに入れます (style.css と同じ場所)。
+
* MO ファイルは <tt>ll_CC.mo</tt> という名前にしてください。ここで、<tt>ll_CC</tt> はロケールの名前です (つまり、テキスト領域はファイル名に含まれません)。
+
* テキスト領域を読み込むには、以下のコード (必要ならば PHP のエスケープで囲って) をテーマの functions.php ファイルに書きます。your_domain は実際のテキスト領域に置き換えてください。
+
<pre>
+
load_theme_textdomain('your_domain');
+
</pre>
+
  
 
= プラグイン開発における推奨事項 =
 
= プラグイン開発における推奨事項 =
202行目: 199行目:
  
 
* プラグインのコードは [[WordPress コーディング基準]]に従ってください。同様に[[Inline Documentation|インラインドキュメント]]/[[:en:Inline Documentation|en]]規約も考慮してください。
 
* プラグインのコードは [[WordPress コーディング基準]]に従ってください。同様に[[Inline Documentation|インラインドキュメント]]/[[:en:Inline Documentation|en]]規約も考慮してください。
* プラグインにあるすべての関数は、他にない唯一の名前を持たなければなりません。WordPress コア、他のプラグインやテーマの関数と違うものにしてください。これに従う1つのうまい方法としては、プラグインの関数すべての名前に、唯一の前置詞を付けることです。他のやり方としては、プラグインの関数をクラスの中で定義します (クラスの名前は他にない唯一のものにする必要があります)。
+
* プラグインにあるすべての関数は、他にない唯一の名前を持たなければなりません。WordPress コア、他のプラグインやテーマの関数と違うものにしてください。これに従う1つのうまい方法としては、プラグインの関数すべての名前に、ユニークな接頭辞を付けることです。他のもっと良いやり方としては、プラグインの関数をクラスの中で定義するという方法があります (クラスの名前は他にない唯一のものにする必要があります)。
* プラグインで、WordPress データベースの前置詞 (通常は「wp_」) をハードコードしないでください。代わりに、 <tt>$wpdb->prefix</tt> 変数を使うようにしてください。(訳注: <tt>$table_prefix</tt> も好ましくありません)
+
* プラグインで、WordPress データベースの接頭辞 (通常は「wp_」) をハードコードしないでください。代わりに、 <tt>$wpdb->prefix</tt> 変数を使うようにしてください。(訳注: <tt>$table_prefix</tt> も好ましくありません)
 
* データベースの読み出しの負荷は軽いですが、書き込みは高負荷です。データベースは、データを取得してあなたに与えてくれる動作において非常に優秀で、これらの操作はたいてい素早いものです。しかしながら、データベースに変更を加えることは、より複雑な処理で、計算量を伴う高負荷なものです。そのため、データベースへの<em>書き込み</em>量が最小限になるよう努力してください。コードでは、まずプリペアードステートメントを使うようにしてください。そうすれば、必要十分の書き込み処理がなされます。
 
* データベースの読み出しの負荷は軽いですが、書き込みは高負荷です。データベースは、データを取得してあなたに与えてくれる動作において非常に優秀で、これらの操作はたいてい素早いものです。しかしながら、データベースに変更を加えることは、より複雑な処理で、計算量を伴う高負荷なものです。そのため、データベースへの<em>書き込み</em>量が最小限になるよう努力してください。コードでは、まずプリペアードステートメントを使うようにしてください。そうすれば、必要十分の書き込み処理がなされます。
* SELECT 文での選択は、必要な分だけ行なってください。データベースからのデータ取得は目にも止まらぬ速さだとしても、最低限のデータだけを選択することで、データベースへの負荷を軽減する努力をするべきです。もし、テーブル内の行数を数える必要があれば、<tt>SELECT * FROM</tt> を使ってはいけません。なぜなら、すべての行のすべてのデータが取り出されてしまい、メモリーを浪費してしまうからです。同様に、プラグインで、post_id と post_author のみが必要であれば、<tt>SELECT</tt> 文でこれら特定のフィールドを選択することで、データベース負荷を最小化できます。次のことを覚えておいてください: 同時に何百もの他のプロセスがデータベースにヒットするかもしれません。データベースやサーバーは、それらすべてのプロセスの間で自身のリソースを分配しなければならないのです。データベースに対してプラグインからのヒットを最小限にする方法を学べば、あなたのプラグインがリソースを食うと非難されることはないはずです。
+
* SELECT 文での選択は、必要な分だけ行なってください。データベースからのデータ取得は目にも止まらぬ速さだとしても、最低限のデータだけを選択することで、データベースへの負荷を軽減する努力をするべきです。もし、テーブル内の行数を数える必要があれば、<tt>SELECT * FROM</tt> を使ってはいけません。なぜなら、すべての行のすべてのデータが取り出されてしまい、メモリを浪費してしまうからです。同様に、プラグインで、post_id と post_author のみが必要であれば、<tt>SELECT</tt> 文でこれら特定のフィールドを選択することで、データベース負荷を最小化できます。次のことを覚えておいてください: 同時に何百もの他のプロセスがデータベースにヒットするかもしれません。データベースやサーバーは、それらすべてのプロセスの間で自身のリソースを分配しなければならないのです。データベースに対してプラグインからのヒットを最小限にする方法を学べば、あなたのプラグインがリソースを食うと非難されることはないはずです。
 
* (訳注: むしろ、データベースへの直接アクセスではなく、WordPress の API を利用してデータを取り出すようにしてみてください。API を使った場合、取り出したデータをメモリにキャッシュするため、データベースの読み込み処理が自動的に軽減されます)
 
* (訳注: むしろ、データベースへの直接アクセスではなく、WordPress の API を利用してデータを取り出すようにしてみてください。API を使った場合、取り出したデータをメモリにキャッシュするため、データベースの読み込み処理が自動的に軽減されます)
 +
* プラグイン内の PHP エラーをなくしましょう。そのために <code>define( 'WP_DEBUG', true );</code> を wp-config.php ファイルに追加し、プラグインのすべての機能を試して、エラーや警告がないかチェックしてください。発生していたら修正し、すべて取り除くまで続けます。
 +
* <script> と <style> タグを直接 echo しないようにしましょう。代わりに、[[関数リファレンス/wp_enqueue_style|wp_enqueue_style()]] と [[関数リファレンス/wp_enqueue_script|wp_enqueue_script()]] 関数を使うことをおすすめします。<!-- They help eliminate including duplicate scripts and styles as well as introduce dependency support. See posts by the following people for more info: [http://planetozh.com/blog/2008/04/how-to-load-javascript-with-your-wordpress-plugin/ Ozh Richard], [http://beerpla.net/2010/01/13/wordpress-plugin-development-how-to-include-css-and-javascript-conditionally-and-only-when-needed-by-the-posts/ Artem Russakovskii], and [http://www.prelovac.com/vladimir/best-practice-for-adding-javascript-code-to-wordpress-plugin Vladimir Prelovac]. -->
  
 
= 外部リソース =
 
= 外部リソース =
 +
=== 日本語 ===
 +
* [http://www.yuriko.net/wp-content/uploads/2009/06/20090627-writing_plugins.pdf WordPressプラグインの作り方] (リンク先はPDF。池田 百合子、2009年6月27日)
 +
* [http://www.yuriko.net/wp-content/uploads/2011/08/writing-secure-plugins.pdf セキュアなWORDPRESS プラグインの作り方] (リンク先はPDF。池田 百合子、2011年8月27日) [http://www.ustream.tv/recorded/16898916/highlight/197778 講演の Ustream 録画]
 +
* [http://www.slideshare.net/tk01k/word-press-35238487 WordPressプラグイン開発 超入門] (Takashi Koike、2014年3月29日)
 +
 +
=== 英語 ===
 +
* [http://planetozh.com/blog/2009/09/top-10-most-common-coding-mistakes-in-wordpress-plugins/ Top 10 Most Common Coding Mistakes in WordPress Plugins] (WordPress プラグインのコーディングでよくある10個の間違い、11SEP09)
 +
* [http://markjaquith.wordpress.com/2006/06/02/wordpress-203-nonces/ WordPress 2.0.3: Nonces (Secure your forms with nonces)] (フォームのセキュリティを Nonce で強化する 02JUN06)
 
* [http://amiworks.co.in/talk/simplified-ajax-for-wordpress-plugin-developers-using-jquery/ Simplified AJAX For WordPress Plugin Developers using Jquery](10APR08)
 
* [http://amiworks.co.in/talk/simplified-ajax-for-wordpress-plugin-developers-using-jquery/ Simplified AJAX For WordPress Plugin Developers using Jquery](10APR08)
 
* [http://www.rafaeldohms.com.br/2008/03/10/desenvolvendo-plugins-para-wordpress/pt/ "Desenvolvendo Plugins para WordPress" by Rafael Dohms (in Brazilian Portuguese)] (10MAR08)
 
* [http://www.rafaeldohms.com.br/2008/03/10/desenvolvendo-plugins-para-wordpress/pt/ "Desenvolvendo Plugins para WordPress" by Rafael Dohms (in Brazilian Portuguese)] (10MAR08)
 
* [http://www.devlounge.net/extras/how-to-write-a-wordpress-plugin 12 part "How to Write a Wordpress Plugin" at DevLounge.net] by [http://ronalfy.com Ronald Huereca] ([http://www.devlounge.net/publik/Devlounge%20-%20How%20to%20Write%20a%20Wordpress%20Plugin.pdf PDF])
 
* [http://www.devlounge.net/extras/how-to-write-a-wordpress-plugin 12 part "How to Write a Wordpress Plugin" at DevLounge.net] by [http://ronalfy.com Ronald Huereca] ([http://www.devlounge.net/publik/Devlounge%20-%20How%20to%20Write%20a%20Wordpress%20Plugin.pdf PDF])
 
* [http://ditio.net/2007/08/09/how-to-create-wordpress-plugin-from-a-scratch/ How to create WordPress Plugin from a scratch] (9AUG07)
 
* [http://ditio.net/2007/08/09/how-to-create-wordpress-plugin-from-a-scratch/ How to create WordPress Plugin from a scratch] (9AUG07)
* [http://www.devlounge.net/articles/using-ajax-with-your-wordpress-plugin Using AJAX with your WordPress Plugin], also at DevLounce.net (25MAY07)
+
* [http://mitcho.com/code/hookpress/ HookPress], a plugin that enables extending WordPress in languages other than PHP via webhooks. (26SEP09)
* [http://atd.agranite.com/emerald-coast/internet/wp-hacks/ How to Write a Simple WordPress Plugin at ATD] (22FEB05)
+
* [http://beerpla.net/2010/01/13/wordpress-plugin-development-how-to-include-css-and-javascript-conditionally-and-only-when-needed-by-the-posts/ How To Include CSS and JavaScript Conditionally And Only When Needed By The Posts] (13JAN10)
 +
* [http://aaron.jorb.in/blog/2010/03/wordpress-external-cron-plugin/ Demonstrating how to use the Settings API, WP_Http, and Pseudo-cron] (01MAR10)
  
{{原文|Writing a Plugin|60571}}<!-- 21:18, August 16, 2008 Filosofo 版 -->
+
{{原文|Writing a Plugin|111514}}<!-- 2011-12-01T21:19:54 Thee17 版 -->
  
 
{{DEFAULTSORT:ふらくいんのさくせい}}
 
{{DEFAULTSORT:ふらくいんのさくせい}}
 
[[Category:プラグイン]]
 
[[Category:プラグイン]]
 
[[Category:WordPress の開発]]
 
[[Category:WordPress の開発]]
 +
[[Category:UI Link]]
  
 
[[en:Writing a Plugin]]
 
[[en:Writing a Plugin]]
 +
[[es:Escribiendo un Plugin]]
 +
[[ja:Writing a Plugin]]
 +
[[pt-br:Escrevendo um Plugin]]
 +
[[ru:Написание плагина]]
 +
[[th:Writing a Plugin]]
 +
[[zh-hans:开发一个插件]]
 +
[[zh-tw:開發一個外掛]]

2020年9月27日 (日) 00:03時点における最新版

このページは最新情報に追随して更新されていません。 最新のプラグイン開発手法についてはプラグインハンドブック (英語版) をご確認ください。

この項目「プラグインの作成」は、翻訳チェック待ちの項目です。加筆、訂正などを通して、Codex ドキュメンテーションにご協力下さい。

はじめに

WordPress プラグインを使うと、WordPress サイトの変更、カスタマイズ、機能強化を簡単に行うことができます。WordPress のコアプログラムに手を入れる代わりに、プラグインで機能を付け加えることができるのです。定義は以下の通りです:

WordPress プラグイン : WordPress プラグインは PHP 言語で記述された、プログラムないし1つ以上の関数の集まりであり、WordPress ブログに (WordPress プラグイン・アプリケーション・インターフェース (API) で提供されるアクセスポイントやメソッドを使って weblog とシームレスに統合された) 特定の機能やサービスを追加します。

WordPress にない機能が欲しい場合や、既存の機能を変更したい場合は、まずプラグインリポジトリなどでを検索してすでに他の人がその機能を実装していないか探してみましょう。もし見つからない場合は、以下の記事で WordPress プラグインの作り方を学びましょう。

この記事は、WordPress の基本的な機能や PHP プログラミングを知っていることを前提に書かれています。

資料

  • WordPress プラグインの基本動作やインストール方法を知るには、プラグインページをご覧ください。
  • プラグイン・リソースには、プラグイン開発者のための総合的な記事やリソースの一覧があります。外部サイトの記事や特別なトピックもあります。
  • プラグインの書き方の基本について学ぶには、上手に書かれたプラグインの PHP ソースコードを眺めると良いでしょう。例えば、Hello Dolly のように WordPress に同梱されているプラグインがその一例です。
  • プラグインを作成したら、プラグインの提出と宣伝を読んで、広く配布する方法を学んでください。

訳注: プラグインを公式プラグインディレクトリでホスティングしたければ、公式ディレクトリで許されることとそうでないことのガイドラインもお読みください。

プラグインの作成

この節では、うまく構成された WordPress プラグインを作るために考慮すべき事項について、順序立てて説明していきます。

名前、ファイル、格納位置

プラグインの名前

プラグイン作成での最初の作業は、プラグインが何を行うかを考えて、プラグインの名前 (できれば唯一の) 名前を生成することです。プラグインやプラグインが参照する他の配布サイトをチェックして、考えた名前が他にない唯一のものであることを検証してください。名称案で Google 検索してみるのもいいでしょう。多くのプラグイン開発者は、プラグインの動作を表す名称にしています。例えば、天気 (weather) に関するプラグインは、たいてい名前に「weather」という単語を含むでしょう。プラグイン名は、複数の単語であって構いません。

訳注: プラグインの名称には日本語文字列は使えません。英数字、空白と一部の記号のみとしてください。英単語が好ましいですが、日本語圏専用ならば、日本語をローマ字綴りしたものものでもよいでしょう。

プラグイン・ファイル

次は、選択したプラグイン名に由来する名前の PHP ファイルを作ります。例えば、プラグインの名前が「Fabulous Functionality」(驚くべき機能) であれば、PHP ファイルは fabfunc.php としていいでしょう。ここでも、他にない唯一の名前を選んでください。あなたのプラグインをインストールする人々は、この PHP ファイルを WordPress のプラグインディレクトリ wp-content/plugins/ に配置しますが、同じファイル名の PHP ファイルであるプラグインは複数存在できないのです。

他の選択肢は、プラグインを複数のファイルに分割することです。プラグインは最低でも1つの PHP ファイルが必要です。他には、JavaScript ファイル、CSS ファイル、画像ファイル、言語ファイル等を含むことができます。もし複数のファイルがあれば、ディレクトリおよび PHP ファイルに対して、他にない唯一の名前を選んでください。この例では fabfuncfabfunc.php でしょう。プラグインの全ファイルをそのディレクトリに配置し、プラグインの利用者には、ディレクトリ全体を wp-content/plugins/ 配下にインストールするよう告知してください。

以後は、「プラグインの PHP ファイル」とは、ディレクトリ wp-content/plugins/ またはサブディレクトリに置かれた、プラグインの主たる PHP ファイルを示します。

説明書

もし、プラグインを公式プラグインディレクトリ /en でホスティングしたければ、readme.txt ファイルを定められた書式で作成して、プラグインに含める必要があります。書式の説明については https://ja.wordpress.org/plugins/developers/ を参照ください。

WordPress プラグインリポジトリは "Requires" および "Tested up to" のバージョンを readme.txt ファイルの stable タグから取得します。

stable タグの readme.txt がプラグインを定義づけるものと見なされることに注意してください。そのため /trunk/readme.txt の stable タグが 4.3 であれば、/tags/4.3/readme.txt がプラグインの情報として表示されます。この場合、 /trunk/readme.txt の内容のうち使われるのは stable タグの指定のみということになります。つまり、 trunk/readme.txt の stable タグさえ適切なバージョンを指定していれば、 trunk で開発をしている時に、現在の stable バージョンにはない機能を意図せず公表してしまうことなく、開発中の情報を trunk/readme.txt に反映することができます。

紹介ページ

また、プラグインの「紹介ページ」となるウェブページを作成するのも有用です。このページで説明することは、プラグインのインストール方法、プラグインが何をするものか、動作する WordPress バージョン、プラグインのバージョンごとの変更点、プラグインの使い方です。

ファイル・ヘッダー

ここでは、プラグインのメイン PHP ファイルにいくつか情報を記載してみます。

標準プラグイン情報

Read this in the plugin developer handbook. 最新はこちらをお読みください。(英語)

プラグインの主たる PHP ファイルの先頭には、標準プラグイン情報ヘッダーを含まなければなりません。このヘッダーは、WordPress にプラグインの存在を認識させ、プラグイン管理画面に表示させます。これにより、プラグインを有効化して、読み込んで、機能を走らせることができます。ヘッダーが存在しない場合、プラグインは有効化も実行もできません。以下にヘッダー書式を示します。

https://wordpress.org/plugins/about/readme.txt にある description のフォーマット または、自動生成 plugin 'readme.txt' generatorも参照ください。

<?php
/*
Plugin Name: (プラグインの名前)
Plugin URI: (プラグインの説明と更新を示すページの URI)
Description: (プラグインの短い説明)
Version: (プラグインのバージョン番号。例: 1.0)
Author: (プラグイン作者の名前)
Author URI: (プラグイン作者の URI)
License: (ライセンス名の「スラッグ」 例: GPL2)
*/
?>

WordPress がプラグインを認識するのに必要な最低限の情報は、Plugin Name の行です。もし残りの情報があれば、プラグイン管理画面でプラグインのテーブルを作るのに使われます。各行の順番は不問です。

License の行にはプラグインのライセンスの短い共通識別子を記入してください。これは、コードのライセンスを明示的に示すための簡単な方法として用意されています。

重要: ファイルは必ず UTF-8 エンコーディングにしてください。

訳注: 原則として、情報はすべて英文で記載してください。ただし、日本語圏のみ配布するプラグインであれば、日本語でも構いません。

ライセンス

ライセンスについてはプラグインデベロッパーハンドブックに記載(英語)がありますのでお読みください。

慣例として、標準プラグイン情報の次にプラグインのライセンス情報を書きます。多くのプラグインは WordPress と同じ GPL2、ないし GPL2 互換のライセンス (英文) を用いています。GPL2 ライセンスを示すには、プラグインに以下の行を含めてください。

訳注: GPL は英文でのみ効力を持ちます。このため、翻訳はしておりません。「作成年」は、プラグインの作成年 (西暦; 2008 など) に置き換えてください。プラグイン作者名は、ローマ字での記載を行なってください。

<?php
/*  Copyright 作成年 プラグイン作者名 (email : プラグイン作者のメールアドレス)

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License, version 2, as
	published by the Free Software Foundation.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
*/
?>

プラグインのプログラミング

ここでは、プラグインの実際の動作を作っていきましょう。この節は、プラグイン開発に関する一般的な考え方について書かれており、プラグインにとって必要な作業を果たす方法を説明しています。

WordPress プラグイン・フック

多くのプラグインが、WordPress 用プラグインフックと1つ以上接続することで、目的を果たしています。プラグインフックが動く方法は、WordPress が走る間のさまざまなタイミングで、いずれかのプラグインがその時点で走る関数を登録していないかを WordPress が確認し、もしあればその関数を走らせることによります。これらの関数は、WordPress のデフォルトの振舞いを変更します。

例えば、WordPress がブラウザへの出力に投稿タイトルを追加する前に、「the_title」と呼ばれる「フィルター」フックに、いずれかのプラグインが関数を登録していないかを見ます。もしあれば、タイトルのテキストが、登録された各関数に順番に渡され、最後の結果が出力されます。すなわち、プラグインが出力されたタイトルに何か情報を追加したければ、「the_title」フィルター関数を登録すればよいのです。

他の例は、「wp_footer」と呼ばれる「アクション」フックです。WordPress が生成する HTML ページのまさに最後の段階で、「wp_footer」アクションフックに、いずれかのプラグインが関数を登録しているかどうかを確認し、順番にそれらを走らせます。

フィルターやアクションのフックに関数を登録する方法や、どんなプラグインフックが WordPress に用意されているかを学ぶには、プラグイン API を見てください。もし、WordPress のコードのある場所で、アクションまたはフィルターが欲しいと思ったものの、そこにフックがなければ、新しいフックとして提案することもできます (一般的に提案は受け入れられます)。やり方についてはバグの報告を見てください。

テンプレートタグ

他に、WordPress に新たな機能を追加する方法は、カスタムのテンプレートタグを作ることです。あなたのプラグインを使いたい人は、これらの「タグ」を、自身のテーマのサイドバー・投稿の内容部分、または適切な場所のどこにでも追加することができます。例えば、地理タグ (geotag) を投稿に追加するプラグインならば、サイドバー向けに geotag_list_states() というテンプレートタグ関数を定義するでしょう。これは投稿にタグ付けられた州 (state) をリストし、プラグインが提供する州ごとのアーカイブページにリンクします。

カスタムのテンプレートタグを定義するには、単に PHP 関数を書き、プラグイン利用者向けに、プラグインの紹介ページおよびプラグインのメイン PHP ファイルでドキュメントを示します。 関数のドキュメントにおいて、関数を使うためにテーマに何を書けばよいかの例を示すとき、<?php?> を含めるのがよいでしょう。

データベースにデータを保存する方法

多くのプラグインが、サイト所有者もしくはブログ利用者から何か入力してもらったら、フィルター関数、アクション関数やテンプレート関数で使うため、セッションの間でその値を保存しておく必要があります。この情報は、セッションを通じて維持させるため、WordPress データベースに保存しなければなりません。データベースにデータを保存するには、2つの基本的な手法があります:

  1. WordPress の「設定」機構 (後述) を使います。この手法は、比較的小さくて比較的変化が少ない、名前のついたデータを保管するのに適しています。データの種類としては、サイト所有者がプラグインの最初の設定を行うときに入力すると期待され、今後めったに変化しないという類いのデータです。
  2. 新しくカスタムのデータベーステーブルを作成します。この手法は、個々の投稿・ページ・添付ファイル・コメントに関連するデータを保管するのに適しています。データの種類としては、時間が経つにつれ大きくなるデータで、名前を持たないデータです。やり方はプラグインでのテーブル作成を見てください。

WordPress 設定機構

設定ページの作成に、自分用の設定値を自動的に保存するようなページの作り方の情報があります。

WordPress には、独立した、名前の付いたデータ (「設定」) を WordPress データベースに保存・更新・読出をする機構があります。設定値の取り得る形式は、文字列 (string)、配列 (array)、もしくは PHP オブジェクトです (オブジェクトは、保管時は「シリアライズ」もしくは文字列に変換され、読出時にオブジェクトに戻されます)。オプション名は文字列で、他にない唯一ものでなければなりません。なぜなら、WordPress や他のプラグインと衝突しないためです。

これは、プラグインが WordPress 設定にアクセスするために使える主たる関数です。

add_option($name, $value, $deprecated, $autoload);
新しい設定を作ります。設定が存在すれば何もしません。
$name
必須 (string)。追加する設定の名前です。
$value
任意 (mixed)、デフォルトは空の文字列です。保管する設定値です。
$deprecated
任意 (string)、もはや WordPress で使われていません。次の $autoload パラメータを使いたいならば、この引数に空の文字列もしくは NULL を入れてください。
$autoload
任意、デフォルトは 'yes' (enum: 'yes' or 'no'). 'yes' を入れると、この設定は wp_load_alloptions 関数によって自動的に読み出されます。
get_option($option);
データベースから設定値を読み出します。
$option
必須 (string)。値を返してほしい設定の名前です。WordPress がインストールされたとき時点でのデフォルト設定の一覧は、設定リファレンスにあります。
update_option($option_name, $newvalue);
データベースで設定値を更新または作成します。($deprecated$autoload パラメータを使わないならば、add_option を呼ばなくて構いません)
$option_name
必須 (string)。更新したい設定の名前。
$newvalue
必須 (string|array|object)。設定の新しい値。

管理画面

プラグインに、WordPress データベースに保管したい設定があれば (前節を参照)、プラグイン利用者が設定値を閲覧したり編集したりするための管理画面を持ちたいと思うでしょう。このための手法は、管理メニューの追加で説明します。

プラグインの多言語化

プラグインのプログラミングを終えたら、(プラグインを配布する計画があれば) 「国際化」について考慮しましょう。国際化は、ソフトウェアを「ローカライズされた」状態にする処理です。ローカライズとは、ソフトウェアによって表示されるテキスト異なる言語に翻訳する処理です。WordPress は世界中で使用されていて、国際化やローカライズの仕掛け (プラグインのローカライズも対象) が組み込まれています。

プラグインの言語ファイルは自動的には読み込まれません。以下をプラグインのコードに含め、言語ファイルが必ず読み込まれるようにしてください。

	load_plugin_textdomain('your-unique-name', false, basename( dirname( __FILE__ ) ) . '/languages' );

文字列を取得するには、__('String name','your-unique-name'); を使って翻訳を返すか、_e('String name','your-unique-name'); をつかって翻訳を出力します。翻訳ファイルはプラグインの /languages フォルダに含めてください。

さまざまな国のユーザーがローカライズできるように、プラグインの国際化は強く推奨されています。国際化についての総合的なリファレンスが WordPress の翻訳ページにあります。

プラグイン開発における推奨事項

最後の節は、プラグイン開発における雑多な推奨事項です。

  • プラグインのコードは WordPress コーディング基準に従ってください。同様にインラインドキュメント/en規約も考慮してください。
  • プラグインにあるすべての関数は、他にない唯一の名前を持たなければなりません。WordPress コア、他のプラグインやテーマの関数と違うものにしてください。これに従う1つのうまい方法としては、プラグインの関数すべての名前に、ユニークな接頭辞を付けることです。他のもっと良いやり方としては、プラグインの関数をクラスの中で定義するという方法があります (クラスの名前は他にない唯一のものにする必要があります)。
  • プラグインで、WordPress データベースの接頭辞 (通常は「wp_」) をハードコードしないでください。代わりに、 $wpdb->prefix 変数を使うようにしてください。(訳注: $table_prefix も好ましくありません)
  • データベースの読み出しの負荷は軽いですが、書き込みは高負荷です。データベースは、データを取得してあなたに与えてくれる動作において非常に優秀で、これらの操作はたいてい素早いものです。しかしながら、データベースに変更を加えることは、より複雑な処理で、計算量を伴う高負荷なものです。そのため、データベースへの書き込み量が最小限になるよう努力してください。コードでは、まずプリペアードステートメントを使うようにしてください。そうすれば、必要十分の書き込み処理がなされます。
  • SELECT 文での選択は、必要な分だけ行なってください。データベースからのデータ取得は目にも止まらぬ速さだとしても、最低限のデータだけを選択することで、データベースへの負荷を軽減する努力をするべきです。もし、テーブル内の行数を数える必要があれば、SELECT * FROM を使ってはいけません。なぜなら、すべての行のすべてのデータが取り出されてしまい、メモリを浪費してしまうからです。同様に、プラグインで、post_id と post_author のみが必要であれば、SELECT 文でこれら特定のフィールドを選択することで、データベース負荷を最小化できます。次のことを覚えておいてください: 同時に何百もの他のプロセスがデータベースにヒットするかもしれません。データベースやサーバーは、それらすべてのプロセスの間で自身のリソースを分配しなければならないのです。データベースに対してプラグインからのヒットを最小限にする方法を学べば、あなたのプラグインがリソースを食うと非難されることはないはずです。
  • (訳注: むしろ、データベースへの直接アクセスではなく、WordPress の API を利用してデータを取り出すようにしてみてください。API を使った場合、取り出したデータをメモリにキャッシュするため、データベースの読み込み処理が自動的に軽減されます)
  • プラグイン内の PHP エラーをなくしましょう。そのために define( 'WP_DEBUG', true ); を wp-config.php ファイルに追加し、プラグインのすべての機能を試して、エラーや警告がないかチェックしてください。発生していたら修正し、すべて取り除くまで続けます。
  • <script> と <style> タグを直接 echo しないようにしましょう。代わりに、wp_enqueue_style()wp_enqueue_script() 関数を使うことをおすすめします。

外部リソース

日本語

英語

最新英語版: WordPress Codex » Writing a Plugin最新版との差分