wordpressのプラグインを理解する

本記事では wordpress におけるプラグインの開発に関して、こちらのドキュメントの内容を流し読みしていきたいと思います。
この記事を読むことでおそらくプラグインって何?どういう事ができるの?どうやって作るの?といったところがなんとなく理解できるようになると思います。

単純に記事の翻訳と、私の言葉でツッコミを入れている箇所が混在しており記事としては少々見づらい構成となっております。ご注意くださいませ。

プラグインの設計思想

wordpress ではコアをスリムにしておいて色々な開発者がプラグインを開発することで拡張できるように設計してあります。
プラグインの実態は php の関数となります。wordpress 側で提供しているプラグインのための API を実装することでプラグインを作成できます。

とりあえず自分の管理する wordpress サイトになにか新しい機能を付け加えたいと思ったときには他の誰かがプラグインをすでに開発していないかをまず確認してみましょう。なければ自分で作るという選択肢をとってみるのもいいと思います。

Plugin Resourcesにプラグイン開発者のための記事をまとめてあるので参考にしてください。

名前やファイルなどなど

プラグイン名

まずはじめに作りたいプラグインが何をするかということをよく考えて、それをうまく表現するような名前を考えてください。
その名前はユニークでなければならないので、 repository 上で検索を行って同じ名前のプラグインがすでに存在しないかを確認してください。
google でプラグイン名を検索することなども合わせて確認してください。名前は複数の単語で構成できます。

プラグインファイル

次にプラグイン名から連想されるファイル名を決定します。例えば “Fabulous Functionality” というプラグイン名であれば “fabulous-functionality.php” というファイル名に決定します。プラグインをインストールすると “wp-content/plugins/” ディレクトリに作成したプラグインファイルがダウンロードされ保存されます。
そのため重複した名称を持つ別々のプラグインをインストールすることはできません。

プラグインは少なくとも1つのphpファイルから構成されますが、js, css, images, language 等のファイルを含むこともできます。
その際にはプラグインのためのディレクトリを作成し、その下にメインのphpファイルを設置してください。その他のファイルも同様にディレクトリ内に設置します。
必須ではないですが、ディレクトリ名とphpファイル名は同じにすることが多いです。

もしディレクトリを作成しているようであれば、リポジトリに対するアップデートの確認はディレクトリ名をもとにして行われます。もしファイルだけで交際されるようであれば、ファイル名をもとにアップデートの確認が行われます。
もし自分がインストールしたプラグインに更新がある通知があるけれども、自分がその更新についてあまり知らない場合は注意してください。
リポジトリ上に存在している全く別のプラグインであるにもかかわらず、同じディレクトリ名(またはファイル名)のプラグインを参照している可能性があります。

この点については正直怖いですね。まだプラグインについて詳細に把握しているわけではありませんが、セキュリティ問題を含む可能性があります。
意図的に存在するプラグインと同じ名称で攻撃するためのスクリプトを上書き更新させる、なんてことができてしまうのかもしれないですね。
wordpress が発展してきたのは、オープンにすることでプラグイン開発の敷居を下げてきたことも起因しているかと思いますが、リポジトリの運用者やそもそものプラグインの仕組み自体を更新することで対応など指定ってほしい箇所ではあると感じます。
(ここまで大きくなったので今更プラグインの仕組みを大幅に更新するのはおそらく無理だと感じますけれども。)

wordpress はプラグインディレクトリが “wp-content/plugins/” から変更する設定を行うことが可能なのでパスの取得については plugins_dir_path() および plugins_url() 関数によって行うようにしてください。

またプラグインのメインファイルに直接アクセスを許容しないようにすることを考慮しておくといいらしいです。
これは下記のようなスクリプトを冒頭に仕込んでおくことで実現できます。

defined( 'ABSPATH' ) or die( 'No script kiddies please!' );

Readmeファイル

もしプラグインをリポジトリ上に公開するようであれば readme.txt ファイルをプラグインディレクトリにフォーマットされた書式で設置する必要があります。
Readmeジェネレータ を使えば簡単に生成することができるらしいです。
リポジトリでは “Requires” と “Tested up to” 項目を参照しています。

ホームページ

プラグインユーザのためにホームページを作成して詳細な情報を公開してあげると非常に有益なものになります。
どうやってインストールするのか、どうやって使うのか、どのバージョンの wordpress と互換性があるのか、バージョンアップデートでどのような機能を追加したのか、などなど様々な情報を提供してあげてください。

