“WordPress 7.1 対応でプラグインを更新した話と、rsync –delete で危うくハマりかけた件”

WordPress 7.1「Mary Lou」が 8/19 にリリースされました。

公開しているプラグイン Sinqwell Event Post Manager を 7.1 で動作確認して、
v1.1.4 としてリリースしたので、その記録を残しておきます。

個人開発なので手順を忘れがちなのですが、今回ちょっと危ない落とし穴に
気づいたので、そこも含めて書いておきます。

今回直したところ

1. クイック編集の権限チェックを追加した(いちばん大事)

投稿一覧の「クイック編集」で会場・料金・時間を編集できるようにしているのですが、
保存処理のチェックが甘いままでした。

追加したのは 3 つです。

• nonce の検証 — フォームが本当に自分のサイトから送られたものか確認する
• current_user_can('edit_post', $post_id) — そのユーザーがその投稿を
  編集していい権限を持っているか確認する
• wp_is_post_revision() — リビジョン(自動保存の履歴)に対して
  誤って保存処理が走らないようにする

このあたりは「動いているから大丈夫」と思って後回しにしがちなのですが、
チェックが無いと、権限のないユーザーがリクエストを直接投げるだけで
データを書き換えられてしまう可能性があります。

WordPress.org には Plugin Check という公式のチェックプラグインがあって、
こういう警告を教えてくれます。今回はそれを掛けて、警告がゼロになるまで直しました。
公開しているプラグインがある方は一度走らせてみるといいと思います。

2. CSS の読み込み方を変えた

イベントの個別ページで投稿日を隠す CSS を、これまで wp-block-library に
ぶら下げる形で読み込んでいました。

ただこれ、WordPress 側の都合で wp-block-library が読み込まれなくなると
CSS ごと消えてしまいます。実際、バージョンが上がるたびにブロック関連の
読み込み方は変わっていくので、他人のハンドルに相乗りするのは危ういです。

なので sinqwell-event-single という独立したハンドルを作って、
そちらから読み込むように変更しました。

他のプラグインやコアのハンドルに依存させない。 地味ですが大事だと思います。

3. 掃除

shortcode.php.bak と .DS_Store をリポジトリから削除して、.gitignore を追加しました。

.bak が残っているのは、実はけっこう危険です。.php.bak は PHP として
実行されないので、URL を直接叩かれるとソースコードが平文で見えてしまいます。
DB の情報やロジックが書いてあったら、そのまま読まれます。

バックアップを取るときは、リポジトリの外に置きましょう。

ハマりかけた話 — rsync --exclude と --delete は仲が悪い

WordPress.org へのリリースは SVN です。GitHub で開発して、
リリース時に SVN の trunk/ へ rsync で同期しています。

こんな感じのコマンドです。

rsync -av --delete \
  --exclude='.git' --exclude='.gitignore' --exclude='.DS_Store' \
  --exclude='*.bak' \
  ~/wordpress/sinqwell-event-post-manager/ trunk/

--delete があるので「ローカルに無いファイルは SVN 側からも消える」と
思っていたのですが、違いました。

--exclude で除外したファイルは、--delete の削除対象からも外れる

つまり、前のバージョンの trunk/ に shortcode.php.bak が残っていた場合、
このコマンドを実行しても 消えずにそのまま残り続ける ということです。
そして次のリリースでも、その次でも、ずっと公開されたままになります。

まさに今回消したかったファイルが、コマンドの書き方のせいで消えない。
なかなか気づきにくい罠だと思います。

今回は幸い SVN 側には元から入っていなかったのですが、リリース前に
確認する手順を足すことにしました。

find trunk -name '*.bak' -o -name '.DS_Store'

これで何も出なければ OK。出てきたら svn rm で個別に消します。

リリース前にやっておくと安心なこと

--dry-run を必ず挟む

--delete が付いたコマンドは、書き間違えると一瞬でファイルが消えます。
同期元のパスを間違えただけで trunk が空になる、なんてこともあり得ます。

rsync -av --dry-run --delete ...

--dry-run を付ければ実際には何も起きず、「何が転送されて何が消えるか」だけを
見せてくれます。deleting の行に消えては困るものが無いか確認してから、
--dry-run を外して本番実行。この一手間で事故は防げます。

バージョン番号は 2 箇所ある

• プラグイン本体のヘッダの Version:
• readme.txt の Stable tag:

WordPress.org はこの両方を見ています。片方だけ上げても、利用者の管理画面に
更新通知が出ません。コミット前に必ず両方を確認します。

grep -n '^ \* Version:' trunk/プラグイン名.php
grep -E 'Stable tag|Tested up to' trunk/readme.txt

コミットは 1 回にまとめる

svn cp trunk tags/1.1.4 してから、trunk と tags をまとめて 1 回でコミットします。
分けてコミットすると、そのたびに全バージョンの zip が再生成されて
サーバーに無駄な負荷がかかります。

おわりに

無事 1.1.4 が公開されました。

セキュリティまわりの修正は、直しても見た目は何も変わりません。
「今日は何も進んでいない気がする」という日になりがちですが、
こういうところを放っておくと、あとで一番困ることになります。

7.1 での動作確認も全項目 OK でした。しばらく様子を見ようと思います。