WordPressのイベントサイトでスマートフォンのメニューが開かないとき：公開画面から調べる

1. 来訪者の症状と直接経路を記録する

モバイルメニューの症状・公開確認シートをダウンロード（Markdown、英語）

ログアウトした実機の電話で、正確な公開URLを新しく開きます。アイコンがない、最初のタップが効かない、パネルが本文の後ろに出る、サブメニューが届かない、のどれかを記録します。端末、ブラウザー、ページ、幅、時刻、スクロール後だけ起きるかも控えます。同じヘッダーの別ページと比較します。編集画面やパソコンだけでは公開状態を確認できません。

修復中は、イベント名、日時、会場、チケットへの直接テキストリンクを対象ページまたは承認済みの代替経路に残します。現在の開催回に進むか確かめます。失敗画面と最後に正常だった時刻を保存し、一つのリンクのために未確認の全体設定を公開しません。

2. ヘッダーを管理する部品を特定する

ヘッダーがWordPressのナビゲーションブロック、従来型テーマのメニュー位置、Elementorウィジェット、独自アドオンのどれを使うか調べます。ブロックテーマなら選択メニューとオーバーレイ、従来型ならテーマの位置への割り当てを確認します。Elementorでは公開中のヘッダーと実際のウィジェットを特定してから設定を見ます。[1][2][3]

テーマ、ビルダー、バージョン、ヘッダーテンプレート、割り当て、直近の変更を記録します。一ページだけなら、全体メニューを変える前にテンプレートと表示条件を比べます。元の設定と復旧方法を保存し、複数のメニュー方式を同時に変えません。[1][2][3]

3. ボタンがない場合は表示と割り当てを確認する

アイコンがないなら、電話の縦向き、タブレット、少し広い画面で比較します。画面幅の境界、端末別の非表示、別のヘッダーが原因の候補です。WordPressナビゲーションブロックには「モバイル」「常に」など独自のオーバーレイ設定があります。Elementorにも部品ごとの表示と境界設定があります。実際の部品だけを調べます。[1][4]

非表示が意図的ならイベント情報への別の見える経路を保ちます。表示すべきなら、ステージングで限定した表示または割り当ての修正を試します。全メニューを強制表示するCSSは、重複ヘッダーを出しかねません。横向きと拡大表示も確認します。[1][4]

4. ボタンが反応しない場合は最初の操作を調べる

アイコンはあるのに反応しない場合、最初と二回目のタップ、スクロール後のタップを比べます。ログアウトした公開画面で、バナーや透明な部品がボタンを覆っていないか確認します。失敗した操作を記録し、必要なら参加者情報を含まない短い画面録画を残します。

担当者に同じページのブラウザーエラーと失敗したスクリプト要求を見てもらいます。依存ファイルの不足や先行エラーで開閉が止まることがあります。一つの警告だけで決めつけたり、別のメニュースクリプトを追加したりしません。性能設定の変更が直前にあったなら、決済やフォームを本番で止めずにステージングで切り分けます。

5. パネルが隠れる場合は切り取りとサブメニューを確認する

パネルが背後に出たり切れたりするなら、親コンテナのはみ出し設定と重なり順を調べます。親が切り取る場合、パネルだけの重なり順を上げても直りません。スクロール前後で比較し、担当するレイアウト設定をステージングで修正します。[6]

親項目のリンクとサブメニューを別々に試します。文字が遷移、矢印が展開を担う方式もあれば、文字が展開する方式もあります。デスクトップのホバーは電話のタップの証明になりません。プログラム、会場、チケットへタッチとキーボードで届き、フォーカスが見え、閉じられることを確認します。[6]

6. 公開画面とキャッシュ済み画面を比べる

ログインした編集者、プレビュー、一般の電話には違うファイルが届く場合があります。同じURLをログアウト状態と別ネットワークで比較します。WP RocketはDelay JavaScript Executionがキャッシュまたは最適化されたページのスクリプトを操作まで遅らせると説明しています。これは条件付きの手掛かりで、原因の証明ではありません。[5]

保護したステージングで設定を保存し、関係する一項目だけを変えます。動くようなら必要なスクリプトと依存関係を特定し、事業者が認める最小の除外を使います。無関係な最適化を戻します。全キャッシュ削除は誤設定の修復ではありません。公開ヘッダーが古いなら版とキャッシュ層を比較します。[5]

7. ステージングで一箇所だけ修正する

症状、担当部品、証拠、提案変更、戻し方をシートに一行で書き、責任者の承認を得ます。ステージングで同じ失敗を再現し、一箇所を変えて再確認します。テーマやプラグインの更新が必要なら、互換性と復旧方法を先に確認します。共有ヘッダーが決済や登録にも使われる場合、本番で試行錯誤しません。

正常なページと失敗したページを比較します。アイコンを出すだけでなく、メニュー構造と行き先を保ちます。チケットリンクが古い開催回へ向かないか確かめます。限定修正が失敗したら試験環境を戻し、CSSや追加スクリプトを積み重ねずに担当者へ証拠を渡します。

8. 公開後に参加者の経路全体を再確認する

公開後、実機の電話でログアウトし、新規読み込みから元のテストを繰り返します。最初のタップで開き、閉じて再び開け、閉じた後にページをスクロールできることを確認します。親リンクとサブメニューから現在のチケット、プログラム、会場、問い合わせへ進みます。別ページ、スクロール後、狭い幅、横向き、拡大も調べます。[6]

キーボードでもボタンへ移動し、開き、リンクを選び、フォーカスを見失わず閉じられるか試します。編集プレビューではなく最終の公開キャッシュ画面を確認します。URL、端末、ブラウザー、時刻、変更、担当者、結果を記録します。まだ失敗するなら直接リンクを残し、具体的な証拠で対応を続けます。[6]