MENU
  1. ホーム
  2. TOYGERブログ
  3. 【SWELL】投稿エディタの背景色がおかしい？原因と解決策を徹底解説

【SWELL】投稿エディタの背景色がおかしい？原因と解決策を徹底解説

PR

SWELLテーマを使っていて、WordPressの投稿エディタや固定ページエディタを開いた際、コンテンツを記述するエリアの背景色が、なぜかおかしいと感じた経験はありませんか？ 本来、エディタの背景色はデフォルトの白色、またはテーマで意図された色になるはずですが、特定の環境下で違う表示になってしまう問題が発生することがあります。サイトのフロントエンド（実際に公開されている記事）では正常なのに、エディタだけ色が異なるという状況は、編集作業に支障をきたすことも。

この記事では、そんなSWELLテーマで発生する投稿エディタの背景色問題に焦点を当てます。まずは、この問題の原因として考えられる一般的なケースと、それぞれに対する標準的な対処法を順を追って解説します。さらに、私たちの実際のケースで遭遇した、一般的な方法では解決しなかった原因不明な状況、そして最終的に解決に至った対処療法（少し特殊な方法）を具体的にご紹介します。同じ症状でお困りの方のトラブルシューティングの一助となれば幸いです。

目次

投稿エディタの背景色がおかしい問題とは

SWELLテーマでWordPressの投稿や固定ページを編集している際、ブロックエディタのコンテンツエリアの背景色が、本来想定される色（例えばデフォルトの白）とは異なる色で表示されてしまうという問題が発生することがあります。

具体的な症状を確認する

この問題の具体的な症状は、WordPress管理画面から投稿編集画面や固定ページ編集画面を開いた際に、実際に文章を入力したり、ブロックを配置したりするメインのエディタ領域の背景色が、期待する色になっていないという状態です。例えば、意図しない灰色になってしまったり、テーマの設定色の一部が反映されたような背景色になってしまったりすることがあります。この予期しない背景色により、記事の実際の見た目を正確に把握しながら編集するのが難しく感じられます。

フロントエンド（公開ページ）との違いを確認する重要性

エディタの背景色問題に気づいたら、最初に行うべき重要な確認の一つが、**サイトのフロントエンド（実際に読者が見る公開された記事やページ）**の表示がどうなっているか、です。

もし、フロントエンドでも同じように背景色がおかしい場合は、子テーマのstyle.cssなどに記述されたCSSがサイト全体に影響している、サイト全体のスタイルに関する問題である可能性が高いです。この場合は、エディタだけでなくサイト全体のCSSを調査する必要があります。

一方で、フロントエンドでは背景色が正常（SWELLテーマのデフォルトである白など）なのに、エディタの表示だけがおかしいという場合は、問題がエディタのスタイリングに特化していると切り分けることができます。

この記事で解説するケースは、まさにこの**「フロントエンドは正常なのに、エディタだけおかしい」**という問題に焦点を当てています。まずはご自身のサイトで、フロントエンドの表示が正常であることを確認してください。

まず試したい！一般的な原因と対処法

投稿エディタの背景色がおかしいと感じた時に、まず確認すべき一般的な原因と、それぞれの対処法を解説します。これらのステップは、多くのエディタ表示問題に共通する基本的なトラブルシューティング方法です。

【ステップ1】フロントエンド用CSSの影響を排除する

SWELLを含む多くのWordPressテーマでは、投稿・固定ページの編集画面で、公開時の見た目に近い状態で編集できるよう、フロントエンド（サイト訪問者が見る側）で使用するCSSの一部をエディタにも読み込んでいます。これは便利な機能ですが、特定のページ（例えばトップページ）だけを装飾するために書かれたCSSが、意図せずエディタにまで適用されてしまい、表示がおかしくなることがあります。

なぜフロントエンド用CSSがエディタに影響するのか

エディタにフロントエンド用CSSが読み込まれる主な理由：

  • WYSIWYG（見たままが得られる）編集体験の提供
  • テーマ全体のデザインの一貫性維持
  • エディタ独自のスタイルだけでなく、テーマの基本デザインも反映させるため

しかし、この際にページの種類（トップページなのか、投稿ページなのかなど）を限定する設定がCSS側で漏れていると、そのスタイルが全てのエディタ画面に適用されてしまうのです。

対処法：子テーマCSSを特定のページにスコープする（.home活用）