ファイルヘッダ

メインphpファイルのファイルヘッダには下記の応報を気欝する必要があります

詳細はこちらにまとめてあります。

  • Plugin Name: (必須) プラグインの名称を記載します。wordpress の管理画面上でプラグイン一覧に表示される際に使用されます。
  • Plugin URI: プラグインのホームページを記載します。できれば自分でホスティングしているサイトが好ましいです。またプラグインごとにユニークである必要があります
  • Description: wordpress の管理画面のプラグインの項目に表示される説明を140文字以内で記載します
  • Version: プラグインのバージョンを指定します
  • Author: プラグインの開発者の名前を記載します。カンマ区切りで複数の開発者を記載できます
  • License: プラグインライセンスのショートネームを記載します
  • License URI: ライセンス全文のリンクを記載します
  • Text Domain: プラグインの gettext のテキストドメインを記載します。
  • Domain Path: 翻訳を見つけるためのドメインパスを記載します。

例えば下記のようにヘッダを記載します。


gettext では 言語ファイルをドメインという名前空間に閉じた形で保持します。その中で「翻訳元 -> 翻訳後」のマッピングを定義します。
プラグインにおいてはその名前空間にプラグインの slug を利用します。そのためテキストドメインに関してはプラグインの slug と一致させる必要があります。
例えば my-plugin.php というファイルまたは my-plugin というディレクトリをプラグインの場合、slug は my-plugin となります。

Domain Path について補足

Domain Path は gettext で使用する言語ファイルが配置されている箇所を指定するために使われます。
例えば my-plugin/languages というディレクトリに言語ファイルが存在する場合 Domain Path には /languages というふうに指定します。

プラグインを実装する

プラグインフック

wordpress プラグインが目的を達成するためにプラグインフックがよく用いられます。
wordpress は様々なタイミングでフックをチェックし、プラグインがそのフックに対して登録されているかチェックします。
フックに何かしらの登録があれば、その処理を実行するような仕組みになります。

例えば wordpress には フィルターフックに “the_title” という物があるのですが、プラグインがそのフックに対して処理を追加した場合、出力されるタイトルに対して加工をすることができるようになります。

また他の例として アクションフックに “wp_footer” というものがあります。このフックにプラグインが処理を追加することで wordpress が生成する html の終了の直前に任意の処理を差し込むことが可能になります。

これは結構いいですね。
基本的に一般向けのプラグイン開発ではプラグインを利用することで簡単に wordpress の機能を拡張することができます。しかしながら wordpress をカスタマイズして行う受注開発などでもプラグインを利用することもできるんではないかと思いました。
汎用的な機能をプラグインとして実装しインストールさせることで wordpress コアに手を触れずに共通機能を実装することができます。
それにその機能をうまく分けてポートフォリオとしてモジュールのような形で持っておけば必要な機能だけを適宜インストールして使うようなこともできそうな気がします。
有効無効が管理画面から簡単に切り替えられるというのもプラグインの大きな特徴ですね。

テンプレートタグ

その他のプラグインの役割としてテンプレートタグを拡張することも可能です。作成したプラグインをインストールしたユーザはテンプレート内でインストールされたテンプレートタグを使用することができるようになります。
ホームページやメインphpファイルなどでどのようなテンプレートタグが利用可能になるのかをドキュメント化して上げると非常に良いです。

プラグインで wordpress を拡張する方法はフィルターフック、アクションフック、テンプレートタグということになるようですね。

プラグインデータをデータベースに保存する

プラグインはセッションをまたいで動作させるためにデータを永続化させる必要があることがあります。
wordpress では4つのメソッドによってそれを実現できます。

  1. option 機構を利用する方法。この方法は比較的が少量の名前付きデータを格納するのに適しています。プラグインの初期設定時に管理者にデータを入力させます。その後はあまり変更されないデータに適した方法です。
  2. PostMeta を利用する方法。記事やページやアタッチメントなどの投稿に対して保存されるメタ情報に関連付けてデータを保存します。
  3. カスタムタクソノミーを利用する方法。カスタムタクソノミーのタームに紐づけてすべての投稿やオブジェクトを参照するような場合はこちらを利用してください。
  4. 新しいテーブルを作成する方法。ポスト、ページ、アタッチメント、コメントなどに紐付いていないデータを保存する際に有効です。

