タグアーカイブ JavaScript

WordPress管理画面でトグル設定が勝手にオンに戻る時の原因と対処法

WordPress管理画面のトグル設定をオフにしても勝手にオンに戻る場合、原因は主にJavaScriptエラーかキャッシュの不整合にある。トラッキング不具合時の診断メール設定が保存されない症状では、画面の表示とデータベースの値がずれている可能性が高く、切り分け手順を順に試すことが最も確実な対処法だ。

トグル設定が勝手にオンへ戻るのはなぜか

WordPressの管理画面にあるトグルボタンは、押した瞬間にAJAX通信でサーバーへ設定値を送信する仕組みだ。送信された値はnonce検証を経てデータベースに保存される。ここで問題が起きると、画面上ではオフに切り替わったように見えても、データベースには保存されないままになる。

別のページへ移動して戻った時、画面はデータベースから最新の設定値を読み込む。保存が失敗していれば、以前の値がそのまま表示されるためトグルがオンへ戻ったように見える。これが今回の症状の正体だ。

特に「トラッキング不具合時の診断メール」のような通知系の設定は、プラグイン側がデフォルトでオンにする仕様になっている場合がある。保存の失敗とデフォルト値の再適用が重なると、オフにしても戻るという挙動が顕著に現れる。

原因になりやすい要素は以下のとおりだ。

• 管理画面でJavaScriptエラーが発生しAJAX送信が失敗している
• キャッシュプラグインやオブジェクトキャッシュが古い設定値を返している
• テーマや別のプラグインが設定を強制的にオンへ戻している
• セキュリティプラグインがnonce検証やAJAX通信をブロックしている
• データベースへの書き込み権限やオプション保存処理に問題がある

このデモはトグル設定の保存が正常に終わる場合と、途中で失敗して次回表示時に設定が戻ってしまう場合のフローを示している。次節からは原因を特定するための手順を具体的に進めていく。

JavaScriptエラーをブラウザで確認する手順

最初に確認するべきは管理画面でJavaScriptエラーが発生していないかだ。ブラウザの開発者ツールを使えば、AJAX通信が失敗した原因を直接確認できる。Chromeの場合はF12キー、Macの場合はCommand＋Option＋I、Windowsの場合はCtrl＋Shift＋Iで開発者ツールが開く。

開発者ツールが開いたらConsoleタブに切り替える。ここに赤いエラーメッセージが表示されていれば、それがトグル設定の保存を妨げている原因になる。特に「FAILED」「POST」「403」「500」のような表示がある場合は、AJAX通信そのものが失敗している証拠だ。

エラーが確認できた場合は、エラーメッセージの内容を控えておく。ファイル名や関数名が表示されていれば、どのプラグインやテーマがエラーの原因かを特定する手がかりになる。調査を次の段階へ進める前に、まずはエラーの有無を確認するだけで状況が大きく変わる。

このデモはJavaScriptエラーの確認から発生源の特定までを順に示している。トグル操作を再現してエラーが増える場合は、そのトグルに関連するスクリプトでエラーが起きている可能性が高い。

キャッシュを削除して保存状態を確認する方法

JavaScriptエラーが見つからない場合はキャッシュの影響を疑う。サイト全体のキャッシュを削除してからトグル設定を再度オフにし、別ページへ移動して戻るという流れで確認する。WordPressでは複数のキャッシュ層が重なっていることがあり、それぞれを順にクリアする必要がある。

キャッシュプラグインのキャッシュを削除する

キャッシュプラグインを利用している場合は、プラグインの管理画面からキャッシュを全削除する。代表的なプラグインでは「キャッシュを消去」「Purge All」のようなボタンが用意されている。削除後、トグル設定をオフにして別ページへ移動し、戻って状態を確認する。

オブジェクトキャッシュを無効化して確認する

高速化のためにRedisやMemcachedといったオブジェクトキャッシュを導入している場合は、一時的に無効化して確認する。オブジェクトキャッシュはデータベースの値をメモリ上に保持するため、更新処理が古い値を返し続けてしまうことがある。wp-config.phpに記載されているキャッシュ関連の設定を一時的に外すか、サーバー側のキャッシュサービスを停止してテストする。

ブラウザキャッシュを削除する

