【WordPress】エディタにCSSを読み込む方法の最適解はどれ

【WordPress】エディタにCSSを読み込む方法の最適解はどれ

子テーマやプラグインから、エディター画面にCSSを読み込ませる方法がいくつかありましたので、最適解を探っていこうと思います。

今回は、以下の2通りご紹介します。

  • 方法1:add_editor_style()で読み込む
  • 方法2:wp_enqueue_style()で読み込む
目次

環境

2つのスタイルシートを用意

まず「フロント用」と「エディター用」のCSSファイルを用意します。

  • フロント用→サイトに適用させるスタイル
  • エディター用→編集画面に適用させるスタイル

プラグインから読み込んでみる

今回は例として、自作プラグインからCSSを読み込んでみます。

  • my-plugin
    • my-plugin.php(ここから読み込む)
    • css
      • style.css(フロント用)
      • editor-style.css(エディター用)

編集画面は実際のサイトにできるだけ近づけるのが望ましいため、通常はフロント用CSSをエディターにも読み込みます。

そうすることで、エディター用CSSは微調整(エディター特有の余白・枠線など)だけで済むようになります。

方法1:add_editor_style()で読み込む

追記:2025年6月23日

プラグインや子テーマからこの読み込み方法を行うと、テーマによってはエディター上のスタイルが一部反映されないなどの現象が起こる可能性があります。詳細は後述します。

/**
 * エディター用の CSS 読み込み
 */
add_action( 'after_setup_theme', function() {

  // ブロックエディターをサポート
  add_theme_support( 'editor-styles' );

  // 指定のファイルを読み込む
  add_editor_style( plugin_dir_url( __FILE__ ) . 'css/style.css' ); // フロント用
  add_editor_style( plugin_dir_url( __FILE__ ) . 'css/editor-style.css' ); // エディター専用
});

add_editor_style()はエディターにスタイルを読み込むメジャーな方法です。

本来はテーマ用に作られた関数ですが、プラグインからでも使用可能です。

add_theme_support( 'editor-styles' )の記述がない場合は、クラシックエディターでのみスタイルが読み込まれます。

特徴

  • 自動で.editor-styles-wrapperが追加される
  • クラシックエディターとブロックエディター両方で読み込まれる
  • インラインCSSで読み込まれる
  • 依存関係は指定できない

自動で.editor-styles-wrapperが追加される

ブロックエディターの編集エリアは.editor-styles-wrapperというクラスで囲まれており、本来スタイルを当てる際にはこのクラスを意識して記述する必要があります。

しかし、add_editor_style()で読み込む場合は、自動的にbody要素が.editor-styles-wrapperに置き換わり、各セレクタの接頭辞にも追加されます。

記述したCSS

body {
  background-color: #fff;
}

p {
  color: #333;
}

h1,
h2 {
  font-size: 2em;
}

読み込まれるCSS

.editor-styles-wrapper {
  background-color: #fff;
}

.editor-styles-wrapper p {
  color: #333;
}

.editor-styles-wrapper h1,
.editor-styles-wrapper h2 {
  font-size: 2em;
}

この仕組みのおかげで、特別な対応をせずともエディター専用のスタイルを容易に反映させることができるというわけです。

ただし、自ら.editor-styles-wrapperを記述すると、読み込まれる際にも同じクラスが二重に追加されてしまうという点に注意してください。

/* 記述したCSS */
.editor-styles-wrapper p {
  color: #333;
}

/* 読み込まれるCSS */
.editor-styles-wrapper .editor-styles-wrapper p {
  color: #333;
}

パスの指定方法

テーマディレクトリからであれば相対パスで指定できますが、プラグインから読み込む場合はプラグインのURLを指定すると正しく動作します。

// テーマに記述する場合
add_editor_style( 'css/editor-style.css' );

// プラグインに記述する場合
add_editor_style( plugin_dir_url( __FILE__ ) . 'css/editor-style.css' );

キャッシュ対策

キャッシュ対策として、URLの最後に更新時刻のクエリパラメータを付与しておくと安心です。

// editor-style.cssの最終更新時刻を取得
$editor_style_ver = filemtime( plugin_dir_path( __FILE__ ) . 'css/editor-style.css' );

// CSSファイルにバージョン番号を付加して読み込む
add_editor_style( plugin_dir_url( __FILE__ ) . 'css/editor-style.css?v=' . $editor_style_ver );

クエリパラメータはhttp(s)から始まる「絶対URL」でなければなりません。(相対パスは不可)

テーマの場合はget_stylesheet_directory_uri()home_url()を使って絶対URLに変換できます。

エディター上のスタイルが一部反映されない問題

プラグイン、または子テーマのfunctions.phpに、以下のコードを記述して検証してみました。

