「テキストタブで一生懸命コードを書いたのに、ビジュアルタブに切り替えたら全部崩れた……」
WordPressのクラシックエディターを使っていて、こんな絶望的な経験をしたことはありませんか？
ブロックエディター（Gutenberg）が主流になった今でも、クラシックエディターを愛用している方は少なくありません。使い慣れたインターフェースの方が執筆スピードが出るという方、既存サイトの運用で変更が難しいという方、さまざまな理由があるでしょう。
しかし、クラシックエディターには昔からある「困った仕様」が存在します。それが、テキストタブ（コードエディター）で入力したHTMLが、ビジュアルタブに切り替えた瞬間に勝手に書き換えられてしまうという問題です。
この記事では、この問題がなぜ起きるのかを詳しく解説し、確実に防ぐための7つの対策を紹介します。「もう二度とコードを壊されたくない！」という方は、ぜひ最後まで読んでみてください。
この記事の結論
HTMLが崩れる原因はTinyMCEの自動整形とWordPressのwpautop関数の二重処理です。最も確実な対策は「TinyMCE設定の変更（functions.php）＋ Syntax Highlighterプラグイン ＋ ビジュアルタブに切り替えない運用ルール」の3点セットです。
そもそも何が起きているのか？ ― 症状の具体例
テキストタブで書いたHTMLがビジュアルタブへの切替時に「空タグの削除」「pタグの自動変換」「HTMLエンティティのデコード」「インラインスタイルの改変」「改行・インデントの消滅」という5種類の崩れを起こします。
まずは「何が崩れるのか」を具体的に見てみましょう。テキストタブで以下のようなHTMLを入力したとします。
症状1: 空のタグが削除される
テキストタブで入力したコード：
|
1 2 |
<div class="spacer"></div> <span id="anchor"></span> |
ビジュアルタブに切り替えて戻すと：
|
1 |
（完全に消滅） |
中身が空のタグは「不要」と判断されて、丸ごと削除されてしまいます。CSSでスペーサーやアンカーとして使っていた場合、レイアウトが完全に崩壊します。
症状2: pタグとbrタグの自動変換
テキストタブで入力したコード：
|
1 2 3 |
<p>1行目のテキスト</p> <p>2行目のテキスト</p> <p>3行目のテキスト</p> |
ビジュアルタブ経由で戻ると、余分な改行が入ったり、逆にpタグが統合されたりすることがあります。wpautop関数による自動整形が絡み合い、意図しない段落構造に変わってしまうのです。
症状3: HTMLエンティティがデコードされる
テキストタブで入力したコード：
|
1 |
コード例: <div class="example"> |
ビジュアルタブ経由で戻ると：
|
1 |
コード例: <div class="example"> |
記事中にコードスニペットを「表示」するためにエスケープしていたエンティティが、実際のHTMLタグとしてデコードされてしまいます。これは技術ブログを書いている方にとっては致命的な問題です。
症状4: インラインスタイルの改変
テキストタブで入力したコード：
|
1 2 3 |
<div style="margin: 20px 0; padding: 15px; background: #f5f5f5;"> カスタムボックス </div> |
ビジュアルタブ経由で戻ると、styleの記述が短縮・変更されたり、一部のプロパティが削除されたりすることがあります。
CSSとキャッシュの問題については「WordPressでCSS更新が反映されない｜キャッシュ5層の切り分け」も参考になります
症状5: コードがminify化される（改行・スペースの消滅）
テキストタブで見やすく整形して書いたコード：
|
1 2 3 4 5 6 7 8 |
<div class="wrapper"> <h2>タイトル</h2> <p>本文テキスト</p> <ul> <li>項目1</li> <li>項目2</li> </ul> </div> |
ビジュアルタブに切り替えてテキストタブに戻すと：
|
1 |
<div class="wrapper"><h2>タイトル</h2><p>本文テキスト</p><ul><li>項目1</li><li>項目2</li></ul></div> |
すべてが1行にまとめられ、まるでminifyツールを通したかのような状態になります。TinyMCEはHTMLをDOM（文書オブジェクトモデル）として解析する際に、タグ間の改行やインデントを「不要な空白」として除去してしまうのです。
コードの内容自体は変わっていないため表示上は問題ありませんが、後から記事を修正しようとしたときに非常に読みづらく、編集効率が大幅に低下します。特にテーブルや複雑なレイアウトを含む記事では、元の構造を把握するのが困難になります。
なぜ崩れるのか？ ― TinyMCEの自動整形の仕組み
原因は、ビジュアルタブ内部で動作する「TinyMCE」エディターの自動正規化処理と、WordPress本体の「wpautop」関数による自動pタグ挿入が、切替のたびに二重に掛かることです。
クラシックエディターのビジュアルタブは、内部で「TinyMCE」というWYSIWYGエディターを使用しています。TinyMCEはHTMLをリアルタイムで編集できる優れたライブラリですが、ビジュアルタブに切り替える際にHTMLを「正規化」する処理が走ります。
TinyMCEが行う自動処理の一覧
| 処理内容 | 具体例 | 影響 |
|---|---|---|
| 空タグの除去 | 空の<div>、<span>を削除 | レイアウト崩壊 |
| HTMLエンティティのデコード | < → <、& → & | コード表示が壊れる |
| 不正HTMLの自動修正 | 閉じタグの補完・移動 | 構造が変わる |
| pタグの自動挿入 | テキストにpタグを自動付与 | 余分な余白 |
| brタグの変換 | 改行をbrに変換、または除去 | 改行位置がずれる |
| 属性の正規化 | style属性の短縮・削除 | デザインが変わる |
| 改行・インデントの除去 | 整形されたHTMLが1行に圧縮 | コードが読めなくなる |
| switchEditorsによるHTML変換 | 切替時にJS側で独自整形 | TinyMCE設定では防げない |
さらに、WordPress本体にも「wpautop」という関数があり、これが保存時にpタグやbrタグを自動挿入します。TinyMCEの処理とwpautopの処理が二重に掛かることで、HTML構造がどんどん崩れていくのです。
崩れが発生するタイミング
具体的には、以下のフローで崩れが発生します：
① テキストタブでHTMLを入力
↓
② ビジュアルタブに切り替え → switchEditors.wpautop()がpタグを自動挿入 → TinyMCEがHTMLを解析・正規化
↓
③ テキストタブに戻す → switchEditors._wp_Nop()がHTMLを整理・minify化 → TinyMCEが再度HTMLを出力
↓
④ 保存 → wpautopが<p>タグを自動挿入
つまり、②の時点ですでにHTMLが書き換わっており、テキストタブに戻しても「元のコード」には戻らないのです。特にminify化（改行の消滅）は③のswitchEditors._wp_Nop()で発生するため、TinyMCEの設定だけでは防げないケースがあります。
【対策①】TinyMCEの自動整形を無効化する（functions.php）
functions.phpにTinyMCEの設定パラメータを追加し、自動pタグ挿入・改行削除・空タグ除去・HTML検証・minify化をすべて無効化します。さらにswitchEditorsのJS処理もパススルーにすることで、切替時のHTML変換を完全にスキップできます。
最も直接的な対策は、TinyMCEの自動整形そのものをオフにすることです。テーマのfunctions.phpに以下のコードを追加します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
// TinyMCE のビジュアル⇔テキスト切替時の自動整形を抑制 function disable_tinymce_auto_formatting( $init_array ) { // 自動p タグ挿入を無効化 $init_array['wpautop'] = false; // 改行の自動削除を無効化 $init_array['remove_linebreaks'] = false; // 冗長な<br>タグの自動削除を無効化 $init_array['remove_redundant_brs'] = false; // HTML検証（自動修正）を無効化 $init_array['verify_html'] = false; // minify化（改行・インデントの消滅）を防止 $init_array['indent'] = true; $init_array['indent_before'] = 'p,h1,h2,h3,h4,h5,h6,div,ul,ol,li,table,thead,tbody,tr,td,th,pre,blockquote,section,article,header,footer,nav,figure,figcaption,hr,br,img'; $init_array['indent_after'] = 'p,h1,h2,h3,h4,h5,h6,div,ul,ol,li,table,thead,tbody,tr,td,th,pre,blockquote,section,article,header,footer,nav,figure,figcaption,hr,br,img'; return $init_array; } add_filter( 'tiny_mce_before_init', 'disable_tinymce_auto_formatting' ); |
各パラメータの解説
wpautop: TinyMCE内での自動段落挿入を制御します。falseにすることで、テキストタブで書いたpタグ構造がそのまま維持されます。
remove_linebreaks: HTMLソースから不要と判断された改行を削除する機能です。falseにすると、テキストタブで入れた改行がそのまま保持されます。
remove_redundant_brs: 連続する<br>タグを「冗長」として削除する機能です。意図的にbrを入れている場合、falseにしておかないと消えてしまいます。
verify_html: HTMLの妥当性チェックと自動修正を行う機能です。falseにすることで、空タグの削除や閉じタグの自動補完が抑制されます。
minify化（改行・スペースの消滅）を防ぐ追加設定
上記の4つのパラメータだけでは、ビジュアルタブに切り替えた際にHTMLがminifyされたように改行やインデント（スペース）がすべて除去されてしまうことがあります。これはTinyMCEがHTMLをDOM（文書オブジェクトモデル）として解析する際に、タグ間の空白テキストノードを「不要」と判断して削除するためです。
テキストタブで見やすく整形して書いたコードが、ビジュアルタブ経由で1行にまとめられてしまうと、後から編集するときに非常に読みづらくなります。
この問題を防ぐために、上記コードには以下の3つのパラメータも含めています：
indent: TinyMCEのHTMLシリアライザ（出力エンジン）が、タグ間に改行とインデントを挿入するようになります。trueにすることで、minify化されたコードに改行が復元されます。
indent_before: 指定した要素の開始タグの前に改行を挿入します。p、div、table、liなど、ブロックレベル要素を網羅的に指定しておくのがポイントです。
indent_after: 指定した要素の閉じタグの後に改行を挿入します。indent_beforeとセットで指定することで、要素ごとに改行が入った読みやすいHTMLが維持されます。
それでもminify化が解消しない場合 ― switchEditorsの無効化
上記のindent設定を追加してもminify化が解消しない場合があります。これは、TinyMCEの設定とは別のレイヤーでHTMLが処理されているためです。
WordPressには switchEditors というJavaScriptオブジェクトが組み込まれており、テキスト⇔ビジュアルの切替時に独自のHTML変換処理を行っています。具体的には以下の2つの関数です：
switchEditors.wpautop()：テキスト→ビジュアル切替時にpタグを自動挿入する関数です。
switchEditors._wp_Nop()：ビジュアル→テキスト切替時にHTMLを整理する関数です。minify化はここで発生します。
functions.phpの tiny_mce_before_init フィルターはTinyMCEエンジンの設定を変えるだけで、この switchEditors のJavaScript処理には影響しません。つまり、TinyMCE以前の段階で改行が消されているのです。
この問題を解決するには、functions.phpに以下のコードを追加します。先ほどの disable_tinymce_auto_formatting はそのまま残し、追加で記述してください：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
// switchEditors の wpautop / _wp_Nop を無効化して minify を防ぐ function disable_switcheditors_minify() { // 投稿編集画面でのみ実行 $screen = get_current_screen(); if ( ! $screen || $screen->base !== 'post' ) { return; } ?> <script type="text/javascript"> jQuery(document).ready(function() { if ( typeof switchEditors !== 'undefined' ) { // テキスト→ビジュアル切替時の自動pタグ挿入を無効化 switchEditors.wpautop = function( content ) { return content; }; // ビジュアル→テキスト切替時のHTML整理（minify化）を無効化 switchEditors._wp_Nop = function( content ) { return content; }; } }); </script> <?php } add_action( 'admin_footer', 'disable_switcheditors_minify' ); |
この方法で switchEditors の2つの関数をパススルー（入力をそのまま返す）に差し替えるため、切替時のHTML変換処理が完全にスキップされます。
switchEditors無効化の副作用を詳しく理解する
switchEditorsを無効化する前に、この変更が何に影響するのかを正確に理解しておきましょう。
■ 通常の動作（switchEditorsが有効な場合）
ビジュアルタブで以下のように改行しながら文章を書いたとします：
|
1 2 3 |
今日は天気がいいです。 明日は雨になるそうです。 来週は晴れるでしょう。 |
テキストタブに切り替えると、switchEditors.wpautop() が自動的に変換してくれます：
|
1 2 3 |
<p>今日は天気がいいです。</p> <p>明日は雨になるそうです。</p> <p>来週は晴れるでしょう。</p> |
逆にテキストタブからビジュアルタブに戻すときは、switchEditors._wp_Nop() が <p> タグを取り除いてビジュアルエディター上で自然な表示にしてくれます。
つまり、この2つの関数はビジュアルタブとテキストタブの「翻訳者」のような役割を担っています。
■ switchEditorsを無効化した場合
パススルーにした状態でビジュアルタブで同じように書くと、テキストタブに切り替えても：
|
1 2 3 |
今日は天気がいいです。 明日は雨になるそうです。 来週は晴れるでしょう。 |
<p> タグが付きません。この状態で保存すると、フロントエンド（実際のサイト表示）ではwpautop関数が有効であれば段落に変換されるので表示上は問題ないケースが多いです。
ただし、対策②でwpautopも無効化している場合は、改行がただの空白として扱われ、フロントエンドでは全文が1つの塊として表示されてしまいます。
■ 具体的に困るケース
ケース1：ビジュアルタブとテキストタブを行き来する執筆スタイルの方
ビジュアルタブで書いた段落がテキストタブ側で <p> タグに変換されないため、テキストタブで見たときに「どこが段落の区切りなのか」が分かりづらくなります。テキストタブ側で追加のHTML編集をする際に混乱しやすくなります。
ケース2：wpautop（対策②）も同時に無効化している方
翻訳者（switchEditors）も自動段落（wpautop）も両方オフにしている状態なので、ビジュアルタブで改行しただけでは段落にならず、自分で <p> タグを書く必要があります。
ケース3：複数人で記事を編集するサイト
他のライターがビジュアルタブで普通に執筆している場合、その方の記事の段落構造が壊れる可能性があります。switchEditorsの無効化はサイト全体に影響するため、自分だけの問題では済みません。
■ 誰に影響があって、誰に影響がないか
| 執筆スタイル | 影響 |
|---|---|
| テキストタブのみで執筆 （自分で<p>タグを書く） |
影響なし ― そもそもswitchEditorsの変換に頼っていない |
| ビジュアルタブのみで執筆 ＋ wpautop有効 |
ほぼ影響なし ― フロントエンドではwpautopが段落を生成してくれる |
| ビジュアルタブのみで執筆 ＋ wpautop無効 |
影響あり ― 段落が生成されない |
| テキスト⇔ビジュアルを 頻繁に切り替える |
影響あり ― テキストタブ側で段落構造が見えなくなる |
| 複数ライターのサイト | 要注意 ― 他のライターの執筆にも影響が出る |
【対策②】wpautopフィルターを無効化する
WordPress本体のwpautop関数を無効化することで、保存時の自動pタグ挿入を止められます。既存記事への影響が心配な場合は、カスタムフィールドで投稿ごとに選択的に無効化する方法がおすすめです。
WordPressには「wpautop」という関数があり、投稿の表示時にテキストを自動的にpタグで囲みます。これはTinyMCEとは別の処理で、保存後の表示段階で実行されます。
対策①と組み合わせることで、より確実にHTML構造を保護できます。
|
1 2 3 |
// wpautop（自動 <p> タグ挿入）を無効化 remove_filter( 'the_content', 'wpautop' ); remove_filter( 'the_excerpt', 'wpautop' ); |
wpautopを無効化する際の注意点
wpautopを無効化すると、すべての投稿・固定ページで自動段落分けが効かなくなります。つまり、今まで改行だけで書いていた記事のpタグが付かなくなり、表示が崩れる可能性があります。
そのため、既存の記事が多いサイトでは安易に無効化せず、以下のような選択的な方法を検討してください。
特定の投稿だけwpautopを無効化する方法
|
1 2 3 4 5 6 7 8 9 10 11 |
// カスタムフィールド 'disable_wpautop' が設定された投稿のみ無効化 function selective_wpautop( $content ) { global $post; if ( get_post_meta( $post->ID, 'disable_wpautop', true ) ) { return $content; } return wpautop( $content ); } remove_filter( 'the_content', 'wpautop' ); add_filter( 'the_content', 'selective_wpautop' ); |
この方法なら、HTMLを厳密に管理したい投稿だけ選択的にwpautopを無効化できます。投稿編集画面のカスタムフィールドで「disable_wpautop」を「1」に設定するだけでOKです。
【対策③】プラグインで対処する
コードを書きたくない方には「Advanced Editor Tools」プラグインがおすすめです。「パラグラフタグを保持」オプションを有効にするだけで、pタグ・brタグの自動変換を抑制できます。
Advanced Editor Tools（旧：TinyMCE Advanced）【おすすめ】
現在最も現実的なプラグイン対策がこのAdvanced Editor Toolsです。70万以上のサイトで有効化されており、定期的にアップデートされている信頼性の高いプラグインです。
このプラグインの「上級者向け設定」セクションに「クラシックブロックとクラシックエディター内のパラグラフタグを保持」というオプションがあり、テキストタブとビジュアルタブの切替時にpタグやbrタグが自動変換されるのを抑制できます。
設定方法：
① WordPress管理画面 → 設定 → Advanced Editor Tools を開く
② 画面を下にスクロールし「上級者向け設定」セクションを見つける
③ 「クラシックブロックとクラシックエディター内のパラグラフタグを保持」にチェックを入れる
④ 「変更を保存」をクリック
この設定を有効にすると、クラシックエディターで <p> タグと <br> タグが自動的に除去されなくなり、テキストタブにこれらのタグがそのまま表示されます。また、テキストエディターの自動補完が停止され、より高度なHTML編集が可能になります。
さらに、画面最下部の「管理」セクションで以下のオプションもチェックしておくと、クラシックエディター全体でAdvanced Editor Toolsの設定が適用されます：
☑ 旧エディター（投稿と固定ページの新規追加と編集）
☑ wp-adminのクラシック（TinyMCE）エディターの他のインスタンス
Advanced Editor Toolsにはそのほか、ビジュアルエディターのツールバーボタンのカスタマイズ、テーブルの詳細設定（セル結合・背景色・リサイズなど）、フォントファミリー・フォントサイズの選択ボタン、リストスタイルオプション（順序付きリストの記号変更など）といった便利な機能も含まれています。
Preserved HTML Editor Markup Plus（開発終了）
かつてはHTML保護の定番プラグインでした。テキストタブで入力したHTMLマークアップがビジュアルタブへの切替時に変更されるのを防ぐ目的で開発され、空タグの削除防止やwpautopの制御など、この記事で扱っている問題にぴったりの機能を持っていました。
現在このプラグインを使用中のサイトでは、Advanced Editor Tools への移行（「パラグラフタグを保持」オプションが代替になる）、対策①（functions.php）への移行（プラグインに依存しない方法）、またはその両方を組み合わせて、プラグイン削除後も同等の保護を確保することを検討してください。
Raw HTML Pro
記事の特定の部分だけTinyMCEの処理から保護したい場合に便利なプラグインです。専用のタグで囲んだ部分のHTMLがそのまま保持されます。
|
1 2 3 4 5 |
[raw] <div class="custom-layout"> ここのHTMLはTinyMCEに変更されません </div> [/raw] |
サイト全体の設定を変えたくないが、特定の投稿や特定のHTML部分だけ確実に保護したいという場合に重宝します。
【対策④】ショートコードでコード部分を保護する
記事中にHTMLコードを「表示」したい場合、自作のショートコードで囲むことでTinyMCEの処理対象から外し、HTMLエンティティのデコードを防げます。技術ブログでコードスニペットを掲載する方に有効です。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
// functions.php に追加 function protected_code_shortcode( $atts, $content = null ) { // brタグの除去（wpautopが挿入する可能性があるため） $content = str_replace( array( '<br />', '<br>', '<br/>' ), '', $content ); // pタグの除去 $content = str_replace( array( '<p>', '</p>' ), '', $content ); // HTMLエスケープして安全に表示 return '<pre><code>' . esc_html( trim( $content ) ) . '</code></pre>'; } add_shortcode( 'code', 'protected_code_shortcode' ); |
使い方
テキストタブで以下のように入力します。
|
1 2 3 4 5 |
[code] <div class="example"> <p>HTMLコードの表示例</p> </div> [/code] |
ショートコード内のHTMLは、ビジュアルタブに切り替えても安全に保持されます。表示時にesc_html()でエスケープされるため、HTMLタグがそのまま「コード」として表示されます。
ショートコードの拡張：言語指定に対応する
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
function enhanced_code_shortcode( $atts, $content = null ) { $atts = shortcode_atts( array( 'lang' => '', ), $atts ); $content = str_replace( array( '<br />', '<br>', '<br/>', '<p>', '</p>' ), '', $content ); $lang_class = $atts['lang'] ? ' class="language-' . esc_attr( $atts['lang'] ) . '"' : ''; return '<pre><code' . $lang_class . '>' . esc_html( trim( $content ) ) . '</code></pre>'; } add_shortcode( 'code', 'enhanced_code_shortcode' ); |
これでCSSでの言語別スタイリングや、Prism.jsなどのシンタックスハイライトとの連携も可能になります。
【対策⑤】Syntax Highlighterプラグインを使う
技術記事でコードスニペットを多用する場合、シンタックスハイライターの導入が最もスマートな解決策です。専用ブロックやショートコードで管理されるため、TinyMCEの自動整形の影響を一切受けません。
おすすめプラグイン
Highlighting Code Block：日本製のプラグインで、ブロックエディターとクラシックエディターの両方に対応しています。Prism.jsベースで軽量、テーマカスタマイズも可能です。
Enlighter：TinyMCEへの統合が優秀で、クラシックエディターでの利用に特に適しています。ビジュアルエディター上で直接コードブロックを挿入でき、専用のボタンがツールバーに追加されます。
SyntaxHighlighter Evolved：WordPress.comでも使われている実績のあるプラグインです。ショートコードベースなので、クラシックエディターとの相性が抜群です。
いずれのプラグインも、コード部分を専用フォーマットで管理するため、ビジュアル⇔テキスト切替でコードが崩れる心配がありません。
図.編集画面
図.フロントエンド画面
【対策⑥】カスタムHTMLブロック（ハイブリッド運用）
Classic Editorプラグインの設定でエディター切替を許可し、HTMLを厳密に管理したい記事だけブロックエディターの「カスタムHTMLブロック」を使う方法です。カスタムHTMLブロック内のHTMLは一切の自動整形を受けません。
「基本はクラシックエディターを使いたいけど、一部だけHTMLを厳密に管理したい」という場合、ハイブリッド運用が有効です。
Classic Editorプラグインの設定で「すべてのユーザーのデフォルトエディター」を「クラシックエディター」にしつつ、「ユーザーにエディターの切り替えを許可」を「はい」にします。
これにより、基本的にはクラシックエディターで執筆しつつ、HTMLを厳密に管理したい記事だけブロックエディターに切り替えて「カスタムHTML」ブロックを使うことができます。
【対策⑦】最も確実な運用ルール
最も確実な方法は「テキストタブで編集を始めたら、その記事ではビジュアルタブに切り替えない」というルールを徹底することです。見た目の確認はビジュアルタブではなく「プレビュー」ボタンを使いましょう。
正直なところ、TinyMCEの自動整形はビジュアルタブに切り替えた瞬間にトリガーされるため、切り替えなければ崩れようがありません。
具体的な運用ガイドライン
① 記事の種類で使い分ける：HTMLをほとんど使わない記事はビジュアルタブのみで執筆。カスタムHTMLが多い記事はテキストタブのみで執筆。
② プレビューで確認する：テキストタブで執筆中に見た目を確認したい場合は、ビジュアルタブに切り替えるのではなく「プレビュー」ボタンを使います。プレビューはTinyMCEを経由しないため、HTMLが崩れません。
③ バックアップの習慣：テキストタブで複雑なHTMLを書く場合は、コードをテキストエディタにコピーしてバックアップを取ってから保存する習慣をつけましょう。
どの対策を選ぶべきか？ ― フローチャート
functions.phpの編集に抵抗がなく技術ブログを運営しているなら「対策① ＋ 対策⑤ ＋ 対策⑦」の3点セットが王道です。コードを書きたくない方は「対策③（プラグイン）＋ 対策⑦（運用ルール）」の組み合わせが最も手軽です。
7つの対策を紹介しましたが、どれを選べばいいか迷う方のために、判断フローチャートを用意しました。
対策選びフローチャート
Q1. functions.phpの編集に抵抗はありますか？
→ はい → 対策③（プラグイン）または対策⑤（Syntax Highlighter）
→ いいえ → Q2へ
Q2. 既存の記事が多く、表示への影響が心配ですか？
→ はい → 対策①（TinyMCE設定のみ）+ 対策⑦（運用ルール）
→ いいえ → Q3へ
Q3. 技術ブログでコードスニペットを多用しますか？
→ はい → 対策⑤（Syntax Highlighter）+ 対策①（TinyMCE設定）
→ いいえ → 対策① + 対策② + 対策⑦（フルセット）
まとめ
クラシックエディターのHTML崩れは「TinyMCEの自動整形」と「wpautop関数」の二重処理が原因です。対策①（TinyMCE設定）＋ 対策⑤（Syntax Highlighter）＋ 対策⑦（運用ルール）の3点セットが、バランスよく対処できる王道パターンです。
この記事で紹介した7つの対策をまとめると：
| 対策 | 方法 | 難易度 | おすすめ度 |
|---|---|---|---|
| ① | TinyMCE設定の変更 | ★★☆ | ★★★ |
| ② | wpautopの無効化 | ★★☆ | ★★☆ |
| ③ | プラグインで対処 | ★☆☆ | ★★★ |
| ④ | ショートコードで保護 | ★★☆ | ★★☆ |
| ⑤ | Syntax Highlighter | ★☆☆ | ★★★ |
| ⑥ | ハイブリッド運用 | ★☆☆ | ★★☆ |
| ⑦ | 運用ルールの徹底 | ★☆☆ | ★★★ |
ブロックエディターが主流の時代とはいえ、クラシックエディターには独自の良さがあります。この記事の対策を活用して、快適なクラシックエディター生活を送ってください。
コメント