この原因の多くは、メディアにおいて画像ファイルをアップロードする際に、WEBP など別のファイル形式を生成する処理を wp_generate_attachment_metadata hook で行うような実装をしているためである。
この hook は、文字どおり画像のメタデータを生成するものだが、これはファイルアップロード時のみに発火する hook ではなく、カスタマイザーなどの画面でも発生する。
具体的にはスターターコンテンツに attachments が登録されているテーマにおいて、fresh_site が 1 に設定されているテーマカスタマイザーの画面である。
なぜこの画面で wp_generate_attachment_metadata hook が発火しているかというと、「公開する」ボタン押下の前にファイルIDや保存するファイル情報を事前にDBに書き込んでいるからである。
これは /wp-admin/includes/media.php の media_handle_sideload() の処理において、wp_insert_attachment() の第4引数の $fire_after_hooks に true を設定することで、wp_insert_post() の第3引数 $fire_after_hooks に引き継がれ、投稿情報とその関連情報の保存後に wp_after_insert_post() 関数を呼び出しており、wp_after_insert_post() という投稿情報を保存した後にアクションを実行する関数により実装されている。
// WP 6.0 の /wp-admin/includes/media.php 506行目
// Save the attachment metadata.
$attachment_id = wp_insert_attachment( $attachment, $file, $post_id, true );
if ( ! is_wp_error( $attachment_id ) ) {
wp_update_attachment_metadata( $attachment_id, wp_generate_attachment_metadata( $attachment_id, $file ) );
}DBのwp_post の連番に謎の更新があったりするのは、だいたい wp_after_insert_post() が原因である。
この原因が判明するのにかなり時間がかかった。
そもそも wp_generate_attachment_metadata hook で別の画像ファイル形式をやめたほうがいいし、名前的にもするべきでないのは明白だが、wp no plugin generate webp などで調べたときに、だいたいこのような処理が出てくる。
かなりレアケースだが、注意したほうがいい。
なお、有名なプラグインがこの現象を回避しており、webp-express は wp_handle_upload、image_make_intermediate_size、wp_delete_file で諸々の処理を行っているようだ。