仕組みを取り込もうとしている。Tables」プラグインは、WordPressサイトにユーザー独自のテーブルを自由に作れ、テーブルさえ作ってしまえばショートコードを使って自動生成型のデータ入力フォームやらデータ閲覧リスト、編集用コンポーネントを簡単に設置できるというモノだ。API」の仕組みを独自で実装していた(WordPressのRewrite仕様をカスタマイズしている)のだが、バージョン2以降はその辺の仕組みの保守をおざなりにしていたこともあって、動作不良が多い機能になってしまった。API」の仕組みを取り込んでリファクタリングしようと思っていたのだが、他のコア部分のリファクタリングに手一杯で着手できずじまいだった...。4.6.1の時点でも完全なビルトインがされていない実情だ。それにしびれを切らしたこともあって、今回のリファクタリングを行うことにしたのだ。2)」を利用したプラグインのカスタマイズを行う過程で、色々と四苦八苦したことや気づいたことがあったので何回かのトピックスに分けてナレッジ化しておこうと思った次第だ。APIがインストールされて有効化されているかどうかを確認する処理部分について紹介しておく。APIプラグインが導入されているかどうかを判定するロジックが必須になるのだ。APIプラグインのみならず、自分のプラグインやテーマ等で他のプラグインとの連携を実装する場合の共通処理と云えるので、覚えておくと何かと有効かもしれない。API」プラグインが有効になっているかどうかを判定することになる。この関数はクセがあって、管理画面側とフロントエンド側では使い方が異なるのだ。詳しくはCodexに説明されているが、簡単に言うと、フロントエンド側でこの関数を使って判定を行う場合、wp-admin/includes/plugin.phpファイルのインクルードが必要になる。API」プラグインを判定する場合の実例コードを見てもらいたい。APIが有効化されている時の処理}──と記述することになる。ちなみに引数に指定する値は「プラグインのディレクトリ名/プラグインのベースファイル名」となる。将来、判定するディレクトリ名やファイル名が変更された場合、指定引数も変更する必要が出てくるので、注意が必要だ。管理画面側とフロントエンド側とで処理を分けていない場合や、テーマのfunctions.php等で判定を行う場合なら、下記のように一元化した判定処理をアクションフックにラップするのがベストかもしれない。APIの利用条件としてはバージョン2系以上に制限をしたい。そのためにはプラグインのバージョンを判定する必要がある。APIプラグインのバージョンを判定してみる。APIプラグインのバージョン2系以上を判定するだけのコードだ。一応、このバージョン判定で、もしバージョン番号から「beta」の記述が外れたり、3.0系になった場合でもTRUEとなるが、バージョン番号書式が変更された場合は判定処理が正常に動作するかの再確認は必要だろう。これを前項のプラグイン有効化判定にマージすると、次のようなコードになる。関数ではバージョン番号の他にも様々なメタ情報が取得できるので、もし他のメタ情報を取得したい時などにはCodexを参照してみて欲しい。APIs」に変更して、管理画面も別画面を用意することにした。このように、あるプラグインの存在確認後に管理メニューの表示等を変更する場合、前述の例のようにプラグイン判定処理を「admin_init」のアクションにフックしてしまうと、メニューが変更できなくなってしまう。管理メニューのカスタマイズを行うためのアクションフック「admin_menu」のフックポイントが「admin_init」より前にあるため、メニューのカスタマイズ処理がプラグイン判定処理より前に実行されてしまうのだ。管理画面側のフックで使う場合は「admin_init」以降で使いなさいと謳っているのだが、今回は管理画面側でもフロントエンド側と同様に「init」で発火させるようにした。基本的に「init」のフックポイントには、管理画面やフロントエンドの区別なくプラグイン読み込み後の初期化処理で利用できるものなので、特に問題は出ない。2」が有効になっているか確認し、有効であればその状態をフラグとして変数に格納しておき、その変数を条件として管理メニューのカスタマイズを行うという建付けになった。Tables」の管理画面用のClassを要所のみピックアップして、概念化したものだ(なので、そのままコーディングしても動作しないので注意が必要)。}}これで、今回のトピックは終了である。API」プラグインのように)外部のリソースに依存するような仕組みをプラグインに持たせる場合、その外部リソースを利用していない環境でもエラーが発生しないように作ることは地味に大切だと思う。私見にはなるのだが、そういうところがしっかりしていると利用してくれるユーザからのアプリケーションへの信頼感を無駄に失わなくて済むからだ。経験則的に、プラグインやテーマを利用していてエラーとかが発生すると、そのエラーがクリティカルなものではなかったとしても、そのアプリケーションへの信頼感は下がってしまう感じがする(いやぁ、自分で書いておきながら、耳が痛いなぁ......苦笑)。次回はカスタム・エンドポイントを使ってプラグインの独自処理を作ってみるトピックにしようかと...。