うっかり「11」という名前のカテゴリを作ってしまった話

WordPressのカテゴリ構造を整理していたとき、WP-CLIで記事に子カテゴリをまとめて割り当てる作業をしていました。
そこで、地味に怖い罠を踏みました。エラーは一切出ていません。

🎥 この記事の内容は動画でも解説しています。

「成功」と表示されたのに、何かがおかしい

WordPressカテゴリの下に、メール・セキュリティ・SEO・構造化データ・GA4・アナリティクス・運用・トラブル・カスタマイズ・拡張という6つの子カテゴリ(term_id 11〜16)を新しく作って、既存の記事をそこへ割り当てていく作業をしていました。
使ったコマンドはこんな感じです。

wp post term add 321 category 11

投稿ID321の記事に、term_idが11番の子カテゴリを割り当てるつもりでした。
実行するとSuccess: Added term to post.と表示されます。エラーは無し。特に気にせず、同じ調子で残り5つの記事にも12から16まで順番に流していきました。

作業が一段落してサイドバーを見たら、見慣れない項目が並んでいました。
「11」「12」「13」「14」「15」「16」。数字だけの名前のカテゴリが、6個もきれいに並んでいます。
一瞬「これ何?」と固まりました。自分で意図して作った覚えは、当然ありません。

最初は、何かのプラグインが自動生成したのかと疑いました。
でも心当たりのあるプラグインは無く、番号が11から16まで連番になっていることに気づいた瞬間、さっき自分が打ったコマンドの数字と一致していることに思い当たりました。

原因は、数字が「ID」ではなく「名前」として扱われていたこと

wp post term addは、既定では渡した値を数値のterm_idとして扱わず、term名かスラッグとして扱う仕様でした。
つまりcategory 11と書くと、WP-CLIは「11」という名前を持つカテゴリを探しに行きます。

該当するカテゴリが存在しない場合、WP-CLIは親切にも(?)新しく作って割り当ててくれます。
しかもこの挙動はエラー扱いにならず、正常終了のSuccessがそのまま返ります。
だから6回連続でやらかしても、1回も気づけませんでした。

term_idを本当に数値として扱わせるには、--by=idというオプションが必要でした。

wp post term add 321 category 11 --by=id

このオプションを付けて初めて、「11」という数値をterm_idとして解釈してくれます。

実際に再現してみました

この記事のために、テスト用の下書きを1本作って、あえて--by=id無しで同じ操作を試してみました。

実行結果をwp term list categoryで確認すると、こうなります。

wp term list categoryの実行結果。term_id34に名前が「11」というだけの意図しないカテゴリが作られており、本来のterm_id11「メール」とは別物として存在していることが分かるターミナルのスクリーンショット

本来のterm_id11は「メール」というカテゴリなのに、term_id34という全く別の場所に、名前が「11」というだけの、意味を持たないカテゴリがしっかり存在しています。

エラーが出ないタイプの罠は、後片付けも1テンポ遅れる

後片付け自体は単純でした。間違って作られた6個のカテゴリを削除し、正しいオプション付きで6回分のコマンドを実行し直すだけです。
作業時間としては5分もかかっていません。

ただ、気づくまでにかかった時間が長かったのが痛かったです。
サイドバーをたまたま見ていなければ、あの数字だけのカテゴリは、誰にも気づかれないままサイトに残り続けていたと思います。
後から見返して「これいつ増えたんだっけ」と原因を辿り直す手間を考えると、気づくタイミングが早いか遅いかで、対応の負担はけっこう変わってきます。

本番環境の作業では、この反省を踏まえてWP-CLIのコマンドをそのまま叩くのをやめました。
代わりにPHPからwp_set_object_terms()を直接呼ぶスクリプトに切り替え、term_idは配列の中で明示的に整数として渡すようにしています。
コマンドラインの引数という、文字列か数値かがあいまいになりやすい経路を挟まない分、こちらの方が安心して実行できています。

他にも同じ罠がないか、一通り洗い直しました

今回の件をきっかけに、WP-CLIで似たような「数値かどうかで挙動が変わる」オプションが他にもないか、使っているコマンドを一通り見直しました。
幸い、他のコマンドで同じパターンの罠は見つかりませんでした。地味な作業でしたが、やっておいてよかったです。

それ以来、カテゴリを一括で割り当てるような作業の後は、必ずwp term list categoryで結果を確認するのを習慣にしています。
数十秒で終わる確認です。この一手間だけで、同じ事故はもう起きていません。

まとめ

今回いちばん怖かったのは、バグそのものより「成功と表示された」という一言に、すっかり油断していたことです。
CLIツールは、引数の型を親切に解釈してくれる便利さの裏返しとして、こちらの意図と違う解釈をされてもエラーという形では教えてくれないことがあります。

何かを一括操作するコマンドを叩いたときは、画面に出た結果のメッセージだけで安心せず、実際の一覧を見て確認するところまでを1セットにしておくと安心です。
地味で気づきにくい罠ほど、こういう一手間の有無で差が出ると、身をもって学びました。
たった1つのオプションの有無で、意図と正反対の結果になり得る。この当たり前のことを、改めて肝に銘じています。

この記事を書いた人

Web制作歴10年近く。WordPressのテーマカスタマイズやコーディングを中心に、副業・本業ともにweb制作に携わっています。このブログでは、実際に手を動かして分かったことを書いています。

Cat's Handをフォローする

この記事が参考になったら、応援クリックをお願いします

タイトルとURLをコピーしました