子テーマのstyle.cssに、特定のページ（特にトップページ）のためだけに記述したCSSがある場合は、そのスタイルが特定のページ以外では適用されないように制限（スコープ設定）する必要があります。WordPressでは、トップページの<body>タグに.homeや.front-pageといったクラスが自動的に付与されます。これを利用して、CSSセレクタの先頭にこれらのクラスを追加します。

例：トップページだけに適用したい.my-elementというクラスのスタイルがある場合

CSS

/* 修正前: トップページ以外やエディタにも影響する可能性 */
.my-element {
    /* スタイル */
}

/* 修正後: トップページ（.homeクラスがあるページ）のみに適用 */
.home .my-element {
    /* スタイル */
}

子テーマのstyle.css全体を見直し、トップページなど特定のページ専用のスタイルには必ず.home（または.front-page）といったスコープ用のセレクタを付与してください。これにより、無関係なCSSがエディタに読み込まれて干渉するのを防ぎます。

【ステップ2】プラグインの干渉を確認する

WordPressにインストールされているプラグインも、独自のエディタ関連機能やスタイルを追加することがあります。プラグイン同士、またはテーマとプラグインの間でCSSやJavaScriptが競合し、エディタの表示がおかしくなることがあります。

プラグインがエディタ表示に影響を与える主な要素：

  • ブロックエディタ用のカスタムブロックスタイルを追加するCSS
  • エディタのUIを変更するJavaScript
  • サイト全体にCSSやJavaScriptを読み込む設定（意図せずエディタにも影響する場合）

対処法：プラグインを全て一時停止して切り分ける

プラグインの干渉が疑われる場合は、原因特定のために全てのプラグインを一時停止します。

  1. WordPress管理画面の「プラグイン」→「インストール済みプラグイン」を開きます。
  2. 全てのプラグインを選択し、「一時停止」を選択して適用します。
  3. 投稿・固定ページの編集画面を開き、エディタの背景色が正常に戻るか確認します。

もし正常に戻った場合、いずれかのプラグインが原因です。プラグインを一つずつ有効化していき、エディタの表示がおかしくなった時点で原因プラグインを特定できます。原因プラグインが特定できたら、そのプラグインの設定を見直すか、代替プラグインを探すなどの対応を検討します。問題が解決しない場合は、プラグインは原因ではありません。

【ステップ3】テーマ設定と追加CSSをチェックする

SWELLテーマ自体や、カスタマイザーの「追加CSS」セクションに記述したCSSがエディタに影響している可能性も考えられます。特に、サイト全体の背景色やコンテンツエリアの背景色に関する設定は、エディタの見た目に反映されやすい項目です。

設定を確認すべき場所：

  • カスタマイザーの「追加CSS」: 「外観」→「カスタマイズ」を開き、「追加CSS」に何かCSSコードが記述されていないか確認します。もしあれば、一時的に全て削除するかコメントアウトしてエディタを確認します。
  • SWELLテーマオプション: SWELL独自のテーマオプション（WordPress管理画面の「SWELL設定」など）の中に、エディタのスタイルや、サイト全体の背景色、コンテンツエリアの背景色などに関する設定項目がないか探します。意図しない色が設定されていないか確認します。（私のケースでは、エディタの背景色に直接関わる設定項目は見当たりませんでした。）

【ステップ4】ブラウザの開発者ツールで適用されているスタイルを調査する

上記の対処法を試しても問題が解決しない場合、実際にエディタに適用されているCSSスタイルを特定する必要があります。この際に最も強力なツールが、ブラウザに搭載されている開発者ツールです。（Chromeの場合、F12キーで開けます。）

開発者ツールで確認すべきポイント：

  • 意図しない背景色が付いている要素: 開発者ツールの要素選択ツール（矢印アイコン）を使って、エディタの背景色がおかしくなっているエリアを正確にクリックし、どのHTML要素に色が適用されているか確認します。特に、.editor-styles-wrapper クラスを持つ要素や、そのすぐ内側にあるコンテンツを囲む要素（<article>タグや特定のdivなど）に注目します。
  • 適用されているCSSプロパティ: 選択した要素に対して、「Styles（スタイル）」タブと「Computed（計算済み）」タブを確認します。background-color や background-image といったプロパティの値を見ます。
  • スタイルの上書き状況: 「Styles」タブでは、複数のCSSルールがリスト表示されます。background-color のルールに打ち消し線が入っている場合、それは別のルールに上書きされています。打ち消し線が入っていないルールが、実際に適用されているスタイルです。

