WordPressでメニュー項目が保存されない時の確認｜max_input_varsとテーマ設定

WordPressでメニュー項目を追加して「メニューを保存」を押したのに、後半の項目だけ消える、並び順が戻る、表示位置のチェックが外れる。この症状は、操作ミスだけでなくPHPの入力変数上限やテーマ側のメニュー方式が関係していることがあります。

結論からいうと、最初に「どの項目が、どのタイミングで消えるか」を確認し、クラシックメニューなら max_input_vars、ブロックテーマならナビゲーションとREST APIを分けて調べるのが正解です。いきなりテーマ変更やメニュー削除をすると、原因を隠して復旧を難しくします。

よこやま良平

20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。メニュー保存の不具合は、画面上では成功したように見えても、送信データの後半だけサーバーで切り捨てられる点が厄介です。

作業は、現状記録、再現テスト、有効値の確認、最小限の設定変更、保存後の再確認という順番で進めます。初心者でも、サーバー設定を変える前にどこまで自分で確認し、どこから管理会社へ依頼すべきか判断できるように解説します。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPressメニューが保存されない時は消え方で原因を分ける

最初に行うべきことは、保存失敗を一括りにせず、症状を三つに分けることです。後ろの項目だけ消える場合と、保存要求そのものが失敗する場合では、確認する場所が違います。

後半のメニュー項目だけ消えるならmax_input_varsを疑う

項目数が少ない時は保存でき、追加した後から末尾の項目だけ消えるなら、PHPの max_input_vars が有力です。WordPressのクラシックメニュー画面は、メニュー名、URL、ラベル、親子関係、説明、CSSクラスなど多数の入力値をまとめて送信します。

1項目が1変数とは限りません。実際には一つのメニュー項目に複数の入力欄があるため、見た目が数十項目でも、送信する変数は数百から千を超えることがあります。上限を超えると、PHPは後半の変数を受け取れず、末尾側だけ保存されない状態になりやすいです。

保存ボタン後にエラーが出るなら通信・権限・WAFを確認する

「更新に失敗しました」「403」「500」「503」などが表示される、保存中の表示が終わらない、ログイン画面へ戻る場合は、入力変数上限だけで決めつけません。REST API、管理画面のセッション、WAF、PHPエラー、サーバー負荷を確認します。

ブラウザの開発者ツールで保存時の通信を見られる場合は、HTTPステータスと応答内容を記録します。再読み込みを繰り返す前に、現在のメニュー構成を別タブやスクリーンショットで残しておくと、安全に切り分けできます。

WordPressで「更新に失敗しました。オフラインのようです」と出る原因と保存確認

保存済みなのに公開画面だけ違うなら表示位置とキャッシュを確認する

管理画面では項目が残っているのに公開画面へ出ない場合は、保存処理より表示側を疑います。テーマの「メニューの位置」が未割り当て、ヘッダーが別テンプレート、ブロックテーマのナビゲーションが別、キャッシュが古い、といった原因があります。

このケースで max_input_vars を上げても直りません。管理画面を再読込して項目が残るか、別ブラウザでも同じ構成か、テーマが参照する位置へ対象メニューが割り当てられているかを順に見ます。

原因調査の前に、現在の構成を復元できる情報を残してください。メニューはサイト全体の導線なので、試行錯誤で項目を削除すると、問い合わせや購入につながるページへ移動できなくなるおそれがあります。

メニュー名・表示位置・階層・末尾項目を控える

最初に、メニュー名、選択中の表示位置、親子階層、先頭と末尾の項目を記録します。外観→メニューを使うテーマなら、画面上部の編集対象メニューと、画面下部のメニュー設定を同じ記録へ入れてください。

可能なら、上から下まで複数枚のスクリーンショットを撮ります。項目名だけでなく、カスタムリンクのURL、別タブで開く設定、CSSクラス、説明を使っている場合は、それらも展開して控えます。

本番メニューを削除せず少量追加で境界を調べる

既存項目を大量に並べ替えるのではなく、テスト用のカスタムリンクを一つだけ末尾へ追加し、保存後に管理画面を再読込します。残れば、さらに少量ずつ追加し、何項目付近から欠落するかを確認します。

毎回ほぼ同じ位置より後ろが消えるなら、入力変数上限の可能性が高まります。項目数に関係なく不規則に失敗するなら、通信、タイムアウト、プラグイン競合、ログインセッションなど別の原因を優先します。

大きな変更はステージング環境で試す

営業時間中の本番サイトや、予約・購入につながるメニューでは、設定変更をステージング環境で試すのが安全です。本番とPHPバージョン、テーマ、プラグイン、メニュー数が同じでなければ再現しないため、環境差も一緒に記録します。

