WordPress mu-plugin の作り方

WordPress の mu-plugin (must-use プラグイン) は、wp-content/mu-plugins/ に配置する PHP ファイルで、WordPress がすべてのリクエストで自動的に読み込みます。管理画面から無効化することはできず、通常のプラグインよりも先に実行されます。カスタムフック、セキュリティルール、パフォーマンス調整、早期に読み込みたい定数など、常に存在させておく必要があるコードに使用します。

mu-plugin のもう一つの活用例は、プラグインや WordPress コアに機能を追加することです。たとえば WP STAGING には多数のフィルターとフックが用意されており、WP STAGING のステージング機能やバックアップ機能をさらに拡張できます。これらドキュメント化されたフィルターはすべて、独自の mu-plugin に組み込むことができます。

クイックアンサー: プラグインヘッダー付きの .php ファイルを wp-content/mu-plugins/ に置くだけです。WordPress は次のページ読み込み時にそのファイルを認識し、有効化の操作は不要です。読み込まれたかどうかは プラグイン → 使用中必須プラグイン で確認できます。

Must-Use プラグインの概要

mu-plugin は wp-content/mu-plugins/ に置かれ (このパスは WPMU_PLUGIN_DIR 定数で制御されます)、wp-content/plugins/ にある通常のプラグインよりも先に WordPress によって読み込まれます。標準のプラグイン一覧には表示されず、管理画面から無効化することもできません。

開発者が mu-plugin を選ぶ最も一般的な状況は次のとおりです。ある関数やフィルターが、それを含むプラグインを別の管理者が無効化したために動かなくなったり、プラグインの更新でカスタマイズが上書きされたりするケースです。mu-plugin はこの両方のリスクを一度に解消します。

WordPress の公式ドキュメントでは、must-use プラグインについて wordpress.org/documentation/article/must-use-plugins/ で解説されています。

同じコードを配置できる他の場所と比べて、mu-plugin はどう違うのでしょうか。

選択肢	自動読み込み	プラグイン更新に耐える	管理者が無効化可能	適した用途
mu-plugin	あり	あり	不可	常に実行すべきフック、定数、セキュリティルール
通常のプラグイン	有効時のみ	あり	可能	サイト所有者が制御するオプション機能
`wp-config.php`	あり	あり	不可	PHP の `define()` 定数のみ
`.htaccess` / `php.ini`	あり (サーバーレベル)	あり	不可	サーバーのリライトや PHP ini 設定

Mu-Plugin の利点

通常のプラグインに対する最大の利点は、改ざんに強いことです。通常のプラグインは、管理者権限を持つユーザーであれば誰でも無効化でき、認証情報が漏れれば削除される可能性もあります。mu-plugin にはこの心配がありません。

mu-plugin が適しているケース:

すべての通常プラグインが無効化されてもコードを実行する必要がある場合 (メンテナンス用リダイレクト、セキュリティヘッダー、HTTPS 強制ルールなど)
プラグイン本体の初期化より前に読み込む必要がある WP STAGING のアクションやフィルターを登録する場合
複数の WordPress サイトを運用しており、バージョン管理されたプラグインの外側でサイト固有の動作を実装したい場合
リクエストのライフサイクルの早い段階で、実行時の PHP 設定 (memory_limit など) を適用したい場合

通常のプラグインが適しているケース:

サイト所有者や開発者が機能をオン/オフできるようにしたい場合
その機能を自動更新付きのインストール可能な製品として提供する場合
他のプラグインが is_plugin_active() で検出できるものを作る場合

WordPress mu-plugin の作成方法

ステップ 1: サイトのファイルにアクセスする

FTP、SFTP、または Web ホストのファイルマネージャーを使ってサイトに接続します。

ステップ 2: mu-plugins ディレクトリを探すか作成する

wp-content/ に移動します。mu-plugins/ フォルダがあるか確認し、なければ作成してください。WordPress は追加の設定なしに、そのディレクトリからすぐに PHP ファイルの読み込みを開始します。