スタイルの上書き元を特定する方法

開発者ツールの「Styles」タブで、適用されている（打ち消し線が入っていない）background-color ルールの右側を見てください。通常、そのCSSが記述されているファイル名と行番号が表示されています。ここをクリックすると、そのコードが書かれているソースを確認できます。

これにより、「どのCSSファイル」「どのセレクタ」が、エディタに意図しない背景色を適用しているのかを特定できます。そのソースが子テーマのCSSなのか、テーマ本体のCSSなのか、あるいは他の場所なのかによって、次の対応が変わってきます。

【ステップ5】functions.phpのカスタムコードを確認する

子テーマのfunctions.phpに記述したカスタムコードが、何らかの形でエディタの表示に影響を与えることも考えられます。これは、直接CSSを読み込んでいなくても、出力されるHTML構造に影響したり、特定の条件下でスタイルを挿入したりする場合です。

エディタ表示に影響する可能性のあるfunctions.phpの記述：

  • admin_head や admin_init、wp_body_open といった管理画面関連のフックに関数を追加しているコード
  • これらの関数内で echo '<style>...' のように直接スタイルタグを出力しているコード
  • 特定の条件下でスクリプトやスタイルシートを読み込む (wp_enqueue_script, wp_enqueue_style) コード

条件分岐（is_adminなど）の確認

functions.phpで管理画面に影響するようなコードを書く場合は、通常 is_admin() や、さらに細かく画面を判定する条件分岐（例: !is_admin() なら実行、is_front_page() なら実行など）を使って、そのコードが意図した画面でのみ実行されるようにします。

ご自身のfunctions.phpにカスタムコードを追記している場合は、それらのコードに適切な条件分岐がされているか確認してください。特に、管理画面（is_admin() が true になる環境）で実行されるコードが、意図せずエディタに干渉していないかを見直します。

標準的な対処法が効かない！原因不明の特殊ケース

一般的な原因に対する標準的な対処法を試しても、エディタの背景色問題が解決しない場合があります。プラグインを全て停止し、子テーマのカスタムCSSやカスタマイザーの追加CSSを削除しても症状が変わらない場合、問題はさらに根深いところに潜んでいます。私のケースもまさにこれで、原因の特定に非常に苦労しました。

なぜ一般的な方法で解決しないのか（考察）

通常、CSSは詳細度や読み込み順序に基づいて適用され、より詳細度が高い、あるいは後に読み込まれたルールが優先されます。標準的な対処法として、高い詳細度を持つセレクタを使ったり、!important を付与したりして背景色を上書きしようと試みましたが、これが効かないということは、意図しない背景色が標準的なCSSのカスケードを無視するほどの高い優先順位で適用されている可能性を示唆しています。

開発者ツールでも原因特定が難しいケースの可能性

ブラウザの開発者ツールはCSSの問題解決に必須ですが、稀に原因の特定が難しいケースがあります。私の事例で上書きしているルールがすぐに見つけられなかったように、以下のような理由が考えられます。

開発者ツールで見つけにくい原因：

  • 内部にある別の要素にスタイルが設定されており、.editor-styles-wrapper の背景を視覚的に覆い隠している
  • HTML要素自体に直接 インラインスタイル (style="...") として背景色が書き込まれている（外部CSSより優先度が高い）
  • JavaScriptによる適用：テーマのスクリプトなどが、ページの読み込み後や特定のアクション時に要素のスタイルを動的に変更している
  • 非常に複雑なセレクタや擬似要素（::before, ::after）など、開発者ツールで直感的に特定しづらい方法でスタイルが適用されている

これらの場合、単純に親要素のスタイルを見たり、リストされたCSSルールを追うだけでは原因にたどり着けないことがあります。

サイト固有の設定やテーマ内部処理の関連性

プラグインを全て停止し、カスタマイザーや子テーマのCSSも最小限にしても問題が再現するという事実は、SWELLテーマ本体に原因があることを強く示唆します。しかし、他のSWELLテーマを使ったサイトでは問題が発生しないという場合、それはSWELLテーマの一般的なバグではなく、この特定のサイトの環境や設定に依存する問題である可能性が高いです。