WordPressのステージング環境とは？本番更新前に使うべきケースと注意点

max_input_varsを確認して必要量だけ引き上げる

max_input_vars は、1回のリクエストでPHPが受け取る入力変数の上限です。クラシックメニューの後半だけ欠ける症状では、現在値を確認し、必要な場合だけ段階的に引き上げます。

サイトヘルスまたはサーバーパネルで現在値を確認する

WordPress管理画面の「ツール→サイトヘルス→情報→サーバー」で確認できる環境があります。表示されない場合は、レンタルサーバーのPHP設定画面やサポート情報を確認してください。

コマンドを使える環境では、次の確認もできます。ただし、コマンドライン版PHPとWebサーバーが使うPHPは別設定の場合があるため、CLIの値だけで有効値を断定しないでください。

php -i | grep max_input_vars

一般的な初期値として1000が使われることは多いものの、サーバー会社やプランによって異なります。確認すべきなのは資料上の標準値ではなく、そのWordPressサイトのWeb実行環境で有効になっている値です。

3000程度から始めて保存結果を再確認する

現在値が1000で、末尾のメニュー項目が欠けるなら、まず3000程度へ変更して再テストします。まだ不足する場合は、メニュー規模とサーバー会社の上限を確認したうえで5000などへ段階的に調整します。

最初から極端に大きい値へする必要はありません。値を上げるほど、1回の要求でPHPが解析する入力数を増やせるため、サイトの用途とサーバー資源に見合う必要最小限の値にします。

PHP設定画面・php.ini・.user.iniの優先順位を確認する

もっとも安全なのは、レンタルサーバーが提供するPHP設定画面です。設定画面がない場合は、サーバー仕様に従って php.ini または .user.ini へ設定します。ファイルの置き場所と反映時間はサーバーごとに違います。

max_input_vars = 3000

Apacheのmod_php環境では、サーバーが許可していれば .htaccess で設定できる場合があります。しかしCGI・FastCGI・PHP-FPM環境でこの記述を追加すると、500エラーになることがあります。対応可否が不明なら使わず、サーバーパネルまたはサポートへ依頼してください。

php_value max_input_vars 3000

wp-config.php に ini_set() を書けば必ず直る、とは考えないでください。入力変数の解析はWordPressが起動する前に行われ、max_input_vars は変更場所にも制約があるため、Webサーバー側のPHP設定で変更するのが基本です。

変更後は有効値と末尾項目の両方を確認する

設定ファイルを書き換えただけでは完了ではありません。PHP-FPMの再読込や反映待ちが必要な環境もあるため、同じ確認画面で有効値が変わったことを確かめ、その後にメニューを保存します。

保存後は管理画面を再読込し、末尾の項目、親子関係、表示位置のチェックを確認します。公開画面はログアウト状態やシークレットウィンドウでも開き、PCとスマートフォンの両方でメニューが展開できるかを確かめます。

メニュー項目数だけで必要値を決めない

必要な入力変数数は、メニュー項目数へ一定の数字を掛ければ必ず求められるものではありません。WordPress本体の入力欄に加え、テーマやメガメニュー、多言語、アイコン設定のプラグインが各項目へ独自フィールドを追加するためです。

たとえば、同じ50項目でも、標準項目だけのサイトと、画像・色・表示条件・端末別設定を持つサイトでは送信変数数が大きく違います。項目数だけを見て「この値なら十分」と断定せず、現在値、追加フィールド、欠落位置、変更後の再現結果をセットで判断します。

共用サーバーでは利用者側で変更できる上限が決められていることもあります。その場合は無理に設定ファイルを重ねず、サーバー会社へ上記の情報を渡し、適用可能な設定場所と反映方法を確認してください。

WordPressでメディアのアップロード上限を変更する方法｜php.iniとサーバー設定

テーマ設定とメニュー編集方式の違いを確認する

WordPressには、外観→メニューで編集する方式と、サイトエディターのナビゲーションを編集する方式があります。画面が似ていても保存先が違うため、利用中テーマがどちらの方式かを先に確認してください。

クラシックテーマはメニュー本体と表示位置を別々に確認する

クラシックテーマでは、メニュー項目が保存されても、ヘッダーやフッターの「メニューの位置」が外れることがあります。メニュー本体が残っているなら、外観→メニュー→位置を管理、またはメニュー設定の表示位置を確認します。

テーマを切り替えた直後は、位置名が変わり、自動では再割り当てされないことがあります。元のテーマで「ヘッダーメニュー」だった場所が、新テーマでは「Primary」など別名になっていても、保存失敗とは限りません。