ステップ 3: プラグインファイルを作成する

新しい PHP ファイルを作成します。例: my-mu-plugin.php。ファイル名には小文字とハイフンを使い、スペースは使わないでください。ファイル名は WordPress 管理画面の プラグイン → 使用中必須プラグイン に表示されるため、内容が分かる名前を選びましょう。

ステップ 4: プラグインヘッダーとコードを追加する

mu-plugin にはすべて、通常のプラグインと同じく先頭にプラグインヘッダーのコメントが必要です。以下は最小限の構成です:

PHP

<?php
/*
Plugin Name: My Custom Mu-Plugin
Description: A custom must-use plugin to enhance my WordPress site.
Version: 1.0
Author: Mickey Mouse
*/

// Your custom code goes here

ステップ 5: Mu-Plugin をアップロードする

サーバー上の wp-content/mu-plugins/ に .php ファイルをアップロードします。

ステップ 6: 有効化を確認する

有効化の操作はありません。WordPress 管理画面の プラグイン → 使用中必須プラグイン を開き、ファイルが読み込まれたことを確認します。表示されない場合は、ファイルが (サブディレクトリの中ではなく) mu-plugins/ の直下にあるか確認してください。

サンプル Mu-Plugin: 管理画面フッターのカスタムテキスト

以下は、すべての WordPress 管理画面の下部に表示されるフッターテキストを変更する、完全に動作する例です:

PHP

<?php
/*
Plugin Name: Custom Admin Footer
Description: Changes the footer text in the WordPress admin area.
Version: 1.0
Author: Your Name
*/

add_filter('admin_footer_text', function () {
    echo 'Customized by Tony Stark - Powered by WordPress';
});

よくある mu-plugin の活用例

WP STAGING のサポートチケットや開発者フォーラムで最もよく登場するパターンを紹介します:

1. wp-config.php を編集せずにデバッグログを強制的に有効化する

<?php
/*
Plugin Name: Enable Debug Log
*/
if ( ! defined( 'WP_DEBUG' ) ) {
    define( 'WP_DEBUG', true );
}
if ( ! defined( 'WP_DEBUG_LOG' ) ) {
    define( 'WP_DEBUG_LOG', true );
}
if ( ! defined( 'WP_DEBUG_DISPLAY' ) ) {
    define( 'WP_DEBUG_DISPLAY', false );
}

これは、本番環境の wp-config.php に手を加えずにログを有効にしたいステージング環境や開発環境で便利です。デバッグの一連の手順については Enable WordPress Debug Log Mode を参照してください。

2. PHP のメモリ上限を引き上げる

memory_limit の ini ディレクティブは ini_set() で実行時に変更できるため、通常のプラグインが読み込まれる前に適用する場所として mu-plugin が適しています:

<?php
/*
Plugin Name: Increase Memory Limit
*/
@ini_set( 'memory_limit', '256M' );

注意: 一部の PHP 設定はサーバーレベルで固定されており、ini_set() による実行時の変更ができません。どのディレクティブが実行時の変更を受け付けるかについての完全な一覧は php.net/manual/en/ini.list.php にあります。

3. WP STAGING のフィルターコード

WP STAGING は、バックアップやステージングの動作を制御するためのドキュメント化されたアクションとフィルターを提供しています。これらは WP STAGING 本体が初期化される前に読み込む必要があるため、登録先として mu-plugin が適しています。add_filter() や add_action() の呼び出しを mu-plugin ファイルに記述しておけば、プラグインの有効化順序に関係なく常に存在します。利用可能なフックの一覧は、下の関連記事にある WP STAGING のアクションとフィルターのドキュメントで確認できます。

4. HTTPS への強制リダイレクト