考えられるサイト固有の原因：

  • このサイト特有のSWELLテーマオプション設定の組み合わせ（直接エディタ背景と関係ない設定が影響することも）
  • サイトのデータベース設定における、テーマに関連する特定の値が他のサイトと異なる、あるいは破損している
  • 過去に使用していたプラグインやカスタムコードの痕跡がデータベース等に残っており、SWELLテーマの動作と干渉している
  • サイトの特定のコンテンツや、使用しているSWELLブロックの特定の組み合わせがトリガーになっている

このようなケースでは、SWELLテーマの内部処理や、サイトのデータベースに格納されている設定値などが複雑に絡み合っているため、ユーザー側だけで原因を特定するのが極めて困難になります。

強制的に上書き！最終手段の対処療法

一般的な原因を全て試しても、エディタの背景色が意図した色にならない。開発者ツールで見ても、なぜか背景色を上書きしているルールがはっきり特定できない、という非常に稀で困った状況。私のケースがまさにそうでした。これは、標準的なCSSのカスケードや詳細度では解決が難しい、強固なスタイルが適用されていることを示唆しています。

なぜこの方法を試すのか

通常のCSSファイル（style.cssや追加CSS）でスタイルを記述しても、テーマ本体のCSSや、もしかするとインラインスタイルなど、より優先される（または特定の要素に直接適用される）スタイルによって上書きされてしまい、見た目に反映されないことがあります。

標準的な方法が効果がなかった理由として考えられるのは、以下の点です。

  • あなたの指定したセレクタよりもさらに詳細度が高いテーマ側のCSSルールが存在する
  • テーマ側のCSSが、あなたのCSSファイルよりも後に読み込まれるように設定されている
  • CSSファイルではなく、テーマのPHPやJavaScriptによって要素に直接スタイル（インラインスタイル）が書き込まれている
  • 背景色が、あなたがCSSでターゲットにした要素ではなく、その内部にある別の要素に適用されており、それが全体を覆い隠している

このような状況では、どんなに頑張って標準的なCSSで詳細度を上げようとしても限界があります。そこで、最終手段として、ブラウザがHTMLを読み込む際に、より確実にCSSを適用させるために、functions.phpを使って管理画面のHTML内に直接 <style> タグごとCSSコードを挿入する方法を試す価値が生まれます。これはあくまで対処療法ですが、目の前の表示問題を解決するためには有効な場合があります。

functions.phpに追加する具体的なコード

SWELL子テーマの functions.php ファイルに、以下のコードを追記してください。必ず元のコードの内容はそのままに、ファイルの一番最後に追加してください。

PHP

<?php // <?php タグがファイルの先頭にあることを確認してください。もし最後の行なら閉じタグ ?> は不要です

