最近、WordPressのテーマを「JIN」から「SWELL」へ変更しました。
SWELL自体はとても気に入ったのですが、テーマを変更すると、過去の記事で使っていたJIN独自のブロックに表示崩れが発生しました。
特に問題になったのは、次のようなパーツです。
- 吹き出し
- 見出し付きボックス
- 通常のボックス
- アイコン付きボックス
- ボタン
- 余白や区切り線
- 箇条書き
- キャプション付きの装飾
- アフィリエイト広告
私のブログには約100記事あります。
これらを一つずつ編集画面で探して修正していたら、おそらく1週間はかかったでしょう。しかも、どこかに修正漏れが残っていた可能性も高いです。
そこで今回は、AIと相談しながら、SSHとCLI（コマンドライン）を使って記事を横断的に調査・変換しました。
結果として、大きな表示崩れはほぼ1日で修正できました。
まだ文字装飾などの小さな調整は残っていますが、テーマ移行で特に目立っていた崩れは解消できました。
この記事では、AIを使ってWordPressの記事をまとめて調査・修正した流れを紹介します。
なぜテーマ変更で表示が崩れるのか
JINからSWELLへ変更しても、記事の文章や画像がすべて消えるわけではありません。
問題になるのは、以前のテーマやプラグインが提供していた独自ブロックです。
例えば、記事データの中に次のような記述が残っていました。
<!-- wp:jin-gb-block/chat-block -->
これはJIN用の吹き出しブロックです。
新しいテーマであるSWELLは、このブロックを標準機能として持っていません。そのため、編集画面には「このサイトは、このブロックに対応していません」という警告が表示されます。
フロント側では、乗り換えサポート用プラグインによってある程度表示できる場合もあります。
ただし、次のような問題が起こることがあります。
- 吹き出しの位置がずれる
- ボックスのデザインが崩れる
- 編集画面でブロックを編集できない
- 古いテーマ用プラグインを停止できない
- 将来のWordPress更新で表示できなくなる可能性がある
そこで、古いJINブロックをSWELLのブロックへ置き換えることにしました。
AIが特に役立ったのは「記事を横断した調査」
WordPressの管理画面では、特定の独自ブロックを使っている記事をまとめて探すのが難しい場合があります。
今回、AIに相談しながらWordPressのデータベースを調査したところ、JINの独自ブロックが使われている記事を一覧化できました。
例えば、JINの「見出し付きボックス」が残っている記事は、PHPとWordPressのデータベース機能を使って検索できます。
php -r '
require "wp-load.php";
global $wpdb;
$rows = $wpdb->get_results(
"SELECT ID, post_title
FROM {$wpdb->posts}
WHERE post_type IN (\"post\", \"page\")
AND post_status NOT IN (\"trash\", \"auto-draft\")
AND post_content LIKE \"%jin-gb-block/box-with-headline%\"
ORDER BY ID"
);
echo "該当件数: " . count($rows) . PHP_EOL;
foreach ($rows as $row) {
echo $row->ID . "\t" . $row->post_title . PHP_EOL;
}
'
これにより、目視で100記事を開かなくても、問題のある記事だけを抽出できます。
今回の調査では、例えば次のような結果が得られました。
- JIN吹き出し：59記事
- JIN見出し付きボックス：31記事
- JIN通常ボックス：20記事
- SBDリスト：29記事
- SBD背景ブロック：23記事
一つの記事で複数種類のブロックを使っていることもあります。
単純に記事数を足すのではなく、重複を除いた対象記事数も確認できました。これはCLIで調査する大きなメリットです。
CLIとは？
CLIは「Command Line Interface」の略です。
黒い画面のターミナルにコマンドを入力して、コンピューターやサーバーを操作する方法です。
最初は難しそうに見えますが、今回私が行った基本操作は次の程度です。
cd ~/public_html/example.com
ls
php script-name.php --dry-run
php script-name.php --apply
cd：作業するフォルダへ移動するls：ファイルの一覧を表示する--dry-run：変更せずに結果だけ確認する--apply：実際に変更を適用する
コマンド自体を暗記する必要はありません。
AIに現在の画面や実行結果を見せながら、一つずつ次のコマンドを教えてもらいました。
ConoHa WINGへSSHで接続する
今回はConoHa WINGを利用しています。
ConoHaの管理画面でSSHを有効化し、秘密鍵をダウンロードしました。
まず、ダウンロードした秘密鍵の権限を変更します。
chmod 600 ~/Downloads/秘密鍵のファイル名.pem
次に、SSHでサーバーへ接続します。
ssh -i ~/Downloads/秘密鍵のファイル名.pem \
-p ポート番号 \
ユーザー名@ホスト名
初回接続時には、接続先が正しいかを確認するメッセージが表示されます。
ホスト名やフィンガープリントがConoHaの情報と一致していることを確認してから接続します。
なお、秘密鍵は絶対にブログやSNSへ掲載してはいけません。GitHubへアップロードするのも避けましょう。
WP-CLIがなくても作業できた
WordPressをCLIで操作するときは、通常「WP-CLI」というツールがよく使われます。
しかし、私のConoHa環境では次のように表示されました。
wp: command not found
つまり、WP-CLIが利用できない状態でした。
それでも、PHPからWordPress本体の wp-load.php を読み込むことで、データベースへアクセスできました。
require "wp-load.php";
global $wpdb;
この方法により、WP-CLIを追加インストールせずに記事を検索・変換できました。
ただし、wp-load.php があるWordPressのルートディレクトリで実行する必要があります。
別のフォルダで実行すると、次のようなエラーになります。
Warning: require(wp-load.php): failed to open stream
その場合は、WordPressが入っているディレクトリへ移動します。
cd ~/public_html/example.com
最初に必ずバックアップを取る
記事の一括変換では、データベースの内容を直接更新します。
そのため、作業前のバックアップは必須です。
今回は対象となる記事のID、タイトル、本文などをJSONファイルとして保存しました。
保存件数: 63
保存先: /home/ユーザー名/jin-block-backup-日時.json
さらに、サーバーに保存したバックアップを自分のパソコンへダウンロードしました。
これはサーバーではなく、ローカルパソコン側のターミナルで実行します。
scp -i ~/Downloads/秘密鍵のファイル名.pem \
-P ポート番号 \
ユーザー名@ホスト名:/home/ユーザー名/バックアップ.json \
~/Downloads/
ダウンロード後は、サーバー側とパソコン側でSHA-256を確認しました。
sha256sum /home/ユーザー名/バックアップ.json
sha256sum ~/Downloads/バックアップ.json
両方の値が一致していれば、ファイルが正しくコピーされています。
可能であれば、これとは別にConoHa側のバックアップや、WordPress全体のバックアップも用意した方が安全です。
いきなり一括変換しない
今回の作業で最も重要だったのは、次の手順を守ることでした。
- 対象記事を検索する
- バックアップを取る
- Dry Runで変換結果を確認する
- 1記事だけ変換する
- 実際のページと編集画面を目視確認する
- 残りの記事へ一括適用する
- もう一度Dry Runを実行する
- 古いブロックが残っていないか最終監査する
例えば、変換スクリプトは最初に次のように実行しました。
php conversion-script.php --dry-run
Dry Runではデータベースを変更せず、次の情報だけを表示します。
Mode: DRY RUN
Posts: 31
Convertible: 47
Unrecognized: 0
Old blocks remaining: 0
Dry run completed. Nothing was written to the database.
ここで特に重要なのが、次の2項目です。
Unrecognized: 0
Old blocks remaining: 0
変換できないブロックや変換後も残るブロックがある場合は、適用を中止する安全装置を入れました。
実際に、特殊な構造を持つボックスが見つかったときは、次のように処理を止めることができました。
Safety check failed. Nothing was written.
この場合は無理に一括変換せず、その記事だけ手動で直しました。
まず1記事だけ変換して確認する
Dry Runが成功しても、いきなり全記事へ適用するのは避けました。
まず、記事IDを指定して1記事だけ変換します。
php conversion-script.php --apply --post-id=3917
変換後は、次の両方を確認します。
- 公開ページの見た目
- WordPress編集画面のブロック構造
問題がなければ、残りの記事へ適用します。
php conversion-script.php --apply
適用時にも、変更直前の本文を別のバックアップファイルへ保存する仕組みにしました。
AIへ何を頼んだのか
AIには、単に「全部直して」と頼んだわけではありません。
主に次の作業を一緒に進めました。
- エラー画面や表示崩れの原因を推測する
- WordPress内の対象ブロックを検索するコマンドを作る
- 対象記事の一覧を出す
- 旧ブロックのHTML構造を分析する
- SWELLのブロック形式と比較する
- Dry Run対応の変換スクリプトを作る
- 記事単位で試験できるようにする
- 更新前の自動バックアップを作る
- 変換できない形式があれば処理を止める
- 変換後に古いブロックが残っていないか再調査する
- 実行結果を見ながら次の作業を判断する
特に便利だったのは、ターミナルの出力をそのままAIへ貼り付けられることです。
エラーが出ても、その出力を見せれば、次に確認すべきことや実行するコマンドを提案してもらえました。
AIを使っても人間の目視確認は必要
AIとスクリプトを使えば、多数の記事を効率よく変換できます。
しかし、最終的な見た目まで完全に自動判定できるわけではありません。
今回も、次のような箇所は目視で確認しました。
- 吹き出しの左右
- ボックス内の改行
- 複雑な入れ子構造
- ボタンのリンク先
- アフィリエイト広告の表示
- スマートフォンでの見え方
- 編集画面で正常なブロックとして認識されるか
AIは大量のデータを探し、規則的に変換するのが得意です。
一方で、読者から見て自然かどうかを判断するのは人間の役割です。
「AIにすべて任せる」のではなく、「AIに調査と反復作業を任せ、最終確認は自分で行う」という使い方が適していると感じました。
100記事を手動で直すより圧倒的に速かった
もし100記事を一つずつ開き、表示崩れを探して、手作業で直していたら、少なくとも1週間はかかったと思います。
さらに、次のような問題も起こったはずです。
- 問題のある記事を見落とす
- 同じ修正を何度も繰り返す
- 間違った場所を編集する
- 修正前の状態へ戻せなくなる
- 作業途中でどこまで終わったか分からなくなる
今回はAIと会話しながら、対象の検索、変換、検証を順番に進めたため、大きな表示崩れは1日でほぼ解消できました。
特に、記事を横断して同じ種類の問題を探す作業では、AIとCLIの組み合わせが非常に役立ちました。
まとめ
JINからSWELLへの移行では、古い独自ブロックによる表示崩れが発生しました。
しかし、AIとCLIを組み合わせることで、次の作業を効率化できました。
- 問題のある記事をブログ全体から検索
- ブロックの種類と個数を集計
- 旧ブロックをSWELL形式へ変換
- 変換前の自動バックアップ
- 1記事だけの試験変換
- 記事をまたいだ一括変換
- 変換後の残存チェック
- 想定外のデータがある場合の自動停止
約100記事を手動で修正すれば、1週間はかかったと思います。しかも、おそらく何らかの取りこぼしが発生していました。
AIと相談しながら進めたことで、大きな表示崩れは1日でほぼ修正できました。
まだ古い文字装飾などの小さな調整は残っていますが、記事を読むうえで目立つ問題を短時間で解消できたのは大きな成果でした。
WordPressのテーマ移行で多数の記事に同じ問題が発生した場合、AIとCLIを使った横断的な修正は非常に有効です。
黒いターミナル画面を見ると難しそうに感じますが、コマンドを一つずつ確認しながら進めれば、専門のエンジニアでなくても取り組めます。
ただし、バックアップ、Dry Run、1記事テスト、目視確認の4つは必ず行いましょう。
AIに大量の調査と反復作業を手伝ってもらい、人間が安全性と最終的な見た目を確認する。
この分担が、WordPressの大規模な修正にとても向いていると感じました。
コメント