add_action( 'after_setup_theme', function() {
  add_theme_support( 'editor-styles' );
});

すると、テーマ(SWELL)の独自ボタンの色変更が、エディター上で反映されなくなりました。

これは、ベーススタイルがカラースタイルよりも後に読み込まれるため、上書きされてしまうことが原因のようです。

通常時

[class*=is-style-btn_] {
  /* ①基本スタイル */
}
.red_ {
  /* ②色変更 */
}

editor-styles有効時

.red_ {
  /* ①色変更 */
}
:where(.editor-styles-wrapper) [class*=is-style-btn_] {
  /* ②色変更クラスよりも後に読み込まれてしまったため、色変更が反映されない */
}

※上記の場合、詳細度が同じなので後で読み込まれているスタイルが優先されます。

このように場合によっては意図しない現象が起こるので、テーマの設計やWordPressの仕様を理解した上でeditor-stylesを適用する必要があります。

方法2:wp_enqueue_style()で読み込む

/**
 * ブロックエディター用のCSS読み込み
 */
function enqueue_custom_editor_assets() {

    // フロント用
    wp_enqueue_style(
        'my-custom-plugin-style',
        plugin_dir_url( __FILE__ ) . 'css/style.css',
        [],
        filemtime( plugin_dir_path( __FILE__ ) . 'css/style.css' )
    );

    // エディター用
    wp_enqueue_style(
        'my-custom-plugin-editor-style',
        plugin_dir_url( __FILE__ ) . 'css/editor-style.css',
        [],
        filemtime( plugin_dir_path( __FILE__ ) . 'css/editor-style.css' )
    );
}
add_action( 'enqueue_block_editor_assets', 'enqueue_custom_editor_assets' );

基本的には、フロントエンドでスタイルシートやスクリプトを読み込む際の記述方法と同じです。

  • フロントエンドで読み込むフック:wp_enqueue_scripts
  • ブロックエディターで読み込むフック:enqueue_block_editor_assets

という感じ。

特徴

  • 編集画面全体(サイドバーやツールバーなど)にスタイルが影響する
  • ブロックエディターでのみ読み込まれる
  • 外部CSSファイルとして読み込まれる
  • 依存関係を指定できる

CSSの書き方に注意

この方法では.editor-styles-wrapperクラスを自動的に付与してくれないため、セレクターの書き方を工夫しないと、編集画面全体にスタイルが適用されてしまいます。

例えば、フロント用のCSSに以下のようなスタイルが記述されていた場合。

/* フロント用CSS */
button {
  font-size: 20px!important;
}

サイドバーやツールバーなどのbutton要素にスタイルが反映されてしまい、編集画面全体が崩れてしまいます。

適切に.editor-styles-wrapperで囲ったり、詳細度を高めたりしないと、意図したスタイルにならないことに注意が必要です。

おまけ:enqueue_block_assetsフック

enqueue_block_assetsはフロント、エディター両方で読み込まれるフックです。

is_admin()で判定し、エディターのみ、もしくはフロントのみで読み込むといったことも柔軟に対応できます。

/**
 * コンテンツアセットのエンキュー。ただし、エディター内のみ
 */
function example_enqueue_editor_content_assets() {
    if ( is_admin() ) {
        wp_enqueue_script(
            'example-editor-content-scripts',
            plugins_url( 'constent-scripts.css', __FILE__ )
        );
        wp_enqueue_style(
            'example-editor-content-styles',
            plugins_url( 'constent-styles.css', __FILE__ )
        );
    }
}
add_action( 'enqueue_block_assets', 'example_enqueue_editor_content_assets' );

ただし、エディターのiframeの内側と外側の両方に読み込まれるため、エンキューするスクリプトライブラリによっては問題が発生するという報告がされているので、今のところ少し使いづらいという印象です。

add_editor_style()とwp_enqueue_style()はどちらが良いか

両者の大きな違いは、.editor-styles-wrapperが自動で追加されるかとどうか、依存関係の指定の有無です。

add_editor_style()の場合は、ブロックエディターを囲っている.editor-styles-wrapperの直前でインラインCSSとして優先的に読み込んでいるため、依存関係は特に不要かなと思っています。

やはり、自動でエディター専用クラスが追加されるのはメリットとして非常に大きいので、他に理由がない限りadd_editor_style()で読み込む方が良いかもしれません。

カスタマイズに困ったらお気軽にご相談を!

  • 「ちょっとしたCSSの調整だけお願いしたい」
  • 「不具合を直してほしい」

料金は3,000円〜、お支払いは銀行振込・Amazonギフトカードなど柔軟に対応してます🤔

役に立ったら他の方にシェア

お気軽にコメントどうぞ

コメントする

目次