はじめに

WordPressを7.0へアップデートしたところ、
管理画面の記事編集画面、いわゆるGutenbergの本文エディタ内の文字サイズが小さく表示される現象に遭遇しました。

調査したところ、原因はWordPress本体の単純な不具合ではなく、
以下の条件が重なったことによるものでした。

WordPress 7.0で投稿エディタのiframe化条件が変わった
テーマ側で、本文エディタにフロント用CSSを読み込ませていた
フロント用CSSに html { font-size: calc(...) } のようなグローバル指定があった
これまで管理画面側で行っていたCSS補正が、iframe内の本文エリアには届かなくなった

この記事では、発生条件、原因、調査方法、対策をまとめます。

結論

応急処置としては、本文エディタ用のCSSを追加し、
iframe内の html の font-size をリセットすれば改善できます。

例えば、テーマ側でGutenberg用CSSを読み込んでいる場合、
以下のようにエディタ専用CSSを追加します。

/wp-content/themes/{theme_name}/functions.php

// Gutenbergにエディタ用CSSを適用する
function block_editor_css() {
    add_theme_support( 'editor-styles' );

    // フロント用CSSをエディタにも適用している場合
    add_editor_style( 'style.css' );
    // 管理画面の本文エディタ補正用CSS
    add_editor_style( 'editor-style.css' );
}
add_action( 'after_setup_theme', 'block_editor_css' );

/wp-content/themes/{theme_name}/editor-style.css

html {
    font-size: 100%;
}

管理画面の本文エディタ上で確実に16px相当に戻したい場合は、以下のように固定してもよいです。

/wp-content/themes/{theme_name}/editor-style.css

html {
    font-size: 16px;
}

ただし、これはあくまで応急処置です。

根本的には、フロント用の style.css を
本文エディタにそのまま読み込ませる構成を見直し、
エディタ専用CSSを分離するのが安全です。

発生した現象

WordPress 7.0へアップデート後、
記事編集画面の本文エディタ内だけ、
文字サイズが小さく表示されました。

フロント画面の表示には問題ありませんでした。

Chrome DevToolsで確認すると、
本文エディタ内の html 要素に、
テーマの style.css に書かれている以下の指定が適用されていました。

/wp-content/themes/{theme_name}/style.css

html {
    min-height: 100vh;
    font-size: calc(10 / 750 * 100vw);
    overflow-x: hidden;
    overflow-y: scroll;
}

このCSSは、フロント画面用に 1rem の基準値を
画面幅に応じて可変にするための指定です。

これが本文エディタのiframe内にも適用されてしまい、
エディタ内の文字サイズが小さくなっていました。

原因

原因は、WordPress 7.0で投稿エディタの表示構造が変わったことです。

WordPress 7.0では、投稿本文に挿入されているブロックのBlock APIバージョンによって、
本文エディタがiframe化されるかどうかが変わります。

ざっくり言うと、以下のような挙動です。

本文内に Block API v2以前のブロックが含まれる場合
- → 従来型の非iframeエディタとして表示される
本文内のブロックがすべて Block API v3以上の場合
- → iframe内に本文エディタが表示される

従来型の非iframeエディタでは、本文エリアは管理画面と同じdocument内に存在します。

イメージとしては以下のような構造です。

<body class="wp-admin">
    <div id="editor">
        <div class="editor-styles-wrapper">
            <p>本文</p>
        </div>
    </div>
</body>

この場合、以下のような管理画面向けCSSが本文エリアにも効きます。

#editor .editor-styles-wrapper {
    font-size: 16px;
}

一方、iframe化された投稿エディタでは、
本文エリアが iframe[name="editor-canvas"] 内の別documentとして表示されます。

イメージとしては以下のような構造です。

<body class="wp-admin">
    <div id="editor">
        <iframe name="editor-canvas">
            #document
                <html>
                    <body>
                        <div class="editor-styles-wrapper">
                            <p>本文</p>
                        </div>
                    </body>
                </html>
        </iframe>
    </div>
</body>