// エディタの背景色を強制的に白色にするカスタムスタイルを挿入
function custom_editor_background_style() {
    // 管理画面かつ投稿・固定ページ編集画面でのみ実行するための条件分岐
    $screen = get_current_screen();
    if ( is_admin() && $screen && ( $screen->base === 'post' || $screen->base === 'edit' ) ) {
        echo '<style type="text/css">';
        echo '
        /* エディタの背景色を強制的に白色に設定 */
        /* !important を使用して他のスタイルより優先 */
        .editor-styles-wrapper,
        .editor-styles-wrapper div[data-block], /* 各ブロックのラッパー */
        .editor-styles-wrapper .wp-block, /* コアブロックのクラス */
        .editor-styles-wrapper p, /* 段落などテキスト要素 */
        .editor-styles-wrapper article, /* コンテンツラッパーとして使われる可能性 */
        .editor-styles-wrapper .editor-post-visual-editor__post-title-wrapper + div /* ブロックリストを囲む要素 */
        {
            background-color: #ffffff !important; /* 背景色を白に！最優先 */
        }

        /* テキスト色が背景色と同化しないよう、必要であればテキスト色も指定 */
        /* SWELLの変数を使うか、特定の色コードを指定 */
        .editor-styles-wrapper,
        .editor-styles-wrapper * { /* エディタ内の全ての要素に対して */
             color: var(--color_text, #333) !important; /* テキスト色を強制！適切な変数や色コードに変更 */
        }
        '; // ここを編集する際は、シングルクォートとダブルクォートの使い分け、エスケープに注意が必要です。
        echo '</style>';
    }
}
// admin_head フックを使って管理画面の <head> にスタイルを挿入
add_action( 'admin_head', 'custom_editor_background_style' );

// 元々の functions.php の他のコードより後に追記してください

コードの解説と注意点

追加したコードの主な点は以下の通りです。

  • custom_editor_background_style() 関数: スタイルを出力するための関数を定義しています。
  • 条件分岐: is_admin() と get_current_screen() を組み合わせることで、管理画面の中でも投稿や固定ページの編集画面でのみスタイルが出力されるように限定しています。これにより、他の管理画面に不要なCSSが読み込まれるのを防ぎます。
  • echo '<style>...</style>';: 定義したCSSコードを、<style> タグで囲んでHTML内に直接出力しています。これにより、外部CSSファイルとして読み込むよりも後に、直接スタイルが適用される可能性が高まります。
  • 複数のセレクタ: .editor-styles-wrapper に加えて、エディタ内で実際にコンテンツブロックを囲んでいる可能性のある複数の要素（div[data-block], .wp-block, article など）をカンマ区切りで複数指定しています。これは、原因となっている背景色が .editor-styles-wrapper 自体ではなく、その内部の要素に適用されている場合に、まとめて上書きするためです。
  • background-color: #ffffff !important;: 背景色を白色（#ffffff）に指定し、さらに !important を付与しています。!important はCSSの他のルールよりも最も高い優先度を持つため、強力にスタイルを上書きできます。
  • color: var(--color_text, #333) !important;: 背景色を白にすると、元のテキスト色が見えづらくなる場合に備え、テキスト色も強制的に指定する例です。SWELLのCSS変数 --color_text を利用しつつ、それが定義されていない場合のフォールバックとして #333 を指定しています。必要に応じて調整してください。

この方法の注意点としては、以下の点が挙げられます。

  • functions.php の編集は慎重に: コードに誤りがあると、サイト全体が真っ白になって管理画面にアクセスできなくなることがあります。編集前に必ずファイルのバックアップを取ってください。
  • 子テーマを使用する: 親テーマの functions.php を直接編集すると、テーマのアップデート時に変更が失われます。必ず子テーマの functions.php に追記してください。
  • 非標準的な方法である: これはWordPressの標準的なエディタースタイルの読み込み方法ではありません。本来はテーマ側が提供する方法や、add_editor_style() を使うべきですが、今回は通常の手段が通用しないための例外的な対処です。
  • !important の乱用: !important は便利ですが、使いすぎるとCSS全体の見通しが悪くなり、後でスタイルを変更したい場合にさらに !important を重ねる必要が出てくるなど、管理が複雑になります。どうしても必要な場面以外での使用は避けるのが望ましいです。

適用手順

  1. WordPress管理画面にログインします。
  2. 「外観」→「テーマファイルエディター」を開きます。
  3. 右側のテーマファイル一覧で、必ず「SWELL CHILD」が選択されていることを確認します。
  4. テーマファイル一覧から「Theme Functions (functions.php)」を選択し、エディターにコードを表示させます。
  5. 表示されたコードの一番下に、上記のコード（<?php や ?> を含む範囲で、既存のコードを壊さないように）をコピー＆ペーストで追加します。
  6. エディターの下にある「ファイルを更新」ボタンをクリックして保存します。コードにエラーがある場合はエラーメッセージが表示されます。
  7. 投稿または固定ページの編集画面を開き、背景色が白色になっているか確認します。
  8. 確認後、ブラウザのキャッシュクリアまたはスーパーリロード（Ctrl+Shift+R または Cmd+Shift+R）を行って、古いCSSが残っていないことを確認します。

この手順でコードが正しく適用されれば、エディタの背景色が白色に強制上書きされているはずです。

まとめ

WordPress SWELLテーマの投稿エディタで発生した、原因不明の背景色表示問題は、一般的なCSSやテーマ設定の調整では解決しない場合があることが分かりました。プラグインの競合やカスタムCSSの影響を排除しても問題が解消しない場合、テーマ本体の強固なスタイル適用やサイト固有の要因が関わっている可能性が高いです。

今回最終的に効果があったのは、functions.php を使用して管理画面のHTML内に直接CSSスタイルを挿入し、!important を使って強制的に背景色を上書きするという、やや非標準的な対処療法でした。同じような稀な問題に直面したSWELLユーザーにとって、この事例が解決の糸口となれば幸いです。

TOYGERブログ
よかったらシェアしてね！
  • URLをコピーしました！
目次