WordPressのカスタマイズでは、とりあえず functions.php にコードを書く、という方法が定番になっています。手軽ですが、運用が長くなるほど「あの機能はどこに書いたっけ」「テーマを変えたら機能が全部消えた」といった問題が起こりやすくなります。
そこで有効なのが、mu-plugin（Must Use Plugins）という仕組みです。この記事では、サイト固有の処理をfunctions.phpから切り出すべき理由と、mu-pluginの作り方・使い分けの基準を解説します。
functions.phpに書き続けるとどうなるか
functions.phpは、テーマの一部として読み込まれるファイルです。つまり、ここに書いた機能は「そのテーマが有効な間だけ」動くことになります。次のような場面で問題が出ます。
- テーマを変更・リニューアルしたとき：カスタム投稿タイプやショートコードが突然消え、記事の表示が崩れる。
- 親テーマを更新したとき：子テーマを使っていない場合、編集内容が上書きされて消える。
- コードが肥大化したとき：数百行〜数千行になり、どこに何があるか分からなくなる。
- 構文エラーを入れたとき：1文字のミスでサイト全体が止まる。
ここで重要なのは、「見た目に関する処理」と「サイトのデータや機能に関する処理」は、本来は寿命が違うということです。デザインを作り直しても、カスタム投稿タイプや独自のルールは残したいはずです。この寿命の違いを分けて管理するのが、mu-pluginの役割です。
mu-pluginとは
mu-pluginは、wp-content/mu-plugins/ フォルダに置いたPHPファイルを、WordPressが自動的に読み込む仕組みです。通常のプラグインとの違いは次のとおりです。
| 項目 | 通常のプラグイン | mu-plugin |
|---|---|---|
| 置き場所 | wp-content/plugins/ | wp-content/mu-plugins/ |
| 有効化 | 管理画面で有効化が必要 | 置くだけで自動的に有効 |
| 無効化 | 管理画面から可能 | ファイルを削除しない限り無効にできない |
| 読み込み順 | 通常のプラグインの順 | 通常のプラグインより先 |
| 更新通知 | あり | なし |
「管理画面から無効にできない」ことは、欠点にも見えますが、クライアントが誤って機能を止める事故を防げるという利点になります。サイトの根幹となる処理を守るのに向いています。
mu-pluginの作り方
作り方はとても簡単です。wp-content の下に mu-plugins フォルダがなければ作成し、その中にPHPファイルを置くだけです。
wp-content/
├─ themes/
├─ plugins/
└─ mu-plugins/
└─ site-functions.phpファイルの先頭には、通常のプラグインと同じくヘッダーコメントを書いておきます。
<?php
/**
* Plugin Name: サイト固有の機能
* Description: このサイト専用のカスタム投稿タイプや共通処理をまとめる
* Version: 1.0.0
*/
// 直接アクセスを防ぐ
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
// 例：カスタム投稿タイプの登録
add_action( 'init', function () {
register_post_type( 'news', array(
'label' => 'お知らせ',
'public' => true,
'has_archive' => true,
'supports' => array( 'title', 'editor', 'thumbnail' ),
'show_in_rest' => true,
) );
} );保存して管理画面を開くと、「プラグイン」画面に「Must-Use」というタブが追加され、そこに表示されます。確認できれば有効化は完了です。
mu-pluginに入れるべきものと、入れないもの
何でもmu-pluginに入れればよい、というわけではありません。判断の基準は「テーマを変えても必要か」です。
mu-pluginに向いているもの
- カスタム投稿タイプ・カスタムタクソノミーの登録
- カスタムフィールドの定義
- 管理画面の制限（不要メニューの非表示、権限の調整）
- ショートコードのうち、データに関するもの
- パーマリンクやリライトルールの設定
- REST APIの拡張、独自のエンドポイント
- セキュリティ関連の設定（XML-RPCの停止、不要な出力の削除など）
functions.php（テーマ側）に置くもの
- CSS・JavaScriptの読み込み（wp_enqueue_scripts）
- アイキャッチやメニューなどのテーマサポートの宣言
- 画像サイズの追加（デザインに依存するもの）
- ウィジェットエリアの登録
つまり、データと機能はmu-plugin、見た目はテーマと考えれば迷いません。たとえば、カスタム投稿タイプを登録する処理がテーマ内にあると、テーマを変えた瞬間に過去の投稿が管理画面から見えなくなります。データは残っているのに、操作できなくなるのです。
ファイルが増えたときの整理方法
mu-pluginsフォルダは、直下にあるPHPファイルしか自動で読み込みません。サブフォルダ内のファイルは読み込まれないため、ファイルを分割したい場合は、直下のファイルから読み込む必要があります。
wp-content/mu-plugins/
├─ loader.php // 直下：各ファイルを読み込む
└─ site/
├─ post-types.php
├─ shortcodes.php
└─ admin.php<?php
/**
* Plugin Name: サイト固有の機能ローダー
*/
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
$files = array( 'post-types', 'shortcodes', 'admin' );
foreach ( $files as $file ) {
require_once __DIR__ . '/site/' . $file . '.php';
}機能ごとにファイルを分けておけば、修正箇所をすぐ見つけられます。また、不具合が出たときに、特定のファイルの読み込みだけを一時的に外して原因を切り分けることもできます。
注意点とよくある失敗
1. 読み込み順に注意する
mu-pluginは、通常のプラグインやテーマより先に読み込まれます。そのため、他のプラグインが提供する関数やクラスを、ファイルの直下でいきなり呼び出すとエラーになります。必ず add_action( 'init', ... ) や plugins_loaded のようなフックの中に処理を書いてください。
2. 更新通知が出ない
mu-pluginは更新の対象外です。サードパーティ製のプラグインをmu-pluginとして置くと、脆弱性が見つかっても更新に気づけません。自作のコード専用にし、配布されているプラグインは通常の場所に入れましょう。
3. 構文エラーの影響が大きい
「管理画面から誤って止められない」ことは利点ですが、裏を返せば、壊れたときはFTPなどでファイルを直すしかないということです。mu-pluginの構文エラーは、管理画面から無効化できません。そのため、サイト全体が止まったときはFTPでファイルを直すか、削除する必要があります。本番サーバーで直接編集せず、ローカルで動作確認してからアップロードしましょう。
4. 本番とローカルで構成を合わせる
mu-pluginsフォルダは、データベースではなくファイルとして管理されます。サイトを移転するときは、wp-content/mu-plugins もコピーし忘れないようにしてください。コピーを忘れると、カスタム投稿タイプなどが消えたように見えます。
5. バージョン管理に含める
GitやSVNでサイトを管理している場合は、mu-pluginsフォルダもリポジトリに含めておきます。サイト固有の資産として、履歴を残せるようになります。
6. 有効化フックは使えない
mu-pluginには「有効化」の概念がないため、register_activation_hook() は動きません。有効化時に1回だけ実行したい処理は、別の方法で行う必要があります。また、has_archive を指定したカスタム投稿タイプを追加した直後は、管理画面の「設定 > パーマリンク設定」を開いて保存し、リライトルールを更新しないと、アーカイブが404になることがあります。
既存のfunctions.phpから移行する手順
すでにfunctions.phpにコードが溜まっている場合は、次の手順で少しずつ移すのがおすすめです。
- functions.phpのバックアップを取る
- コードを「見た目に関するもの」と「データ・機能に関するもの」に仕分けする
- データ・機能のコードを、mu-pluginの新しいファイルに貼り付ける
- functions.php側の同じコードを削除する（二重定義でエラーになるため、必ず消す）
- サイトの表示と管理画面を確認する
一度に全部移すと、問題が起きたときに原因が分かりにくくなります。機能ごとに1つずつ移して、そのたびに動作確認をしましょう。
まとめ
functions.phpは手軽な反面、テーマに依存するという弱点があります。サイト固有の処理をmu-pluginに切り出すと、次の利点が得られます。
- テーマを変更しても、カスタム投稿タイプや独自機能が消えない
- 置くだけで有効になり、管理画面から誤って停止されない
- 機能ごとにファイルを分けて、保守しやすくなる
- テーマは見た目だけを担当し、役割がはっきりする
「データと機能はmu-plugin、見た目はテーマ」。この線引きを覚えておくだけで、長期運用するサイトの安定度が大きく変わります。次にカスタム投稿タイプを追加するときは、ぜひmu-pluginに書いてみてください。
コメント