🚀 WordPressで「PHP Max Input Vars Limit」エラーを修正する方法

WordPressサイトを構築または管理しているときに、突然次のエラーに遭遇することがあります:

「警告: Max Input Vars制限に達しました」
または
「max_input_varsをより高い値に増やしてください。」

…これは、サーバーがPHPがあまりにも多くの入力フィールドを処理するのをブロックしていることを意味します — 大きなメニューやページビルダー(ElementorやWPBakeryなど)、またはフォーム送信時によく見られます。

この記事では、以下の内容をカバーします:

  • ✅ max_input_varsディレクティブとは
  • 🧠 WordPressへの影響
  • 🔧 複数の方法(php.ini、.htaccess、wp-config、Nginx、cPanelなど)での修正方法
  • 🔐 ベストプラクティスとセキュリティ考慮事項

🔍 max_input_varsとは?

max_input_varsは、PHPが受け入れることができる入力変数の数を制限するPHPディレクティブです(POST、GET、REQUEST経由)。これは、サーバーをハッシングによるサービス拒否攻撃から保護しますが、CMSプラットフォームでの正当な操作にも影響を与えます。

デフォルト値:

max_input_vars = 1000

この制限を超えると(例:1000以上のアイテムを持つWordPressメニューを保存する場合)、PHPは入力をカットオフし、WordPressはすべての変更を静かに保存できなくなります。

📌 エラーが発生する場面

  • 大きなナビゲーションメニューを保存する
  • たくさんのフォームフィールドを持つページを保存する
  • 複雑なレイアウトのページビルダーを使用する
  • WPML、ElementorWooCommerceなどのプラグイン

🛠️ エラーの修正: 6つの実証済みの方法

✅ 1. php.iniを修正する(ルートまたはVPSアクセスがある場合の最良の方法)

これは、独自のサーバーを運営している場合にmax_input_varsを変更するための最もクリーンな方法です:

ステップ1: php.iniファイルを見つけるか作成します(サーバーによります):

sudo nano /etc/php/8.2/apache2/php.ini

8.1をあなたのPHPバージョンに置き換えてください。

ステップ2: ディレクティブを見つけて編集します:

max_input_vars = 3000

ステップ3: ウェブサーバーを再起動します:

sudo systemctl restart apache2

または

sudo systemctl restart php8.2-fpm

✅ 2. .htaccessを更新する(共有ホスティングのApacheユーザー向け)

もしphp.iniにアクセスできない場合は、WordPressインストールのルートにある.htaccessを編集してみてください:

<IfModule mod_php.c>
php_value max_input_vars 3000
</IfModule>

⚠️ これはmod_phpが有効な場合のみ機能します。一部のホストはPHP-FPMを使用しており、この方法は機能しません。

✅ 3. wp-config.phpを使用する(常に効果的とは限らない)

WordPressはmax_input_varsのオーバーライドをネイティブにサポートしていませんが、一部の構成ではこれを追加することで機能する場合があります

@ini_set('max_input_vars', '3000');

それを上に置いてください:

/* That's all, stop editing! Happy publishing. */

✅ 4. ユーザーphp.iniまたはcPanelのphp_valueを修正する

もし共有ホスティングをcPanelで使用している場合:

  • cPanel > PHPバージョンを選択 > オプションに移動します
  • max_input_varsを探して3000以上に増やします
  • 保存し、phpinfo()を確認して確認します

✅ 瞬時に機能します — 再起動は不要です。

✅ 5. .user.iniを使用する(PHP-FPMまたはCGI環境向け)

WordPressのルートフォルダーに.user.iniを作成または編集します:

max_input_vars = 3000

その後、PHPを再起動します(または、ホストが自動的に変更を適用する場合は5分以上待ちます)。

✅ 6. NGINX + PHP-FPMサーバー用

NGINXは.htaccessを使用しないため、FPMプールまたはphp.iniを介してPHPを構成します。

/etc/php/8.1/fpm/php.iniを編集します:

max_input_vars = 3000

その後、再起動します:

sudo systemctl restart php8.2-fpm
sudo systemctl restart nginx

🧪 動作確認方法

WordPressのルートにphpinfo.phpファイルを作成します:

<?php phpinfo(); ?>

ブラウザでアクセスします: https://yourdomain.com/phpinfo.php

max_input_varsを検索し、更新されていることを確認します。

🧼 ファイルを削除するのを忘れないでください — それは敏感なサーバー情報を公開します。

🛡️ ベストプラクティス

推奨事項理由
max_input_varsを999999に設定しないDoS脆弱性を引き起こす可能性があります
3000〜5000に留める大きなメニュー/ページビルダーに十分です
メモリ制限を監視する大きな入力変数 = より多くのメモリ使用
phpinfo()またはini_get()を使用してデバッグする推測を避ける

💡 ボーナス: 他の関連制限を増やす

時々、この問題は他の制限に達することを伴います:

max_execution_time = 300
memory_limit = 512M
post_max_size = 64M
upload_max_filesize = 64M

これらもphp.ini、.htaccess、または.user.iniに追加できます。

🧭 最後の考え

WordPressにおけるmax_input_varsエラーの理解と修正。このmax_input_varsエラーは、WordPressにおいて微妙ですが潜在的に破壊的な問題であり、しばしば見過ごされます—何か重要なものが壊れるまで。 このPHP設定ディレクティブは、サーバーが単一のリクエストで処理する最大入力変数の数(フォームフィールドやメニューアイテムなど)を制御します。この制限が低すぎると、特に複雑な環境では、ウェブサイトの一部が変更を正しく保存できないことがあります。

問題が発生する場所
このエラーは通常、以下のシナリオで発生します:

大きなまたはネストされたWordPressメニュー:詳細なメニュー構造を構築する際、メニューの一部しか保存されないか、保存後に変更が消えることがあります。

  • 多言語ウェブサイト:WPMLやPolylangなどのプラグインは、各言語のために多くの入力フィールドを持つフォーム送信に大きく依存しています。
  • ページビルダー:Elementor、WPBakery、またはDiviなどのドラッグアンドドロップツールは、多くの要素や行を持つレイアウトを保存する際に問題が発生することがあります。
  • テーマやプラグインの設定:リッチな設定パネルを持つテーマやプラグインは、制限を超えるとすべての設定を正しく保存できない場合があります。
  • 最悪の部分? 目に見えるエラーメッセージはほとんどなく、変更が適用されないだけで、何が間違ったのかを考えさせられます。