i-f – Web Works –

WP-CLIで記事本文を更新するとブロックが壊れる原因と防ぎ方

  • 2026年9月21日
  • etc
etc WP-CLIで記事本文を更新するとブロックが壊れる原因と防ぎ方

WP-CLIを使うと、記事の本文をファイルから流し込めます。

スポンサーリンク

何十本もまとめて直すときは、これが一番早いです。

エックスサーバーでWP-CLIが動かないときは、エックスサーバーでWP-CLIを使う｜wpコマンドが動かない原因と対処を先に見てください。

ですが、更新したあとに編集画面を開くと、こんな警告が出ることがあります。

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

見た目は崩れていないのに、編集画面だけが赤くなります。原因はHTMLではありません。

  1. WP-CLIで本文を差し替えるとブロックが壊れる理由
  2. 更新前と更新後に検算する方法
  3. 一部だけ差し替えるときの安全なやり方
  4. –user オプションは必要なのか（実測しました）
目次

原因は、ブロックコメントのずれです。

ブロックエディタの記事本文は、ただのHTMLではありません。

データベースには、こういう形で入っています。

<!-- wp:heading -->
<h2 class="wp-block-heading">見出しです。</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>本文です。</p>
<!-- /wp:paragraph -->

HTMLコメントで、1ブロックずつ囲まれています。

ブラウザから見れば、コメントはただの飾りです。だからサイトの表示は崩れません。

ですが編集画面は、このコメントを見てブロックを組み立てています。開始と終了の対応が崩れると、そこから先を解釈できなくなって警告が出ます。

本文の途中に文章を1つ差し込んだだけ、というときにこれが起きます。<!-- wp:paragraph --> を書き忘れたり、既存のブロックの内側に入ってしまったりするからです。

スポンサーリンク

まず、更新前の本文を保存しておきます。

作業の前に、必ず現状を取り出しておきます。

wp post get 123 --field=post_content > before.html

これがあれば、失敗してもそのまま書き戻せます。

wp post update 123 before.html

リビジョンからも戻せますが、手元にファイルがあるほうが確実です。

スポンサーリンク

ブロックコメントの数を数えて検算します。

壊れているかどうかは、開始と終了の数を数えれば分かります。

# 開始タグの数（自己完結ブロックを除く）
grep -o '<!-- wp:[^/]' new.html | wc -l

# 終了タグの数
grep -o '<!-- /wp:' new.html | wc -l

この2つの数が合っていなければ、その時点で壊れています。

ひとつ注意があります。画像やリストの中に入れ子になるブロックがあるので、必ず更新前のファイルでも同じ数え方をして、差が想定どおりかを見てください。

段落を3つ足したなら、両方とも3ずつ増えているはずです。片方だけ増えていたら書き間違えています。

実際にこれで、見出しブロックの <!-- wp:heading --> と <h2> が離れてしまっているのを見つけました。数えるだけなので、更新のたびにやっておく価値があります。

スポンサーリンク

元から壊れていることもあります。

数が合わないので自分のミスを探したものの、見つからないことがありました。

更新前のファイルを数えてみたら、元の本文がすでに壊れていました。

中身が空の <ul> の後ろに <!-- /wp:paragraph --> だけが残っている、という状態です。過去に編集画面で操作したときの取りこぼしだと思います。

表示には出ないので、何年も気づきませんでした。

差し替えのついでに直せるので、数が合わないときは自分のミスと決めつけず、更新前のファイルも数えてみてください。

一部だけ差し替えるときは、行番号で切り貼りします。

本文の一部だけを入れ替えたいときは、文字列を探して置換するより、行番号で切ったほうが安全です。

# どこを差し替えるか、行番号で確認する
grep -n 'wp:heading' before.html

# 1〜40行目 + 差し込むHTML + 55行目以降
head -n 40 before.html  >  new.html
cat insert.html         >> new.html
tail -n +55 before.html >> new.html

このとき、切る位置をブロックの境目に合わせます。

<!-- wp:heading --> と <h2> の間で切ってしまうと、ブロックが真っ二つになります。壊れるのはたいていここです。

差し込むHTMLのほうも、ブロックコメントで囲んだ状態で用意しておきます。

–user オプションは必要なのか。

「WP-CLIで更新するとHTMLが除去されるので --user=1 を付けろ」という話を見かけます。

気になったので、下書き記事を作って実際に試しました。

wp eval '
echo get_current_user_id() . "\n";
echo var_export( current_user_can("unfiltered_html"), true ) . "\n";
echo var_export( has_filter("content_save_pre","wp_filter_post_kses"), true ) . "\n";
'

結果は、こうでした。

0
false
false

ユーザーは未指定（ID 0）で、権限もありません。

ですが3行目が false です。除去する処理そのものが登録されていません。

実際に --user なしで data-lang 属性や iframe を含む本文を流し込んでも、そのまま保存されました。WP-CLIは、スクリプトで扱うときに中身が変わってしまわないよう、この処理を外しているようです。

つまり、HTMLを守る目的では --user は要りません。

ただし、付けておいたほうがいい理由は別にあります。

  • リビジョンの作成者が「不明」にならない。
  • 保存時に権限を見るプラグインがある場合に、処理が正しく走る。
  • あとから更新履歴を見たときに、誰の操作か分かる。

害はないので、管理者のIDを付けておけばいいと思います。

# 管理者のIDを調べる
wp user list --role=administrator --field=ID

wp post update 123 new.html --user=1

なお、この挙動はWordPressやWP-CLIのバージョンで変わる可能性があります。確認したのはWordPress 7.1.1です。心配なら、上のコードを自分の環境で走らせてみてください。

まとめ

WP-CLIで本文を差し替えるときは、この順番で進めると安全です。

  1. 更新前の本文をファイルに保存する。
  2. ブロックコメントの開始と終了の数を数えておく。
  3. ブロックの境目で切って、差し込む。
  4. 更新用のファイルでもう一度数えて、差が想定どおりか見る。
  5. 更新して、編集画面を開いて警告が出ていないか確かめる。

表示が崩れないぶん、壊れていても気づきにくいのがやっかいなところです。

数を数えるだけで防げるので、習慣にしておくのがおすすめです。

スポンサーリンク
スポンサーリンク