WordPressのエラーページはショボすぎるし、エラーの内容がある程度想像できるし。ちょっと使いたくないです。
そんなとき自分でカスタマイズできます。ただPHPファイルを用意するだけなんだけど。
WordPressのドロップインという機能を使います。
WordPressには、テーマやプラグイン以外にテンプレートファイルを用意できる機能があります。
『ドロップイン』です。管理画面ではプラグインメニューの中にありますが、プラグインではありません。独立したテンプレート機能です。
ドロップインはテンプレートだけではありません。本来は機能拡張のためのものです。
(本当はテンプレートファイルじゃなくて拡張機能ファイル。)
wp-contentディレクトリ直下にファイルを置くので、WordPressシステム全体のカスタマイズです。
ドロップインの種類
拡張できるドロップインは_get_dropins()で取得できます。
function _get_dropins() {
$dropins = array(
'advanced-cache.php' => array( __( 'Advanced caching plugin.' ), 'WP_CACHE' ), // WP_CACHE
'db.php' => array( __( 'Custom database class.' ), true ), // Auto on load.
'db-error.php' => array( __( 'Custom database error message.' ), true ), // Auto on error.
'install.php' => array( __( 'Custom installation script.' ), true ), // Auto on installation.
'maintenance.php' => array( __( 'Custom maintenance message.' ), true ), // Auto on maintenance.
'object-cache.php' => array( __( 'External object cache.' ), true ), // Auto on load.
'php-error.php' => array( __( 'Custom PHP error message.' ), true ), // Auto on error.
'fatal-error-handler.php' => array( __( 'Custom PHP fatal error handler.' ), true ), // Auto on error.
);
if ( is_multisite() ) {
$dropins['sunrise.php'] = array( __( 'Executed before Multisite is loaded.' ), 'SUNRISE' ); // SUNRISE
$dropins['blog-deleted.php'] = array( __( 'Custom site deleted message.' ), true ); // Auto on deleted blog.
$dropins['blog-inactive.php'] = array( __( 'Custom site inactive message.' ), true ); // Auto on inactive blog.
$dropins['blog-suspended.php'] = array( __( 'Custom site suspended message.' ), true ); // Auto on archived or spammed blog.
}
return $dropins;
}
テンプレート | 何をする? | 使うこと ある? | 有効化 |
---|---|---|---|
advanced-cache.php | 独自のキャッシュ機能を実装する。 標準のオブジェクトキャッシュとの共存可。 | ○ | ファイルを置いただけでは機能しない。 wp-config.phpで『define('WP_CACHE', true);』の追加が必要。 |
object-cache.php | オブジェクトキャッシュの拡張。 永続的なキャッシュなどで使う。 | △ | ファイルを置く。 (オート有効) |
db.php | WordPressのDBを拡張する。 もしくはWP以外のDBを使う。 拡張DBアクセス処理のクラスなどを定義。 $wp_dbを上書きすることができる。 また、独立させて共存することもできる。 | ○ | ファイルを置く。 (オート有効) |
db-error.php | DBエラーページのカスタマイズ。 | ◎ | ファイルを置く。 (オート有効) |
install.php | 独自のインストーラーを定義。 | △ | ファイルを置く。 (オート有効) |
maintenance.php | メンテナンス中ページのカスタマイズ。 | ◎ | ファイルを置く。 (オート有効) |
fatal-error-handler.php | 独自のPHP Fatalエラーハンドラを定義。 | △ | ファイルを置く。 (オート有効) |
php-error.php | PHPエラーページのカスタマイズ。 | ◎ | ファイルを置く。 (オート有効) |
テンプレート | 何をする? | 使うこと ある? | 有効化 |
---|---|---|---|
sunrise.php | マルチサイトの立ち上げ時の処理を定義? くわしくは分からない。 | △ | ファイルを置いただけでは機能しない。 wp-config.phpで『define('SUNRISE', "任意の値");』の追加が必要。 |
blog-deleted.php | サイトが既に削除されたメッセージ出力ページのカスタマイズ。 | ◎ | ファイルを置く。 (オート有効) |
blog-inactive.php | サイトが非アクティブメッセージ出力ページのカスタマイズ。 | ◎ | ファイルを置く。 (オート有効) |
blog-suspended.php | サイトがアーカイブされている、停止されているメッセージ出力ページのカスタマイズ。 | ◎ | ファイルを置く。 (オート有効) |
WordPress.orgリファレンス
◎ ページのカスタマイズ
一番かんたんなドロップインでの拡張はページのカスタマイズです。なんらかのエラーやサイトが見れないメッセージを出力するページですね?
/wp-conent直下にファイルを置くだけなので設定も不要です。
マルチサイト
マルチサイトのページのカスタマイズは3つあります。
しかし、特権管理者以外のユーザーが、すでに停止、アーカイブ、削除したサイトの管理画面を表示しようとしたときにしか表示されません。
カスタマイズの優先度は低いでしょう。
一応、標準ではこんな感じのページが表示されます。
どういうとき? | 標準ページ | カスタム ファイル |
---|---|---|
サイトが削除されている。 | 別タブで見る | blog-deleted.php |
サイトを停止している。 | 別タブで見る | blog-inactive.php |
サイトがアーカイブされている。 | 別タブで見る | blog-suspended.php |
○△ がっつりプログラミング系
使う機会がけっこうあるけども、ドロップインで機能をがっつり実装するものはキャッシュ、データベースまわりです。
今回、この投稿を書くためにいろいろ調べてみましたが、具体的なHow Toは少ないので、WPソースを読んでそこから考えました。
既存DBとの統合(DB拡張)
まずは、DBセッティングのコードを見てみましょう。(WP5.4.1)
function require_wp_db() {
global $wpdb;
require_once ABSPATH . WPINC . '/wp-db.php';
if ( file_exists( WP_CONTENT_DIR . '/db.php' ) ) {
require_once WP_CONTENT_DIR . '/db.php';
}
if ( isset( $wpdb ) ) {
return;
}
$dbuser = defined( 'DB_USER' ) ? DB_USER : '';
$dbpassword = defined( 'DB_PASSWORD' ) ? DB_PASSWORD : '';
$dbname = defined( 'DB_NAME' ) ? DB_NAME : '';
$dbhost = defined( 'DB_HOST' ) ? DB_HOST : '';
$wpdb = new wpdb( $dbuser, $dbpassword, $dbname, $dbhost );
}
既存DBを拡張したければ、new wpdb()をdb.phpでセットすればいいです。
<?php
/**
ここで、拡張するものを$wpdbに突っ込む。
$wpdbはクラスオブジェクトなのでオブジェクト参照で追加すること。
/wp-includes/wp-db.phpのwpdbを継承した拡張クラス(自作)のnewが妥当か?
*/
$dbuser = defined( 'DB_USER' ) ? DB_USER : '';
$dbpassword = defined( 'DB_PASSWORD' ) ? DB_PASSWORD : '';
$dbname = defined( 'DB_NAME' ) ? DB_NAME : '';
$dbhost = defined( 'DB_HOST' ) ? DB_HOST : '';
class wpdb_ext extends wpdb {
// ここに拡張処理を書く。
}
global $wpdb;
$wpdb = new wpdb_ext( $dbuser, $dbpassword, $dbname, $dbhost );
別DBを独立して使う
今度は$wpdbとは別のDBをセッティングします。
($wpdbもセッティングする。複数DB環境の共存。)
<?php
/**
ここで、$second_dbに別DBのアクセスオブジェクトを突っ込む。
DBアクセス処理をいちから作る必要はない。
/wp-includes/wp-db.phpのwpdbを継承した別DB用クラスを用意すれば、作業が短縮できるはず。
*/
// wp-config.phpに定義しておくこと。
$dbuser = defined( 'SECOND_DB_USER' ) ? SECOND_DB_USER : '';
$dbpassword = defined( 'SECOND_DB_PASSWORD' ) ? SECOND_DB_PASSWORD : '';
$dbname = defined( 'SECOND_DB_NAME' ) ? SECOND_DB_NAME : '';
$dbhost = defined( 'SECOND_DB_HOST' ) ? SECOND_DB_HOST : '';
global $second_db;
class second_db extends wpdb {
// ここに処理を書く。
}
$second_db = new second_db( $dbuser, $dbpassword, $dbname, $dbhost );
まだ作る機会がないのでこのくらいしか言えません。あとはご自身でチャレンジしてください。
(でもやり方は伝わると思う。)
独自のキャッシュ機能
advanced-cache.phpはキャッシュ系プラグインをインストールしたときに勝手に作られることが多いです。
(もしくは、プラグインの設定を保存したら作られる。)
ということは、このファイルを使うキャッシュプラグインは共存できません。それぞれのプラグインが作るファイルの内容がちがうから。
自作したキャッシュ機能で使ってるときも同じです。
オブジェクトキャッシュ
WP標準のオブジェクトキャッシュは、クラスオブジェクトに情報を保持するキャッシュで、httpリクエストを受けてからレスポンスを返すまでの間しか記憶しません。
カート機能みたいなものは無理です。そこで拡張が必要になります。
まずは、オブジェクトキャッシュのセッティングを見てみましょう。
function wp_start_object_cache() {
global $wp_filter;
static $first_init = true;
// Only perform the following checks once.
if ( $first_init ) {
if ( ! function_exists( 'wp_cache_init' ) ) {
if ( file_exists( WP_CONTENT_DIR . '/object-cache.php' ) ) {
require_once WP_CONTENT_DIR . '/object-cache.php';
if ( function_exists( 'wp_cache_init' ) ) {
wp_using_ext_object_cache( true );
}
// Re-initialize any hooks added manually by object-cache.php.
if ( $wp_filter ) {
$wp_filter = WP_Hook::build_preinitialized_hooks( $wp_filter );
}
}
} elseif ( ! wp_using_ext_object_cache() && file_exists( WP_CONTENT_DIR . '/object-cache.php' ) ) {
wp_using_ext_object_cache( true );
}
}
if ( ! wp_using_ext_object_cache() ) {
require_once ABSPATH . WPINC . '/cache.php';
}
// 省略。
}
オブジェクトキャッシュは、拡張すると標準のオブジェクトキャッシュ(/wp-includes/cache.php)は使えなくなります。
(処理の展開(require)すらしない。)
なので、自分でwp_cache_***()の関数を用意する必要があります。
(テーマやプラグインでキャッシュ処理を入れている場合PHPエラーになるので。)
/**
既存のソースを丸ごとコピー(/wp-includes/cache.php)。
カスタム処理を追加したり、既存関数を修正する。
WP_Object_Cacheの子クラスを作ってオブジェクトのカスタムもあり。
ここではオブジェクトキャッシュのカスタマイズに特化する。別のキャッシュ機能はadvanced-cache.phpで。
*/
/**
* カスタムのクラスオブジェクトを使う場合
*/
/** WP_Object_Cache class */
require_once ABSPATH . WPINC . '/class-wp-object-cache.php'
class WP_Object_Cache_Ext extends WP_Object_Cache {
//ここでカスタマイズする。
}
function wp_cache_init() {
// オブジェクトキャッシュの載せ替え
$GLOBALS['wp_object_cache'] = new WP_Object_Cache_Ext();
}
// ほか省略。
これもまだ作る機会がないのでこのくらいしか言えません。あとは自身でチャレンジして下さい。
PHPパッケージのインストール
install.phpは、PHPパッケージのインストールなどWordPressの機能拡張に必要なプログラムをインストールするのに使います。
PHPじゃないといけないことはありません。pythonとか。
サンプルコードは省略します。
PHPエラーハンドラ
fatal-error-handler.phpはPHPエラーハンドラをカスタマイズします。
(このハンドラはPHPエラーが発生したときの挙動をコントロールする。)
これを変更する人はほとんどいないでしょう。
まあ変更するといっても、WP_Fatal_Error_Handlerの子クラスを作ってそれに載せ替えるだけなんですが。
WordPress.orgリファレンス
ただ、fatal-error-handler.phpの最後で、新しいハンドラクラスのインスタンスを返す必要があります。
if ( ! class_exists( 'WP_Fatal_Error_Handler' ) ) {
require_once ABSPATH . WPINC . '/class-wp-fatal-error-handler.php';
}
class Ext_WP_Fatal_Error_Handler extends WP_Fatal_Error_Handler {
// ここに拡張機能を突っ込む。
}
return new Ext_WP_Fatal_Error_Handler();
あまり使う気がしないので説明もこのへんで。
あっ、ひとつ忘れてました。ドロップインphp-error.phpは標準ハンドラの一部で、標準ハンドラのエラーページ出力のカスタマイズです。
php-error.phpのカスタマイズくらいじゃないかな? このへんをイジるのは。