この場合、親画面側に書かれている以下のようなCSSは、
iframe内の本文には届きません。

#editor .editor-styles-wrapper {
    font-size: 16px;
}

つまり、今回の問題は単に「セレクタ名が変わった」という話ではありません。
本文エディタがiframe化されたことで、CSSの適用対象documentが変わったことが本質です。

なぜ文字サイズが小さくなったのか

今回のサイトでは、Gutenbergにフロント用CSSを適用するため、
テーマ側で以下のような実装をしていました。

/wp-content/themes/{theme_name}/functions.php

function block_editor_css() {
    add_theme_support( 'editor-styles' );
    add_editor_style( 'style.css' );
    add_editor_style( 'editor-style.css' );
}
add_action( 'after_setup_theme', 'block_editor_css' );

この設定により、フロント用の style.css が本文エディタにも読み込まれていました。
その style.css には、以下の指定がありました。

/wp-content/themes/{theme_name}/style.css

html {
    font-size: calc(10 / 750 * 100vw);
}

iframe化された本文エディタでは、
iframe内に独立した html 要素が存在します。

そのため、フロント用CSSの html { font-size: calc(...) } が、
iframe内の html に適用されました。

その結果、iframeの幅を基準に font-size が小さく計算され、
本文エディタ内の文字も小さく表示されました。

再現条件

今回の現象は、主に以下の条件が重なったときに発生します。

1. 本文内にBlock API v2以前のブロックが含まれていない

本文内のブロックがすべてBlock API v3以上の場合、投稿エディタがiframe化されます。
そのため、記事の新規投稿画面や、標準ブロックのみで構成された記事では再現しやすいです。

一方で、本文内にBlock API v2以前のカスタムブロックが含まれている場合、
その記事では従来型の非iframeエディタとして表示されることがあります。

その場合は、これまで通り div#editor 配下のCSSが効くため、
見た目が変わらないことがあります。

2. Gutenbergにフロント用CSSを適用している

例えば、以下のように add_editor_style() で
フロント用の style.css を読み込んでいる場合です。

/wp-content/themes/{theme_name}/functions.php

function block_editor_css() {
    add_theme_support( 'editor-styles' );
    add_editor_style( 'style.css' );
}
add_action( 'after_setup_theme', 'block_editor_css' );

この構成自体は珍しくありません。
ただし、フロント用CSSをそのまま本文エディタへ適用すると、
管理画面に不要なグローバル指定まで効いてしまう可能性があります。

3. フロント用CSSに `html` や `body` などの広いセレクタ指定がある

今回の直接原因は、以下の指定でした。

/wp-content/themes/{theme_name}/style.css

html {
    min-height: 100vh;
    font-size: calc(10 / 750 * 100vw);
    overflow-x: hidden;
    overflow-y: scroll;
}

特に問題になりやすいのは以下のような指定です。

html { ... }
body { ... }
:root { ... }
* { ... }

また、以下のような単位を使っている場合も注意が必要です。

rem
vw
vh

今回のように html の font-size を変えている場合、
本文の文字サイズだけでなく、rem を使っている
余白、行間、幅、高さ、ボタンサイズなどにも影響する可能性があります。

確認方法

Chrome DevToolsで、記事編集画面を確認します。

iframe化されているか確認する

Elementsタブで、本文エリアが以下のiframe内に表示されているか確認します。

<iframe name="editor-canvas">

iframe化されている場合、
本文エリアは親画面とは別documentです。

`html` のfont-sizeを確認する

iframe内の html 要素を選択し、
Computedタブで font-size を確認します。

また、Stylesタブで、どのCSSファイルのどの指定が効いているか確認します。

今回のケースでは、以下のように style.css の指定が効いていました。

html {
    font-size: calc(10 / 750 * 100vw);
}

この指定をDevTools上で無効化して文字サイズが戻る場合、原因はほぼ特定できます。

対策1：応急処置としてエディタ用CSSで上書きする

まず、エディタ専用CSSを用意します。