管理画面に表示する

例えばオプションとしてプラグインのためのパラメータを設定した際に、管理画面でその値が確認できたり、変更できたりすると便利です。
実際に wordpress ではこの機能を提供しており こちら で実装詳細については説明されています。(ここでは割愛します)

多言語対応する

wordpress は世界中で使われるためプラグインを公開するときなどには多言語対応することを検討しておくべきです。
wordpress はプラグイン内部に設置した言語ファイルを自動的に読み込んだりはしてくれません、下記のようなコードを実装してプラグインのロード時に言語ファイルを読み込ませる必要があります。

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

文字列をフェッチする際には __(‘string-name’, ‘plugin-name’) とします。またはエコー表示さ焦る際には _e(‘string-name’, ‘plugin-name’) とします。

プラグインをアップデートする

ここでは wordpress 公式リポジトリでホスティングされているプラグインを更新するための手順について説明します。

SVNでソースをアップロードしたりする必要があるようですが、今回は割愛します。

プラグイン開発のすすめ

  • プラグイン開発はコーディングガイドに沿って実装しましょう
  • プラグインで実装する関数名は wordpress core や他のプラグインと重複しないようにユニークな名称としてください。そのために一律 prefix を付与することを推奨します。といっていますがこの点は wordpress の設計が弱かった点だと言っていいでしょう。気をつけなければならないですね。
  • wordpress のテーブルプレフィックス(通常 wp_)はハードコードしないでください。$wpdb->prefix で参照することができます。この値は設定によって変更されることがあるので、ハードコードしてしまうとプラグインが破壊されますね
  • データベースの読み込みは高速だけれども、書き込みに関してはパフォーマンスに影響を与える可能性があるので、なるべく書き込みを行わないように実装してください。とのことですが、実際読み込みも場合によってはコストが高く付く場合もあります。書き込みも場合によっては許容されるべきケースもありますので、個人的にはちょっとどうかなという印象。
  • 直接SQLを記述しないで wordpress のAPIを使ってください。これは当然そうしましょう。
  • 新規にテーブルを作成するのはなるべくやめて、既存のテーブルを使いましょう。これも当然ですね。プラグイン上で独自のテーブルを作るとなると初期化時にテーブルの作成、プラグインの削除時にテーブルの削除、その他諸々実装する箇所が膨大に膨れ上がります。また様々な場合で正常に動作することが担保するのが難しくなります。おとなしくカスタムポストやポストメタ、カスタムタクソノミーなどの既存の仕組みを利用してプラグインを実装するのが賢い方法だと思います。
  • むやみにデータベースから SELECT しないこと。これも当然ですね。負荷のかかるような実装を抱えたプラグインは wordpress 全体がダウンする可能性があります。注意する必要があります。
  • プラグイン中のエラーは潰しておいてください。WP_DEBUG を有効にすることでエラーと警告があるかどうかが確認できます。
  • scriptタグを直接出力しないでください。wp_enqueue_script や wp_enqueue_style という関数があるのでそっちを使ってくださいとのこと。

まとめ

プラグイン開発の概要について概要を把握することができました。
端的に言ってしまうとプラグインはフィルター、アクション、テンプレートタグをユーザに提供することができるんですね。
プラグインで実現する機能で何かしらの永続化が必要な場合は、オプション、ポストメタ、カスタムタクソノミー、データベースなどを状況に応じて使いましょう。
また世界中の多くのユーザに使ってもらうために、多言語化をサポートしましょうね。といった感じでしょうか。

そう考えるとプラグインってそんな大層なものではなくて、単純にプラグインディレクトリにファイルがあったら wordpress がコアを初期化したあとにそこにあるファイルを読み込みますよ。っていうだけと言っても過言ではないように思います。
そこで好きなことしてね。ただし任意のタイミングで機能を呼ぶ必要があるときには wordpress のライフサイクルフックに差し込んでくださいね。ということだと思います。
もしフックが必要なければ単純にプラグインに処理を記述するだけですね。ユーザのページロード毎に呼ばれるプラグインが出来上がります。

公式の中でも結構 deprecated と記載されているドキュメントも多かったので、実際にプラグインを開発したり公開する場合は最新の情報を検索しながら追いかけていくことも必要になりそうです。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください