WordPressのプラグインを実際に作っていきながら、開発の流れやポイントなどをまとめていこうと思います。
この手の解説記事は全体の開発を行ってから記事にまとめる流れで作られているものも多いと思いますが、今回は実際の開発と並行して記事を書いているのでどれくらいの長さになるのか未定です。またもしかすると間違った説明で手戻りしちゃうかもしれませんがご了承ください。
今回は前置きとして、実際の作業を進める前に、そもそもプラグインとテーマの違いなどを把握し、プラグインとして開発する必要性について確認していきたいと思います。
WordPressでのプラグイン開発の必要性を考える
そもそも、WordPressでプラグイン開発が必要になるのはどんな状況でしょう。
WordPressは非常に幅広いカスタマイズ性が特徴のCMSで、このカスタマイズ性の多くはユーザーにより公開されているテーマやプラグインによる機能拡張により提供されています。
WordPressテーマとプラグインの違い
WordPressを拡張する機能として提供されている前述の「テーマ」と「プラグイン」ですが、これらの区分は大きくそれらが提供する機能に違いがあり、テーマは主にWebサイトの見た目やコンテンツ構造などにかかわる全体的な「ビジュアル面」の提供、プラグインは主に見た目以外の動作やツールなどを追加する「機能面」の提供としておおよそ区別されます。
と、テーマとプラグインの違いに触れたものの、WordPressのテーマとプラグインの導入をいくつか試された方にはすでにお分かりかと思いますが、テーマとプラグインは相互に機能が共通しているケースが多くあります。
例えば、投稿をSNSなどに共有するための機能を提供するものとして、導入することでFacebookやTwitterへのシェアボタンを表示するプラグインもあれば、テーマによってはそのようなプラグインを利用せずにシェアボタンを表示するものもあります。
では、テーマとプラグインを明確に分ける違いはどこにあるのでしょうか。作れるモノが同じであればわざわざWordPressでの機能上でも区別する必要はないようにも思えます。
テーマ関数、プラグイン関数でできることの違い
WordPressでのテーマとプラグインを分ける違いのひとつに、テーマ関数とプラグイン関数の利用が挙げられます。これらはその名前の通り、テーマやプラグインを開発するために用意された関数です。
このテーマ関数、プラグイン関数を見てみるとそれぞれの使われ方の違いなどをある程度理解することができます。
例えば、WordPressのリファレンスからテーマ関数の項目を見てみると「comments_template」「get_footer」「get_header」「get_template」などのhtmlテンプレートの読み込みや見た目の状態を取得する関数などが用意されています。また、プラグイン関数の項目には「register_activation_hook」「register_deactivation_hook」など、プラグインの有効無効を切り替えた時に動作させる関数などが用意されています。
こういった違いから「テーマ」と「プラグイン」の特徴を列挙してみると以下のようなものが挙げられます。
| テーマ | プラグイン |
|---|---|
| サイト全体の見た目を完全に作る必要がある。 （一部分だけを作る、ということはできない） | サイトの一部に対して部分的な機能を追加できる |
| 子テーマという機能を使うことで、 テーマの部分的な追加・変更をユーザーの手で行うことができる | 既存のプラグインの部分的な追加、変更を行うことはできない（困難） |
| 必ず1つはテーマが動作している必要がある | 有効、無効の切り替えができる |
| wordpress.orgサイトに公開してユーザーに使ってもらうことができる（親テーマ、子テーマいずれも可能） | wordpress.orgサイトに公開してユーザーに使ってもらうことができる |
WordPressの追加開発やカスタマイズなどを行いたい場合、これらの違いを踏まえてどういう方法で行うかを決めていく必要があるかと思います。
テーマで作るかプラグインで作るか
では、もしWordPressで何かカスタマイズや機能追加を行いたい場合、テーマで作るかプラグインで作るか、またその他の方法で行うかのどの方法を取ればよいでしょうか。
ざっくりですがWordPressでやりたいことに対しての開発や改修の対象となるものを列挙してみました。
| WordPressでやりたいこと | 開発・改修対象 |
|---|---|
| 文字やボタンなどの要素の見た目を変更したい | 子テーマの変更（子テーマCSS） |
| 文字やボタンなどの要素の位置を変更、追加したい | 子テーマの変更（テンプレート） |
| 現在のサイトのために独自機能を追加したい | 子テーマの変更（functions.php） |
| 現在および今後構築するサイトのために独自機能を追加したい（再利用や流用を考慮しない） | 子テーマの変更（新クラスや関数を外部化し、functions.phpから呼び出し） |
| 現在および今後構築するサイトのために独自機能を追加したい（再利用を考慮したいが、プラグインとの連携などが必要） | 子テーマの変更（新クラスや関数を外部化し、functions.phpから呼び出し） |
| 現在および今後構築するサイトのために独自機能を追加したい（再利用を考慮し、独立した機能を構築する） | プラグインの新規開発 |
| 新しい見た目や機能を満たすサイトをゼロからデザインしたい | 親テーマの開発 |
上記のリストを見ていただいたもおおよそわかる通り、現在のサイトに独自の見た目や機能を追加するためであれば、そのほとんどは子テーマに対するカスタマイズで実現できます。
プラグインとして実装するかどうかのポイントとしては、他サイトなどでの再利用が必要となるかどうかが挙げられるかと思います。
WordPressは多様なカスタマイズ方法が用意されているとともに、これらを連携させることで低コストでサイトに大きな改修や機能追加を行うことができます。例えば、Advanced Custom Fieldsプラグインを使うと、WordPressサイトに独自のデータベーステーブルのようにカスタムフィールドを追加し、投稿ごとに追加のデータを記録してそれらを子テーマのfunctions.phpやテンプレートファイルから呼び出して複雑なWebサイトを構築することなどが可能です。
このように追加のプラグインを使って子テーマを改修することでカスタマイズそのものの負担を軽減できるメリットがありますが、これらで加えたカスタマイズを動作させるためにはテーマが提供する機能や連携する追加プラグインなどが使えることが前提となってしまうため、サイトの移行やバージョンアップ、他サイトでの再利用などが容易に行えない（移行時の負担がより重くなる）可能性があるというデメリットも発生します。
この負担は事前に完全に見積もることは難しいため、多くのケースでは実装が容易な子テーマの改修を優先的に選んでしまうかもしれませんが、複数サイトを運営している場合や、のちのち機能を独立的にリリースしたい場合などは、それらを考慮してプラグインとして設計・開発することも選択肢のひとつとなります。
機能を外部化してプラグイン化
子テーマのカスタマイズのデメリットとして他サイトでの再利用の負荷が重くなるとの話をしましたが、一方で再利用やサイト移行などのタイミングでプラグイン化の検討を行うという判断もあるかと思います。
開発コストとの兼ね合いになるかとは思いますが、実装する機能が一般的なものであれば、プラグイン化しておくことで新しいサイトで利用する際のコストを大幅に削減できるほか、プラグインをwordpress.orgサイトに公開できればさらに広いユーザーに利用してもらうことなども可能です。
これらは一般的な生産活動などで行われる「ワンオフ」と「量産」、「書き下ろし」と「テンプレート化」などと同様の考え方に当てはまります。
WordPressのカスタマイズは再利用を考慮するとどうしてもコストが上がりがちですが、今回の例などを参考に、同様の作業に繰り返し直面した時にその作業の負担を見直してプラグインの開発を進めていくのが良いのではないかと思います。
コメント