/wp-content/themes/{theme_name}/functions.php

function block_editor_css() {
    add_theme_support( 'editor-styles' );

    // 既存で読み込んでいるフロント用CSS
    add_editor_style( 'style.css' );
    // 管理画面の本文エディタ補正用CSS
    add_editor_style( 'editor-style.css' );
}
add_action( 'after_setup_theme', 'block_editor_css' );

/wp-content/themes/{theme_name}/editor-style.css

html {
    font-size: 100%;
}

100% ではなく、確実に16pxにしたい場合は以下でもよいです。

/wp-content/themes/{theme_name}/editor-style.css

html {
    font-size: 16px;
}

html だけで不十分な場合は、以下も追加します。

/wp-content/themes/{theme_name}/editor-style.css

html,
body,
.editor-styles-wrapper {
    font-size: 16px;
}

ただし、この方法はあくまで上書きです。

フロント用CSSを本文エディタにそのまま読み込ませている限り、
別のグローバル指定が今後も影響する可能性は残ります。

対策2：エディタ専用CSSを分離する

より安全なのは、フロント用CSSをそのままエディタに読み込ませないことです。

例えば、以下のようにエディタ用CSSだけを読み込みます。

/wp-content/themes/{theme_name}/functions.php

function block_editor_css() {
    add_theme_support( 'editor-styles' );
    add_editor_style( 'editor-style.css' );
}
add_action( 'after_setup_theme', 'block_editor_css' );

editor-style.css には、
本文編集に必要な最低限のスタイルだけを書きます。

/wp-content/themes/{theme_name}/editor-style.css

html {
    font-size: 100%;
}

body {
    font-size: 16px;
    line-height: 1.8;
}

.editor-styles-wrapper {
    font-size: 16px;
    line-height: 1.8;
}

.editor-styles-wrapper p {
    margin: 0 0 1em;
}

.editor-styles-wrapper h2 {
    font-size: 1.5em;
    line-height: 1.5;
}

フロント画面の完全再現を目指して style.css を丸ごと読み込ませると、
以下のような指定まで管理画面の本文エディタに入り込む可能性があります。

html {
    font-size: calc(10 / 750 * 100vw);
}

body {
    overflow-x: hidden;
}

* {
    box-sizing: border-box;
}

そのため、Gutenberg用CSSは、
フロント用CSSとは分けて管理するのが安全です。
（二重管理になるので、メンテナンスが煩雑になるという課題はあります。）

Block API v1 / v2 のカスタムブロックがある場合

上記現象の再現手順がわかった理由でもあります。
今回の調査では、自作のカスタムブロックが、
Block API v1で登録されていることも判明しました。

コンソールには以下のような警告が表示されていました。

Block with API version 2 or lower is deprecated since version 6.9.
The block "custom/hide-rss-block" is registered with API version 1.
This means that the post editor may work as a non-iframe editor.
Since all editors are planned to work as iframes in the future,
set the `apiVersion` field to 3 and test the block inside the iframe editor.

この警告が出ている場合、そのブロックを含む記事では、
互換性維持のため従来型の非iframeエディタで表示されることがあります。

つまり、同じサイト内でも以下のように記事によって見た目が変わる可能性があります。

Block API v1 / v2 のカスタムブロックを含む記事
- → 非iframeエディタ
- → 従来の管理画面向けCSSが効く
- → 見た目が従来通り
Block API v1 / v2 のカスタムブロックを含まない記事
- → iframeエディタ
- → 従来の管理画面向けCSSが届かない
- → iframe内に読み込まれたstyle.cssの影響が出る
- → 文字サイズが小さくなる

この場合、文字サイズ問題とは別に、
カスタムブロックのAPIバージョン対応も必要です。

カスタムブロック側でやること

自作のカスタムブロックがある場合は、以下を確認します。

apiVersion が 3 になっているか
iframeエディタ内で正しく表示されるか
document / window を直接参照していないか
editor用CSSがiframe内に読み込まれているか
既存記事でブロックが invalid にならないか
RSSやフィード出力に関係するブロックの場合、従来通り出力制御できているか