ブラウザ側のキャッシュが管理画面の表示に影響することは少ないが、シークレットウィンドウを使えば完全にキャッシュの影響を排除できる。シークレットウィンドウで管理画面へログインし、トグル設定をオフに変更してから別ページへ移動し、再度戻って状態を確認する。この方法で問題が再現しなければ、通常のブラウザセッションにキャッシュが残っていたことになる。

プラグイン競合を切り分ける手順

JavaScriptエラーやキャッシュの影響が見つからない場合、次に疑うのはプラグイン同士の競合だ。特にセキュリティ系プラグインや高速化系プラグインは、管理画面のAJAX通信に干渉することがある。テーマに含まれるスクリプトが原因になることも少なくない。

切り分けは次の順序で行う。まず全プラグインを一括で無効化し、標準テーマ（Twenty Twenty-FourやTwenty Twenty-Fiveなど）へ切り替える。この状態でトグル設定をオフに変更し、別ページへ移動して戻る操作を行い、設定が保持されるか確認する。

この状態で問題が再現しなければ、プラグインの1つずつを有効化して同様の操作を繰り返す。問題が再現した時点で、直前に有効化したプラグインが原因の可能性が高い。特定できたらそのプラグインの設定を見直すか、開発元へ情報を集める。

なお全プラグインの一括無効化はサイトの表示にも影響を与える。切り分け作業を行う場合は、アクセスの少ない時間帯を選ぶかステージング環境を利用する。

このデモはプラグイン競合の特定を効率的に進めるための順序を示している。問題が再現したタイミングを記録しておくと、原因プラグインの特定がスムーズになる。

データベースの設定値を直接確認して修正する方法

ここまでの切り分けで原因が特定できない場合は、データベースに保存されている設定値を直接確認する。WP-CLI（WordPress Command Line Interface。WordPressのコマンドライン操作ツール）が使える環境であれば、管理画面を経由せずにオプション値を調べられる。

WP-CLIでオプション値を検索する

トグル設定に関連するオプション名を確認するには、wp option listコマンドを使う。オプション名はプラグインごとに異なるが、diagnosticやtrackingといったキーワードを含むものが対象になる。該当するオプションの値がオン（1やyesと表示される）になっていれば、設定がデータベースに保存されていないことが確定する。

wp option list | grep -i diagnostic
wp option list | grep -i tracking

見つかったオプション名を指定して値を確認するには、wp option getコマンドを使う。値がオンを示していれば、トグル設定が保存されていないことになる。値がオフを示していれば、保存自体は成功しているため別の要因が影響している。

wp option get 該当するオプション名

phpMyAdminで直接確認する場合

WP-CLIが使えない環境ではphpMyAdminを使う。データベース内のwp_optionsテーブル（プレフィックスが異なる場合は該当するテーブル）から、option_name列にキーワードを含む行を検索する。option_value列の値がオンを示していれば保存が失敗している。

検索にはSQL文を使う。プレフィックスは環境によって異なるため、テーブル名を確認してから実行する。

SELECT * FROM wp_options WHERE option_name LIKE '%diagnostic%';

直接データベースを変更する場合は必ずバックアップを取ってから行う。設定値がシリアル化された配列の中に含まれている場合、直接変更するとデータ構造が崩れるリスクがある。不安がある場合は手動更新を避け、プラグインの設定画面から保存し直す方が安全だ。

このデモはデータベースの設定値の状態から原因の方向性を切り分ける方法を示している。保存の成否を知ることで、その後の調査対象を絞れる。

よくある質問

トグル設定が勝手に戻るのはいつどんな状況で起きるのか

主にJavaScriptエラーが発生している場合に起きやすい。管理画面のトグルはAJAX通信で設定を保存するが、他のプラグインやテーマが読み込むスクリプトと競合して通信が失敗すると、画面表示だけが切り替わって保存が行われない。キャッシュプラグインの影響で古い設定値が表示される場合もある。

キャッシュプラグインを使っていないのに設定が戻るのはなぜか

サーバー側のオブジェクトキャッシュやホスティング会社が提供する静的キャッシュが影響している可能性がある。またテーマのfunctions.phpや別のプラグインに、設定を強制的にオンへ戻すコードが含まれている場合もある。データベースの値を直接確認すれば保存の成否がわかる。

