WordPressプラグイン『Search Regex』で記事内の文字列を、正規表現を用いて検索＆一括置換した際の設定・備忘録記事です。
記事内（投稿ページ）のショートコードの内容を書き換えるために、記事の内容を一括置換できるプラグイン『Search Regex』を利用しました。
置換したいショートコードが含まれる記事は100以上。対象のショートコードには一定の型があるものの、中身の文字列はそれぞれに違うため、正規表現を使って検索（抽出）＆一括置換しました。
Search Regexは以前にも使ったことがあるのですが、すっかり使い方を忘れていました。
基本情報
Search Regexについて
『Search Regex』は、「投稿・固定ページ・カスタム投稿タイプ・その他」に関わる諸々のデータを検索＆一括置換できるWordPresプラグイン。
複数の記事に含まれる特定の文字列をまとめて検索（抽出）して、別の文字列に全部まとめて書き換える、といったことができる。
検索には正規表現を使うこともできるので、柔軟に文字列を抽出することができる。
手作業では手間がかかりすぎる修正を一発でまとめて出来ちゃう感じです。
100以上の記事の内容を手動で書き換えるとか無理なんで、めっちゃ助かります😂
目的・事情
記事内に設置しているテーマ『Cocoon』の機能「Amazon商品リンク」のショートコードをまとめて書き換えた。
時期や以前の挙動を正確に把握できていないが、以前はショートコード単体でキャッシュされていたと思われるAmazon商品リンクが、LiteSpeed Cacheのページキャッシュに取り込まれて一括りにキャッシュされていた。
いずれにしても、Amazon商品リンクが適切にキャッシュされない状況になっていた。そこで、LiteSpeed CacheのESI機能を使って、Amazon商品リンクをページキャッシュから除外し、テーマ側（Cocoon）のショートコード用のキャッシュ設定が適用されることを狙った。
- WordPress：6.2.2
- テーマ：Cocoon 2.6.4.10
- Search Regex：3.0.6
- WP Last Modified Info：1.8.8
- LiteSpeed Cache：5.6
CocoonのAmazon商品リンクのショートコードをESIブロック化したところ、キャッシュが設定期間どおり正常に更新されるようになったぽいです（様子見中🤔）。
基本的な使い方
Search Regexの基本的な使い方について。
置換対象を確認する
Search Regexの画面には「管理画面→ツール→Search Regex」からアクセス。
まずは、置換対象となる記事や文字列の数を確認するために検索機能のみを利用する。
プラグインのデフォルト設定で「投稿（通常の記事）」と「固定ページ」の内容だけを検索する場合は以下のようになる。
- 入力と絞り込み
- 入力：投稿（コア＆カスタム）
- 絞り込み：「投稿タイプ」+「に含む」+「投稿、固定ページ」
- 検索（設定項目）
- 任意の文字列
- 検索（検索の実行ボタン）
- 検索した文字列が含まれる投稿・固定ページとその内容の一覧が表示される
- 該当の文字列がハイライトされるので分かりやすい
実際の置換処理を行わずに対象になる記事や文字列の数を把握できます。
条件が違う場合は「操作・フラグ・置換・結果表示数」など各種設定の変更が必要になります。
一括置換する
実際に置換する場合は以下のような流れになる。
- 入力と絞り込み
- 入力：投稿、コメント、ユーザーなど対象を選択
- 絞り込み：各対象の種類と範囲を指定
- 追加ボタンで条件を追加できる
- 検索（設定項目）
- 置換対象となる文字列を入力
- フラグ
- 「正規表現、大小文字の区別なし、複数行」を任意でチェック
- 操作
- 「操作なし」「全体の文字列を置換」「一致項目を修正/エクスポート/削除」「アクションを実行」から選択
- 置換の場合は「全体の文字列を置換」
- とりあえず検索結果だけ見たい場合は「操作なし」
- 置換
- 置換用の文字列を入力
- 右側にあるプルダウンメニューから「単一行/複数行/削除」を選択
- 結果表示数
- お好みで選択
- 「列を表示」のメニューから表示する列を選択できる
- 検索（検索の実行ボタン）
- 置換した際のプレビューが表示される
- 検索ボタンを押しただけでは置換処理は行われない
- すべて置換
- 置換処理が実行される
置換完了
進行状況が100％に達すれば置換処理が完了。
大量の記事の内容を一発で書き換えられるので便利です。
更新日が更新されるのを防ぐ
下準備その1。
Search Regexを実行すると、対象となる記事の更新日が更新されていた。記事の内容を書き換えるのだから当然といえば当然だけど。
当サイトでの記事の”更新日”は「記事の内容（コンテンツ）がある程度以上の規模で追加・変更された日」であるため、サイト管理上のメンテナンスでの”更新”では”更新日”を変更しない。
プラグイン『WP Last Modified Info』の「全記事の更新日変更を無効にする」機能で対処した。
「管理画面→設定→WP Last Modified Info→ツール→更新無効オプションの切り替え」で「すべてオンにする」ボタンを押す（これは『更新日の変更を無効にする機能を有効にする』の意）。
処理は数秒で完了した。
記事の一覧ページでの表示を更新日順にしているので、記事内容の微修正で並び順が変わるのも都合が悪かったのです。
”更新日の変更をロックする”この機能は、各記事のエディターページや投稿一覧などから個別・一括で解除出来ます。
メモリ上限とタイムアウト
下準備その2。
PHPメモリ上限とタイムアウト設定について。
ある程度以上のメモリや時間を必要とする処理を実行する場合に問題になりやすいので、メモリ上限とタイムアウト時間を一時的に引き上げてからSearch Regexを実行した。
サーバーの管理ソフトがcPanelなら「MultiPHP INI Editor」で簡単に変更できます。
目安となる値はケースバイケースでしょうからよく分かりません。とりあえずメモリ2GB、タイムアウト1800秒にして試してみました。
ショートコードを置換する
CocoonのAmazon商品リンクのショートコードに、LiteSpeed CacheのESIブロック用のコードを追加した。置換対象となるショートコードの数（行）は181となっていた。
検索設定は、
(esi amazon asin=".+" kw=".+" ttl="0")置換設定は、
esi $1 ttl="0"ショートコードの前後に「esi 」と「 ttl=”0″」を追加した。
エラー
置換処理を実行し始めて6分後くらいにエラーが表示された。
処理がどうなったのか再度検索して確かめたところ、置換自体は完了していた。
エラーの原因となるものには、他のプラグインやキャッシュ（ページキャッシュ）などがあるらしい。
置換対象数を10に減らして同じ条件で試してみたところ、上記エラーは発生しなかった（全てのプラグイン有効、LiteSpeed Cacheのページキャッシュも有効な状態）。
泥沼っぽいので、何が原因なのかは深掘りしませんでした。
とりあえず、置換対象数を少なくして実行すればエラーは起きないようです。
一度に置換する数を減らす
対象範囲を絞り込むことで一度に置換する数を減らせる。
絞り込みに使えるのは投稿に関する諸々の要素「ID、タイトル、スラッグ、本文、投稿者、日時、カテゴリー、タグ、etc…」と多種。
日時・カテゴリーあたりで絞り込んでやれば数十単位で置換しやすいと思われる。
エラーが出たりもしましたが、ひとまず無事に目的の一括置換ができました👍