古いブロックでは、以下のように apiVersion が未指定、
または1のままになっていることがあります。

wp.blocks.registerBlockType( 'custom/hide-rss-block', {
    title: 'RSS非表示',
    icon: 'hidden',
    category: 'formatting',

    edit: function() {
        // ...
    },

    save: function() {
        // ...
    }
} );

最低限、以下のように apiVersion: 3 を指定します。

wp.blocks.registerBlockType( 'custom/hide-rss-block', {
    apiVersion: 3,
    title: 'RSS非表示',
    icon: 'hidden',
    category: 'formatting',

    edit: function() {
        // ...
    },

    save: function() {
        // ...
    }
} );

ただし、apiVersion: 3 を指定するだけで完全対応とは限りません。

既存の save() が出力するHTMLと、修正後の保存HTMLが変わると、
既存記事で以下のようなエラーが出る可能性があります。

このブロックには、想定されていない、または無効なコンテンツが含まれています。

そのため、既存記事で使用されているカスタムブロックは、
必ず編集・保存・再読み込みまで検証する必要があります。

既存記事でカスタムブロックが使われているか調べる

対象ブロックがどの記事で使われているかは、DBから確認できます。

SELECT ID, post_type, post_status, post_title
FROM wp_posts
WHERE post_content LIKE '%wp:custom/hide-rss-block%'
ORDER BY post_modified DESC;

件数を確認するだけなら以下です。

SELECT post_type, post_status, COUNT(*) AS count
FROM wp_posts
WHERE post_content LIKE '%custom/hide-rss-block%'
GROUP BY post_type, post_status;

これで、修正後に検証すべき記事を洗い出せます。

調査時のチェックリスト

今回のような現象が出た場合、以下を確認すると原因を切り分けやすいです。

WordPress 7.0で発生しているか
記事編集画面に iframe[name="editor-canvas"] が存在するか
iframe内の html / body / .editor-styles-wrapper の computed font-size を確認したか
font-size の出所がテーマの style.css か確認したか
add_editor_style() でフロント用CSSを読み込んでいないか
style.css に html / body / :root / * などの広いセレクタ指定がないか
style.css に rem / vw / vh を使った指定がないか
本文内に Block API v1 / v2 のカスタムブロックが含まれていないか
コンソールに Block API version の警告が出ていないか
既存記事と新規投稿画面で挙動が異ならないか
修正後、フロント画面に影響が出ていないか

まとめ

今回の現象は、単純に「WordPress 7.0で文字サイズが小さくなった」というより、
以下のように整理できます。

WordPress 7.0で投稿エディタのiframe化条件が変わった
↓
記事本文のブロック構成によって、非iframeエディタとiframeエディタに分岐する
↓
iframeエディタでは本文エリアが親画面とは別documentになる
↓
これまで div#editor 配下に当てていた管理画面向けCSSがiframe内に届かない
↓
iframe内に読み込まれたフロント用 style.css が効く
↓
style.css の html { font-size: calc(...) } により本文エディタの文字サイズが小さくなる

応急処置としては、エディタ専用CSSで html の font-size をリセットすれば改善できます。

html {
    font-size: 100%;
}

ただし、根本的には、フロント用CSSをGutenbergの本文エディタにそのまま読み込ませるのではなく、
エディタ専用CSSを分離するのが安全です。

また、Block API v1 / v2 のカスタムブロックが残っている場合、
今後のWordPressではiframeエディタ前提の対応が必要になります。

そのため、以下の2つを分けて対応するのがよいです。

1. 文字サイズ問題
   → editor-style.cssを分離し、iframe内の本文表示を補正する

2. カスタムブロックの互換性問題
   → apiVersion: 3へ移行し、iframeエディタ内で検証する

WordPress 7.0以降は、Gutenbergの本文エリアを「管理画面の一部」として見るよりも、
iframe内に表示される独立した編集用documentとして扱った方が、
CSSの問題を切り分けやすくなります。