セキュリティプラグインが原因になることはあるか

ある。セキュリティプラグインが管理画面のAJAXリクエストやnonce検証をブロックすると、設定の保存が失敗する。ファイアウォール機能が過剰に反応して管理画面の操作を妨げるケースがあるため、一時的に無効化して切り分けを行う必要がある。

設定値をデータベースから直接変更しても問題ないか

問題ない場合が多いが、バックアップを取ってから行うことが必須。WP-CLIでオプション名を確認してからupdate_optionを行う。ただしプラグインの設定構造によってはシリアル化された配列に含まれており、直接変更が難しいこともある。不安がある場合はプラグインの設定画面から保存し直す方が安全だ。

本体のアップデートで解消されることがあるか

ある。プラグイン側のバグが原因の場合は本体アップデートで修正されることが多い。プラグインとWordPress本体を最新版に更新してから再度確認する価値は十分にある。ただし更新前にバックアップを取っておくと安心だ。

この記事のポイント

• トグル設定が勝手に戻る原因の多くはJavaScriptエラーかキャッシュの不整合
• ブラウザの開発者ツールでconsoleエラーを確認するのが最初の切り分け手順
• キャッシュプラグインとオブジェクトキャッシュを順に無効化して特定する
• プラグインを全停止し1つずつ再有効化して競合元を見つける
• 最終手段としてWP-CLIやphpMyAdminからデータベースの設定値を直接確認する

佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

JavaScriptがログアウト時に動かない原因と直し方

管理画面にログインしているときだけ JavaScript が動き、ログアウトすると止まる。この現象の原因は、ほぼ「スクリプトの読み込み順序」と「キャッシュ・最適化プラグインの挙動」のどちらか、あるいは両方の組み合わせだ。ログイン時は管理バー用のスクリプト等が読み込まれるため依存関係が偶然成立し、ログアウト時にそれが外れてエラーになるケースが多い。

ログアウト時だけ JavaScript が動かなくなる仕組み

このデモは典型的な依存関係の崩れを示している。ログイン中は WordPress が管理バーやフッターに jQuery を読み込むため、その後に記述されたスクリプトが偶然動く。ログアウトすると jQuery が存在せず、$ is not defined や jQuery is not defined といったエラーで止まる。

HTML ブロックに直接書いた JavaScript が招く問題

WordPress の「カスタム HTML」ブロックに <script> タグを直書きする方法は、一見手軽だが制御が難しい。出力される位置がテーマやブロック配置に依存し、jQuery などのライブラリより前に実行されれば必ず失敗する。さらにインラインスクリプトは多くのキャッシュプラグインで最適化対象から外されたり、結合・遅延読み込みの対象にならず、ログアウト時だけ二重に不利な状況を生む。

HTML ブロック直書きスクリプトの3つの弱点

• 読み込み順序を制御できない（テーマの render 順に依存する）
• jQuery の依存関係を WordPress に伝えられない
• キャッシュ・圧縮プラグインがスクリプトとして認識しない場合がある

ログアウト時でも動くようにする正しい組み込み手順

原則は「JavaScript は HTML ブロックに直書きせず、WordPress の仕組み（wp_enqueue_script）で読み込む」ことだ。すでに直書きで動いているものを移行するには、以下の手順で進める。

STEP 1 既存の script タグを外部ファイルに移す

HTML ブロック内の <script>〜</script> 部分だけを抜き出し、子テーマのフォルダ内に testimonial-slider.js のような名前で保存する。<script> タグそのものは不要で、中身のコードだけを移す。HTML ブロックにはスライダーの構造（ul や div のマークアップ）だけを残す。

STEP 2 functions.php で安全に読み込む

子テーマの functions.php に以下のコードを追加する。管理画面ではなくフロントエンドだけに読み込ませるために wp_enqueue_scripts フックを使う。依存関係として jquery を指定すれば、WordPress 本体の jQuery が先に読み込まれてから実行される。

function my_testimonial_slider_script() {
    wp_enqueue_script(
        'testimonial-slider',
        get_stylesheet_directory_uri() . '/testimonial-slider.js',
        array('jquery'),
        '1.0.0',
        true
    );
}
add_action('wp_enqueue_scripts', 'my_testimonial_slider_script');

