WordPressプラグイン開発の覚書です。
WordPressプラグイン開発入門!
functions.phpをプラグイン化
最初、functions.phpで作りたいもののコードを書きました。テストにはいいでしょう。
このファイルをそのままプラグイン化できます。
functions.phpは本来、テーマ固有の機能を実装するためのファイルなので簡単なテストが終わったらプラグイン化します。
Localを使用している場合は、Localの開発環境内のWordPressプラグインディレクトリ（wp-content/plugins/）に新しいディレクトリとファイルを作成します。
プラグイン化に必要な最低限のコードは次だけのようです。このコードを書いたフォルダをプラグインフォルダに放り込むと、ActivateとDeactivateができます。
<?php
/*
Plugin Name: Sample
*/Localをインストールしていない場合はローカルをいれます。
- 新しいディレクトリ内に、メインのPHPファイルを作成します。例えば、「title-image-gen.php」という名前にします。
- プラグインのヘッダー情報を追加します。
<?php
/*
Plugin Name: Title Image Gen
Plugin URI: https://www.ithands.dev/
Description: 投稿タイトルからアイキャッチ画像を自動生成するプラグイン
Version: 1.0
Author: neru
Author URI: https://www.ithands.dev/
*/- functions.phpのコードをプラグインのファイルにコピー
- functions.phpから移行したコード内で、テーマのディレクトリを参照しているパスがある場合は、プラグインのディレクトリを参照するように修正します。
- WordPress管理画面の「プラグイン」メニューから、作成したプラグインを有効化します。
functions.phpをプラグイン化する場合のパス指定
基本コピペでいいですが、functions.phpとパスが違います。フォントファイルなどがある場合はパスを書き換えましょう。
// functions.PHPのパス指定
// $font_path = ABSPATH . 'wp-content/themes/cocoon-child-master/fonts/NotoSansJP-Regular.ttf';
// プラグインのパス指定
$font_path = plugin_dir_path(__FILE__) . 'fonts/NotoSansJP-Regular.ttf';プラグインページのフォルダ構成
plugin-directory/
├── plugin-main-file.php
├── includes/
│ ├── settings-page.php
│ └── ...
├── assets/
│ ├── css/
│ │ └── ...
│ ├── js/
│ │ └── ...
│ └── images/
│ └── ...
├── templates/
│ └── ...
└── languages/
└── ...プラグインページのadd_options_pageとファイル分割
プラグインの設定ページを追加したい場合は、WordPress の add_options_page 関数を使用してページを追加し、設定項目を登録します。 add_options_page 関数は、プラグインの設定ページをWordPressの管理メニューに追加するために使用します。この関数を使用しない場合、設定ページはWordPressの管理メニューに表示されません。
require_onceはファイル分割です。
<?php
/*
Plugin Name: Your Plugin
Plugin URI: https://example.com/
Description: Your plugin description
Version: 1.0
Author: Your Name
Author URI: https://example.com/
*/
// 設定ページを追加するアクションフック
add_action( 'admin_menu', 'your_plugin_add_settings_page' );
function your_plugin_add_settings_page() {
add_options_page(
'Your Plugin Settings',
'Your Plugin',
'manage_options',
'your-plugin-settings',
'your_plugin_render_settings_page'
);
}
// 設定ページのファイルを読み込む
require_once plugin_dir_path( __FILE__ ) . 'settings-page.php';<?php
// 設定ページのHTMLとPHPコードをここに記述します
function your_plugin_render_settings_page() {
?>
<div class="wrap">
<h1>Your Plugin Settings</h1>
<form method="post" action="options.php">
<?php settings_fields( 'your_plugin_settings' ); ?>
<?php do_settings_sections( 'your-plugin-settings' ); ?>
<?php submit_button(); ?>
</form>
</div>
<?php
}プラグインの初期化処理
プラグインの規模が小さく、初期化処理が必要ない場合は、直接メインファイルでファイルを読み込んでも問題ありません。 提示していただいたコードのように、plugins_loaded アクションフックを使用して初期化処理を行うことは良い方法です。
/**
* プラグインの初期化処理
*/
function title_image_generator_init() {
// 設定ページのファイルを読み込む
require_once plugin_dir_path(__FILE__) . 'includes/settings-page.php';
}
add_action('plugins_loaded', 'title_image_generator_init');require、require_once、include、include_onceの違い【PHP】
require:
- 指定されたファイルを読み込み、実行します。
- ファイルが存在しない、または読み込みに失敗した場合、致命的なエラー（E_COMPILE_ERROR）が発生し、スクリプトの実行が停止します。
- 同じファイルを複数回読み込もうとすると、その都度ファイルが読み込まれます。
require_once:
- 指定されたファイルを読み込み、実行します。ただし、同じファイルが既に読み込まれている場合は、重複して読み込まれません。
- ファイルが存在しない、または読み込みに失敗した場合、致命的なエラー（E_COMPILE_ERROR）が発生し、スクリプトの実行が停止します。
include:
- 指定されたファイルを読み込み、実行します。
- ファイルが存在しない、または読み込みに失敗した場合、警告（E_WARNING）が発生しますが、スクリプトの実行は継続します。
- 同じファイルを複数回読み込もうとすると、その都度ファイルが読み込まれます。
include_once:
- 指定されたファイルを読み込み、実行します。ただし、同じファイルが既に読み込まれている場合は、重複して読み込まれません。
- ファイルが存在しない、または読み込みに失敗した場合、警告（E_WARNING）が発生しますが、スクリプトの実行は継続します。
WordPressのプラグインが古い理由
WordPress のバージョンが上がった際に、プラグインが古いと表示されるのは、プラグインの互換性に関する情報が更新されていない場合に発生します。この情報は、プラグインのメインファイルにあるプラグインヘッダーの一部である “Requires at least” と “Tested up to” で指定されています。
<?php
/*
Plugin Name: Title Image Generator
Plugin URI: https://example.com/
Description: 投稿タイトルからアイキャッチ画像を自動生成するプラグイン
Version: 1.0
Author: Your Name
Author URI: https://example.com/
Requires at least: 5.0
Tested up to: 5.7
*/動作する場合は数字を変えるだけで、WordPressのバージョン対策はできます。
WordPressプラグイン開発のsettingページ作成
最小のサンプルはこうです。
<?php
/*
Plugin Name: Sample
*/
/**
* プラグインの設定ページを追加
*/
function myplugin_add_settings_page() {
// 'add_options_page' 関数を使って新しい設定ページを追加する
add_options_page(
'マイプラグイン設定', // 設定ページのタイトル名
'マイプラグイン', // サイドのSettingsに表示されるメニュー名
'manage_options', // この設定ページを表示するために必要な権限
'myplugin', // 設定ページのスラッグ（URLの一部になる）
'myplugin_render_settings_page' // 設定ページのHTMLを出力する関数の名前
);
}
// 'admin_menu' アクションフックに 'myplugin_add_settings_page' 関数を登録する
// これにより、WordPress は管理者メニューを構築する際に 'myplugin_add_settings_page' 関数を呼び出す
add_action('admin_menu', 'myplugin_add_settings_page');ただし、これだけだとマイプラグインを選んでも灰色の画面が表示されるだけです。htmlを追加してあげます。基本的にhtmlとセットで作っていく感じです。
/**
* プラグインの設定ページのHTMLを出力
*/
function myplugin_render_settings_page() {
?>
<div class="wrap">
<h1>マイプラグイン設定</h1>
<form method="post" action="options.php">
<?php
settings_fields('myplugin_settings');
do_settings_sections('myplugin');
submit_button();
?>
</form>
</div>
<?php
}上記を追加すると、マイプラグイン設定とsave changesというボタンが表示されます。
保存まわりについては詳しくはこちらの記事をみてください。
設定ページの作成
WordPress のプラグイン開発において、設定項目を扱う際の基本的な流れは以下の通りです。
- 設定項目を関数として定義する
- 各設定項目の名前、デフォルト値、入力フィールドのHTMLなどを定義します。
- これは通常、
add_settings_field関数を使って行います。
- 設定項目を
register_settingで WordPress に登録するregister_setting関数を使って、各設定項目を WordPress のオプションAPIに登録します。- これにより、WordPress は設定項目の名前、デフォルト値、データベースのオプション名、検証用コールバック関数（オプション）を知ることができます。
- 設定ページのHTMLを出力する
- 設定ページのHTMLを出力する関数を定義し、
add_options_page関数を使ってその関数を設定メニューに登録します。 - 設定ページのHTMLには、設定項目の入力フィールドを含めます（
do_settings_sections関数を使う）。 - また、フォームの
action属性をoptions.phpに設定しておきます。
- 設定ページのHTMLを出力する関数を定義し、
これがプラグイン開発者の主な仕事です。設定項目の定義と登録、そして設定ページのHTMLの出力です。
あとは、WordPress のoptions.phpページが自動的に以下のことを行ってくれます：
- 設定ページのフォームがサブミットされたら、POSTデータから新しい設定値を取得する。
- 新しい設定値を検証する（
register_settingで登録された検証用コールバック関数を使う）。 - 検証に合格した新しい設定値をデータベースに保存する（
update_option関数を使う）。
つまり、プラグイン開発者は設定項目の定義と登録に集中でき、データの保存と読み込みの詳細は WordPress に任せることができるのです。
これは WordPress の設定APIの大きな利点の一つで、プラグイン開発者の負担を大幅に軽減してくれます。設定項目を適切に定義し、register_settingで登録さえしておけば、あとはWordPressがデータの保存と読み込みを自動的に行ってくれるのです。
add_settings_sectionとadd_settings_field
add_settings_section: 設定ページにセクション（設定項目のグループ）を追加する。
add_settings_field: セクションに設定フィールド（個々の設定項目）を追加する。
もう少し詳しく説明すると：
add_settings_section:
- 設定ページを論理的なセクションに分割するために使用されます。
- 各セクションはタイトルを持ち、関連する設定フィールドをグループ化します。
- セクションはオプションで説明文を持つことができます。
- セクションそのものは設定値を保持しません。設定値はフィールドに保持されます。
add_settings_field:
- 設定ページに実際の設定フィールド（テキストボックス、チェックボックス、ラジオボタンなど）を追加するために使用されます。
- 各設定フィールドはラベルを持ち、特定の設定値を保持します。
- 設定フィールドのHTMLは、指定されたコールバック関数によって出力されます。
- 設定フィールドは特定のセクションに属します（セクションを使わない場合もあります）。
add_settings_section 関数は以下のパラメータを取ります：
$id: セクションの一意の識別子（ID）。$title: セクションのタイトル。設定ページ上に表示されます。$callback: セクションの説明を出力するためのコールバック関数。必要なければnullを指定します。$page: セクションを追加するページのスラッグ。add_options_page関数で指定したスラッグと同じものを使います。
セクションを追加した後、add_settings_field 関数を使って、そのセクションに設定フィールドを追加します。
add_settings_field 関数は以下のパラメータを取ります：
$id: 設定フィールドの一意の識別子（ID）。$title: 設定フィールドのラベル。設定ページ上に表示されます。$callback: 設定フィールドのHTMLを出力するためのコールバック関数。$page: 設定フィールドを追加するページのスラッグ。add_settings_section関数で指定したページのスラッグと同じものを使います。$section: 設定フィールドを追加するセクションのID。add_settings_section関数で指定したIDと同じものを使います。
プラグインのアンインストール
register_settingやupdate_optionを使ってデータベースに追加したデータをどこかでクリアしなければなりません。プラグインをアンインストールする際にdelete_optionを呼べばOKです。
/**
* プラグインのアンインストール時にデータのクリア
*/
function myplugin_uninstall() {
delete_option('myplugin_text');
}
register_uninstall_hook(__FILE__, 'myplugin_uninstall');DBをチェックすると、保存されたデータが削除されていることが確認できます。
uninstall.phpの動作
- 配置場所:
uninstall.phpファイルは、プラグインのメインディレクトリ（通常はwp-content/plugins/あなたのプラグイン名/）に配置します。 - 自動実行: WordPressは、プラグインが削除（アンインストール）される際に、自動的にこのファイルを探して実行します。
- 実行タイミング: プラグインが WordPress 管理画面から削除される時にのみ実行されます。単に無効化されただけでは実行されません。 FTP などで直接ファイルを削除した場合は実行されません。
- セキュリティ:
uninstall.phpの冒頭にif (!defined('WP_UNINSTALL_PLUGIN')) { exit; }を含めることで、直接アクセスされた場合の実行を防ぎます。 - 代替方法:
uninstall.phpの代わりに、プラグインのメインファイルでregister_uninstall_hook()を使用することもできますが、uninstall.phpの方が一般的で推奨される方法です。
コメント