WP REST APIをプラグインに組み込む!:その1. REST APIの存在確認

現在、私が開発している「Custom DataBase Tables」プラグインに「WordPress REST API」プラグインの RESTful な仕組みを取り込もうとしている。

Custom DataBase Tables」プラグインは、WordPressサイトにユーザー独自のテーブルを自由に作れ、テーブルさえ作ってしまえばショートコードを使って自動生成型のデータ入力フォームやらデータ閲覧リスト、編集用コンポーネントを簡単に設置できるというモノだ。
何気にバージョン1の時点から、URLベースでデータ入力や参照ができる「Web API」の仕組みを独自で実装していた(WordPressのRewrite仕様をカスタマイズしている)のだが、バージョン2以降はその辺の仕組みの保守をおざなりにしていたこともあって、動作不良が多い機能になってしまった。
──そんなわけで、本当は現行バージョンの2.1.xにアップグレードする際に「WordPress REST API」の仕組みを取り込んでリファクタリングしようと思っていたのだが、他のコア部分のリファクタリングに手一杯で着手できずじまいだった…。その後は、WordPressのコアにREST APIが組み込まれるということだったので、コアに実装されたら取り掛かろう…とか考えていたのだが、現在のWordPress 4.6.1の時点でも完全なビルトインがされていない実情だ。それにしびれを切らしたこともあって、今回のリファクタリングを行うことにしたのだ。

──と、まぁ、経緯は別段どうでもいいのだが、今回「WordPress REST API(Version 2)」を利用したプラグインのカスタマイズを行う過程で、色々と四苦八苦したことや気づいたことがあったので何回かのトピックスに分けてナレッジ化しておこうと思った次第だ。

WordPress REST API の存在確認

今回のトピックでは、WordPress REST APIがインストールされて有効化されているかどうかを確認する処理部分について紹介しておく。
もし、WordPress REST APIを利用した機能が自分のプラグインの新機能であれば、元々ユーザさんの環境にREST APIプラグインがインストールされて稼働していることを前提にしてプラグインをリファクタリングしてもそれほど問題は起きないかもしれないが、私のプラグインのようにすでにREST APIと競合する機能が実装されていて、REST APIのあり/なしで使用する機能をスイッチさせたいと考えた場合、ユーザのWordPress環境にREST APIプラグインが導入されているかどうかを判定するロジックが必須になるのだ。

今回のトピックはWordPress REST APIプラグインのみならず、自分のプラグインやテーマ等で他のプラグインとの連携を実装する場合の共通処理と云えるので、覚えておくと何かと有効かもしれない。

有効なプラグインを判定するための関数 is_plugin_active()

WordPressには有効化されているプラグインを判定する関数として、is_plugin_active()が用意されているので、この関数を使って「WordPress REST API」プラグインが有効になっているかどうかを判定することになる。ただし、この関数はクセがあって、管理画面側とフロントエンド側では使い方が異なるのだ。
詳しくはCodexに説明されているが、簡単に言うと、フロントエンド側でこの関数を使って判定を行う場合、wp-admin/includes/plugin.phpファイルのインクルードが必要になる。以下の「WordPress REST API」プラグインを判定する場合の実例コードを見てもらいたい。

まず、管理画面側では、

一方、フロントエンド側では、

──と記述することになる。
ちなみに引数に指定する値は「プラグインのディレクトリ名/プラグインのベースファイル名」となる。もし将来、判定するディレクトリ名やファイル名が変更された場合、指定引数も変更する必要が出てくるので、注意が必要だ。

もし、管理画面側とフロントエンド側とで処理を分けていない場合や、テーマのfunctions.php等で判定を行う場合なら、下記のように一元化した判定処理をアクションフックにラップするのがベストかもしれない。

プラグインのバージョン番号を判定する

「WordPress REST API」の現在の主流はバージョン2系であり、バージョン1系と2系では機能に差があるため、組み込むプラグイン側でREST APIの利用条件としてはバージョン2系以上に制限をしたい。そのためにはプラグインのバージョンを判定する必要がある。
WordPressにはプラグインのバージョンなどのメタデータを取得できる関数として get_plugin_data() が準備されているので、この関数を使って、ユーザが使用しているWordPress REST APIプラグインのバージョンを判定してみる。

上記は、WordPress REST APIプラグインのバージョン2系以上を判定するだけのコードだ。一応、このバージョン判定で、もしバージョン番号から「beta」の記述が外れたり、3.0系になった場合でもTRUEとなるが、バージョン番号書式が変更された場合は判定処理が正常に動作するかの再確認は必要だろう。
さて、これを前項のプラグイン有効化判定にマージすると、次のようなコードになる。

ちなみに、get_plugin_data() 関数ではバージョン番号の他にも様々なメタ情報が取得できるので、もし他のメタ情報を取得したい時などにはCodexを参照してみて欲しい。

REST APIプラグインが有効な場合に管理画面のメニューを変更する

「Custom DataBase Tables」プラグインでは、WP REST APIが有効になっている場合に、プラグインメニューのサブメニューを「WEB APIs」ではなく「REST APIs」に変更して、管理画面も別画面を用意することにした。このように、あるプラグインの存在確認後に管理メニューの表示等を変更する場合、前述の例のようにプラグイン判定処理を「admin_init」のアクションにフックしてしまうと、メニューが変更できなくなってしまう。
なぜなら、管理メニューのカスタマイズを行うためのアクションフック「admin_menu」のフックポイントが「admin_init」より前にあるため、メニューのカスタマイズ処理がプラグイン判定処理より前に実行されてしまうのだ。
Codexでは is_plugin_active() を管理画面側のフックで使う場合は「admin_init」以降で使いなさいと謳っているのだが、今回は管理画面側でもフロントエンド側と同様に「init」で発火させるようにした。基本的に「init」のフックポイントには、管理画面やフロントエンドの区別なくプラグイン読み込み後の初期化処理で利用できるものなので、特に問題は出ない。

最終的に、「init」アクションフックで「WordPress REST API Version 2」が有効になっているか確認し、有効であればその状態をフラグとして変数に格納しておき、その変数を条件として管理メニューのカスタマイズを行うという建付けになった。
なお、下記のサンプルは、私の「Custom DataBase Tables」の管理画面用のClassを要所のみピックアップして、概念化したものだ(なので、そのままコーディングしても動作しないので注意が必要)。

これで、今回のトピックは終了である。

(今回の「WP REST API」プラグインのように)外部のリソースに依存するような仕組みをプラグインに持たせる場合、その外部リソースを利用していない環境でもエラーが発生しないように作ることは地味に大切だと思う。私見にはなるのだが、そういうところがしっかりしていると利用してくれるユーザからのアプリケーションへの信頼感を無駄に失わなくて済むからだ。
経験則的に、プラグインやテーマを利用していてエラーとかが発生すると、そのエラーがクリティカルなものではなかったとしても、そのアプリケーションへの信頼感は下がってしまう感じがする(いやぁ、自分で書いておきながら、耳が痛いなぁ……苦笑)。

次回はカスタム・エンドポイントを使ってプラグインの独自処理を作ってみるトピックにしようかと…。

Leave a Reply

Your email address will not be published.