最後の引数 true はフッターで読み込む指定だ。スライダーの DOM 要素が本文中に存在する場合はフッター読み込みで問題ない。もしスライダーを本文より前に実行する必要があるなら false にしてヘッダーで読ませるが、多くのケースではフッターで十分だ。

STEP 3 $ の衝突を防ぐ

WordPress の jQuery は noConflict モードで動作しているため、$ がそのまま使えない環境がある。古いコードを流用している場合は $ is not a function エラーが起きやすい。回避策として、外部ファイル全体を即時実行関数で囲み、引数で $ を受け取る記法が安全だ。

(function($) {
    $(document).ready(function() {
        // ここにスライダーのコード
    });
})(jQuery);

STEP 4 キャッシュプラグインでスクリプトを除外する

ここまで対応しても直らない場合、キャッシュや最適化プラグインが原因の可能性が高い。ログアウト時はページキャッシュが有効になり、スクリプトの遅延読み込みや結合が適用される。自前の testimonial-slider.js をこれらの処理から除外する必要がある。

プラグインの設定画面で「スクリプトの除外」「遅延読み込みの除外」といった項目を探し、testimonial-slider（ハンドル名）または testimonial-slider.js（ファイル名の一部）を指定する。除外後は必ずキャッシュを全削除してからログアウト状態で確認する。

Elementor のフックやテーマのアクションフックを使った場合の注意点

テーマ付属のフック（GeneratePress の Element など）に HTML ブロックごと差し込む方法も考えられるが、根本的にはスクリプトの読み込み順序問題は同じだ。フックで出力する位置を変えても、jQuery より前に呼ばれるリスクは残る。フックを使う場合でも、スクリプト部分は wp_enqueue_script に任せ、フックにはマークアップだけを出力する形が堅実だ。

Elementor Pro の「カスタムコード」機能を使っているなら、その中に script タグを書くのではなく、同様に子テーマのファイルとして切り出してハンドル登録するほうが制御できる。どうしても直書きが必要なら、カスタムコードの「場所」設定を「本文の終了タグ直前」にし、さらにコード内で jQuery を明示的に使う（$ を使わない）ことでエラーを減らせる。

よくある質問

コンソールに「$ is not defined」と出るがどう直せばいいか

jQuery が読み込まれる前に $ を使っているか、noConflict モードで $ が無効になっている。即時関数で (function($) { ... })(jQuery); とラップし、すべての $ をこのスコープ内に収めれば解決する。

functions.php を編集せずに直す方法はあるか

「WPCode」などのコードスニペット管理プラグインを使えば、管理画面から wp_enqueue_script のコードを登録できる。functions.php を直接触りたくない場合の現実的な代替手段だ。スニペットの実行場所を「フロントエンドのみ」に設定するのを忘れないようにする。

キャッシュを削除しても直らないのはなぜか

ブラウザキャッシュだけを消していて、サーバー側のページキャッシュや CDN キャッシュが残っているケースが多い。WordPress のキャッシュプラグインの「すべてのキャッシュを削除」を実行し、さらに CDN を使っている場合はその管理画面からもパージする。シークレットウィンドウで確認するとブラウザキャッシュの影響を除外できる。

スライダーのマークアップだけ残して script を外したら表示が消えた

新しく作った JS ファイルが正しく読み込まれていない。ブラウザの開発者ツールの「ネットワーク」タブで testimonial-slider.js が 200 番で返っているか確認する。404 ならパスが間違っている。読み込まれているのに動かない場合は、コンソールに別のエラーが出ていないか調べる。

この記事のポイント

• ログアウト時だけ JavaScript が動かない原因は、jQuery の依存切れとキャッシュ最適化の複合
• HTML ブロックへの script 直書きは読み込み順序を制御できず、根本対策にならない
• wp_enqueue_script で jQuery 依存を明示し、外部ファイルとして切り出すのが正攻法
• 即時関数で $ の衝突を防ぎ、キャッシュプラグインでは独自スクリプトを除外対象に追加する
• Elementor やテーマフックを使う場合も、スクリプトだけは enqueue に任せる設計が堅実

佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている