WordPressプラグイン開発のススメ～実践編

WordPressプラグイン開発のススメ～入門編の続きです。
実践的なサンプルコードでプラグイン開発に触れてみましょう。

functions.phpでやっていることをプラグインで

HTMLが先行してできあがっている開発の場合は、どうしても不要になりがちな自動整形機能、これを無効化する処理です。

// 本文の自動整形を無効化する
remove_filter('the_content', 'wpautop');
// 抜粋の自動整形を無効化する
remove_filter('the_excerpt', 'wpautop');

これをプラグインにしてみましょう。

<?php
/*
 Plugin Name: Control AUTOP Plugin
 Description: 自動整形機能を無効化するプラグイン
 */

// 本文の自動整形を無効化する
remove_filter('the_content', 'wpautop');
// 抜粋の自動整形を無効化する
remove_filter('the_excerpt', 'wpautop');

これをプラグインとしてインストールすると、「Control AUTOP Plugin」を有効化した場合に、自動整形機能が無効化されます。無効化した場合に、自動整形機能が有効化されます。

functions.phpでできないことをプラグインで

標準でバックアップをとれる利点はあるものの、放っておくとDBを圧迫しかねない投稿のリビジョン、これを制限する処理です。

// リビジョンの数を3つに制限する
define( 'WP_POST_REVISIONS', 3 );

リビジョンを保存しないようにする処理です。

// リビジョンの保存を無効化する
define( 'WP_POST_REVISIONS', false );

これをfunctions.phpに書き込むことはできません。'WP_POST_REVISIONS'はテーマを読み込むより先にwp_functionality_constants()の中で定義済みなので、定数の再定義ということになってしまい、これは不可能なのです。
書き込むなら、wp-config.phpに。ですが、コアファイルをあまり汚したくない人もいるでしょう（筆者）。
ならばプラグインだ。

<?php
/*
 Plugin Name: Control Revision Plugin
 Description: リビジョンの保存を無効化するプラグイン
 */

// リビジョンの保存を無効化する
define( 'WP_POST_REVISIONS', false );

これをプラグインとしてインストールすると、「Control Revision Plugin」を有効化した場合に、リビジョンの保存が無効化されます。無効化した場合に、リビジョンの保存が有効化されます。

functions.phpでやること

こうなると、いろんなことをプラグインでやって、functions.phpでやることがなくなりそうですが。
テーマと密接に関わるものは、プラグインではなくfunctions.phpでやったほうがよいでしょう。
例えば、カスタム投稿タイプの定義とか。htmlのコードを生成する関数とか。
別のテーマで再利用されたり当該テーマで不要になったりならなかったりが考え難いものですね。

こんな感じで、適宜プラグインの作成をしてみましょう。

WordPressプラグイン開発のススメ～入門編

WordPressのテーマ（テンプレート）開発をしていて、独自関数の定義や設定の書き換えをするとき、テーマ内のfunctions.phpに書き込んでいくのが基本かと思われます。
かくいう筆者も、WPテーマ開発に参画した当初は、仕様に合わせて実現方法を調べて、見つけた方法でコードをfunctions.phpにどんどん書き込んでいました。

時は流れて最近。WPにもう一歩踏み込んでみて、何でもかんでもfunctions.phpではなく、どんどんプラグイン化してしまうのもアリだな…？と感じるようになりました。

メリット

１．再利用が楽
わかりやすいメリットはこれですね。

２．要/不要の切り替えが楽
個人の好みによるかとは思いますが、functions.phpの一部をコメントアウトしたり戻したりするよりスマートでは。

３．functions.phpより読み込みが先
個人的には目から鱗だったメリットはこれです。
以下、WP（※WordPress 5.1.1）のコアファイルに踏み込んだお話ですが。
wp-settings.phpの中で、

foreach ( wp_get_active_and_valid_plugins() as $plugin ) {
    wp_register_plugin_realpath( $plugin );
    include_once( $plugin );
    do_action( 'plugin_loaded', $plugin );
}

でプラグインを読み込む処理の方が、

foreach ( wp_get_active_and_valid_themes() as $theme ) {
    if ( file_exists( $theme . '/functions.php' ) ) {
        include $theme . '/functions.php';
    }
}

でテーマを読み込む処理より先に行われています。さらに言うと、プラグインを読み込む処理とテーマを読み込む処理の間には、

wp_functionality_constants();

なども挟まっているので、functions.phpではできない、一部の定数の定義が可能になったりするんです。

デメリット

１．テーマファイル群とプラグインファイル群に分かれる
管理する範囲が、テーマファイル群１フォルダで済むところ、２フォルダ（以上）になったり。

２．有効化が必要
不要な時の無効化が楽な半面、管理画面（またはDB直接更新）で有効化が必須。

プラグインをつくってみる

今回は、「My Pluginという名前の」「固定のメッセージを返す関数を提供する」プラグインを作成し、テーマの中で使ってみましょう。

１．プラグインを作成する
１．１．ファイル構成
お馴染み「Hello Dolly」プラグインがそうであるように、１ファイルだけでも成立しますが、現実的には、フォルダ（パッケージ）を用意してその中にプラグインを構成するファイル群を配置することになるでしょう。
今回は、my-pluginフォルダを用意し、その中にプラグインのメインになるmy-plugin.phpファイルを配置します。

my-plugin/
  └my-plugin.php

１．２．ファイルヘッダー

テーマのstyle.cssにそのテーマの情報を書いたり、個々のページテンプレートファイルにそのテンプレートファイルの情報を書いたりするように、プラグインのメインになるファイルにはそのプラグインの情報を書きます。

my-plugin.php

<?php
/*
Plugin Name: My Plugin
Description: 固定のメッセージを返す関数を提供するプラグイン
*/

最低限必要な情報

• Plugin Name（プラグインの名前）

次いで必要な情報

• Description（プラグインの説明）

その他

• Plugin URI
• Version
• Author
• Author URI
• License
• Text Domain
• Domain Path

１．３．プログラミング
functions.phpと書き方は同じです。PHPの記法に沿ってクラス定義やユーザー定義関数の作成などをします。

my-plugin.php

<?php
/*
Plugin Name: My Plugin
Description: 固定のメッセージを返す関数を提供するプラグイン
*/

/**
 * 固定のメッセージを返す
 * 
 * @return string メッセージ
 */
function get_my_plugin_message() {
    return 'This is My Plugin.';
}

２．プラグインを使う
２．１．ファイルアップロード
配布されているプラグインを手動インストールする場合、WPディレクトリ下のwp-content/pluginsフォルダにプラグイン用フォルダをアップロードしますね。
同じように、WPディレクトリ下のwp-content/pluginsフォルダにmy-pluginフォルダをアップロードします。

wp-content/
  └plugins/
      └my-plugin/
          └my-plugin.php

２．２．有効化
配布されているプラグインのインストールが済んだら、管理画面から有効化しますね。
同じように、管理画面のプラグイン画面を開き、「My Plugin」の有効化をクリックします。

２．３．テーマの中で使ってみる
有効化されたプラグイン内のユーザー定義関数などは、functions.phpや個々のページテンプレートファイルで使用できます。
例えば以下のように。

index.php

<?php echo get_my_plugin_message(); ?>

以上、プラグインのつくり方でした。