<?php
/*
Plugin Name: Force HTTPS
*/
add_action( 'template_redirect', function () {
    if ( ! is_ssl() ) {
        wp_redirect( 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'], 301 );
        exit;
    }
} );

5. XML-RPC を無効化する

<?php
/*
Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );

制限事項と注意点

mu-plugin を採用する前に、知っておくべきいくつかの挙動があります:

無効化フックやアンインストールフックがない。 WordPress は mu-plugin に対して deactivate_{plugin} や uninstall_{plugin} を発火しません。プラグインがオプション、カスタムテーブル、スケジュールされた cron イベントを作成する場合は、手動でクリーンアップする必要があります。ファイルを削除したうえで、保存されたデータを自分で取り除いてください。

サブディレクトリの読み込みにはローダーファイルが必要。 WordPress は wp-content/mu-plugins/ の直下にある PHP ファイルのみを読み込みます。コードをサブディレクトリ (例: mu-plugins/my-plugin/my-plugin.php) に置いた場合、WordPress はそれを認識しません。一般的な手法は、mu-plugins/ のルートに薄いローダーファイルを作成し、サブディレクトリ内のファイルを require_once で読み込むことです。

マルチサイトでの挙動。 WordPress のマルチサイトネットワークでは、mu-plugin はすべてのリクエストで全サイトに読み込まれます。サイトごとにオン/オフを切り替えることはできません。ネットワーク内の特定のサイトに動作を限定したい場合は、プラグイン内で is_main_site() や get_current_blog_id() を使用します。

読み込み順序。 mu-plugin はファイル名のアルファベット昇順で、wp-content/plugins/ にあるどのプラグインよりも先に読み込まれます。mu-plugin 同士の実行順が重要な場合は、ファイル名に接頭辞を付けます: 00-runs-first.php、10-runs-second.php。

管理画面での表示。 mu-plugin はプラグイン → 使用中必須プラグインに表示されますが、プラグインヘッダーに Plugin Name、Description、Version が含まれていないと詳細は表示されません。ヘッダーは必ず記述しましょう。問題が起きたときの原因究明がずっと速くなります。

更新の仕組みがない。 WordPress には mu-plugin の更新を通知したり更新したりする組み込みの仕組みがありません。サードパーティのコードを mu-plugin 向けに転用する場合は、更新の把握と手動での適用を自分で行う責任があります。社内で開発した mu-plugin では問題になりませんが、コミュニティ製プラグインを mu-plugin に変換しようと考えている場合は留意しておく価値があります。

このコードはどこに置くべきか?

シナリオ	最適な配置場所
PHP 定数や `define()`	`wp-config.php`
サーバーのリライトルール	`.htaccess`
PHP のメモリや実行時間の上限	`.htaccess` (`php_value` 経由) または `php.ini`
常に実行する必要がある WordPress 関数を使うコード	`wp-content/mu-plugins/` の mu-plugin
サイト所有者が制御するオプション機能	`wp-content/plugins/` の通常のプラグイン
テーマ固有の出力やスタイルの変更	子テーマの `functions.php`

役立つ目安として、コードが WordPress 関数 (add_filter、get_option、wp_redirect など) を呼び出すなら mu-plugin に置きます。単なる PHP の define() や、WordPress の起動前に実行する必要がある調整であれば、wp-config.php が適切な場所です。

まとめ

mu-plugin は、常に実行する必要があり、誤って無効化されるわけにはいかないコードに最適なツールです。セットアップは数分で完了します。wp-content/mu-plugins/ を作成し、プラグインヘッダー付きの .php ファイルを追加すれば、あとは WordPress が処理してくれます。

カスタムの mu-plugin コードを開発・テストする場合は、本番環境に展開する前にステージング環境で検証することをおすすめします。WP STAGING を使えば、本番サイトを簡単に複製し、変更を公開する前に mu-plugin が期待どおりに動作することを確認できます。

著者： Rene Hermenau

著者について: René Hermenau は WP STAGING の創設者です。WordPress のバックアップ、ステージング、移行、データベース処理、安全なデプロイメントワークフローに取り組んでいます。

Rene Hermenauの著者プロフィール全文を見る