ブロックテーマはナビゲーションとテンプレートパーツを確認する

ブロックテーマでは、外観→エディターからヘッダーのテンプレートパーツやナビゲーションブロックを編集します。同名のナビゲーションが複数あり、別のナビゲーションをヘッダーが参照していると、保存できたのに表示が変わらないように見えます。

この方式ではREST API、編集競合、権限、テンプレートパーツの保存状態が重要です。クラシックメニューと同じ症状に見えても、後半項目の一律欠落がなければ、まずサイトエディター側の保存先を確認します。

WordPressサイトエディターの変更が反映されない原因｜テンプレートとキャッシュを確認

操作ユーザーの権限とテーマ固有メニューを確認する

管理者以外のユーザーでは、テーマ編集やナビゲーション更新に必要な権限が不足することがあります。別ユーザーで保存できる場合は、役割と追加権限を比較し、必要以上に管理者権限を配布せずに原因を直します。

テーマ独自のヘッダービルダーやメガメニュー機能を使っている場合は、WordPress標準メニューとは別の保存処理が動きます。標準メニューで再現するかを確認し、テーマや拡張プラグインの更新履歴、既知の不具合、保存時ログを調べます。

max_input_vars以外の保存失敗を安全な順番で切り分ける

上限を変更しても直らない場合は、設定値を上げ続けず、保存要求がどこで止まるかを調べます。安全な順番は、ブラウザ、ユーザー権限、通信応答、WAF、プラグイン、テーマ、サーバーログです。

ブラウザとログインセッションを確認する

別ブラウザまたはシークレットウィンドウで管理画面へ入り、少量の変更を保存します。拡張機能、古いCookie、管理画面キャッシュが原因なら、この比較で差が出ます。

ただし、未保存のメニューを開いたままCookie削除や再ログインをすると変更を失います。現在の構成を記録してから、新しいセッションでテストしてください。

WAF・セキュリティ機能・REST APIを確認する

保存要求が403になる場合は、WAFやセキュリティプラグインが、長いPOSTデータ、URL文字列、特定のラベルを攻撃と誤判定している可能性があります。WAFを恒久的に無効化せず、発生時刻と対象URLをサーバーログで照合します。

一時除外が必要なら、対象操作と送信元を限定し、保存テスト後に必ず元へ戻します。ブロックテーマでREST APIエラーが出る場合は、サイトヘルス、ブラウザのネットワーク応答、セキュリティ設定のREST制限を確認します。

プラグインとテーマの競合はステージングで確認する

メガメニュー、権限管理、多言語、キャッシュ、セキュリティ系プラグインは、メニュー画面や保存処理へ介入することがあります。本番で一括停止せず、ステージング環境で一つずつ無効化し、同じメニュー保存を再現します。

標準テーマへ切り替える試験も、表示崩れを避けるためステージングで行います。原因プラグインが判明したら、更新、設定見直し、代替機能、開発元へのログ提供の順で対応します。

PHPエラー・タイムアウト・サーバー負荷をログで確認する

500や503になる、保存に長時間かかる場合は、PHPエラーログ、Webサーバーログ、PHP-FPMログ、リソース使用量を同じ時刻で確認します。メモリ不足、実行時間超過、ワーカー枯渇は、max_input_vars とは別問題です。

WordPress管理画面だけ503エラーになる原因と復旧手順

ログに残るエラーを確認せず、memory_limitやmax_execution_timeをまとめて上げると、根本原因を隠すことがあります。一度に一つだけ変更し、変更前後の保存時間、HTTP応答、末尾項目を比較してください。

WordPressメニュー保存トラブルのよくある質問

最後に、メニュー項目が保存されない時によくある疑問を整理します。設定値だけでなく、保存方式と検証方法まで含めて判断してください。

WordPressメニューを安全に保存する確認順まとめ

WordPressのメニュー項目が保存されない時は、末尾だけ消えるのか、保存要求がエラーになるのか、管理画面には残るのに公開画面だけ違うのかを最初に分けます。この分類だけで、不要なサーバー変更をかなり減らせます。

重要なのは、設定ファイルを書き換えたことではなく、保存後に全項目と階層が残り、正しい表示位置で公開画面から利用できることです。原因と変更内容を記録し、次回のテーマ更新やメニュー追加でも同じ基準で確認してください。

WordPressのメニュー保存トラブルが自分で直せない時は

WordPress保守・不正アクセス対策・マルウェア駆除・WordPressクイックレスキュー365

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

これらでお悩みなら最短30分ですぐに解決します！

いまなら期間限定で